ByteBook Training Handbook

The audit and assurance side

The audit trail and the chain

Chapter 1211 min read

Every entry carries a fingerprint that includes the one before it. Change an old number and the chain says so.

The idea

A bookkeeping record is a claim about the past, and the claim is only useful if you can tell whether it has been altered since it was written.

ByteBook seals every entry with a SHA-256 fingerprint: a short string of characters computed from the entry's own contents — its date, its accounts, its amounts, its description. Change any of that and the fingerprint changes. There is no way to adjust an entry and keep the same fingerprint.

Then it does the second, more useful thing. Each entry's fingerprint is computed including the fingerprint of the entry before it. This is a chain, and it has a property that a list of separate fingerprints does not: altering an entry anywhere in the middle breaks every fingerprint after it. To alter an old entry and leave no trace, you would have to recompute every entry that follows, in order, in secret. The books are a file on a disk, so that is not impossible — but it is no longer a quiet edit.

What the Audit trail page shows

Open Audit trail. ByteBook recomputes the whole chain from the database, including the voided entries whose fingerprints do not change when they are voided, and reports:

  • how many entries there are;
  • how many verify;
  • how many links are broken, if any;
  • a fingerprint of the whole ledger.

If a link is broken, the page says so, and the meaning is specific: something wrote to the database outside ByteBook. That is not a bookkeeping error. It is a statement about the record itself, and it is worth more than a page of clean ticks.

The chain, drawn

The chain page draws the same thing. Every entry is a block; every fingerprint is a line between two. You can drag to move, scroll to zoom, click a block to read the entry behind it, and click a link to see the two hashes it joins. There is a filter and a search box, and a button that verifies the whole chain link by link.

Two details are worth noticing, because they are the difference between a picture and evidence:

  • The page draws only what the server recomputed from the database when you asked for it. It is not a stored image.
  • A voided entry still appears as a block. Corrections are part of the history, so they are part of the picture.

Where this fits in an audit

The chain is not a replacement for an auditor's procedures, and ByteBook does not claim it is. It answers one narrow question extremely well: has the record changed since it was written?

That question sits underneath several others. When an auditor relies on the books, they are relying on the information in them being relevant and reliable ISA (NZ) 500.7. A chain of fingerprints is evidence about reliability that is produced by the system itself, on every entry, rather than sampled.

Procedure A01 in chapter 13 reports it as part of the routine: entries verified, broken links, and the fingerprint of the whole ledger. Procedure A12 then asks the next question: does a period that was sealed still match the ledger as it stands now?

  1. Stop and find out what wrote to the file. Restore, tooling, a script, a copy edited by hand — a broken chain always has a cause, and the cause is the finding.
  2. Do not re-seal anything. Recomputing fingerprints to make a broken chain look intact destroys the only evidence you have.
  3. Record what you found. In a training exercise, that note is the answer.
Arrow keys, or the buttons