The Ledger and Chart of Accounts
The general ledger holds the double-entry record of what the business has done. The design decision worth stating plainly: the ledger is the system of record, and external accounting packages feed into it. Xero, QuickBooks, Sage and your bank are sources, not the destination.
Where to find it
Architect Panel → ERP - Finance:
- Ledger — the console — trial balance, account enquiry, posting
- Chart of Accounts — your account codes and their types
- Journals — every posted journal and its lines
- Tax Codes — rates and the accounts tax posts to
- Posting Rules — which document event produces which posting
Why that direction
The usual arrangement — an operational system exporting to an accounts package which then becomes the truth — leaves two sets of books and a permanent reconciliation problem.
"Why does the sales figure in the report not match the accounts?" has no good answer when the two genuinely disagree and neither is wrong. Making the ledger the destination removes the second set of books entirely.
Setting up the chart
Enter your codes with their account type — asset, liability, income, expense, capital. The type is what lets the ledger produce a balance sheet and a profit and loss without being told which account belongs where.
Keep the chart as small as the business genuinely needs. An account per customer is what the subledger is for; a chart with four hundred codes is one nobody can post to confidently.
Tax codes
Set up a code per rate you actually charge or reclaim, each pointing at the account tax posts to. Getting this wrong is expensive and quiet, so verify with one transaction of each type before going live.
Posting rules
Rather than hard-coding which document produces which journal, Posting Rules declares it: when this document type reaches this status, post these lines to these accounts.
Post at the point the business considers the transaction real — usually approval or despatch, rarely draft. Posting from draft means every abandoned quotation is in your accounts.
Immutability
A posted journal cannot be edited or deleted. A correction is a reversing entry followed by the correct posting.
Users find this frustrating and it is worth explaining rather than defending: the alternative is a system where last month's reported figures change after they were reported. The reversing entry leaves both the mistake and the correction visible, which is what an audit expects to see.
Nothing double-posts
Every journal carries a unique key derived from what caused it, so a redelivered webhook, a retried task or an overlapping feed cursor cannot post the same transaction twice.
Worked example
A sales invoice reaching Approved posts: debit trade debtors with the gross, credit sales with the net, credit VAT control with the tax — the split coming from the line tax codes. The rule is declared once against the type and status, so every invoice posts identically and nobody journals by hand.
Recommendations
- Agree the chart with whoever prepares your accounts before entering it.
- Post at approval, not at draft.
- Test one transaction per tax code before go-live.
- Explain immutability to users early — it prevents a lot of support calls.