Debits equal credits
Enforced at the transaction boundary, not checked afterwards. An unbalanced entry cannot be persisted, so there is no state in which the ledger is temporarily wrong.
Platform · financial core
The general ledger is the one component where being nearly right is worthless. Ours enforces its invariants in the posting engine rather than validating after the fact, keeps append-only history, and publishes the test suite that asserts all of it.
Connect read-only and we will reproduce your trial balance independently, with every variance explained.
Invariants
Not policies or best practices — conditions the engine refuses to violate. Everything else in the platform is built on the assumption that these hold.
Enforced at the transaction boundary, not checked afterwards. An unbalanced entry cannot be persisted, so there is no state in which the ledger is temporarily wrong.
Period state is evaluated by the engine on every write. Corrections into a closed period are made as reversing entries in the next open one, which is what an auditor expects to see.
Nothing is edited or deleted. A correction is a new entry referencing the original, so the history of a disagreement is itself part of the record.
AR and AP detail must reconcile to their control balances continuously, not at month end. A break is surfaced the day it happens.
Entity, department, location, and project are required on posting rather than optional, which is why dimensional reporting works without a monthly rebuild.
The invariants above are tested against generated transactions rather than a fixed list of cases. The suite is published so your accountant can read what we assert.
Period control
Most systems have open and closed. The two intermediate states are where a real close actually happens — and where automation has to be constrained differently.
The most common structural problem we find in a mid-market chart of accounts is that it is doing the job of a reporting system. Nine hundred accounts, most of them variations on the same expense split by department or location, because sub-accounts were the only dimension the previous system offered.
A chart built that way cannot answer a question it was not anticipated. Adding a location means adding forty accounts. Reporting across a dimension nobody thought of at setup means a manual mapping exercise every month, forever.
The alternative is a short chart and real dimensions. One hundred to two hundred accounts describing what the money is, with entity, department, location, project, and class carried on every line describing where and why. Any combination is then a query rather than a restructure.
A dimension that can be left blank will be left blank, and a report that silently excludes twelve percent of transactions is worse than no report. Required dimensions are configured per account — a bank account does not need a project, a consulting expense does — and the posting engine rejects entries that omit one.
This is mildly annoying in week one and it is the reason department and project reporting works without reconciliation for the following five years.
The correctness suite is public and versioned. It asserts the invariants above using property-based testing — generated transactions across many shapes rather than a fixed list of examples — and it is deliberately readable by an accountant rather than only by an engineer.
A third-party attest firm reviews the engine and issues a written opinion. That is a separate assurance from SOC 2, which addresses security rather than whether the ledger is correct, and it is the one most finance teams actually want and rarely get offered.
Transaction, functional, and reporting currency are handled distinctly, with realised and unrealised gain and loss and cumulative translation adjustment in equity. Deep local statutory filing across many jurisdictions is not our strength — see the comparison pages for where that points elsewhere.
Questions
The correctness suite is public. Connect read-only and we will reproduce your trial balance beside it.