Immutable ledger: why posted entries are never edited and how errors are corrected

What is an immutable ledger?

In most organisations the general ledger is where every financial fact eventually lands: sales, purchases, payroll, transfers, fees and settlements. In many conventional systems, a user with enough permissions can open a posted journal and change its amount or date. The balance moves, but the story of why it moved disappears with the old value

An immutable ledger removes that option. Drafts can be edited freely before posting, but posting is a one-way door, and the only way to undo the effect of an entry is to post another one. The idea is not new: careful bookkeepers always worked this way on paper, where a crossed-out figure was a warning sign. The difference is that software can enforce the rule instead of relying on personal discipline

Double-entry accounting in one paragraph

Double-entry accounting records every event in at least two accounts, with total debits equal to total credits. When a company pays a supplier 500, cash falls by 500 and the amount owed to that supplier falls by 500. Because each entry balances on its own, the whole ledger balances too, and an entry that does not balance is rejected before it can become final

• Every balance change is an event: a payment, an invoice, a fee, a transfer or a settlement
• Every event is posted as a balanced entry with matching debits and credits
• Every entry carries a date, a source, an author and, where required, an approver
• Balances are never stored as editable numbers; they are the sum of the entries behind them

Why posted entries are never edited or deleted

Editing a posted entry looks efficient: the figure is wrong, so fix it. The problem is what the fix destroys: the original amount, how long it was in effect, every report produced in the meantime and the reason it changed. A report sent to a lender last week no longer agrees with the ledger this week, and nobody can prove why

Deleting is worse. A deleted entry leaves a gap no one can see, and invisible gaps are exactly what internal control exists to prevent. When entries are append-only, any report ever issued can be reproduced from the entries that existed at that moment, and every later change is visible as its own line

• Closed periods stay closed, so figures already reported do not drift
• Errors remain visible, which makes their root causes easier to find and fix at the source
• Auditors test the complete population of entries, not whatever survived later edits
• Disputes with customers, suppliers or partners are settled against a fixed record

Correction by reversal: a worked example

Suppose a supplier invoice for 1,200 is posted on 3 March, but the clerk types 2,100. The entry debits office expenses 2,100 and credits accounts payable 2,100. It balances, so the system accepts it. On 10 March a reviewer spots the difference while matching the invoice to the supplier's statement. The amounts are purely illustrative

1. The original entry stays exactly as it was: debit office expenses 2,100, credit accounts payable 2,100, dated 3 March
2. A reversing entry mirrors it: debit accounts payable 2,100, credit office expenses 2,100, with a reference to the original entry and the reason for the correction
3. A new, correct entry is posted: debit office expenses 1,200, credit accounts payable 1,200, with the same invoice as its source
4. Net effect: both accounts show 1,200, and the ledger holds three lines that tell the whole story

If the error is found after the period has closed, the reversal and the new entry are normally posted in the current open period, unless the organisation decides to reopen the closed one. Reopening a closed period is a sensitive action in its own right and should need approval from a second person

When to use a reversing entry

Use a reversing entry whenever the amount, account, date or counterparty of a posted entry is wrong. In accrual workflows many teams also post an automatic reversal at the start of the next period, so the actual invoice can be booked without double counting. In both cases the rule is the same: the original line is never touched

What a complete audit trail records

An audit trail is only useful if it can answer, months later, the questions an auditor or controller will ask. For every entry, the ledger should be able to show the following

• Who: the person or system that created the entry, and the person who approved it where approval applies
• When: the time the entry was recorded and the accounting date it affects, kept as two separate values
• Source: the document, bank line, invoice or system event it came from, with a link back to it
• Why: a reason code or note, mandatory for reversals, adjustments and manual entries
• Relationship: a reference to the entry it reverses, or to the entry that reversed it

Because balances are derived from entries rather than stored as editable figures, any balance can be rebuilt for any date by summing the entries up to that point. If the rebuilt figure ever disagrees with a reported one, that disagreement is itself a finding to investigate, not a number to overwrite

A related rule matters just as much: no figure without a source and a time. When a data feed is missing, the gap stays marked as unknown instead of being silently treated as zero, so a missing bank file cannot quietly become a clean balance. Daily checks of this kind are the heart of daily close and source reconciliation

Idempotent posting: why one event is never recorded twice

A ledger receives events from many places: payment gateways, banks, internal products, spreadsheets and people. Connections drop and messages are resent. Without protection, a resent message can post the same payment twice, and the ledger will balance perfectly while being wrong

Idempotent posting is the plain-language fix. Every event carries a unique key, such as the bank's transaction reference combined with the name of the source. The first time the ledger sees that key, it posts the entry. If the same key arrives again, the ledger recognises it and returns the original result instead of posting a second copy. Retrying becomes safe, and duplicates are stopped at the door rather than hunted down at month end

Pitfalls to avoid

• Choosing a key that is not truly unique, such as amount plus date, which blocks legitimate separate payments
• Generating a fresh key on every retry, which defeats the purpose
• Accepting manual entries without a duplicate check against existing source references

Separation of duties for sensitive actions

Some actions carry more risk than everyday postings because they change history or move value in ways that are hard to spot later. In a well-controlled ledger these actions need two separate people: one records, one approves. The person who prepares the entry cannot approve it, and the approval itself becomes part of the audit trail

• Manual adjustments and reclassifications
• Opening balances when a new company, account or system goes live
• Rate changes applied after transactions were already posted
• Reopening a closed period
• Transfers above defined limits

Separation of duties depends on access rights that match real roles, so it works best alongside clear access governance and security controls. For groups running several entities or customers on one platform, separating data and access matters just as much, as our guide to secure multi-tenant architecture and data isolation explains

How an immutable ledger supports auditors and internal control

An immutable ledger does not replace an independent audit, and no software can honestly claim that it does. What it does is make audit work faster and more reliable. An auditor can take every entry for a period, trace a sample back to source documents, confirm that each correction is a visible reversal and check that sensitive entries were approved by someone other than their author

For internal control, the same properties let a finance team answer routine questions without detective work: why did this balance change, who approved this adjustment, which report used the old figure. Questions that once took days of reconstruction become a filtered view of the ledger

A quick self-assessment

• Can anyone, even an administrator, edit or delete a posted entry?
• Can every balance be rebuilt from entries for any past date?
• Does every reversal point to the entry it corrects, with a reason?
• Would a resent bank or gateway message create a duplicate?
• Can the same person both record and approve an adjustment or an opening balance?

How Arfinex applies these principles

In Arfinex the ledger is the reference system for the organisation's money. Every balance change is an event with a balanced double entry, mistakes are corrected with reversing entries rather than edits, and every posting carries a unique key so the same event is never recorded twice. Totals, rates, fees, postings and period close run on deterministic, testable code; AI can propose and explain, and its output is labelled as a proposal until a person approves it

The multi-asset financial engine and ledger connects to source systems read-only and keeps customer backing, treasury, counterparties, revenue and expenses apart. It is one part of a wider financial operating system that ties accounting, treasury, reporting and operations to the same entries. Arfinex is not an auditor or a tax adviser, so local accounting and tax treatment is confirmed by your own accountant or adviser

Trust the history, not just the balance

An immutable ledger turns accounting history into evidence. Balanced double entries, correction by reversal, a complete audit trail, idempotent posting and two-person approval for sensitive actions together produce books that can be explained at any date to anyone who asks. If your team still fixes errors by editing posted figures, that is the first habit worth changing