General Ledger

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.

Journals, Currency and Intercompany

Every journal line stores three amounts: the transaction amount in the currency it happened in, the functional amount in the entity's own currency, and the reporting amount in the group's. All three are computed once, at post time.

Where to find it

Architect Panel → ERP - Finance:

• Exchange Rates — the rates used at post time
• Intercompany Rules — how a transaction between your own companies posts to both
• Allocations — spreading a cost across entities, departments or projects
• Journals — the posted result

Why store all three

The alternative — storing the transaction amount and translating on demand — is simpler and wrong, because the answer changes every time you ask.

Run last year's trial balance today and again next month and the figures differ, because the rate moved. Financial statements that will not reproduce are not financial statements.

Storing all three means a closed period returns the same numbers next year as it did on the day it closed. A rate correction afterwards is a posting, visible as such, rather than a silent restatement of history.

Exchange rates

Maintain rates in Exchange Rates. The rate in force at post time is the one captured, so keeping it current matters more than keeping it precise — a stale rate silently misstates every posting made against it, and nothing will warn you.

Single-currency systems

The three amounts are identical and you can ignore the distinction. It costs nothing to have them, and adding a second currency later becomes a configuration change rather than a re-engineering job.

Intercompany

Intercompany Rules declares how a transaction between two of your companies posts to both, in one operation, each side in its own functional currency.

This is exactly why entity is a separate dimension from tenant: tenant isolation forbids writing across the boundary, and an intercompany journal has to.

Allocations

Allocations spreads a cost across entities, departments or projects on a basis you define — headcount, floor area, revenue share.

Run them before closing, and keep the basis documented. An allocation nobody can explain is one that gets argued about at year end, usually by the department carrying the largest share.

Consolidation

A consolidated view reads every entity and reports in the group currency using the reporting amounts already on each line. Because translation happened at post time, consolidation adds up figures that already exist rather than re-translating history.

Worked example

A UK parent recharges its Irish subsidiary for shared services in euro. The intercompany rule posts a receivable in the parent's books in sterling and a payable in the subsidiary's in euro, both from one entry, each carrying its own functional amount and a common reporting amount. Consolidation eliminates the pair without anyone journaling it out by hand.

Recommendations

• Set both currencies on every entity at creation.
• Keep exchange rates current — put it on somebody's checklist.
• Document the basis of every allocation in its description.
• Run allocations before close, not after.

Accounting Periods and Closing

A journal belongs to an accounting period as well as a date. Periods let the business say a month is finished and have that mean something.

Where to find it

Architect Panel → ERP - Finance:

• Accounting Periods — open and close each period
• Ledger — the trial balance you review before closing

What closing does

Closing stops further postings being dated into that period. That is the whole mechanism and it is enough: the figures reported for that month can no longer change, so a statement produced from them stays true.

Without it, a late invoice dated into a closed month silently changes a figure somebody has already circulated to a board.

A late transaction

Post it into the current open period rather than reopening the old one.

Reopening invalidates everything already reported from that period. Posting into the current one is visible and explicable. Where the timing genuinely matters for reporting, an accrual in the closed period and a reversal in the new one is the accounting answer — and both are ordinary, visible postings.

Before you close

• Clear the feed inbox — an unprocessed item at close means the period is missing transactions.
• Confirm documents that should have posted have reached the status that posts them.
• Run depreciation for the period.
• Run any allocations.
• Run the calculated-field recalculation sweep if there have been imports.
• Review the trial balance and confirm it balances and looks sane against last month.

Closing is a decision, not a routine

Do not automate it on a schedule. Closing asserts that the figures are final, and that assertion should be made by a person who has looked at them — not by a timer that fires on the fifth working day whether anybody checked or not.

Reporting afterwards

Because amounts were translated at post time and postings are immutable, a report over a closed period is reproducible indefinitely. The number you quote in March is the number the system still gives in December — which is the whole payoff for the discipline.

Worked example

A finance team closes on the fourth working day. The checklist is a saved report showing unprocessed feed items, unposted approved documents, and whether depreciation has run. All three must be clear before the trial balance is reviewed and the period closed. A supplier invoice arriving on day six is posted into the new period with an accrual in the old one where it is material.

Recommendations

• Build the pre-close checklist as a saved report so it is checked rather than remembered.
• Never reopen a closed period to accommodate one transaction.
• Close on a fixed working day so everyone knows the cut-off.
• Compare the trial balance to last month before closing — anomalies are obvious side by side.