Journal Register — every posted transaction in one list

One row per posted transaction in a period — every invoice, receipt, purchase, payment, journal, transfer, or refund shows up as a single line with its debit total, credit total, and the difference between the two.

The main use is a fast audit-quality scan: if any transaction's debit doesn't equal its credit, something posted wrongly and the row shows up red. Also useful for tracing a specific document ("what did that invoice actually post?") without opening it.

Before you start

• You need Ledger Reports permission (same access that opens the General Ledger and Day Book).
• Every row is a source document, not a single Ledger line — one invoice is one row here, even though it typically posts 3–4 legs.
• The Difference column should always be zero for a healthy transaction. A non-zero value means the posting is broken.

Steps

1. Open Reports → Journal Register.
2. Pick a From / To date. Defaults to the last month.
3. Optional: pick a Module to narrow to one type — e.g. Invoice for every sale in the period, PayBill for every supplier payment.
4. Scan the Δ column at the right. Zero (green dash) means balanced; any number in red means unbalanced.
5. Click a row's #Ref ID to open the General Ledger view — from there you can see the individual Ledger legs and open the source document.
6. Export → Excel produces a filterable spreadsheet for auditors.

Tips

• The Legs column counts how many Ledger rows the transaction wrote. A number below 2 (highlighted red) is suspicious — a valid posting needs at least a debit and a credit.
• Grand totals at the bottom always tie across the whole set — their Δ column is a health check for the period as a whole.
• Sort defaults to newest first. Click a column header (in exported Excel) to sort otherwise.
• The Description column is a sample from one of the transaction's Ledger legs — enough to recognise the doc but the definitive description lives on the source itself.

Common problems

• Red rows with non-zero Δ — a broken posting. Common causes: a trigger was disabled during a manual SQL edit, a partial refund flow didn't rebalance, or someone edited a locked field. Cross-check against Ledger Diagnostics which does the same check across the whole database rather than a single period.
• "Legs = 1" — a document that posted only one side of a journal. Almost always a bug. Fix by re-posting the source document (open it, save it) or by asking support to investigate.
• Grand totals don't tie — every unbalanced row contributes to the grand difference. Once the individual red rows are fixed, the grand totals will tie automatically.
• Missing transactions you expected to see — the report is date-bounded by Ledger.TransactionDate, which is the posting date, not the source document's own date. If a stay-arrival invoice posted on the day of check-in but has an issue-date a week earlier, it shows up on the posting date here.