Why an AI Cannot Simply Edit Your Ledger

If an AI assistant can write to your books at all, the natural worry is: what stops it — or a bug, or someone who managed to compromise it — from quietly changing a number that's already been posted, rewriting history instead of just adding to it? It's the right question to ask before trusting anything with your financial records, and the honest answer is more specific than "we tested it and it behaves."

The other guides in this cluster cover how a mistake gets corrected — with a reversing entry, which cancels an error's effect while leaving both it and the fix visible. This one is about something underneath that: why editing or deleting a posted entry isn't offered as an option at all, at the deepest layer, rather than merely being something the application's interface happens not to expose.

It's enforced at the database level, not the application level. An attempt to UPDATE, DELETE, or TRUNCATE the journal is refused by a trigger on the database itself — and that holds even if something bypassed BalanceMCP's own application code entirely and tried to write directly with raw SQL. That's a meaningfully different, stronger guarantee than "the app doesn't have an edit button." It's not a policy choice that someone could forget to enforce or that a bug could accidentally bypass through some other path in the code — the storage layer itself has no path for editing history, full stop.

Compare that to the more familiar alternative: a spreadsheet cell, or a database row that gets updated in place, has no memory of what it used to say. Once it's overwritten, the previous value simply isn't anywhere anymore. An edit and a cover-up look identical from the outside, because both just leave you with a new number and no record of the old one. An append-only ledger with correcting entries is a genuinely different kind of object: every version of the truth — "here's what we recorded on the 3rd, and here's the correction we made on the 9th, once we noticed" — survives, in order, permanently.

Picture the failure mode this actually prevents: an AI assistant posts a bad entry, later "notices" it was wrong, and — if editing were possible — simply changes the original numbers so it looks like the mistake never happened. From the outside, you'd have no way to know that ever occurred; the books would just show correct-looking numbers with no trace of the detour. Because editing isn't possible here, the same scenario instead leaves two visible entries: the original mistake and a reversal correcting it, both permanently in the journal, whether the AI reversed it on its own initiative or you asked it to.

This matters more, not less, when the one making changes might be an AI rather than a person. An AI can misread a receipt, act on an ambiguous instruction, or occasionally just be wrong — the same as a person can. What an append-only ledger buys you isn't that those mistakes stop happening; it's that none of them can compound silently. Every entry an AI (or anyone) posts is a new fact added to a visible, ordered timeline, never a rewrite of a fact that was already there. If it's wrong, the fix is another new, equally visible fact — a reversal — not the first fact quietly disappearing.

Worth being clear about what this doesn't promise: it doesn't mean an AI, or a person, can only ever make one mistake, and it doesn't make every mistake obvious the moment it happens — you still have to look, which is why reconciling monthly and locking periods once you're satisfied both matter, and both have their own guides. What it does guarantee is that once you do look, nothing has been erased out from under you. Every entry also records whether a person, a bank import, or an AI posted it, so a mistake is always traceable to its actual source, not just to "something changed somewhere."

This is, in a sense, the oldest idea in bookkeeping applied to a new kind of author. A paper ledger, kept honestly, was never edited either — a mistake got a line drawn through it and a correcting entry written below, both still legible, rather than an erasure. An append-only database enforces the same discipline mechanically rather than relying on a bookkeeper's integrity to maintain it by hand, which matters more, not less, once some of the entries in that ledger might be posted by something other than a person.