Skip to content
LedgerMind

Your books are never closed because they were never open.

An accounting system that stores the facts and the reasoning, not just the conclusion.

  • Multi-entity
  • Multi-currency
  • Consolidated
  • Audit-first

Every ERP is a filing cabinet. A person decides what happened, encodes it as a journal, and the software stores the answer.

  1. 01

    Store the conclusion

    Store the facts and the reasoning

    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.

  2. 02

    Policy in a document

    Policy as something that runs

    A manual nobody can execute and a configuration nobody wrote down disagree from the day they are both created, and nothing reconciles them.

  3. 03

    Query what happened

    Query what did not

    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

Six properties, one line each

Each of these is asserted by a test that may not be deleted.

  • Continuous

    Events post as they arrive, not at month end.

    Continuous posting

  • Explainable

    Every figure drills to the record that caused it.

    One traversal primitive

  • Governed

    Agents hold identities and never hold approval.

    The authorization engine

  • Reversible

    Posted journals are never edited, only reversed.

    An append-only ledger

  • Isolated

    Row-level security, not an application filter.

    Postgres row-level security

  • Attestable

    The audit chain detects a rewritten entry.

    A signed hash chain

The product

Screens from the running system

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

The Command Center

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 Command Center. 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 LedgerMind command centre, showing counts of items awaiting a decision, open duty conflicts and audit chain status, a row of money figures including amounts owed to suppliers and to the company, and a feed of recent governed activity naming the person behind each change.
  • The Constitution. Accounting policy as versioned code, with its fixture run and the artifact hash a determination cites. The Constitution screen, listing accounting policies by state with the one in force showing its version, the dates it applies between, the event class that triggers it and the role that owns it.
  • The ledger. Chart, periods and journals, with the trial balance computed from lines rather than maintained as a stored number. The ledger workbench, showing the chart of accounts with balances and the journals posted against them.
  • Supplier invoices. The three-way match, with a variance that has to be explained before anybody can approve past it. The supplier invoices workbench, listing invoices with their match status against the purchase order and the goods receipt.
  • Bank reconciliation. The matcher declines rather than guesses. What it could not match stays visible as exposure instead of quietly clearing. The banking workbench, showing imported statement lines matched to payments and receipts, with the unmatched lines and their total value listed separately.
  • Multi-currency. Every line carries what the transaction was in and what it is worth in the entity's own currency. Only monetary items revalue. The foreign exchange screen, showing rates by type and date and a revaluation run with the gain or loss it produced per account.
  • Consolidation. Intercompany balances found by identity rather than by convention, with every elimination shown pair by pair. The consolidation screen, showing group members with their effective interest, the intercompany balances eliminated and the non-controlling interest separated out.
  • The close. A health score denominated in materiality, decomposable into the named breaches that made it. The close screen, showing the close health score broken into scoring domains, with the open breaches that reduced it and the domains that could not be scored named rather than hidden.
  • Completeness. What should have happened and did not, stored as a hypothesis before the event failed to arrive. The completeness screen, listing expected events that have not arrived, each marked with the generator that predicted it and how confident that prediction is.
  • The audit trail. Hash chained and append only, with the chain verified in the page that shows it rather than in a report somebody has to ask for. The audit trail screen, listing every governed mutation in sequence with the actor, the action and the chain verification result.

The Constitution

Your accounting policy, as something that runs

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.

What it determined for one invoice

AED 112,800 of cloud hosting from a British supplier. Four postings, not two, and the tax is not folded into the expense.

  • 6200 TechnologyDr 112,800.00
  • 1450 Input VAT recoverableDr 5,640.00
  • 2450 Output VAT payableCr 5,640.00
  • 2010 Trade payablesCr 112,800.00

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

What changes when the close never opens

  • Controller

    Writes policy once instead of writing journals every month.

  • CFO

    Reads a number and reaches the document under it in three steps.

  • External auditor

    Samples the whole population rather than forty items.

  • Group consolidation

    Entities post under one chart and one policy set.

  • Tax

    A reverse charge is a policy with fixtures, not a memo.

  • Treasury

    No payment reaches bank details nobody verified out of band.

The argument

A system that stores conclusions cannot answer the question an auditor asks

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

What has shipped, and what has not

Shipped and testedPlanned, not built

  1. Identity and authorization

    RBAC, ABAC, duties, audit chain

    Shipped

  2. Double-entry ledger

    Chart, periods, journals, trial balance

    Shipped

  3. Procure to pay, order to cash

    Three-way match through to payment

    Shipped

  4. The Accounting Constitution

    Policy as versioned executable code

    Shipped

  5. Close, bank and currency

    A close score, reconciliation, revaluation

    Shipped

  6. Multi-entity consolidation

    Translate, eliminate, separate the minority

    Shipped

  7. Connectors and inference

    Events from the systems that make them

    Planned

The obvious objection

What stops the agent from approving its own work?

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

  • No machine approves anythingchecked before grants are consulted
  • The preparer cannot approve their own itemwhatever roles they hold
  • Twenty-two duty conflictsrefused at the point of grant
  • Every model action recordedinputs, output, confidence, disposition
See where it is enforced

Questions

The nine a finance buyer actually asks

What happens when the model is wrong?

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.

Can one person walk a payment from request to bank?

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.

How is one tenant kept out of another's data?

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.

What evidence can I hand an auditor?

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.

Somebody disputes a number. What then?

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.

Where does the accounting policy live?

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.

Where is my data held?

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.

What does migration actually cost?

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.

Is this production ready?

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.

Bring your hardest close

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?