Accounting Events

Accounting events are the bridge between business transactions in AR and AP and the subledger journal entries that record their financial effect. Events are raised automatically by database triggers whenever a transaction reaches a milestone — there is no manual step.

Event classes

Each accounting event is categorised by an event class that identifies what happened. The event class determines which journal lines fsl_create_accounting will generate.

AR event classes

Event class	Trigger point	What it records
AR_INVOICE	Transaction status → FINAL (type INVOICE or DEBIT_MEMO)	Revenue recognition and the receivable
AR_CREDIT_MEMO	Transaction status → FINAL (type CREDIT_MEMO)	Reversal of revenue and reduction of the receivable
AR_RECEIPT	Cash receipt created	Cash received and unapplied balance
AR_RECEIPT_APPLICATION	Receipt schedule created (receipt linked to a transaction)	Application of cash against the receivable, with realised FX gain/loss
AR_RECEIPT_REVERSAL	Receipt status → REV	Reversal of the original receipt

AP event classes

Event class	Trigger point	What it records
AP_INVOICE	Transaction status → VALIDATED	Expense recognition and the payable
AP_PAYMENT	Payment schedule amount applied increases	Cash disbursement against the payable, with realised FX gain/loss
AP_PAYMENT_VOID	Payment schedule amount applied decreases	Reversal of a prior payment

How events are raised

Events are raised by database triggers on AR and AP tables. The triggers fire automatically — application code does not need to call any accounting function.

AR triggers

Trigger	Fires on	Condition
fsl_ar_invoice_event_tg	t_far_customer_transaction_headers AFTER UPDATE of transaction_status	New status is FINAL
fsl_ar_receipt_event_tg	t_far_cash_receipts AFTER INSERT	Every new receipt
fsl_ar_receipt_application_event_tg	t_far_receipt_schedules AFTER INSERT	Every new receipt schedule (links receipt to transaction)
fsl_ar_receipt_reversal_event_tg	t_far_cash_receipts AFTER UPDATE of receipt_status	New status is REV

AP triggers

Trigger	Fires on	Condition
fsl_ap_invoice_event_tg	t_fap_supplier_transaction_headers AFTER UPDATE of transaction_status	New status is VALIDATED
fsl_ap_payment_event_tg	t_fap_payment_schedules AFTER UPDATE of amount_applied	Amount applied changes — increase raises AP_PAYMENT, decrease raises AP_PAYMENT_VOID

What each trigger records

Every trigger creates one row in t_fsl_accounting_events with:

• event_class_code — the event class (e.g. AR_INVOICE)
• source_table — FAR or FAP
• source_header_id — the AR or AP transaction header ID
• ledger_id — resolved from the organisation's ledger
• accounting_date — typically the transaction date or receipt date
• entered_currency_code — the transaction currency
• exchange_rate_type and exchange_rate — from the source transaction, defaulting to CORPORATE
• status — always UNPROCESSED

Event statuses

Status	Meaning
UNPROCESSED	The event has been raised but not yet turned into a journal entry
PROCESSED	fsl_create_accounting has successfully created a journal entry for this event
ERROR	Processing failed; the error_text field contains the error message

Events move from UNPROCESSED to either PROCESSED or ERROR. An ERROR event can be retried after the underlying issue is resolved.

Relationship to tax calculation

Tax calculation happens before accounting events are raised. The FTX triggers fire on BEFORE UPDATE (calculating tax lines), while the FSL triggers fire on AFTER UPDATE (creating accounting events). This means tax lines are always available when fsl_create_accounting runs.

See Tax Calculation for details on how tax lines are generated.

Further reading

• Data Model — how events fit into the broader subledger data model
• Account Derivation — how GL accounts are resolved for journal lines
• Create Accounting and Transfer to GL — how events are processed into journal entries