Balance invariant
For any generated transaction of any shape, total debits equal total credits or the write is rejected. Tested against generated inputs rather than a fixed list of examples somebody thought of.
Platform · trust
Security attestation and accounting correctness are different assurances, and a vendor answering the second by pointing at the first is either confused or hoping you are. This is our answer to the second: a published test suite over the ledger invariants, written to be read by an accountant, plus an independent attest review of the engine.
What it does
For any generated transaction of any shape, total debits equal total credits or the write is rejected. Tested against generated inputs rather than a fixed list of examples somebody thought of.
No posting into a closed or locked period from any actor, including internal services. Corrections must be reversing entries into an open period.
The account exists, is active, accepts postings, belongs to the entity, and is not a control account being written to directly.
Required dimensions per account are present. A posting with a blank required dimension is rejected rather than accepted and quietly breaking reporting later.
AR and AP detail sums to the control balance continuously. A generated sequence of transactions cannot produce a state where they diverge.
No path accepts an edit or delete of a posted entry. Corrections are new entries referencing the original, and the test suite attempts to violate this deliberately.
Most test suites check specific cases: a two-line journal entry balances, a posting to a closed period is rejected. Those are useful and they only cover situations somebody anticipated.
Property-based testing inverts it. You state the property — debits equal credits — and the framework generates thousands of transactions of varying shape, line count, currency, sign, and rounding, trying to find one that violates it. The cases it finds are the ones nobody would have written by hand, which is precisely why they matter.
For a ledger this is the appropriate tool, because the failure you fear is not the case you thought of. It is the twelve-line multi-currency entry with a rounding difference on a reversal in a period somebody reopened.
The suite is deliberately readable by somebody who understands accounting rather than only by an engineer. The invariants are named in accounting terms, the assertions state what is being guaranteed, and the failure messages describe the accounting consequence rather than a stack trace.
That is a design choice with a purpose: it means your controller or your CPA can read what we assert and disagree with it. A test suite only an engineer can evaluate is not evidence to a finance team, whatever its coverage.
We engage an attest firm to review the accounting engine’s behaviour and issue a written opinion. That is separate from SOC 2, costs a fraction of it, and is the assurance finance teams actually want and are rarely offered.
It is not an audit of our company and we do not present it as one. It is an independent examination of whether the engine does what we say it does, and it is available under NDA with the security pack.
The suite guarantees the engine’s invariants. It does not guarantee that your chart of accounts is well designed, that your team codes consistently, or that a judgement about revenue recognition is correct. Those are your accounting decisions and no software attestation substitutes for them.
Nor does it eliminate the possibility of a bug elsewhere in the product. Concentrating the correctness risk in a small, deterministic, heavily tested component is the design; claiming the whole system is provably correct would be nonsense.
Limits
It attests that the engine enforces its invariants. Whether your accounting is right depends on your chart, your coding, and your judgements — which is what your auditor is for.
Different assurance. SOC 2 covers our control environment; this covers whether the arithmetic and period control hold. You want both and they are not substitutes.
It covers the posting engine, deliberately, because that is where an error is unrecoverable. Bugs elsewhere in the product remain possible and are handled through the error policy.
Questions
The suite and the attest review, sent for your CPA or auditor to evaluate before you buy anything.