Sealed packs and working papers

Sealing a period

Fingerprints protect entries one at a time. A sealed pack protects a whole period at once.

When you seal a period, ByteBook takes its entries, its figures, the fingerprint of the whole ledger, and the fingerprint of the pack before it, and hashes them together into one value. That value is the pack's fingerprint. Verifying a pack recomputes it from the ledger as it stands now.

The consequence is sharp and easy to demonstrate:

• Backdate an entry into a sealed period and the pack's fingerprint changes. Verification fails, and it fails because of the change, not because something is missing.
• Void an entry inside a sealed period and the same thing happens — correctly, because the period's totals moved, and moving them after the fact is precisely what a sealed pack is designed to detect.

Linking each pack to the one before it means the periods form a chain of their own, one level up from the entries.

Timeline: what a pack protects

1. Work the period. Invoice, code the bank, file GST.
2. Check it. Run the assurance procedures; deal with what they found.
3. Seal it. ByteBook records the pack and its fingerprint.
4. Later, verify it. The fingerprint is recomputed from the ledger as it is now. Match or no match, with no discretion in between.
5. If it fails, find out why. In a training exercise the cause is usually a backdated entry, and finding it is the exercise.

Working papers

Every procedure offers a working paper as a CSV. That is the format an auditor actually wants: a table you can open, check, and attach to a file, with the columns named and the figures traceable.

Two things make a working paper useful, and both are about the reader rather than the writer:

• It says what was done. Not "bank checked", but the balance in the ledger, the balance on the statement, the difference, and the date.
• It says what it found. Four exceptions, listed, so that a second person can re-perform the check and get the same answer.

This is ISA 230.8 applied to a small business: documentation sufficient for an experienced auditor with no previous connection to the engagement to understand what was done, what the results were, and what was concluded.

Assembling the file

There is a finishing step, and it has a deadline. The auditor assembles the documentation into an audit file and completes the administrative process of assembling the final audit file on a timely basis after the date of the auditor's report ISA (NZ) 230.14. Where there is a legal or regulatory deadline to complete the assembly, the standard's own period applies.

In ByteBook the equivalent is short: run the procedures, download the working papers, seal the period, take a backup, and put the pack's fingerprint in the file. The fingerprint is one line, and it is what lets a reader verify the period years later without re-reading everything.

What stays outside the program

ByteBook can prove that a period has not changed, that the two sides of every entry are equal, that the bank agrees, and that the figures on the reports can be reproduced from the rows. Those are arithmetic and record-integrity claims, and a computer is good at them.

It cannot judge whether a debt will be collected, whether a provision is adequate, whether a related party transaction was on arm's length terms, or whether a business is a going concern. Those are judgements, and they come with a person's name attached.

Knowing which side of that line you are standing on is most of what makes an auditor useful.