The Ledger as System of Record

The general ledger holds the double-entry record of what the business has done. The design decision worth stating plainly is its direction of travel: the ledger is the system of record, and external accounting packages feed into it. Xero, QuickBooks, Sage and your bank are sources. They are not the destination.

Why that direction

The usual arrangement — an operational system that exports to an accounts package which then becomes the truth — leaves you with two sets of books and a reconciliation problem. Questions like "why does the sales figure in the report not match the accounts?" are then permanent, because the two systems genuinely disagree and neither is wrong.

Making the ledger the destination removes the second set of books. Operational documents post into it, feeds bring external transactions into it, and a report and a trial balance are answering from the same data.

What a journal is

A journal is a balanced set of lines, each debiting or crediting an account, belonging to an entity and dated to a period. Nothing posts unbalanced. A journal may be created by hand, generated when a document reaches a status, or produced by a bank feed.

Posted journals are immutable

Once posted, a journal cannot be edited or deleted. A correction is a reversing entry — a second journal that undoes the first — followed by the correct posting.

Users sometimes find this frustrating, and it is worth explaining rather than defending. The alternative is a system where last month's reported figures can change after they were reported, which makes every historical statement provisional. The reversing entry leaves the mistake and the correction both visible, which is what an audit expects to see.

Nothing double-posts

Every journal carries a unique key derived from what caused it. If a webhook is redelivered, a scheduled task retried, or a feed cursor overlaps, the second attempt is recognised as the same event and does not post again. Duplicated postings are the classic failure of integrations that retry, and it is prevented structurally rather than by hoping retries do not happen.

Getting started

Set up your chart of accounts and your entities first, then decide which documents post and at which status. Post at the point the business considers the transaction real — usually approval or despatch, rarely draft.