Included in ERPClaw, free
Audit-ready books, without doing anything extra
Most software makes clean books your job. ERPClaw, the Free & Open Source ERP you host yourself, makes them the system's job: every entry is checked the moment it posts, mistakes are corrected in the open, and the whole history stays explainable. When the auditor, the bank, or the buyer shows up, you are already ready, and it cost you $0.
How the books stay provable
Four things happen automatically, on every entry, that most systems leave to discipline and luck. They apply the same way whether a person keys the entry or an AI agent posts it through AI bookkeeping.
Every entry is checked before it stands
Every posting passes a validation checklist before it is written to the books. An entry that would break the accounting, debits that do not match credits, money appearing from nowhere, is refused on the spot instead of discovered at year end.
Nothing is ever quietly edited
Posted entries are permanent. A mistake is fixed with a reversal that shows what changed and when, the way an auditor expects, so the history always tells the whole story. There is no delete key for the past.
Every action leaves a trail
Who asked for what, what the system did, and what it posted: recorded, every time, automatically. When someone asks 'why is this entry here', the answer is a lookup, not an investigation.
The engine itself can be inspected
ERPClaw is fully open source. Your accountant, your auditor, or your own developer can read the exact code that keeps the books, which is a level of trust no closed system can offer at any price.
The $100 that appears out of nothing
Software can pass every test its developers wrote and still leave your books wrong. The simplest way to see it is a $100 transfer.
You move $100 from savings to checking. A typical test asks one question: did checking go up by $100? It did, so the test passes. But suppose the code forgot the other half, and savings never went down. You have just created $100 out of nothing, and every test is still green, because each test only checks what it was told to check.
An invariant asks a different question, one that does not care which feature ran: across the whole book, do all the debits still equal all the credits? That fails the moment the $100 appears. ERPClaw's test suite asks it, along with other whole-book checks, after every test that touches the ledger, and every live posting is checked for balance before it is written, so an entry that does not balance is refused. In the case study we presented at IEEE IRI 2026, these checks caught bugs during development that ordinary tests had passed: code that did exactly what it was asked and still left the books broken.
Tests check that the code did what you asked. Invariants check that the books still make sense.
More on this: how ERPClaw is tested, and the four questions from the IRI talk, where this one came up from the audience.
"An audit is only frightening when the books have secrets. We built ERPClaw so they cannot keep any: every entry is checked the moment it posts, every correction happens in the open, and every question has a lookup instead of an investigation. A boring audit is the product."
Two questions you can always answer
"Are the books actually balanced?"
One question, answered by real double-entry math on the spot, not a dashboard's opinion. If they ever were not, the entry that broke them would have been refused when it was made.
"Why is this entry in the books?"
The trail is a lookup: who asked for it, what the system did, what it posted, and when. The ledger itself is permanent, so the answer cannot have been edited after the fact.
And they stay provable through upgrades
Keeping books provable on the day you post an entry is the easy half. Keeping them provable through every upgrade, repair, and correction afterwards is the half that decides whether you can still trust the history a year from now.
A release has to prove itself against the books
Before a version ships, it has to run complete business scenarios from beginning to end, driven in plain business language, and a deterministic check reads the books that come out and decides pass or fail. A scenario that ends with the wrong balance stops the release.
Upgrades say what they touched
When an upgrade repairs something in your history, it records an audit-trail row for every document it changed, inside the same transaction as the change. Nothing about your past gets quietly tidied.
Corrections are visible and confirmed
Group consolidation is safe to run twice, and if an earlier repeat run left damage behind, the consolidated trial balance names the leftover rows instead of absorbing them. Removing them takes an explicit confirmation, and every removal is recorded.
A closed route beats a quietly wrong one
Shortcuts that could move stock quantity, or post group adjustments, without a matching entry in the books were retired rather than patched. They now decline and name the flow that does the job properly.
These arrived in ERPClaw 4.15, written up intested the way you actually work.
The days this pays for itself
The loan application
The bank wants financials it can trust. Yours come out of a system that provably balances, with the trail to show it.
Due diligence
A buyer or investor sends their accountants in. Clean, permanent, explainable books are the difference between a week and a quarter.
Tax season
Your accountant gets books that reconcile instead of a shoebox with software around it. Their hours drop, and so does their bill.
The bad-surprise day
When a number looks wrong, the trail shows exactly what happened and when. No archaeology, no blame roulette.
Related: three-way matching before money leaves · profit by department or project · work with your books from your AI tools · how ERPClaw is tested
Common questions
What does 'audit-ready books' actually mean?
It means the books are kept in a way an auditor can verify: every entry balanced and checked at the moment it was made, corrections done as visible reversals rather than silent edits, and a complete trail of who did what. In ERPClaw that is how the system works by construction, not a report you generate at the end.
Does the AI make this riskier?
The opposite, because of how ERPClaw is built. The AI decides what you meant; deterministic accounting code decides what gets posted; and every posting is validated before it is written, so an entry that does not balance is refused. The AI never has a pen of its own.
Can I show this to my accountant?
Please do. The short version for them: double-entry ledger, immutable postings with reversal-based corrections, full audit trail, and open-source posting logic they can read. Most accountants relax visibly at the second item.
Is this an extra module or a paid tier?
Neither. It is how the free product keeps books. ERPClaw is $0 forever, self-hosted, open source, and the posting checks are not optional, for you or for us.
What happens to my books when I upgrade?
Upgrades are held to the same standard as the books themselves. A version has to clear complete business scenarios judged against the resulting books before it ships, and any upgrade step that repairs existing data records what it changed, document by document, in the same transaction as the change. If a repair happens in your history, you can read exactly what it was.
Does this replace an actual audit?
No, and we will not pretend it does. Audits are performed by auditors. What audit-ready books change is what the audit costs you in time, fees, and surprises, because the evidence an auditor needs already exists in order.
What if I need accounting help, not just software?
We make software, and we offer implementation help getting set up. For bookkeeping, tax, or close work done by people, our accounting partners can help; reach out through the support page and we will connect you.
Books you never have to apologize for
ERPClaw: the AI-native ERP. Run your whole business in plain language. Free forever, self-hosted, PostgreSQL or SQLite.