Continuous
Events post as they arrive, not at month end.
Continuous posting
An accounting system that stores the facts and the reasoning, not just the conclusion.








Every ERP is a filing cabinet. A person decides what happened, encodes it as a journal, and the software stores the answer.
Store the conclusion
A journal entry is somebody's answer. By the time it reaches the ledger the inputs are gone and the rule that was applied is in a person's memory.
Policy in a document
A manual nobody can execute and a configuration nobody wrote down disagree from the day they are both created, and nothing reconciles them.
Query what happened
There is no predicate that finds the invoice a supplier never sent. Absence has to be recorded as a hypothesis before the event fails to arrive.
What it does
Each of these is asserted by a test that may not be deleted.
Events post as they arrive, not at month end.
Continuous posting
Every figure drills to the record that caused it.
One traversal primitive
Agents hold identities and never hold approval.
The authorization engine
Posted journals are never edited, only reversed.
An append-only ledger
Row-level security, not an application filter.
Postgres row-level security
The audit chain detects a rewritten entry.
A signed hash chain
The product
Ten of them, captured from the application rather than drawn. The figures are a seeded demonstration tenant. Drag, use the arrow keys, or press play and watch.
1 of 10
What needs a person, what the money is doing, and every governed change with who made it. Not a dashboard of charts nobody acts on.
The Constitution
Not a document somebody reads once and encodes by hand. This is a real policy from the starter library, versioned, scoped to the entities and currencies it applies to, and refusing to decide anything at all until the evidence it names is held.
policy tax.uae.reverse_charge.imported_service {
version 1.0.0
effective { from 2024-01-01, to open }
scope {
entities any
books [IFRS]
currencies [AED]
event_classes [supplier_invoice.entered]
}
when
cbe.type is "supplier_invoice.entered"
and vendor.country is not "AE"
and invoice.category is "service"
requires evidence {
evidence.supplier_invoice_pdf as "the supplier's invoice"
evidence.vat_certificate if invoice.total > AED 100000.00
}
determine {
let net = invoice.net
let vat = net times 0.05
debit net to account 6200 "Technology"
debit vat to account 1450 "Input VAT recoverable"
credit vat to account 2450 "Output VAT payable - reverse charge"
credit net to account 2010 "Trade payables"
}
materiality { autonomy_ceiling L3 }
}Trimmed to fit. The fixtures it must pass before promotion are not shown.
AED 112,800 of cloud hosting from a British supplier. Four postings, not two, and the tax is not folded into the expense.
On the journal it posts
Imported service from Cloudspan Infrastructure Ltd in GB. VAT of 5,640.00 accounted for under the reverse charge, Article 48 of the UAE VAT Decree Law. Policy tax.uae.reverse_charge.imported_service@1.0.0.
The default treatment is two lines with the tax folded in. Both of them balance. Nothing in a conventional ledger tells them apart, and the journal that results says nothing about which was applied or why.
Who it is for
Writes policy once instead of writing journals every month.
Reads a number and reaches the document under it in three steps.
Samples the whole population rather than forty items.
Entities post under one chart and one policy set.
A reverse charge is a policy with fixtures, not a memo.
No payment reaches bank details nobody verified out of band.
The argument
A journal entry is somebody's answer. By the time it reaches the ledger the inputs are gone, the rule that was applied is in a person's memory, and the alternatives that were considered were never written down anywhere. Ask why a number is what it is three years later and the honest answer is that nobody knows, only that somebody competent decided it at the time.
That is not a software problem, it is a storage decision, and every ERP has made the same one. Store the conclusion and you can produce a report. Store the facts, the policy that was in force, and the reasoning that connected them, and you can produce the report and defend it, replay it under a policy that changed, and show an auditor the population rather than a sample of it.
The second half is harder and matters more. A record of what happened cannot tell you about the invoice nobody sent, because the missing invoice has no row, no key and no place in the schema. Absence has to be stored as a hypothesis before the event fails to arrive, or it can never be found at all.
An accounting system should be able to show its working, not just its answer.
Where it is
Shipped and testedPlanned, not built
RBAC, ABAC, duties, audit chain
Shipped
Chart, periods, journals, trial balance
Shipped
Three-way match through to payment
Shipped
Policy as versioned executable code
Shipped
A close score, reconciliation, revaluation
Shipped
Translate, eliminate, separate the minority
Shipped
Events from the systems that make them
Planned
The obvious objection
Nothing it holds. No agent holds an approval capability at all: the governance layer rejects an approval whose principal is not human, and that check runs before any grant is consulted.
An agent is a principal like any other. It has an identity, roles, value limits and duty conflicts in the same tables as a person, and the same engine evaluates it. There is no agent branch in the authorization path, which is deliberate: adding one is the single change most likely to end this product.
It is enforced in code and asserted by a test that may not be deleted, rather than by a configuration flag somebody can turn off during an incident.
Where it is enforced
Questions
A model is only called where a rule cannot decide, and what it produces is a proposal carrying its evidence and its confidence, not a posting. Anything outside the trust envelope queues for a named person. Every determination records what the human did about it, so being wrong is measured rather than absorbed.
No. Nine principals, one per duty, and every one of them is refused at least one step. The releaser of a payment is neither its initiator nor its approver, refused three times over: by capability, by the service per item, and by a database constraint.
Postgres row-level security, enabled and forced, with the application connecting as a role that does not hold BYPASSRLS. With no tenant set, every tenant-owned table returns zero rows. It is proven at the database layer by a test, because proving it in application code only proves the application remembered.
The audit log is hash chained and append only, signed with Ed25519 and anchored in ranges. A rewritten payload and a deleted entry are both detected, by three independent checks that can disagree with each other.
You open it. Every figure descends to the record that produced it: account balance to journal line to journal to invoice to the purchase order, the goods receipt and the requisition, ending at the person who asked. Where a record genuinely has nothing beneath it, the surface says so in words rather than leaving a dead link.
In a language your controller can read, compiled and tested. A branch with no otherwise does not compile. Adding two currencies without a rate does not compile. No version is promoted by the person who wrote it, and no version is promoted with a failing fixture.
Not yet answerable. Residency controls are designed and not built. Today this runs on one Postgres you provide, and until region pinning ships that is the honest answer.
Not yet measurable. The design calls for running in shadow beside the incumbent rather than cutting over, and policy inference to draft your rules from your own history. Neither is built, so anybody quoting you a number for this today is guessing.
No, and the trajectory above says which parts exist. What is built is tested against real Postgres semantics with the isolation, duty and audit suites treated as undeletable. What is not built is named rather than implied.
A walkthrough runs against a working system, not slides. Come with the entry your current ERP cannot explain and we will trace it end to end.
No sequence
One person replies. Nothing enrols you in anything.
No sales engineer
The people who built it are the ones on the call.
Bring your data
Or ours. The demonstration tenant is real and seeded.
Would rather write an email? hello@ledgermind.example
Tell us what you need
1 of 7
Who are we talking to?