The reports
Finance → Reports produces five:
| Report | What it shows |
|---|---|
| Summary trial balance | Every account with its debit and credit totals. The first check that the ledger balances. |
| Trial balance by GL account | The same for a single account, drilled into its lines. |
| Income statement | Revenue and expenses for a period. |
| Balance sheet | Assets, liabilities and equity at a point in time. |
| Bank reconciliation | Ledger against bank statement. |
Reading them in order
When something looks wrong, work top down:
- Summary trial balance — does the ledger balance at all, and does anything sit on the wrong side of its normal balance?
- Trial balance by account — for the account that looks odd, what are the actual lines?
- The journal line — which posting rule produced it? See Posting rules.
An account showing a balance opposite to its normal side is the single most useful signal on the trial balance. It usually means either a posting rule with the Dr/Cr reversed, or an account typed wrongly — see The chart of accounts.
The bank reconciliation report
This one is a control rather than a statement: it compares the ledger to the bank and shows what does not agree. Run it every period. Two patterns to watch:
- Statement lines with no ledger entry — a transaction you never recorded.
- Ledger entries with no statement line — something you recorded that the bank never saw. Old ones are usually a duplicate or a payment that failed.
See Bank, treasury and cheques.
Before reporting a period
- All invoices for the period are issued.
- All vendor invoices are entered — see Vendor invoices.
- Charge lines awaiting cost are cleared or accrued — see Quotation charge lines and closed periods.
- Bank accounts are reconciled.
- The period is closed, so the numbers cannot subsequently move.
The event log
Finance → Event log shows the events the finance system has received from the rest of the platform — an invoice issued, a cheque updated, a custody payment processed — and what happened to each.
| Field | Notes |
|---|---|
| Key | Composite of source and identifier. |
| Source | Which part of the system raised it. |
| Status | See below. |
| Attempt count | How many times processing was tried. |
| Errors | Each attempt's error, with the time it occurred. |
| Metadata | Context about the event. |
| Result | The outcome. |
Status
| Status | Meaning |
|---|---|
| Processing | In flight. |
| Processed | Done. |
| Failed | Processing failed. |
| Manual intervention | Parked, awaiting a person. |
Failed and manual intervention can both be retried from this screen. Processing and processed cannot — one is still running and the other is already done.
This is where a missing journal is explained
If an invoice was issued and no journal appeared, the event log is the first place to look, and it usually answers the question outright:
- No event at all — the originating action did not raise one. The problem is upstream, not in finance.
- Failed — the error list says why. Fix the cause, then retry.
- Manual intervention — the system deliberately stopped, because processing needed a decision it could not make.
- Processed, but no journal — the event was handled and no posting rule matched it. Go to Posting rules and work down the checklist there.
Retrying safely
Retry after fixing the cause, not before. A retry re-runs the same processing against the same event; if the underlying configuration is still wrong, it fails again and adds another attempt to the list.
Do not let failures accumulate. A backlog in the event log means the ledger is incomplete, and every report drawn from it is understated by an amount nobody has quantified.
Last updated 13 September 2026