Skip to main content

Create Accounting and Transfer to GL

Once accounting events have been raised by AR and AP triggers, two operations turn them into posted GL entries: Create Accounting processes events into balanced subledger journal entries, and Transfer to GL copies those entries into GL journal batches.

Create Accounting​

The fsl_create_accounting function processes a single UNPROCESSED accounting event. It:

  1. Creates a DRAFT subledger journal entry linked to the event's ledger and period
  2. Generates debit and credit lines based on the event class
  3. Derives the GL account for each line using the account derivation engine
  4. Converts entered amounts to the ledger's functional currency using the event's exchange rate
  5. Verifies that total accounted debits equal total accounted credits
  6. Sets the entry to FINAL and the event to PROCESSED

If any step fails, the draft entry is removed and the event is set to ERROR with a diagnostic message.

Journal lines by event class​

AR_INVOICE (and AR debit memos)​

Line typeSideAmount source
REVENUECREach transaction line's extended transaction price
TAX_LIABILITYCREach tax line's tax amount
RECEIVABLEDRBalancing total (sum of revenue + tax)

AR_CREDIT_MEMO​

The same lines as AR_INVOICE but with reversed sides — revenue is debited, tax liability is debited, and the receivable is credited.

AR_RECEIPT​

Line typeSideAmount source
CASHDRReceipt amount
UNAPPLIEDCRReceipt amount

AR_RECEIPT_REVERSAL​

The reverse of AR_RECEIPT — unapplied is debited and cash is credited.

AR_RECEIPT_APPLICATION​

Line typeSideAmount source
UNAPPLIEDDRReceipt amount at the receipt's exchange rate
RECEIVABLECRInvoice amount at the invoice's exchange rate
REALISED_GAINCRIf the functional-currency receipt amount exceeds the receivable amount
REALISED_LOSSDRIf the functional-currency receipt amount is less than the receivable amount

The realised gain or loss arises when the exchange rate at the time of receipt differs from the rate at the time of invoicing. See Realised gain and loss below.

AP_INVOICE​

Line typeSideAmount source
EXPENSEDREach transaction line's extended transaction price
TAX_RECOVERABLEDREach tax line's recoverable amount
EXPENSEDREach tax line's non-recoverable amount
PAYABLECRBalancing total (sum of expense + all tax)

For tax lines where the tax is partially or fully recoverable, the recoverable portion posts to TAX_RECOVERABLE and the non-recoverable portion posts to EXPENSE. When the tax is not recoverable at all, the entire tax amount posts to EXPENSE.

AP_PAYMENT​

Line typeSideAmount source
PAYABLEDRInvoice amount at the invoice's exchange rate
CASHCRPayment amount at the payment's exchange rate
REALISED_GAINCRIf functional-currency payment is less than the payable
REALISED_LOSSDRIf functional-currency payment is more than the payable

AP_PAYMENT_VOID​

The reverse of AP_PAYMENT — payable is credited, cash is debited, and any gain/loss is reversed.

Realised gain and loss​

Realised FX gain or loss occurs when a transaction is settled in a different currency environment than when it was created. The system calculates it as the difference between:

  • The accounted amount of the settlement (receipt or payment converted at the settlement exchange rate)
  • The accounted amount of the obligation (receivable or payable converted at the original transaction exchange rate)

If the settlement yields more functional currency than the obligation, a realised gain (credit) is recorded. If it yields less, a realised loss (debit) is recorded. For same-currency transactions, the gain/loss is zero and no gain/loss line is created.

Batch processing​

The fsl_create_accounting_pending function processes all UNPROCESSED events for a given ledger and period in a single call. It iterates over each event and calls fsl_create_accounting individually, returning the count of events processed. This is the function invoked by the fsl-create-accounting lambda during the month-end sequence.

Transfer to GL​

The fsl_transfer_to_gl function copies FINAL subledger journal entries into GL journal batches. It:

  1. Verifies the AR or AP period is OPEN for the specified ledger and period
  2. Creates a new GL journal batch with source set to RECEIVABLES (for AR) or PAYABLES (for AP)
  3. Creates one GL journal header per subledger entry, mapping the event class to a GL journal category:
    • AR_INVOICE, AR_CREDIT_MEMO → SALES_INVOICES
    • AR_RECEIPT, AR_RECEIPT_APPLICATION, AR_RECEIPT_REVERSAL → RECEIPTS
    • AP_INVOICE → PURCHASE_INVOICES
    • AP_PAYMENT, AP_PAYMENT_VOID → PAYMENTS
  4. Copies each subledger journal line to a GL journal line, preserving the link via fsl_journal_entry_id and fsl_journal_line_id
  5. Marks each subledger entry as TRANSFERRED
  6. Optionally posts the GL batch immediately if the p_post parameter is TRUE

Month-end sequence​

The typical month-end closing sequence is:

  1. Create accounting — process all pending AR and AP events for the period (fsl_create_accounting_pending)
  2. Transfer AR to GL — transfer all finalised AR subledger entries to GL (fsl_transfer_to_gl with application code AR)
  3. Transfer AP to GL — transfer all finalised AP subledger entries to GL (fsl_transfer_to_gl with application code AP)
  4. Post GL batches — post the transferred batches to update GL balances (fgl_post_batch)
  5. Close AR period — close the AR period for the ledger (fgl_close_period with AR)
  6. Close AP period — close the AP period for the ledger (fgl_close_period with AP)
  7. Close GL period — close the GL period (fgl_close_period with GL); requires AR and AP to be closed first

Pre-close checks​

Period close enforces prerequisites:

  • AR/AP close refuses if any UNPROCESSED or ERROR accounting events exist for the period
  • AR/AP close refuses if any DRAFT or FINAL (untransferred) subledger entries exist for the period
  • GL close refuses if any unposted GL journal headers exist for the period
  • GL close requires AR and AP to be CLOSED, PERMANENTLY_CLOSED, or NEVER_OPENED

Further reading​