What Is an Immutable Ledger? Audit Trails and Why Deleting Entries Is a Bug
Why posted accounting entries must never be edited or deleted, how corrections work in an append-only ledger, and what period locks and audit logs actually guarantee.
An immutable ledger is one where posted entries are never changed and never deleted. Corrections are made by adding new entries that reverse or adjust the old ones, so the history of the books is itself part of the books.
This is not a technical preference. It is what makes accounting records evidence rather than a current opinion about the past — and it is why "add a delete button for journal entries" is a request that should be refused.
Why edit and delete break everything
The audit trail is the product. The purpose of double-entry bookkeeping is that every balance decomposes into the entries that produced it. If entries can be silently altered, the decomposition proves nothing: the trail shows what someone most recently decided it should show.
Filed figures stop matching the books. A VAT return filed in March quotes March's numbers. Edit a March invoice in June and your ledger no longer agrees with a document already submitted to a tax authority. Nobody notices until a reconciliation, and by then the cause is months of transactions away.
Fraud becomes invisible. Detecting manipulation depends on being able to see that something changed. Where entries can be edited in place, there is nothing to see — which is exactly why tax administrations across the EU require accounting records to be tamper-evident, and why several countries certify billing software specifically on this property.
Distributed state diverges. If an invoice was sent to a customer, exported to a bank file, transmitted to an e-invoicing platform, and read by a partner API, editing your copy changes nothing about theirs. You have not corrected an error; you have created a discrepancy.
How corrections actually work
Every legitimate correction is an addition:
| Situation | Correct mechanism |
|---|---|
| Wrong journal entry | Post its reversal, then the correct entry |
| Wrong amount invoiced | Issue a credit note, then a new invoice if needed |
| Wrong period | Post in the current open period, dated when the correction happened |
| Estimate superseded | Reverse the accrual, book the actual — see accrued revenue |
The result reads as a narrative: here is what we thought, here is when we learned otherwise, here is the correction. An auditor asking "what happened to invoice S-1041?" gets a complete answer instead of a number that has always, apparently, been that number.
The cost is that the ledger contains mistakes forever. That is the point — a company whose books show no corrections is either exceptionally lucky or editing them.
What immutability is not
- Not "nothing can be fixed." Anything can be corrected; it is corrected by adding, not overwriting.
- Not blockchain. Cryptographic chaining is one implementation of tamper-evidence; an append-only relational ledger with enforced constraints and an audit log gives you the accounting property without the distributed-consensus baggage.
- Not the same as an audit log. An audit log records who did what. Immutability means the accounting data itself does not change. You want both, and they answer different questions.
- Not applicable to drafts. A draft invoice is a working document and can be edited freely. Immutability begins at issue — the moment the document becomes real to someone else.
How Nordlet enforces it
Three mechanisms, all structural rather than conventional:
Posted entries are append-only. Journal entries are written once. There is no endpoint that edits or deletes a posted transaction, and POST /v1/ledger/journal/transactions/create validates before writing — debits must equal credits, accounts must exist and be postable, the period must be open. An unbalanced ledger is not a state the database can represent.
Periods lock. POST /v1/ledger/periods/lock closes a month, and any transaction dated into a locked period is rejected — whether it comes from a manual entry, an invoice, a bank import or an automated recognition run. Locking is what makes a filed return match the books permanently, and unlocking is itself an audited action. The accounting period article covers the workflow.
Everything is audited. State-changing operations write to an audit log with the actor, the action, the entity and a diff — including automated ones, which record a system actor rather than pretending a human did it. When intercompany mirroring creates an invoice, both companies' logs show it.
Documents follow the same rule: issuing a sales invoice allocates a number from a gapless series and posts; correcting it afterwards means a credit note, never an edit. The original invoice, the credit note and the resulting balance all remain visible on the customer's history.
Draft documents remain fully editable, and deletion is a soft delete — a deletedAt timestamp that hides the record from active queries while preserving it.
FAQ
What is an immutable ledger?
An accounting ledger where posted entries are never modified or deleted. Corrections are made by adding reversing or adjusting entries, so the complete history — including mistakes and their corrections — remains part of the record.
Why can't I just delete a wrong journal entry?
Because the entry may already be reflected in a filed tax return, a document sent to a customer, or another system's records. Deleting it makes your books disagree with all of those silently. Reversing it corrects the numbers while leaving evidence of what happened.
Does an immutable ledger require blockchain?
No. Blockchain is one way to make records tamper-evident. An append-only database design with enforced balance constraints, period locks and an audit log delivers the accounting properties that matter, without distributed consensus.
Can I edit a draft invoice?
Yes. Immutability applies from the moment a document is issued and becomes real to someone else. Drafts are working documents and can be changed or deleted freely.
How do I correct an entry in a closed period?
Post the correction in the current open period, dated when the correction happened. If the closed period's reported figures were materially wrong, the alternative is to deliberately reopen it, correct, re-report and re-lock — an audited action, which is the honest way to restate.