A signed financial statement that can be rewritten proves nothing

A balance sheet goes out on the fifth. On the twentieth somebody fixes a three-month-old journal entry — a legitimate correction, properly approved. The PDF already circulating no longer matches the ledger, and nobody finds out. That is the normal state of affairs in most accounting systems, and it only surfaces the day someone compares the two.

Signing the file is the easy half

Most systems that claim to sign a financial statement store the hash of the generated PDF. That proves the file has not been altered, which is true and almost useless: nobody was going to edit the PDF. What changes underneath is the ledger, and a hash of the file says nothing about it.

The question a signature has to answer is not «is this file intact?» but «do the figures in this file still follow from the books?». Those are different questions and they need different evidence.

Freeze the figures, fingerprint the entries

Two things get stored at the moment of signing, not one:

• A copy of the figures as they stood. Not a reference to the ledger — a copy. The signed document has to be readable in ten years even if the ledger has moved on, been migrated, or been closed.
• A fingerprint of the entries that produced them: the ordered list of the postings in the period, hashed. Not the amounts alone: the list, so that removing one entry changes the fingerprint just as much as editing an amount.

With the copy, the document survives. With the fingerprint, the system can tell — cheaply, at any moment — whether the ledger still produces that document.

Warn, do not block

The tempting design is to lock the period so nothing can change. It is also the design that gets worked around within the month: corrections are legitimate, they happen, and a system that forbids them ends up with the real numbers living in a spreadsheet next to it.

The useful behaviour is the opposite. Let the correction through, and the moment the fingerprint stops matching, say so: this signed statement no longer reflects the books. Whoever signed it decides what to do — sometimes nothing, because the correction is immaterial; sometimes issue a new one.

A system that blocks the correction does not protect the evidence. It just moves the truth somewhere it cannot see.

Replace, never correct

A signed document is not edited. Ever. If the numbers have to change, a new document is issued and signed, and the previous one remains as what it is: proof of what was accepted on that date. Two documents, two signatures, one order between them.

This is the part that most implementations get wrong, and it is not a technical detail. The day the figures are disputed, an edit history on a single document invites the question of who edited what and when. Two separate documents do not: each one says what it says, and neither has ever changed.

Four questions for the system you already use

• If I fix an entry from three months ago, does anything tell me that the statement I already signed no longer matches?
• Can I open a statement signed last year if the ledger was migrated since? Does it still show the same figures?
• Is the signature over the file, or over the figures and the entries behind them?
• When a signed statement is corrected, does the old one survive, or does the system quietly overwrite it?

If any of those answers is uncomfortable, what you have is a PDF with a signature on it. That is not the same as evidence.