How Axiom Layer compares
Where a validity layer fits against the tools you already run
why a system that works after the data lands cannot answer
a recognition-time question · the objections, including the one we answer with no
Two different moments
Your accounting tool, your reconciliation scripts, your accounts-payable automation all do the same thing well: they process data after it lands. They book the bank event, then reconcile it. Modern platforms run at seventy to eighty percent automation doing exactly that. None of them decides whether the entry had the right to exist before it was booked.
The money has moved, the entry exists, and the tool tidies it — matches it, tags it, flags the mismatch for someone to chase. Good at the routine. But by the time it acts, the questionable entry is already on the books, and correcting it is a process, not a guarantee.
A recognition layer sits upstream of the ledger. It decides whether money that has already moved is allowed to become accounting truth — against the agreement that governs it. If an invariant fails, the entry is not finalised. The invalid state is never booked in the first place.
“Before” goes further than refusing to book a bad entry. On the payables side the expected payment is frozen at approval, so a payment that does not match — wrong amount, wrong payee, outside the window — is held before it settles, not chased after the money has left. And the governance does not stop at invoices: the performance guarantees, advances, retention and deposits that ring a contract are tracked as recognised instruments and released only at a validated closure — the commercial edges a reconciliation tool never sees.
The five validity questions
Each maps to a cost you already carry today — the same five anchors the Validity Gap questionnaire sizes. A data-time tool can ask them after the fact. A recognition layer answers them before the entry is finalised.
Against the categories you run
The comparison is by category, because the distinction is architectural, not competitive. Brand names sit as examples under each category; what matters is the moment each tool acts.
| Validity question | Accounting / ERPTally, Zoho, SAP | Custom reconciliationin-house, spreadsheet, ledger-matching tools | AP automationinvoice-scanning & payment platforms | Audit-time reviewannual statutory audit | Axiom Layerthe validity layer |
|---|---|---|---|---|---|
| Amount matches the agreement | ◐ | ◐ | ◐ | ✗ | ✓ |
| Disagreement caught before it ages | ✗ | ◐ | ✗ | ◐ | ✓ |
| Recognised without manual reconciliation | ◐ | ✗ | ◐ | ✗ | ✓ |
| Input credit claimed before it lapses | ◐ | ◐ | ✗ | ✗ | ✓ |
| Withholding cleared and matched | ◐ | ◐ | ✗ | ◐ | ✓ |
| Acts before the entry becomes accounting truth | ✗ | ✗ | ✗ | ✗ | ✓ |
The marks reflect when a tool acts, not how capable it is. The other categories detect and repair after the entry exists, or do not touch the question at all. Only a recognition layer prevents the invalid state from being booked — that is the bottom row, and it is the whole distinction. One honest limit on the right-hand column: every tick holds only where a written agreement governs the transaction. Where no agreement exists, there is nothing to enforce.
Complement, not replacement
Your tool makes the books fast. We make them right.
Axiom Layer sits above the accounting tool you already run, whichever it is. The ledger continues to be the ledger; your accountant’s month-end does not change; the ERP keeps doing what it does. We add one thing it was never built to do — decide, at recognition, whether an entry is valid against its agreement.
And we never touch money. The layer is observational on movement: your bank rails move the money exactly as before. We decide when money that has already moved becomes accounting truth. Nothing about your payment flow, your approvals, or your statutory filing is taken over — a validity layer is added, not a system replaced.
Three honest objections
“We’ll just train the team and tighten the process.”
You can, and it works — for as long as you sustain it. But accuracy bought with discipline is a team property: its cost scales with your revenue, and it still produces more than one version of the truth at the edges. The point of a recognition layer is to make validity a property of the system, so it holds without being re-earned every month.
“We already have a reconciliation tool.”
A reconciliation tool works at data-time: it finds and repairs mismatches after the entry exists. That is useful, and it stays. What it cannot do is prevent the invalid entry from being booked in the first place — the validity question lives upstream of where it operates. The two sit together; one does not remove the need for the other.
“Most of our spend is tail and ad-hoc.”
Then the honest answer is no — not yet, at least not broadly. Axiom Layer enforces only where a written agreement governs the transaction. If most of your spend is ungoverned, there is little for it to act on today, and the right first move is formalising that tail into agreements. That is a contract-digitisation conversation, not a recognition one.
In summary
Every tool you run acts after the data lands — recording, reconciling, repairing. The validity question lives one moment earlier, before money that has moved becomes accounting truth, and that is the one moment none of them work in. Axiom Layer adds that layer above your stack, where a written agreement governs the transaction, and leaves everything else exactly as it is.