ByteBook is a bookkeeping program for New Zealand businesses. It keeps the whole set of books in one file on the computer it runs on. It records invoices and bills, imports a bank statement and codes every line, works out the GST return, and produces the reports an accountant or an auditor asks for.

It also does something most bookkeeping programs do not. Every entry is sealed with a fingerprint when it is written, and the record can never be quietly changed: a mistake is voided, which posts the mirror image of the entry and leaves both in the books. Anyone can then re-run the checks and see for themselves that the books still add up. That is what makes ByteBook useful for training auditors as well as bookkeepers.

Why there is a handbook

Most bookkeeping training happens on a live client's file, or on a spreadsheet invented for the lesson. Neither is ideal. A live file punishes a wrong click with a real consequence; a spreadsheet does not behave like a set of books. It has no GST return, no bank reconciliation and no audit trail, so the parts that are actually hard to learn are missing.

ByteBook ships with twelve practice businesses. Each one is a New Zealand business with months of trading already in the books: a hairdresser who is not registered for GST, a builder taking stage payments, a café banking its takings, an online store handling credits and reversals, a landlord with exempt rent, a horticulture contractor on a six-monthly GST cycle, a software company with costs and no income, a dental practice where roles matter. Open any of them from Practice businesses in the app. They are copies kept beside your own books, so nothing you do in one can touch your records, and Start over puts a business back the way it was. Nothing you do in training can damage a client's records, because there is no client.

This handbook is the course that goes with it. It covers the daily work — sending an invoice, coding a bank line, filing GST — and then the audit side, where the same books are checked the way an auditor would check them. Each chapter names the accounting or auditing standard behind the step, and each reference can be followed to the publisher's own document.

Who it is for

• New accounting staff. You will do the work in a business that behaves like a real one, where a payment arrives late, a bill is paid twice, and the bank statement does not agree at the first try.
• Audit staff in training. You will meet the sixteen procedures an auditor runs, learn what each one is for, and see what the exception looks like when the books are wrong.
• Students. Every topic here is a topic in a New Zealand accounting or taxation paper, seen from the inside rather than from a textbook.
• The person running the training. Every exercise has a marking note, and the twelve sessions in Part 5 can be handed out as they are.

Three ways to use it

1. Read it straight through. The chapters follow the order a month actually happens in: set up, trade, bank, file, report, then check.
2. Work through it with the program open. Each chapter has steps to carry out in ByteBook. The work is where the learning is; the reading only gets you to the right screen.
3. Use it as a reference. The glossary explains the terms in plain words, and every standard is listed in the reference index with the screen it belongs to.

What this handbook is not

Being clear about this saves trouble later.

• It is not tax advice. ByteBook works out GST figures from your own transactions and lays them out in the boxes Inland Revenue asks for. Whether a particular sale is taxable is a question about a particular business.
• It does not replace the standards. It points at them, quotes a few words where the words matter, and names the paragraph. Read the standard itself before you rely on it. Every reference in this handbook carries the address of the publisher's document and the fingerprint of the copy we read.
• It does not replace professional judgement. An auditor does not conclude from a tick list. ByteBook reports what it found and leaves the conclusion to the person; this handbook does the same.
• It is written for New Zealand. The standards referenced are New Zealand's: NZ IFRS, which carry international accounting standards with New Zealand additions, and the ISAs (NZ), which carry the international auditing standards with New Zealand additions. GST is a New Zealand tax.

Install it

On a Mac, open the ByteBook disk image and drag ByteBook into Applications. That is the whole install. The program carries everything it needs, so it works on a computer with nothing else on it and with the internet switched off.

On Windows, run the installer and follow it. It installs for your own user account, so it does not need an administrator password, and it leaves a ByteBook shortcut in the Start menu. The Windows build is an unsigned beta, so Windows may warn you the first time; the download page publishes a SHA-256 checksum you can check the file against.

On a Mac the application is signed with ByteMind's Apple Developer ID and notarized by Apple, so there is nothing to click through: it opens on a Mac that has never seen it, with the internet switched off.

Answer four short questions

The first time ByteBook opens, it runs four short steps and then leaves you alone. You can change any answer later in Settings.

1. Your business. Its name and contact details, which print on every document. Use a pretend name for training — keeping the practice business separate from a real one matters more than it sounds.
2. GST and your balance date. Whether you are registered for GST, how often you file, whether you are on the invoice basis or the payments basis, and the date your financial year ends. These decide whether GST appears on a document and which return period a transaction falls in.
3. How you invoice. The prefix for invoice numbers and how many days a customer has to pay. (The note at the foot of an invoice is set later under Settings → Invoices.)
4. You are ready. A short checklist, and the button that opens the books.

Learning to find and correct one of these settings is part of the exercise: they all live under Settings afterwards.

Practice on a business that already exists

Setting up a business from nothing teaches you the setting up. It does not teach you what it is like to open somebody's books in the middle of a year, which is the situation most of this handbook is really about.

Practice businesses — in the sidebar under Set up — are twelve New Zealand businesses with months of trading already in their books. Each one is a different trade, and each trade brings its own kind of question:

Business	Trade	What it is there to teach
Bright Cuts	Hairdressing	A business below the GST threshold, with no tax on anything
Kōwhai Advisory	Consulting	GST on the payments basis, where the tax follows the money
Tasman Builders Ltd	Construction	Stage payments over months, where ageing matters more than the total
Harbour Cafe & Co	Hospitality	Daily takings banked in a lump, and the difference somebody has to explain
Loom & Light	Online retail	Refunds and reversals, which are not negative sales
Marine Parade Rentals	Residential property	Exempt rent, and repairs you cannot claim GST on
Whirinaki Contracting	Horticulture	Seasonal work on a six-monthly GST period
Foundry Labs	Software	A year of costs and no income, funded by somebody else
Marine Parade Dental	Health	Staff, an accountant who may look but not touch, and an access log
Ngata Plumbing Ltd	Trades	A busy bank statement, with two payments that look identical
Pacific Trading Ltd	Wholesale	Imports, and a balance date that is not 31 March
Precision Engineering Ltd	Engineering	Amounts that break careless rounding, to the cent

Press Start this business and ByteBook opens that business's books. A line at the top of every page says which business you are in, and it carries Back to my books so you can always get back. The practice business is a copy kept beside your own books, so nothing you do in it can touch them. Work you do there is kept; Start over puts the business back the way it was.

A practice business lives in a folder called training beside your own books. On a Mac that is ~/Library/Application Support/ByteBook/training/, and on Windows it is %APPDATA%\ByteBook\training\. Each business is one file, so copying its folder is a complete backup of it.

Every one of these businesses is complete and internally consistent: open the audit trail on any of them and the chain verifies, and the assurance programme reports no exceptions. (It may show a note for information — a bank statement balance saved with the business, for instance, can be older than the books.) What is waiting in them is the ordinary work of a business — invoices past their due date, an unpaid bill, a draft to finish, a reconciliation to check — and What to try on each one is a place to start.

Give yourself a role

By default ByteBook opens without a password, which is right for a computer only one person uses. For training it is better to switch security on, because the roles are part of what you are here to learn:

Role	May do
Owner	Everything, including settings, backups and who can sign in
General manager	Run the books: invoices, bills, bank, GST, reports
Accountant	Read everything, including the tax working papers; change nothing
Auditor	Read the books and the assurance work, change nothing

Turn on Settings → Security, set your own password first, then add the other roles. ByteBook will not switch anyone else's access on until the owner has a password, so a login cannot be handed out that locks the owner out.

The distinction between reading and changing is the point. An auditor who cannot change the books is not a technical detail; it is the arrangement that makes the audit worth anything.

The assistant, if you switch it on

The assistant is off by default, and while it is off ByteBook never contacts anyone. Settings → Assistant switches it on: choose a provider, add an API key, and press Test connection, which sends one tiny request and nothing from your books.

The key is kept outside your books, in the operating system's secure store where there is one, so a backup of the books does not carry the key with it. If a key looks incomplete after you paste it, ByteBook tells you on the same page instead of failing quietly later — paste the whole key and save again.

What a request sends is limited to what the question needs: account names and balances, plus customer names only when you ask it to draft an invoice. Bank account numbers and contact details are not sent. With a local model (Ollama), nothing leaves the computer at all.

The assistant explains and drafts; it does not post entries. Every figure it quotes comes from the page you were looking at, so it can be checked there.

Know where the books are

The whole bookkeeping record is one file. On a Mac it lives in ~/Library/Application Support/ByteBook/; on Windows it lives in %APPDATA%\ByteBook\. Beside it is a backups folder that keeps the last thirty copies.

That single file is worth understanding before you start. Backing up a set of books is copying one file. Moving them to another computer is copying one file. Nothing in it is locked to ByteBook, although reading it without the program needs a database viewer. It also means the fingerprint chain described in chapter 12 has something to protect: the record is a file on a disk, and the chain is what tells you whether anyone has edited it.

Your first walk-through

Before you change anything, look at the main areas of the screen. In ByteBook's sidebar they are grouped by what they are for:

Everyday — Overview, Invoices, Bills to pay, Bank & coding, Transactions, Timesheets. This is where the business happens.

Understand — Reports, GST, Assistant, Audit trail, Assurance, The chain. This is where you read what the business did.

Set up — Customers & suppliers, Chart of accounts, Recurring, Practice businesses, Settings, Help. This is where you configure it.

ByteBook ships with twelve practice businesses. Each one is a real shape of New Zealand business, and each one already has months of trading in its books: invoices sent and partly paid, bills to pay, a bank statement coded line by line, GST returns worked out, and reports ready to read.

Business	Trade	What it is there to teach
Bright Cuts	Hairdressing	Not registered for GST, so no GST appears on any document and none is claimed back
Kōwhai Advisory	Consulting	GST on the payments basis: the same invoice changes periods depending on when the money arrives
Tasman Builders Ltd	Construction	Stage payments against one contract, so one job produces several invoices over months
Harbour Cafe & Co	Hospitality	Daily takings banked in a lump, so the money in the bank is not the money rung up
Loom & Light	Online retail	Refunds and reversals: a credit is not a deleted sale, and the record shows both
Marine Parade Rentals	Residential property	Rent is exempt, so there is income with no GST and costs whose GST cannot be claimed
Whirinaki Contracting	Horticulture	A six-monthly GST period, so one return covers a lot of trading
Foundry Labs	Software	A year of costs and no income: the loss and its funding are the story
Marine Parade Dental	Health	Roles, an accountant who may look but not touch, and an access log
Ngata Plumbing Ltd	Trades	A busy bank statement with lines of every kind, and two payments that look identical
Pacific Trading Ltd	Wholesale	Importing stock, selling it here, and a balance date that is not 31 March
Precision Engineering Ltd	Engineering	Amounts built to break careless rounding: odd quantities, long prices, a cent that will not sit still

Open one

1. In the sidebar, under Set up, choose Practice businesses.
2. Read what each business is there to teach. Under What to try there are four things worth doing in that business.
3. Press Start this business. ByteBook closes and opens again on that business's books, and a line at the top of every page says which business you are in.

Your own books are never touched. A practice business is a copy kept beside them, and the line at the top of the page is how you always know which set you are looking at.

Come back, or start again

• Back to my books. The line at the top of every page has this button. It closes the practice business and opens your own books again.
• Continue. If you have already worked in a business, the button says Continue and it picks up where you left off. Work you do in a practice business is kept.
• Start over. This puts the business back exactly as it was, ready for the next person. You cannot start over the business you are currently in — open another one, or your own books, first.
• Save a copy of these books. Downloads the practice business as an ordinary ByteBook file, which you can open from **Practice businesses → Open your own books from a file**.

What is already true of all twelve

Every one of these businesses is complete and internally consistent. Before they shipped, each was traded through the real application and then checked from the raw rows:

• every entry balances, so money in equals money out;
• every invoice's lines add up to its total;
• the GST in the return equals the GST in the ledger;
• the balance sheet balances;
• nothing is stored off the cent;
• a voided entry cancels itself out;
• the fingerprint chain has no breaks;
• the assurance programme reports no exceptions (it may still carry notes for information).

That last point can sound odd in a training business. It is deliberate. What is waiting in these books is the ordinary work of a business — invoices past their due date, a bill still to pay, a draft invoice to finish, a bank reconciliation to check — not a planted mistake. Your job is to do the work and read the evidence, not to hunt for something the program has hidden.

Why this matters more than it sounds

A rule that is easy to state is often hard to apply. Inventory is measured at the lower of cost and net realisable value NZ IAS 2.9 is one sentence. Knowing when a selling price has fallen far enough that the book value has to come down is a judgement, and judgement needs practice on something that behaves like a real business.

The awkward cases are in these books on purpose:

• a customer who pays late, so the aged debtors report has something in it;
• two identical-looking payments to the same supplier, which you have to check are genuinely two payments (A03 lists identical lines for you to check, and A08 looks for the same amount described the same way twice in a week);
• a manual journal, which an auditor will ask about;
• a bank statement that has to be reconciled, with a closing balance that has to come from the statement rather than from the ledger;
• a period that can be sealed, and then checked again later.

Choosing where to start

If you are new to bookkeeping, start with Kōwhai Advisory (consulting). It is a small business with ordinary transactions and one late payment.

If you are here for the audit side, start with Ngata Plumbing Ltd (trades). A busy bank statement produces more coding decisions, more places to make a mistake, and a more interesting reconciliation.

If you are teaching, use Precision Engineering Ltd last. It is built from the amounts that break careless rounding, and it shows why money has to be kept in whole cents: a cent cannot go missing when amounts are added.

What an invoice does

An invoice does two separate things, and keeping them separate prevents most of the confusion in this chapter.

1. It is a document. It goes to a customer, it shows what was supplied, what it cost, how much GST is included, and when payment is due. ByteBook prints it with your letterhead, and the same page can be saved as a PDF or posted.
2. It is an accounting entry. When the invoice is posted, the books record money owed to you, the revenue you have earned, and the GST you have collected.

You can create an invoice as a draft, which does the first job and not the second. A draft is a document you can still change. Nothing in your reports moves until you post it. That distinction is the single most useful thing to understand about the Invoices screen.

Raise one

1. Go to Invoices → New invoice.
2. Choose the customer. If they are not there, add them first under **Customers & suppliers**. Their GST number, if you record it, prints on the invoice, but it is not what makes the invoice valid: a tax invoice has to show your own GST number.
3. Add the lines: what you supplied, the quantity, and the price.
4. Decide how the price is expressed. ByteBook stores every amount **excluding GST** and holds the GST separately, so no report ever has to guess which way a number was meant. Choose Yes — the price already includes GST if the price you were given already includes it, and ByteBook will take the GST out.
5. Put it in my books now is already ticked. Leave it ticked to post the invoice immediately, or untick it to keep the invoice as a draft.

When revenue is recognised

This is where the accounting standard earns its place, and it is worth reading slowly.

Revenue is recognised when the business satisfies a performance obligation by transferring a promised good or service to the customer NZ IFRS 15.31. Not when the invoice is raised, not when the money arrives: when the promise is kept.

For most small businesses, those three dates are close enough together that the distinction does not bite. It bites in these cases:

• Stage payments on a contract. The Tasman Builders practice business raises several invoices for one job. Each invoice recognises revenue for the work it covers, because that is the work that has been transferred.
• A deposit taken before any work is done. Money received is not revenue yet. It is money you owe back in services.
• A service delivered in March and invoiced in April. The revenue belongs in March.

ByteBook will not stop you from posting an invoice on the wrong date. It records the date you enter, and the reports follow it. Choosing the right date is the job.

What posting does to the books

Posting an invoice creates one balanced entry. Three things happen at once:

Side	What it means
Money owed to you goes up	An asset. The customer owes the business
Revenue goes up	Income, recorded excluding GST
GST collected goes up	A liability you owe Inland Revenue, not income

The last line is the one people get wrong by hand. GST collected on a sale is never income. It is money held on behalf of Inland Revenue until the return is filed, which is why ByteBook keeps it in its own account and reports it in box 8 of the return.

Common mistakes

• Treating GST collected as income. Check that revenue in the profit and loss report is the figure excluding GST.
• Raising an invoice and assuming it is in the books. Look for the word draft. A draft is a document, not an entry.
• Entering a GST-inclusive price as if it excluded GST. The invoice then overstates revenue by the GST. ByteBook's totals make the error visible: the invoice total will not match the amount you agreed with the customer.

In the transaction list

Every posted invoice appears under Transactions with its own entry, and the entry shows both sides. Open one and read it. Learning to read the entry behind the document is the skill this screen exists to teach, and an auditor who cannot read the entry behind a document is stuck at the first question.

Recording a payment

When money arrives, open the invoice and use the payment box. ByteBook applies the amount against the invoice, marks it paid or part-paid, and posts an entry that moves money from owed to you into the bank.

Part payments work the same way. Record what actually arrived. If a customer short-pays because of a dispute, the balance stays on the invoice, and the debtors report keeps showing it, which is how the question gets asked.

What the aged debtors list is for

Reports → Who owes what lists what customers owe, grouped by how long it has been owed. It is not a statement about whether the money will arrive. It is a statement about what has been invoiced and not yet paid, and it is the starting point for two different jobs:

• Chasing the money. ByteBook can draft a reminder letter for any unpaid invoice. The text is a starting point; the relationship is yours.
• Judging whether the money is real. A debt that is not going to be paid is not an asset worth its face value.

The second question: will it be paid?

This is where a bookkeeping exercise turns into an accounting judgement. Trade receivables are measured at an amount that reflects the cash the business expects to collect, and for trade receivables the loss allowance is measured at lifetime expected credit losses NZ IFRS 9.5.5.15. In plain words: for money owed by customers, you start from the assumption that some of it will not be paid, and you estimate how much.

The usual approach in a small business is a provision matrix. Group the debtors by age, apply a percentage to each group based on experience, and add the results:

Age	Typical treatment
Current	No allowance, or a very small one
1–30 days past due	A small percentage
31–90 days past due	A larger percentage
Over 90 days	A large percentage, or the whole amount
Identified as bad	The whole amount

Two things make this a professional judgement rather than arithmetic. The percentages have to come from somewhere — the business's own history, or industry experience — and a specific debt known to be bad is written off in full whatever the age table says.

What the auditor asks next

An auditor does not take the debtors list at face value. The main procedure is external confirmation: asking the customer, directly, whether they agree that they owe the amount. Where the answer raises doubt about its reliability, the auditor has to obtain further evidence to resolve it ISA (NZ) 505.10.

In the practice businesses, the debtors procedure reports:

• how much is owed and how much of it is late;
• any document that looks overpaid, which usually means a payment went to the wrong invoice or was recorded twice;
• the invoices that have been owed for more than 90 days.

The procedure reports what it found. Whether a 90-day debt will be paid is a question for a person, and ByteBook does not pretend otherwise.

Common mistakes

• Recording a payment against the wrong invoice. The total owed is right and the ageing is wrong, which hides a real problem. Check the invoice number on the remittance.
• Treating a part payment as full settlement. ByteBook keeps the balance open, and that is correct.
• Writing off a debt by deleting the invoice. ByteBook will not let you delete it, and that is also correct: the record of the sale and the record of the loss are both part of the history. Void the invoice, or post the write-off as an expense, and the trail stays readable.
• Leaving the allowance at last year's percentage without looking. The estimate is meant to describe this year's debts.
• Leaving a payment against the wrong invoice. Open the invoice, choose Reverse the payment, and record it against the right one. The correction stays in the record beside the mistake, and the invoice can then be voided if it should never have been raised.

Two kinds of outgoing

Money leaving a business arrives in two shapes, and ByteBook keeps them apart:

• A bill. An invoice from a supplier, with a due date, that you will pay later. Record it under Bills to pay. Until it is paid it sits in creditors.
• An expense paid now. Money that has already left the bank. Usually you meet these while coding the bank statement, in chapter 7.

Both end up in the same place: an expense in the profit and loss report, and a GST credit if the purchase carried GST.

Record a bill

1. Go to Bills to pay → Record a bill.
2. Choose the supplier. Add the supplier's GST number to the contact if it is missing. It is needed on their tax invoice, and ByteBook's documents procedure reports the ones that do not have it.
3. Enter the lines, and mark whether the amounts include GST.
4. Save. The bill is now in creditors, and the expense is in the books.
5. Pay it when the money leaves, from the bill itself, so the payment and the bill stay linked.

The document, not just the number

For a bookkeeping record to be worth anything, each figure has to be traceable to the document behind it. Inland Revenue's rule is practical: a tax invoice for more than $50 has to show the supplier's GST number, among other things. ByteBook's documents procedure checks for that and reports the documents that have something missing.

An auditor's version of the same question is in the auditing standard on audit evidence: the auditor designs and performs procedures that are appropriate in the circumstances for obtaining sufficient appropriate audit evidence ISA (NZ) 500.6, and considers the relevance and reliability of the information used as evidence ISA (NZ) 500.7. A supplier's own tax invoice is stronger evidence than a note in a diary.

Getting the expense in the right period

An expense belongs in the period the business consumed whatever it paid for, not the period the money left the bank. Two common cases:

• A bill received in March for February's electricity. The expense belongs in February, when the power was used, even though the bill arrived in March. Post it with February's date.
• A payment in April for a service covering April to June. Part of it belongs in a later period. That part is a prepayment.

Procedure A11 lists the large one-off costs where these questions have to be asked; deciding whether a cost is personal or an asset is yours, not the program's.

If a figure is found to be wrong after the financial statements were issued, material prior period errors are corrected retrospectively NZ IAS 8.42. If the business changed an estimate — how long a machine will last, for instance — the effect is recognised prospectively, in this period and later ones NZ IAS 8.36. An error and a change in estimate are different things, and they are accounted for differently, which is why the distinction is worth learning early.

Expenses an auditor looks at twice

The expenses procedure in ByteBook is deliberately blunt. It reports the three patterns where an expense account is most often wrong:

• Round numbers. A $1,000 payment described as "sundry" is a question, not an answer.
• Large one-off costs. Above about $1,000, the question is whether it was an expense at all, or something the business now owns. An item of property, plant and equipment that qualifies for recognition is measured at its cost NZ IAS 16.15, and depreciation begins when it is available for use NZ IAS 16.55, not when it was paid for.
• Costs that look personal. These matter for two reasons: they may not be deductible, and if the owner took value out of the company this way, the transaction may be with a related party.

Related parties

A small company's transactions with its owners and their other businesses are related party transactions, and they get special attention because they are where the interests of the business and the interests of an individual can diverge. An auditor is required to inquire of management about the identity of the entity's related parties, including changes from the prior period, and about the nature of the relationships and transactions ISA (NZ) 550.13.

In practice: if the business paid money to a person or a company connected with the owner, say so, and keep the paperwork.

Why this chapter matters most

The bank statement is where the books meet the outside world. It is also where most small-business bookkeeping errors live, because coding a bank line is a judgement made quickly, hundreds of times.

Get this screen right and the rest follows: the GST return falls out of the coded transactions, the reports are sums of real rows, and the reconciliation tells you whether you are finished. Get it wrong and every later figure is wrong in a way that is hard to see.

Import

Download a CSV from your internet banking, then open Bank & coding, choose Import a bank statement, pick the file and say which account it came from. ByteBook reads the columns, works out which is the date, the description and the amount, and skips anything that has already been imported, so importing the same file twice does not double the books. Two identical lines in one statement are kept as two lines: two coffees on the same day are two coffees. Only a re-import is skipped.

If your bank's export looks unusual, the page offers a CSV template showing the shape ByteBook expects.

Code each line

Every imported line is a question: what was this for? You answer by choosing an account. ByteBook guesses from the description, and you confirm or correct it.

Three answers are possible:

• Code it to an account. The line becomes a real transaction in the books.
• Mark it as not business. The line stays on the statement and out of the reports. A personal coffee on the business account belongs here, or better, it belongs in drawings.
• Leave it waiting. Nothing in the reports moves until you decide.

The screen tells you how many lines are waiting. Until that number is zero, the books are incomplete, and a report run now is a report on part of the period.

Does it agree with your bank?

There is a second half to the screen, and it is the one that turns coding into assurance. Enter the closing balance and the date from your bank statement, and ByteBook compares its own bank balance with the bank's figure.

Two agreements matter.

The bank agrees. The balance ByteBook holds for the bank account equals the balance on the statement at the statement's date. ByteBook remembers the last balance and date you entered, so check they are current: an old closing balance produces a difference that is a stale note, not a bookkeeping error. If it does not, either something has not been recorded, or something has been recorded twice, or the date is wrong. This is bank reconciliation, and it is procedure A03 in chapter 13.

Every line has been dealt with. The number waiting to be coded is zero, and nothing has been left in a half-finished state. A reconciliation that matches on the balance but has twenty uncoded lines is not a reconciliation.

Why the reconciliation is evidence

An auditor treats a bank confirmation as strong evidence, because the answer comes from outside the business. The auditing standard on external confirmations deals with the auditor's use of a confirmation request, and requires further evidence where the reliability of a response is in doubt ISA (NZ) 505.10. The statement you import is the same kind of evidence: it was produced by the bank, not by the business.

That is why the reconciliation is worth doing even when the balance already looks right. It is not arithmetic housekeeping. It is the test that ties the books to something outside them.

Common mistakes

• Coding a line to the wrong side. A payment received coded as an expense cancels the error in the total while leaving the GST and the customer balance wrong.
• Choosing the wrong GST treatment for the account. The bank line is what left the account, GST included, and ByteBook always takes the GST out of that amount. What it needs from you is the account the money was really for, because that decides whether the payment carries GST at all.
• Reconciling to the wrong date. Agree the balance at the statement's date, not at today's date.
• Marking a business line as not business to clear the list. The waiting count goes down and the books get worse. If you are unsure, leave it waiting and find out.

What the GST screen does

Open GST and ByteBook shows the return for the period you choose, built from the transactions in your books. Nothing is typed in twice and nothing is estimated: every box is a sum of coded entries, and every figure can be traced back to the transactions that produced it.

The boxes you will meet:

Box	What it is
5	Total sales and income from taxable supplies, including GST
6	Zero-rated supplies included in box 5
7	Sales subject to GST (box 5 minus box 6)
8	GST on sales
9	Debit adjustments
10	Total GST collected (box 8 plus box 9)
11	Total purchases and expenses for GST, including capital purchases
12	GST on purchases
13	Credit adjustments
14	Total GST credit (box 12 plus box 13)
15	GST to pay, or refund due (box 10 minus box 14)

If you registered part-way through a year, enter the date in Settings → Tax → Registered from. Transactions before that date are outside the GST return, and a period that ends before it is not a filing period.

Selling a business asset is a taxable supply when the asset was used in the taxable activity: the proceeds go in Box 5, the sale is part of Box 7, and the GST is Box 8. It is not an "adjustment".

The numbers are those on the GST101A return you file in myIR, and ByteBook shows the same boxes. Box 11 is the standard-rated side of purchases and expenses, including capital purchases; exempt, imported and settlement transactions are outside it. Boxes 9 and 13 are for adjustments, and are zero unless something like a bad debt adjustment has been entered.

Box 5 covers sales and income from your taxable activity: standard-rated sales with their GST, and zero-rated sales. Exempt supplies - residential rent, interest, bank fees - are not part of the GST return at all, so they do not appear in Box 5 or Box 8. Keeping sales and the GST on them apart is the point of the box structure, and mixing them up is the most common GST error in small-business records.

Work out a period

1. Choose the period. ByteBook offers the cycles that match your filing frequency, and you can set any start and end date.
2. Press Recalculate. The boxes fill in from the ledger.
3. Read the Result: GST on sales less GST on purchases, which is box 15, the amount to pay or the refund due.
4. Check the period against the ledger before you go further. The GST reconciliation procedure (A06) checks that the GST in the return is the GST in the ledger, transaction by transaction.
5. Save this as a snapshot. The snapshot is a record of what you filed, at the date you worked it out, and it stays after the transactions move on.
6. Mark as filed once you have entered the figures in myIR. If the ledger is changed after that, ByteBook warns that the filed return no longer matches the books.

Invoice basis and payments basis

The basis you chose when you set the business up decides which transactions fall inside a period:

• Invoice basis. GST is accounted for when the invoice is issued or received, whether or not the money has moved. A sale invoiced in March is in the March period even if the customer pays in May.
• Payments basis. GST is accounted for when money actually moves. The same March invoice belongs in the period the payment arrived.

Most small businesses can use the payments basis; larger ones cannot. The choice changes the figures in every period, and it is the reason two businesses with identical invoices can have different returns.

ByteBook works the return out on the basis in your settings, and the basis is shown beside the figures. Read it before you read the numbers: a figure without its basis is a figure you cannot check, and changing the basis can move the same transactions to a different period.

When a sale carries no GST

Not every sale is taxable. The Marine Parade Rentals practice business earns exempt rent beside taxable supplies. Exempt supplies are outside the GST return: they do not appear in box 5 or box 8, and the business cannot claim GST on costs that relate to them. Zero-rated supplies are different: they are taxable supplies at 0%, so they do appear in box 5 (and box 6) with no GST.

This is where a bookkeeping exercise becomes a tax question, and it is worth being plain about the limit: ByteBook adds up what you coded. Whether rent, a particular financial service or a going concern is taxable, zero-rated or exempt is a question about the specific supply, and Inland Revenue's own guidance is the authority for it. Getting the treatment wrong is easy to do and expensive to fix.

A note on income tax

GST is not income tax, and the two should never be mixed in your thinking. GST is a tax on the supply of goods and services, collected by the business on Inland Revenue's behalf. Income tax is a tax on profit. A GST return says nothing about whether the business made money.

For income tax, ByteBook prepares the working papers: Reports → IRD working papers builds the IR3, IR10 and IR4 figures from the same ledger. Current tax is measured at the amount expected to be paid to the taxation authorities, using the tax rates and laws that have been enacted or substantively enacted by the reporting date NZ IAS 12.46.

Common mistakes

• Filing before every bank line is coded. The return is built from transactions. A line still waiting is a transaction the return has not seen.
• Recording a GST-inclusive figure as the GST amount. At 15%, the GST inside a GST-inclusive amount is three twenty-thirds of it: $15 in $115. ByteBook works that split for you. Reading box 5 as though it were box 8 is the mistake to avoid.
• Filing without saving a snapshot. Then there is no record of what was filed, and the reconciliation has nothing to compare against. If the ledger is changed later, ByteBook warns that a filed period no longer matches its snapshot — read that warning, because the return you filed and the books you now hold disagree.
• Filing on the wrong basis. The basis is a setting, not a rule of bookkeeping. Check the word beside the figures before signing the return.
• Treating a refund as negative sales in the wrong period. A credit note or a refund reverses the sale it corrects, and the period it lands in matters.

One report, one question

ByteBook's main reports are deliberately narrow. Each one answers a single question, and knowing which question saves a lot of time.

Report	The question it answers
Profit and loss	Did the business make money in this period?
Balance sheet	What does it own and owe, as at this date?
Trial balance	Do the accounts add up, and does the ledger balance?
General ledger	What happened in this account, entry by entry?
Money in and out	Where did the money come from and go?
Who owes what	Who owes us, and who do we owe?

Profit and loss

Income less expenses for a period. Income is recorded excluding GST, because GST collected was never the business's money.

One choice matters more than it looks. Expenses can be analysed by nature — what was bought, such as wages, rent, power — or by function — what the cost was for, such as cost of sales and administration. The standard requires one or the other, whichever provides information that is reliable and more relevant NZ IAS 1.99. ByteBook's chart of accounts is arranged by nature, which suits a small business and is easy to check.

Balance sheet

Assets, liabilities and equity at a date, and the arithmetic that has to hold:

assets − liabilities = equity

ByteBook computes that difference and states it on the page. If it is not zero, the page says so rather than hiding it. A balance sheet that does not balance is not a presentation problem; something is wrong in the ledger, and the figures are not usable until it is found.

The statement of financial position has to include certain line items where they are relevant, such as property, plant and equipment, inventories, trade and other receivables, cash, and trade and other payables NZ IAS 1.54. ByteBook groups its accounts to present them, and the general ledger is where you go when you want to see what is inside a line.

Trial balance and general ledger

The trial balance is every account with its balance, and the check that total debits equal total credits. It is the fastest way to find that something is wrong.

The general ledger is the detail. Pick an account and see every entry that touched it, in order. When a report figure looks wrong, this is where the answer is: not in the report, which is a sum, but in the rows that were summed.

Money in and out

Profit and cash are different things, and Money in and out is where the difference starts to show. ByteBook's report lists the money that actually arrived and left each month, and the balance it leaves in the bank. That is the raw material of a cash flow statement, not the finished statement.

A full statement of cash flows classifies every movement as operating, investing or financing NZ IAS 7.10, and is prepared using either the direct method or the indirect method NZ IAS 7.18. Transactions that involve no cash are left out of it and disclosed separately NZ IAS 7.43. A vehicle bought with a loan is the classic example: a real transaction, no cash, so it has to be disclosed rather than shown as a payment.

ByteBook does not build that classified statement. For a small business, the "money in and out" list plus the profit and loss and balance sheet is usually enough to answer the question. Where a full statement is needed — a lender, a sale, a formal set of financial statements — the classification is done from these reports.

Checking a report rather than trusting it

Every report in ByteBook is a sum of the entries in the ledger. The final assurance procedure, A14, goes further: it rebuilds the trial balance from the raw rows, checks debits equal credits, and recomputes the balance-sheet difference that the page reports.

This check exists because there are two different ways for a number to be wrong. The books can be wrong — a transaction coded to the wrong account — and the report can be wrong, through a defect in the program that builds it. The first is a bookkeeping problem; the second is a reporting problem, and no amount of careful coding will fix it.

A figure you cannot reproduce from the rows underneath it is not yet evidence.

A closing routine

Closing a period is not an accounting event managers attend to. It is a short list of checks, done in order, that ends with a set of books you would be willing to hand to someone else.

1. Every bank line is coded. The waiting count on Bank & coding is zero.
2. The bank agrees. Reconcile to the statement's closing balance and date.
3. Outstanding items are current. Look at who owes you and who you owe. Anything long overdue is either a collection problem or a recording problem.
4. Prepayments and accruals are posted. Money paid in advance for a later period, and costs incurred but not yet invoiced.
5. Depreciation is posted. For each class of asset, the depreciable amount is allocated on a systematic basis over its useful life NZ IAS 16.50.
6. Provisions are reviewed. A provision is recognised where there is a present obligation from a past event, an outflow is probable, and the amount can be estimated reliably NZ IAS 37.14.
7. The GST period is saved as a snapshot and marked as filed.
8. The reports are reproduced. Run the assurance procedures and confirm that the figures on the reports can be recalculated from the rows.
9. The period is sealed. See chapter 14.
10. A backup is taken. Settings → Backups & data, then Back up now, writes a copy of the whole set of books beside them.

Inventories, if the business holds any

Inventories are measured at the lower of cost and net realisable value NZ IAS 2.9. Cost includes the costs of purchase, the costs of conversion and the other costs incurred in bringing the inventories to their present location and condition NZ IAS 2.10, and it is assigned using first-in, first-out or a weighted average NZ IAS 2.25.

Net realisable value is the estimated selling price less the estimated costs of completion and sale. Where cost is not recoverable — damaged stock, or stock whose selling price has fallen — the write-down is recognised as an expense in the period it happens NZ IAS 2.28.

The Pacific Trading practice business trades inventory, so this is where to practise it. ByteBook records the purchases and sales; the closing stock value is a calculation you make and keep with the working papers.

Leases, if the business rents premises or equipment

A contract is, or contains, a lease if it conveys the right to control the use of an identified asset for a period of time in exchange for consideration NZ IFRS 16.9. At the commencement date the lessee recognises a right-of-use asset and a lease liability NZ IFRS 16.22.

In plain words: a long lease is recognised in the balance sheet, not simply expensed as rent. Short-term and low-value leases have practical exemptions, which is why the rent line in a small business is a mix of both treatments.

Events after the reporting date

Work does not stop on balance date. The standard divides the time afterwards into two kinds of event, and the treatment differs:

• Adjusting events provide evidence of conditions that existed at the reporting date. The amounts in the financial statements are adjusted to reflect them NZ IAS 10.8. A customer who owed $40,000 going into liquidation shortly after balance date is the classic example: the customer was already in trouble at the date.
• Non-adjusting events concern conditions that arose after the reporting date. The amounts are not adjusted, but a material event may still need to be disclosed NZ IAS 10.10.

An auditor performs procedures designed to obtain sufficient appropriate audit evidence about events between the date of the financial statements and the date of the auditor's report ISA (NZ) 560.6. After the report is signed, the auditor has no obligation to keep looking — but if a fact comes to light before the statements are issued, the standard says what to do about it ISA (NZ) 560.10.

Going concern

One question sits underneath all of this. Are these financial statements prepared on the basis that the business will keep trading?

The objective of the auditor is to obtain sufficient appropriate audit evidence about, and conclude on, the appropriateness of management's use of the going concern basis of accounting ISA (NZ) 570.9. Where management has not yet made an assessment, the auditor asks them to make one ISA (NZ) 570.16.

For the person doing the books, the practical version is this: if the business cannot pay its debts as they fall due, the accounts look different, and the time to raise it is during the closing routine rather than after the statements are issued.

The temptation

You post an invoice to the wrong customer. Or an amount is typed as $1,290 instead of $1,209. The tidy thing is to fix it: change the number, and the books look as though the mistake never happened.

That is exactly the habit this chapter is here to break.

What ByteBook does instead

No posted entry in the books is deleted or edited in place. A mistake is voided. Voiding marks the original entry as void and posts the mirror image of it: the same accounts, the same amounts, the opposite direction. Both stay in the books and both are still counted, so they cancel each other out in every total. The figures end up where they should have been, and the record shows both what happened and what was done about it.

Drafts are different: a draft is not in the books yet, so it can be changed or deleted. Bank lines that have not been coded can be removed from the statement, and ordinary names, accounts and settings can be edited. The rule is about posted entries, which are the record.

Three consequences follow, and each is worth knowing:

1. The net effect is correct. The books are not wrong because a mistake was made and corrected. They are wrong only if the mistake is still uncorrected.
2. The history is intact. Anyone can see that an entry was raised in error, on what date, and what was done.
3. The fingerprint chain still holds. A voided entry keeps the fingerprint it was sealed with, so voiding does not break the chain that chapter 12 describes. Editing the original would break it immediately.

What this has to do with auditing

An auditor's working papers have to do a specific job: they must allow another auditor, who has never seen the engagement, to understand what was done. The auditing standard puts it plainly. The auditor shall prepare audit documentation that is sufficient to enable an experienced auditor, having no previous connection with the audit, to understand the nature, timing and extent of the procedures performed, the results, and the significant matters and judgements ISA (NZ) 230.8.

Now read that against the two habits:

Habit	What the next auditor can see
Edit the entry	A number that has changed, and no record of what it was
Void and re-post	The original, the correction, the dates, and the reason

The second one is a working paper. The first one is a gap, and an unexplained gap in a set of books is worse than a visible mistake.

The same discipline applies to the person doing the books. Documentation has to be prepared on a timely basis ISA (NZ) 230.7 — which in practice means correcting an entry when you notice it, not at the end of the year when you have forgotten why.

How to void something in ByteBook

Open the document or the transaction, choose Void this document (or Void and reverse on a transaction), and write the reason. The reason is optional in the form, but write one: it is the part that matters six months later. If a payment has already been recorded, open the invoice first and choose Reverse the payment, then void.

The entry and its mirror image remain in the books, the pair cancels out in the totals, and the audit trail records what happened.

A practical rule

Before you correct anything, ask what a new person would need to see in order to agree with your corrected figure. If the answer involves knowing something that is not written down, write it down. That is the whole of it.

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 recorded entries, 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 books 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 shows the same thing at three scales, because one picture cannot answer both "is this intact?" and "what exactly is in this entry?".

The ribbon is the whole record on a time axis. Each mark is one day, and how tall it is tells you how many entries that day holds. Under the marks runs the chain itself — a line that is solid where the links hold and broken where they do not. Under that, each sealed period is drawn as a span across the days it covers, linked to the period before it. Everything the record has ever held is in that ribbon: it is not sampled and it is not paginated.

The chain below is the entries in order, each one a block and each fingerprint a line between two. The window starts at the most recent two dozen entries; click a day on the ribbon to open it, or press Everything to see the lot. Click a block to read the entry behind it, click a link to see the two hashes it joins. A correction is a block too: a voided entry stays in the picture, because it is part of the history.

The panel beside them takes one entry apart. It shows what was hashed — the date, the reference, the description, the type, the accounts and the amounts — and the fingerprint that came out, and which entry before it points at it. Then it offers the thing a chain cannot offer on its own: Fetch the proof. That returns the handful of sibling hashes that carry this one entry up to the Merkle root of the whole ledger, and whether they arrive there.

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

• The page draws only what ByteBook recomputed from the entries when you asked for it, and it does no arithmetic of its own. Even the proof is checked by ByteBook and reported on the page.
• The ribbon can be read in one glance, which matters when the answer is "no": a break is a break in the line, not a block you have to hunt for.

Proving one entry without the whole ledger

The chain and the tree answer two different questions, and it is worth keeping them apart.

The chain asks has anything moved? To answer it you have to read every entry from the beginning, because each one is built on the one before. That is the right question for the owner of the books and the wrong one for somebody checking a single invoice.

The Merkle tree asks was this entry in the ledger? The fingerprints of all the entries are folded together in pairs until one value is left, and that value is the Merkle root. To prove that one entry belongs, you need its fingerprint and one sibling hash per level: about ten hashes for a thousand entries, not a thousand.

That is what Fetch the proof gives you, and what chapter 14 puts in the file an external auditor can check on their own computer.

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?

What catches what

Five things can happen to a record, and they are not caught by the same thing. Knowing which is which is most of what makes the rest of this part useful.

If somebody…	What catches it
changes a figure in an old entry	the entry's own fingerprint: the block turns red
deletes an entry from the middle	the link the next entry carries
posts into a period that was already sealed	procedure A09, and the pack itself
rewrites the whole record, end to end	a receipt held outside the file
enters a figure that is simply wrong	a person

The fourth line is the one people find surprising, and it is worth being exact about. Somebody with the file, the algorithm and the patience can recompute every fingerprint and leave a chain that verifies perfectly. Nothing inside the file can detect that, because there is nothing inside the file that disagrees. A copy of the fingerprints held somewhere else can, which is what a checkpoint receipt is for. See chapter 14.

What to do when a link breaks

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.

What gets hashed, exactly

It is worth reading once, because it is where a chain either holds or leaks. The fingerprint of an entry is computed from this text and nothing else:

id | date | reference | description | type | fingerprint of the entry before
   | account:amount:amount | account:amount:amount | …

Voiding an entry afterwards does not change its fingerprint. That is deliberate: voiding is a legitimate correction, and a correction that broke the chain it sits in would make the chain useless. The reversal is posted beside the original, and both stay in the chain.

Two consequences follow, and both are worth knowing before somebody asks.

What the fingerprint covers: the money, and the words that identify the entry. A change to any of those is caught, on that entry and on every entry after it.

What it does not cover: the tax code on a line, the contact, and the line description. Those can change without breaking the chain. A chain that verifies is therefore proof that the amounts and the entry itself are as they were written, and not proof that the GST treatment is the one somebody typed.

That gap is why the tree exists. Its leaf for an entry is a fingerprint of every field the entry holds — the tax codes, the contacts and the line descriptions included — written as JSON with sorted keys so it cannot be rearranged into a different entry. The leaf is not stored and not chained: it is recomputed from the row whenever it is needed, which is what lets it afford to be that greedy.

So there are two fingerprints, and it is worth keeping them apart:

• the chain fingerprint covers the money, and holds the chain together;
• the print in the tree covers everything, and is what an entry is proved against and what a receipt witnesses.

Together they mean a change to a tax code leaves the chain intact and still cannot survive a receipt you kept.

What this screen is

Open Assurance. Sixteen procedures run on every visit, against the actual entries in the books. Each one has a reference, a title, an objective, and a result. Each one offers a working paper you can download as a CSV.

The page says something important about itself. These procedures report what they found and leave the conclusion to you. It does not say "the records are wrong". It says "three documents are missing a GST number". The difference between those two statements is the difference between a procedure and a conclusion, and it is the thing this chapter is really about.

The programme

Ref	Procedure	The objective, in the program's own words
A01	Ledger integrity	Every entry still carries the fingerprint it was sealed with, and each one includes the fingerprint of the entry before it
A02	Double entry	Every transaction moves money from somewhere to somewhere else: the two sides of each entry must be equal
A03	Bank reconciliation	The bank balance in the ledger agrees with the balance on the statement, and every imported line has been dealt with
A04	Debtors	Money owed to the business is real, correctly aged, and not overpaid
A05	Creditors	Money the business owes is recorded, and no bill is paid twice
A06	GST reconciliation	The GST in the return is the GST in the ledger, and the control accounts agree with what has been filed
A07	Journal entries	Entries that did not come from an invoice, a bill or the bank are where adjustments hide
A08	Duplicate payments	The same amount, described the same way, twice within a week is usually a mistake, and sometimes a fraud
A09	Cut-off	Entries dated in the future, or inside a period that has already been packed and closed, are the two ways a figure moves after the fact
A10	Documents and compliance	A tax invoice over $50 has to show the supplier's GST number, and every document should say what it is for
A11	Expenses	Round numbers, large one-off costs and costs that look personal are the usual places an expense account is wrong
A12	Sealed packages	Every pack that has been sealed still reproduces the figures and entries it recorded
A13	Access and housekeeping	Who can sign in, when the books were last backed up, and whether anything failed quietly
A14	Reproduce the numbers	The reports are recalculated from the raw rows and compared with what the report says
A15	The record is complete	Nothing has been taken out of the ledger: no gaps in the numbering, no two entries sharing a fingerprint, and the record still holds everything a checkpoint witnessed
A16	Who did what	How the entries are distributed between the people who made them: who posts journals, who voids, who works outside the office week, and whether one person did both halves of the same transaction

Reading a result

Each procedure ends in one of three states, and the distinction is deliberate.

• No exceptions. The procedure ran and found nothing to report.
• Exceptions to look at (the page counts them). The procedure found something specific: four bank lines not coded, three documents missing a GST number, three figures that do not reproduce from the ledger.
• For information. Nothing is wrong; the procedure is telling you something you should know. Three manual entries exist. Nothing has been sealed yet.

The page sorts exceptions to the top, then information, then clean results, so the first thing you read is the thing that needs a decision.

Six procedures worth understanding properly

A07, journal entries. A journal is an entry that came from nowhere: not an invoice, not a bill, not the bank. Most journals are perfectly ordinary — depreciation, an accrual, a correction. But because they are not tied to a document, they are also the natural place to put a figure that has no support. An auditor's response is not suspicion, it is a question: what is the paperwork behind this one, and who posted it? The procedure lists every manual entry with who posted it and when, so the question can be asked precisely.

A08, duplicate payments. The same amount described the same way twice inside a week is usually a mistake and occasionally a fraud. Either way it is worth the two minutes it takes to check against the supplier's statement.

A09, cut-off. Two patterns, and both matter. An entry dated in the future has been posted into a period that has not happened. An entry dated inside a period that was already sealed and closed has changed a figure after the fact. Neither is automatically wrong; both need an explanation before anyone relies on the period.

A14, reproduce the numbers. This is the check that catches a reporting bug rather than a bookkeeping error. The reports are recalculated from the raw rows and compared with what the page says. If they disagree, the report is wrong even though the ledger is right, and the two possibilities lead to completely different work.

A15, the record is complete. A15 asks a different kind of question from every procedure above it. Those ask whether the numbers are right; this one asks whether anything is missing. Three things are checked. The entry numbers should run without a gap — a missing number is usually a draft that was thrown away, which is entirely normal, and occasionally it is an entry that was deleted, which is not. No two entries should carry the same fingerprint, which the numbering makes impossible by accident. And the record should still contain everything a checkpoint witnessed: if a checkpoint counted nineteen entries and the ledger now holds eighteen, something has been taken off the end.

That last check is the one worth understanding. The chain catches an edit, and it catches a deletion from the middle, because the next entry's link points at a fingerprint that is no longer there. It cannot catch the end being replaced, because there is nothing after the end to disagree with. A copy of the fingerprints held somewhere the books cannot reach — a receipt — is what does.

A16, who did what. This procedure reports and never judges, which is why it always comes back for information and never exceptions. It counts who posted what, who voided, which entries were entered outside the office week, and whether one person both entered a transaction and reversed it. None of that is an error. All of it is the material an internal auditor asks for first, because the person who can put an entry in and take it out again is the person a fraud needs, and the rest of the controls may never see it.

Why fraud gets its own thinking

Four of the sixteen procedures are aimed at fraud rather than error, and the reason is in the auditing standards. When the auditor identifies and assesses the risks of material misstatement due to fraud, there is a presumption that there are risks of fraud in revenue recognition, and the auditor has to evaluate which types of revenue, revenue transactions or assertions give rise to those risks ISA (NZ) 240.27.

The second is about who is best placed to do it. Management is in a unique position to perpetrate fraud, because of the ability to manipulate accounting records and override controls that otherwise appear to be working ISA (NZ) 240.32. That is why journal entries and unusual transactions get attention even when everything else looks well controlled.

Professional scepticism

The quality of every procedure on this page depends on one habit, and it has a name. When applying the conceptual framework in the ethics standard, an assurance practitioner is required to have an enquiring mind, exercise professional judgement, and apply the reasonable and informed third party test PES 1 R120.5.

An enquiring mind is not suspicion. It is the willingness to ask what the evidence actually supports, rather than what you expect it to show. The exception list on this page is where that habit starts: something is different from what you expected, and the next step is to find out why.

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. Open Audit trail → Sealed packs, choose the period and press Seal this period. ByteBook records the pack and its fingerprint.
4. Later, verify it. Reopen the pack and check it. The fingerprint is recomputed from the entries as they are 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 (the CSV button on each procedure), seal the period, record a checkpoint (Audit trail → Checkpoints → Check the record now), 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.

Handing the record to somebody outside

An external auditor is usually given a PDF and a set of CSVs, and then has to take the numbers on trust. Audit trail → Hand it over produces the alternative: one folder, or one zip, containing the record itself and a small checker that tests it. In the training exercises, the same checks are on the Audit trail and The chain pages; running verify.py is the receiving auditor's job, not the learner's.

In the bundle	What it is
entries.csv	one row per entry, with the fingerprint it carries
lines.csv	one row per journal line, which is what the fingerprint covers
packs.json	every sealed period, with the figures it sealed
checkpoints.json	what the record looked like each time it was witnessed
receipts/	one receipt per checkpoint, to keep or pass on
manifest.json	what is inside, and a fingerprint of every file
verify.py	the script that checks all of the above
README.txt	what the folder is, in words

The auditor unpacks the folder and runs one small checker, verify.py (a reader who wants to repeat the checks inside ByteBook can use The chain → Check the record instead):

python3 verify.py

Python is a free program; if it is installed, that is all the checker needs. No ByteBook, no internet, no account. The script recomputes every entry fingerprint from the recorded fields, walks the chain, rebuilds the Merkle root, reproduces each sealed pack, checks the chain of checkpoints, and reads the receipts back against the entries. Then it prints PASS or FAIL, with the reason for anything it could not reproduce.

Three things about it are deliberate.

It reports, it does not judge. If the chain is broken, the bundle still exports and says so on its first page. An export that hid a broken chain would be the one failure that matters.

It is checkable years later. The bundle does not need this program, or this version of it, to be understood. The script is a page of plain Python that a reader can read before running.

A pass is narrower than it sounds. It means the files are exactly as exported and the record they describe holds together. It does not mean the entries are correct, that money moved, or that a price was agreed.

A read-only key, for an internal auditor

An external auditor usually wants a file. An internal auditor, or the organisation's own scripts, may want to pull the figures repeatedly and test them with their own tools. That is what an audit key is for: a named, revocable, read-only credential for the audit API.

The whole surface is twelve GET endpoints, all of which show what the pages show:

curl -H "Authorization: Bearer bbk_…" http://127.0.0.1:8321/api/audit/verify

• /verify — is the chain intact, and the Merkle root
• /entries, /lines — the rows, as JSON or CSV
• /proof/{id} — one entry, proved against the whole ledger
• /packs, /checkpoints — what was sealed and what was witnessed
• /procedures, /working-paper/{code} — the programme and its papers
• /bundle — the whole folder, as a zip
• /tokens, /access-log — which keys exist, and who read what, including the attempts that were refused
• /help — the list itself, for a tool that wants to discover it

Four properties make this something an organisation can actually hand out.

1. A key cannot write. It cannot post, edit, void, seal, or change a setting. It is refused in the language it asked in — JSON, with a reason — rather than being quietly redirected.
2. A key is shown once. Only its SHA-256 is kept, so a copy of the database does not hand anybody a working key, and a lost key is replaced rather than recovered.
3. A key can be taken away. Revoking it stops the next request, and the attempt is recorded.
4. Using a key leaves a trace. Every read is written to the access log with the key's name, the path, and how many rows were handed over. An auditor reading the books leaves a trace in the same record they came to read, which is the arrangement they would ask for if they designed it.

A checkpoint, and why a receipt matters

A checkpoint is one line of evidence. Every time somebody checks the record — or seals a period, which does the same thing by itself — ByteBook writes down how many entries there were, the fingerprint of the last one, and the Merkle root of the whole ledger. Each checkpoint includes the fingerprint of the checkpoint before it, so the log of checks is a chain of its own.

On its own that is still just another table in the same file. It becomes evidence when a copy leaves the file, and that copy is a receipt: two dozen lines with the business name, the date, the entry count, the last fingerprint, the Merkle root and the checkpoint's own fingerprint.

Keep a receipt the way you would keep a bank statement. Email it to your accountant at every month end, print it, drop it in the audit file. It costs nothing. What it buys is this: a record rewritten as a whole can rebuild every entry fingerprint, but it cannot reach the copy in somebody else's inbox.

To check one, paste it into Audit trail → Checkpoints → Check a receipt. The printed version and the JSON version both work. ByteBook says whether the books still contain everything the receipt witnessed, and how much work has happened since — because more work after a checkpoint is normal, and a record shorter than one is not.

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.

The four roles

Role	May do
Owner	Everything, including settings, backups and who can sign in
General manager	Run the books: invoices, bills, bank, GST, reports
Accountant	Read everything, including the tax working papers; change nothing
Auditor	Read the books and the assurance work; no settings, change nothing

Two of those roles cannot change a number, and that is the feature.

The rule that keeps it honest

ByteBook will not switch on another person's sign-in until the owner has set a password of their own, and the security settings open only for the owner. That single rule prevents the obvious failure: nobody can hand out a login that locks the owner out of their own books.

It also means every role was created deliberately, from the owner's own screen. ByteBook does not keep a separate log of role changes, so in a training business write down who set it up and when.

Why an auditor should not be able to edit

The ethics standard states the requirement plainly. An assurance practitioner shall comply with the principle of objectivity, which requires exercising judgement without being compromised by bias, a conflict of interest, or undue influence PES 1 R112.1. An assurance practitioner shall also comply with the principle of integrity, which requires being straightforward and honest in all professional and business relationships PES 1 R111.1, and with professional competence and due care PES 1 R113.1.

An auditor who holds the ability to change the records they are auditing is in a position where objectivity cannot be demonstrated, however honest they are. The read-only role removes the question rather than asking anyone to be trusted about it.

The same logic runs through the whole quality management system in a firm. The objective of that system is to provide the firm with reasonable assurance that the firm and its personnel fulfil their responsibilities and perform engagements in accordance with professional standards PES 3.14. Access control is a small, concrete piece of the same idea.

Access is also an assurance question

ByteBook's A13 procedure reports who can sign in, when the books were last backed up, and whether anything failed quietly while people were working. It is the least glamorous procedure of the sixteen and one of the most useful, because the questions it asks are exactly the ones an engagement team asks about any system they are relying on: who has access, is the record protected, and would anybody have noticed if something went wrong.

A practical training routine

When you work through the Marine Parade Dental practice business, which is the one meant to be audited:

1. Set the owner password first.
2. Add an accountant login and use it to prepare the tax figures.
3. Add an auditor login and run the assurance procedures from it.
4. Try to change something as the auditor. Notice that you cannot, and that the program does not offer you the option.
5. Switch back to the owner and void something deliberately. Then look at the audit trail as the auditor and find it.

Step five is the exercise that makes the rest of the design make sense.

Two families of document

Everything this handbook refers to comes from one of two families.

Accounting standards say how a transaction is recognised, measured and disclosed, and what the financial statements must show. In New Zealand they are the NZ IFRS standards, issued by the External Reporting Board. Each one carries an international standard from the International Accounting Standards Board with New Zealand additions, which is why they are called NZ IAS 1, NZ IFRS 15, and so on.

Auditing and assurance standards say how the work of checking those financial statements is planned, performed, documented and reported. In New Zealand they are the ISAs (NZ), issued within the External Reporting Board, alongside the PES standards for ethics, quality management and engagement quality reviews. Each ISA (NZ) carries an international standard from the IAASB with New Zealand additions.

Reading an identifier

The identifier is the shorthand a working paper uses. Take NZ IAS 1.15:

Part	Means
NZ IAS 1	The New Zealand standard: NZ IAS 1, Presentation of Financial Statements
.15	Paragraph 15 of that standard

And ISA (NZ) 230.8:

Part	Means
ISA (NZ) 230	The New Zealand auditing standard: ISA (NZ) 230, Audit Documentation
.8	Paragraph 8

The naming carries history you will meet constantly:

• IAS numbering is old — standards issued before the International Accounting Standards Board was formed in 2001, and still in force. IAS 1, IAS 2, IAS 7.
• IFRS numbering came after. IFRS 9, IFRS 15, IFRS 16.
• IFRIC and SIC are interpretations: short documents that settle how a standard applies to a particular situation.
• FRS is used for New Zealand domestic standards that have no international equivalent.
• (Revised) in an auditing standard's name means it has been rewritten. ISA (NZ) 315 changed substantially in 2019, and ISA (NZ) 570 was revised in 2024. Citing the superseded version is a real and common error.

Why paragraph numbers matter

A reference to "the standard on going concern" is not checkable. A reference to paragraph 16 of ISA (NZ) 570 is: it says one specific thing, and a reader can find it in a minute.

For the audit side this matters even more than for accounting. An auditor's working paper cites paragraphs, because the whole point of the paper is that somebody else can re-perform the reasoning.

Effective dates

Every standard here has a date from which it applies, usually expressed as periods beginning on or after a certain date. Two standards on the same subject can both exist while the older one still applies to an earlier period.

The library records, for each standard, the effective date as the publisher states it, plus the date the document was issued and the date it was compiled to. When you quote a standard, check all three. A version compiled in one year may carry the same number as a version compiled a decade later and say something different.

Following a reference to its source

Every citation in this handbook can be followed. Each one gives you:

• the identifier, so you can search for it;
• the publisher — the XRB for New Zealand standards, IFAC for the IAASB Handbook;
• the address of the document on the publisher's own site;
• the SHA-256 of the copy this handbook was checked against.

The last item is what makes the reference checkable rather than merely pointed at. If the publisher later issues a new version, the fingerprint in this handbook will no longer match the document at that address — which is exactly the signal that says go and read the new one.

The limits of a reference

Quoting a paragraph is not applying it. A paragraph tells you what the standard requires; it does not tell you whether your contract is a lease, whether your revenue is recognised over time or at a point in time, or whether a debt will be collected. Those are judgements made on facts, and the standard is the frame you make them in.

This handbook tries to keep the two apart on every page: the fact, then the judgement, then the reference that constrains the judgement.

This chapter is a map, not a substitute. Each entry gives the question the standard answers, the requirements you will meet in these exercises, and where to see it happen.

NZ IAS 1 — Presentation of Financial Statements

The question: what must a set of financial statements contain, and what does it mean to present them fairly?

• A complete set includes a statement of financial position, a statement of profit or loss and other comprehensive income, a statement of changes in equity, a statement of cash flows, and notes NZ IAS 1.10.
• Fair presentation requires the faithful representation of the effects of transactions, other events and conditions NZ IAS 1.15.
• Where an entity departs from a requirement to achieve a fair presentation, the departure and its effect are disclosed.
• The statement of financial position presents specified line items where they are relevant NZ IAS 1.54.
• The profit or loss section presents specified line items in addition to those required by other standards NZ IAS 1.82.
• Expenses are analysed by nature or by function, whichever provides reliable and more relevant information NZ IAS 1.99.
• Accounting policy information is disclosed where it is material NZ IAS 1.117, along with the judgements management made in applying those policies NZ IAS 1.122 and the major sources of estimation uncertainty NZ IAS 1.125.

In ByteBook: Reports → Balance sheet and Profit and loss. The balance sheet states the difference between assets and liabilities plus equity rather than hiding it.

NZ IAS 7 — Statement of Cash Flows

The question: where did the money come from, and where did it go?

• Cash flows are classified as operating, investing or financing activities NZ IAS 7.10.
• Operating cash flows are presented by the direct method, showing gross receipts and payments, or by the indirect method, starting from profit NZ IAS 7.18.
• Investing and financing transactions that do not use cash at all are excluded from the statement and disclosed elsewhere NZ IAS 7.43.

In ByteBook: Reports → Money in and out.

NZ IAS 8 — Accounting Policies, Changes in Accounting Estimates and Errors

The question: what happens when a number you reported last year turns out to have been wrong?

• A change in an accounting estimate is recognised prospectively, in this period and future ones NZ IAS 8.36.
• A material prior period error is corrected retrospectively NZ IAS 8.42.

In ByteBook: the void and correct routine in chapter 11. A correction that reverses a wrong figure is visible in the audit trail, which is what makes the treatment checkable.

NZ IAS 10 — Events after the Reporting Period

The question: the balance date has passed and something has happened. Does it change the accounts?

• Adjusting events provide evidence of conditions that existed at the reporting date, and the amounts recognised are adjusted NZ IAS 10.8.
• Non-adjusting events concern conditions that arose after the reporting date. The amounts are not adjusted NZ IAS 10.10, though material ones may need disclosure.

In ByteBook: the closing routine in chapter 10, and the cut-off procedure A09.

NZ IFRS 9 — Financial Instruments

The question: how much of the money customers owe will actually be paid?

• For trade receivables, the loss allowance is measured at an amount equal to lifetime expected credit losses NZ IFRS 9.5.5.15.

In ByteBook: Reports → Who owes what, and the debtors procedure A04.

NZ IFRS 15 — Revenue from Contracts with Customers

The question: when has a business earned its revenue?

• Revenue is recognised when the entity satisfies a performance obligation by transferring a promised good or service to the customer NZ IFRS 15.31.
• Where a performance obligation is not satisfied over time, it is satisfied at a point in time NZ IFRS 15.38.
• When a performance obligation is satisfied, revenue is the amount of the transaction price allocated to it NZ IFRS 15.46.
• The transaction price is allocated to the performance obligations on a relative stand-alone selling price basis NZ IFRS 15.73.

In ByteBook: Invoices, and the Tasman Builders practice business with its stage payments.

NZ IFRS 16 — Leases

The question: is this rental an expense, or an asset and a liability?

• A contract is, or contains, a lease if it conveys the right to control the use of an identified asset for a period of time in exchange for consideration NZ IFRS 16.9.
• At the commencement date the lessee recognises a right-of-use asset and a lease liability NZ IFRS 16.22.

In ByteBook: the recurring rent entries post rent as an ordinary expense. ByteBook does not do lease accounting; a long lease would need a manual journal for the right-of-use asset and the lease liability, outside these exercises.

NZ IAS 16 — Property, Plant and Equipment

The question: when is a purchase an expense, and when is it something the business owns?

• An item that qualifies for recognition is measured at its cost NZ IAS 16.15.
• The depreciable amount is allocated on a systematic basis over the useful life NZ IAS 16.50.
• Depreciation begins when the asset is available for use NZ IAS 16.55.

In ByteBook: the expenses procedure A11, which reports the large one-off costs where this question has to be asked.

NZ IAS 2 — Inventories

The question: what is the stock worth on the balance sheet?

• Inventories are measured at the lower of cost and net realisable value NZ IAS 2.9.
• Cost comprises the costs of purchase, the costs of conversion, and the other costs of bringing the inventories to their present location and condition NZ IAS 2.10.
• Cost is assigned using first-in, first-out or a weighted average cost formula NZ IAS 2.25.
• Where cost is not recoverable, the write-down is recognised as an expense in the period it happens NZ IAS 2.28.

In ByteBook: the Pacific Trading practice business. ByteBook records the purchases and sales; it does not keep a stock ledger, so the closing valuation is a calculation the learner makes and keeps with the working papers.

NZ IAS 37 — Provisions, Contingent Liabilities and Contingent Assets

The question: when do you put a cost in the accounts for something that has not happened yet?

• A provision is recognised where there is a present obligation from a past event, an outflow of resources is probable, and a reliable estimate can be made NZ IAS 37.14.
• The amount recognised is the best estimate of the expenditure required to settle the obligation at the reporting date NZ IAS 37.36.

In ByteBook: the closing routine in chapter 10.

NZ IAS 21 and NZ IAS 12

Two more you will meet as soon as a business trades across a border or has a tax bill.

• A foreign currency transaction is recorded by applying the spot exchange rate at the date of the transaction NZ IAS 21.21. Where the presentation currency differs from the functional currency, the results are translated for presentation NZ IAS 21.38.
• Current tax for the current and prior periods is measured at the amount expected to be paid to, or recovered from, the taxation authorities, using the tax rates and laws enacted or substantively enacted by the reporting date NZ IAS 12.46.

In ByteBook: Reports → IRD working papers, which build the IR3, IR10 and IR4 from the same ledger.

Two things this chapter does not cover

The framework for smaller entities. New Zealand has reporting tiers, set by XRB A1 and XRB A2. A business reporting under a reduced disclosure regime applies the same recognition and measurement rules with fewer disclosures, so the standard you reach for is the same and the disclosure requirements are not.

Estimates that need a specialist. NZ IAS 36 impairment, NZ IAS 19 employee benefits and NZ IFRS 17 insurance contracts are all in the library and all outside the scope of a small-business set of books. They are named here so that you know what you have not read.

Where an audit starts

The overall objectives of the auditor are to obtain reasonable assurance about whether the financial statements as a whole are free from material misstatement, whether due to fraud or error, and then to report in accordance with the auditor's findings ISA (NZ) 200.11.

Everything below is machinery in service of that sentence. Notice what it promises and what it does not: reasonable assurance, not certainty, and about matters that are material, not about everything.

Planning and risk

ISA (NZ) 300 — Planning. In establishing the overall audit strategy, the auditor considers the characteristics of the engagement that define its scope and the reporting objectives, among other things ISA (NZ) 300.8.

ISA (NZ) 315 — Risk assessment. The auditor has to understand the entity's information system relevant to the preparation of the financial statements ISA (NZ) 315.25, and then identify the risks of material misstatement and determine whether they exist at the financial statement level or at the assertion level for classes of transactions, account balances and disclosures ISA (NZ) 315.28.

That last distinction is the one to carry away. "The receivables balance may be overstated" is an assertion-level risk. "The finance team is new and the systems changed" is a risk at the financial statement level.

ISA (NZ) 320 — Materiality. The auditor determines materiality for the financial statements as a whole ISA (NZ) 320.10, and performance materiality — a lower figure, set to reduce to an acceptably low level the probability that uncorrected and undetected misstatements exceed materiality ISA (NZ) 320.11.

ISA (NZ) 540 — Estimates and ISA (NZ) 550 — Related parties each need their own thinking. For related parties, the auditor inquires of management about the identity of the entity's related parties, including changes from the prior period, and about the nature of the relationships and transactions ISA (NZ) 550.13.

Gathering evidence

ISA (NZ) 500 — Audit evidence. The auditor designs and performs audit procedures that are appropriate in the circumstances for the purpose of obtaining sufficient appropriate audit evidence ISA (NZ) 500.6, and considers the relevance and reliability of the information to be used as evidence ISA (NZ) 500.7. Sufficient is about quantity; appropriate is about relevance and reliability.

ISA (NZ) 505 — External confirmations. Where the auditor identifies factors giving rise to doubts about the reliability of a response to a confirmation request, the auditor obtains further audit evidence to resolve those doubts ISA (NZ) 505.10.

ISA (NZ) 520 — Analytical procedures. Where substantive analytical procedures are used, the standard sets out what that involves, including determining the suitability of the data and evaluating whether the expectation is precise enough ISA (NZ) 520.5.

ISA (NZ) 330 — Responding to assessed risks. Further audit procedures are designed and performed so that their nature, timing and extent are responsive to the assessed risks at the assertion level ISA (NZ) 330.6, and irrespective of those risks, substantive procedures are performed for each material class of transactions, account balance and disclosure ISA (NZ) 330.18.

ISA (NZ) 450 — Misstatements. The auditor communicates, on a timely basis, all misstatements accumulated during the audit to the appropriate level of management, and requests that they be corrected ISA (NZ) 450.8.

Documenting the work

ISA (NZ) 230 — Audit documentation. Documentation is prepared on a timely basis ISA (NZ) 230.7 and must be sufficient to enable an experienced auditor with no previous connection to the audit to understand the procedures performed and their results, the evidence obtained, and the significant matters, conclusions and judgements ISA (NZ) 230.8. The final audit file is assembled on a timely basis after the date of the auditor's report ISA (NZ) 230.14.

This is the standard behind ByteBook's working papers and sealed packs. If you remember one auditing standard from this handbook, remember this one: it is the standard that makes every other procedure checkable.

Communicating

ISA (NZ) 260 — Those charged with governance. The auditor communicates with the people responsible for overseeing the entity, which in a small company usually means the board or the owners.

ISA (NZ) 265 — Deficiencies in internal control. Where deficiencies have been identified, the auditor determines whether, individually or in combination, they constitute significant deficiencies ISA (NZ) 265.8. Notice the framing: the deficiency is reported, and the determination of significance is a judgement to be made and recorded.

Fraud and subsequent events

ISA (NZ) 240 — Fraud. There is a presumption that there are risks of fraud in revenue recognition, and the auditor evaluates which types of revenue, revenue transactions or assertions give rise to those risks ISA (NZ) 240.27. Management is in a unique position to perpetrate fraud because of the ability to manipulate accounting records and override controls that otherwise appear to be operating effectively ISA (NZ) 240.32.

ISA (NZ) 560 — Subsequent events. The auditor performs procedures designed to obtain sufficient appropriate audit evidence that all events occurring between the date of the financial statements and the date of the auditor's report that require adjustment or disclosure have been identified ISA (NZ) 560.6.

Going concern, representations and the opinion

ISA (NZ) 570 — Going concern. The objectives include obtaining sufficient appropriate audit evidence about, and concluding on, the appropriateness of management's use of the going concern basis of accounting ISA (NZ) 570.9. Where management has not yet performed an assessment, the auditor requests that they make one ISA (NZ) 570.16.

ISA (NZ) 580 — Written representations. The auditor requests a written representation that management has fulfilled its responsibility for the preparation of the financial statements in accordance with the applicable financial reporting framework ISA (NZ) 580.10. A representation letter does not replace procedures; it is a formal record of who is responsible for what.

ISA (NZ) 700 — The opinion. The auditor expresses an unmodified opinion when concluding that the financial statements are prepared, in all material respects, in accordance with the applicable financial reporting framework ISA (NZ) 700 (Revised).16. Under a fair presentation framework, the opinion uses one of the phrases the standard specifies ISA (NZ) 700 (Revised).25.

ISA (NZ) 701 — Key audit matters. Where key audit matters are communicated, the description of each one includes a reference to the related disclosures and addresses why the matter required significant auditor attention ISA (NZ) 701.13.

ISA (NZ) 705 — Modifications. The shape of the report follows the nature of the problem:

Situation	Opinion
Misstatements are material but not pervasive	Qualified ISA (NZ) 705.7
Misstatements are material and pervasive	Adverse ISA (NZ) 705.8
Unable to obtain sufficient appropriate evidence, and the possible effects are material and pervasive	Disclaimer ISA (NZ) 705.9

Read those three together and the logic becomes clear. A qualified opinion says the statements are broadly right with a specific exception. An adverse opinion says they are not right. A disclaimer says the auditor could not find out. They are different statements about different problems, and choosing the wrong one is a serious error.

Ethics and quality

PES 1 — International Code of Ethics for Assurance Practitioners (including International Independence Standards) (New Zealand). The five fundamental principles, and the framework for applying them:

Principle	Requirement
Integrity	Be straightforward and honest in all professional and business relationships PES 1 R111.1
Objectivity	Exercise professional or business judgement without being compromised by bias, conflict of interest or undue influence PES 1 R112.1
Professional competence and due care	Attain and maintain professional knowledge and skill at the level required for a competent service PES 1 R113.1
Confidentiality	Respect the confidentiality of information acquired in professional and business relationships PES 1 R114.1
Professional behaviour	Comply with relevant laws and regulations, and behave consistently with the profession's responsibility to act in the public interest PES 1 R115.1

The conceptual framework requires an enquiring mind, professional judgement, and the reasonable and informed third party test PES 1 R120.5.

PES 3 — Quality management. New Zealand's quality management standard carries the IAASB's ISQM 1 with New Zealand additions, and it is the one a New Zealand firm applies. The objective of the firm's system of quality management is to provide reasonable assurance that the firm and its personnel fulfil their responsibilities in accordance with professional standards and applicable legal and regulatory requirements, and conduct engagements accordingly PES 3.14.

How to use this chapter

Do not memorise it. Use it the way a working paper uses it: when a procedure raises a question, find the standard that answers the question, read the paragraph, and write down what you concluded and why.

The map

ByteBook screen	What you are doing	Accounting standard	Auditing standard
Invoices	Recognising revenue, raising a tax invoice	NZ IFRS 15.31	—
Bills to pay	Recording a liability and an expense	NZ IAS 1.54	ISA (NZ) 500.6
Bank & coding	Coding transactions and reconciling	—	ISA (NZ) 505.10
Reports → Profit and loss	Reporting performance	NZ IAS 1.99	—
Reports → Balance sheet	Reporting position	NZ IAS 1.15, NZ IAS 1.54	—
Reports → Money in and out	Reading the cash movements	—	—
Reports → Who owes what	Aged debtors and creditors	NZ IFRS 9.5.5.15	ISA (NZ) 505.10
GST	Building the return from the ledger	—	—
Reports → IRD working papers	Current tax working papers	NZ IAS 12.46	—
Transactions	Reading the entry behind a document	—	ISA (NZ) 230.8
Audit trail	Proving the record has not changed	—	ISA (NZ) 500.7
The chain	Reading the record at three scales	—	ISA (NZ) 500.7
Checkpoints	Witnessing what the record said, and holding a receipt for it	—	ISA (NZ) 230.8
How a number gets in	Understanding the controls over what is recorded	—	ISA (NZ) 315.26
Hand it over	Giving evidence to somebody outside the business	—	ISA (NZ) 230.8
Assurance → A07	Manual entries	—	ISA (NZ) 240.32
Assurance → A09	Cut-off	NZ IAS 10.8	ISA (NZ) 560.6
Assurance → A11	Expenses	NZ IAS 16.15	ISA (NZ) 500.7
Assurance → A14	Reproducing the reports	—	ISA (NZ) 500.6
Assurance → A15	Gaps, repeated fingerprints, witnesses	—	ISA (NZ) 500.6
Assurance → A16	Who entered, voided and worked out of hours	—	ISA (NZ) 240.32
Sealed packs	Closing and protecting a period	—	ISA (NZ) 230.14
Practice businesses	Learning on books that already exist	—	ISA (NZ) 230.8
Setting up roles	Who may change the books	—	PES 1 R112.1

How to use it

Three ways, depending on what you are doing.

When you are learning a screen. Read the row before you start. Knowing that the bank reconciliation is tied to the standard on external confirmations changes how you read the page: you stop looking for a balance that agrees and start looking for evidence that comes from outside the business.

When something looks wrong. Find the row, open the standard, and read the paragraph. The standard usually tells you what the correct treatment is and, just as often, what it is not.

When you are writing a working paper. Cite the paragraph. Not the standard's name, not the general topic: the paragraph. A reference that cannot be checked is not a reference.

A worked example: a bank line coded as an expense

Suppose the bank statement shows $1,150 paid to a supplier, and you code it to expenses when it should have been a payment against a bill.

1. What is wrong? The supplier's balance still shows as unpaid, and an expense has been recorded twice: once when the bill was entered, and again from the bank line.
2. Which accounting question is it? Whether the expense is recognised at the right amount in the right period — a matter of faithful representation NZ IAS 1.15.
3. Which procedure catches it? A05, creditors, which reports money the business owes and checks for a bill paid twice. The GST figures move as well, which A06 will see.
4. Which auditing standard applies? The reliability of the bank statement as evidence ISA (NZ) 500.7, and the requirement that misstatements found during the audit are accumulated and communicated ISA (NZ) 450.8.
5. How is it fixed? Open the coding entry under Transactions and choose Void and reverse. Then record the payment against the bill, from the bill itself, so the payment and the bill stay linked. Both the wrong entry and the correction stay in the record, and ISA (NZ) 230.8 explains why that matters.

That five-step shape — what is wrong, which accounting question, which procedure, which auditing standard, how to fix it — is the shape of a working paper. It works for a mis-coded bank line and for a misstated provision alike.

The problem with a handbook

Any document that quotes standards is out of date the moment a standard changes, and it is most dangerous when it is confidently out of date. A handbook that teaches last year's rule with this year's certainty is worse than no handbook.

So accuracy here is not a promise. It is a set of checks that run every time the handbook is published.

Where the documents come from

Every reference in this handbook points to a document that was downloaded from its publisher, stored, and fingerprinted:

Publisher	What they publish	What we hold
External Reporting Board (XRB)	New Zealand accounting standards (NZ IFRS, which carry the IASB's text) and auditing standards (ISAs (NZ), PES and the framework)	The current version of each standard, with its effective date and the address of the publisher's page
IAASB, published by IFAC	The Handbook of International Quality Management, Auditing, Review, Other Assurance, and Related Services Pronouncements, 2025 edition	Volumes 1, 4 and 5, which carry the ISAs, the ISQMs, the assurance and review standards, and the framework

Both publishers make these documents available free of charge. Neither permits their standards to be republished in full, which is why this handbook quotes short passages with attribution and links to the source rather than reproducing the text.

What is checked, and how

Three checks run over the handbook before it is published.

Every reference must exist. A citation naming a standard that is not in the stored list stops publication. There is no path where a typo becomes a published reference to a standard that does not exist.

Every cited paragraph must exist in the publisher's own text. The check reads the extracted text of the document, finds the paragraph by the number the citation gives, and shows the opening words of that paragraph. Where the paragraph cannot be found, publication fails: a reference cannot be published pointing at something that is not there.

Every document must still have the fingerprint we recorded. Checking the stored documents fetches each one again and compares its SHA-256 (a unique fingerprint of the file's contents) with the one recorded when it was first downloaded. A difference means the publisher has issued a new version, and the handbook is re-checked against it before anything is republished.

That third check is the one that keeps this honest over time. It cannot be argued with: either the bytes match or they do not.

What you can check yourself

Every citation in this handbook shows the identifier, the publisher, the address of the source document, and the fingerprint of the copy that was read. You do not need to check any of it to use the handbook; it is there so that a claim can be traced if somebody wants to. Follow the link, find the paragraph, and read it. If this handbook has misread a standard, that is how it will be found, and finding it is the point of the design.

When a standard changes

Standards change in three ways, and each is handled differently.

• A new version of an existing standard. A revised ISA (NZ) 315 or a recompiled NZ IAS 1 will show up as a changed fingerprint and a changed effective date. The references that touch it are reviewed, and the handbook states the new effective date.
• A new standard. NZ IFRS 18, *Presentation and Disclosure in Financial Statements*, takes effect for periods beginning on or after 1 January 2027 and will change how performance is presented. It is already in the library, and it will appear in these pages as it becomes applicable.
• A withdrawal. A standard superseded by another stays in the library with the period it applied to, because a working paper about a 2023 audit still has to cite the 2023 rule.

A caution about dates

This edition states the effective date of each standard as the publisher gave it at the time of writing. Effective dates are the thing most likely to have moved. Before you rely on a reference for a live engagement, open the publisher's page from the citation and read the current version. That takes a minute and it is the only way to be certain.

How to run a session

Each session takes about an hour. The shape is the same every time:

1. Open the business in ByteBook: in the sidebar, under Set up, choose Practice businesses. The cards are labelled by trade; find the trade named in the session and press Start this business.
2. Do the task in the application. The task always ends with a document or a number somebody else could check.
3. Run the assurance procedures and write down what they found.
4. Mark it against the note at the end of the session.

Marking is where the learning happens, so do not skip step four.

Session 1 — Bright Cuts (hairdressing, no GST)

In the app: Practice businesses → Hairdressing (the books of Bright Cuts) → Start this business.

Task: Raise three invoices, record two payments, and produce the profit and loss report for the quarter.

Marking note: The business is not registered for GST, so no GST appears on any document, no GST return is expected, and the invoice totals equal the revenue. A candidate who records a GST figure has applied last week's habit instead of reading the settings. Look for evidence that they checked the registration status before invoicing.

Session 2 — Kōwhai Advisory (consulting, payments basis)

In the app: Practice businesses → Consulting (the books of Kōwhai Advisory) → Start this business.

Task: Work out the GST return for the quarter, then explain why the figure changes if you switch the period to include the following month.

Marking note: The business files on the payments basis, so a March invoice paid in May belongs in the later period. The correct answer explains that the basis moves the transaction, not the invoice date. The most common wrong answer treats the invoice date as decisive.

Session 3 — Tasman Builders Ltd (construction, stage payments)

In the app: Practice businesses → Construction (the books of Tasman Builders Ltd) → Start this business.

Task: Explain, for one contract, why more than one invoice is raised, and what each invoice recognises.

Marking note: Revenue is recognised as each performance obligation is satisfied NZ IFRS 15.31. Each stage invoice recognises the work transferred in that stage, not the whole contract at the first invoice and not on receipt of money. Look for the phrase as the work is done, and for a candidate who can say what would change if the whole contract were invoiced up front.

Session 4 — Harbour Cafe & Co (hospitality, volume)

In the app: Practice businesses → Hospitality (the books of Harbour Cafe & Co) → Start this business.

Task: Open the bank reconciliation. Read the ledger balance, the statement balance saved with the business and its date, and the difference. Explain what the page is testing, and what document a real reconciliation needs. Then explain how one lump deposit covers several trading days.

Marking note: The first lesson is that a reconciliation is evidence only if the balance compared comes from an outside document — here the statement the business was built from — and that a saved balance has a date for a reason. The second is tying the money in the bank to the money rung up: every line accounted for, and an explanation in words of why a deposit and a day's takings are not the same number. Mark down an answer that only says "the balances match" without explaining either point.

Session 5 — Loom & Light (online retail, refunds)

In the app: Practice businesses → Online retail (the books of Loom & Light) → Start this business.

Task: Find the voided invoice and the reversal it produced, explain what each one did to revenue and GST, and then finish and post the draft invoice.

Marking note: The reversal corrects the sale it belongs to. Revenue and GST both come back down, and the period it lands in is the period it happens. A candidate who treats the reversal as a new negative sale in a later period has the arithmetic right and the period wrong — and the GST reconciliation procedure will show it. The draft invoice is there to test whether "post" and "pay" are still understood as two separate events.

Session 6 — Marine Parade Rentals (residential property, exempt income)

In the app: Practice businesses → Residential property (the books of Marine Parade Rentals) → Start this business.

Task: Read the GST return for the period and explain where the exempt rent has gone, and what the return says about GST on the costs of the residential property.

Marking note: Exempt rent is income but it is outside the GST return: it is not in box 5 or box 8, and GST on costs relating to it is not claimable. The strongest answers notice that box 5 therefore holds only the commercial rent and any other taxable supplies, and that the return's purchases and credits should contain only the taxable side of the property costs. That apportionment is the trap in this exercise and the reason the business is in the set.

Session 7 — Whirinaki Contracting (horticulture, six-monthly)

In the app: Practice businesses → Horticulture (the books of Whirinaki Contracting) → Start this business.

Task: Save the six-monthly return as a snapshot and reconcile it to the ledger.

Marking note: A longer period contains more transactions and more chances for a misfiled one. The mark is for the reconciliation, not the total: the candidate should be able to show that the GST in the return is the GST in the ledger, transaction by transaction, rather than asserting that the totals match.

Session 8 — Foundry Labs (software, no revenue)

In the app: Practice businesses → Software (the books of Foundry Labs) → Start this business.

Task: Produce a balance sheet and a profit and loss report for a business with no income, and explain what each one says.

Marking note: This is the session that separates people who can read reports from people who can produce them. With no revenue, the profit and loss report is all costs, and the balance sheet is where the money went. A strong answer explains that a growing loss with a falling bank balance and rising creditors describes a business being funded by someone, and names who.

Session 9 — Marine Parade Dental (health, security on)

In the app: Practice businesses → Health (the books of Marine Parade Dental) → Start this business.

Task: Switch security on, set up three roles, do a piece of bookkeeping as the general manager, and run the assurance procedures as the auditor.

Marking note: The two things to look for are that the owner had set a password before any other sign-in could be switched on, and that the candidate noticed they could not change anything as the auditor. That second observation is the learning objective of the session.

Session 10 — Ngata Plumbing Ltd (trades, a busy statement)

In the app: Practice businesses → Trades (the books of Ngata Plumbing Ltd) → Start this business.

Task: Reconcile the bank, run the assurance procedures, and write a working-paper note on what the clean result does and does not prove. Then record the same manual payment twice — same amount, same description, same week — and show that A08 reports the pair.

Marking note: Mark the explanations, not the exceptions. "The reconciliation agrees" is an observation. "The reconciliation agrees because every line is coded and the closing balance is the statement's balance at its date, so the bank is accounted for" is a finding. The deliberate duplicate is the second half: the candidate should be able to say which procedure noticed it (A08 looks for the same amount described the same way inside a week), why an honest pair can look like a duplicate, and what the correction must leave behind. Run Start over afterwards so the business is clean for the next person.

Session 11 — Pacific Trading Ltd (wholesale, inventory)

In the app: Practice businesses → Wholesale (the books of Pacific Trading Ltd) → Start this business.

Task: Read the balance sheet and the profit and loss for the year ended 30 June, find the bills to the overseas suppliers, and explain how the stock bought and sold shows up in those reports — then say how you would value the stock left on the shelves.

Marking note: Inventories are measured at the lower of cost and net realisable value NZ IAS 2.9, and cost is assigned using first-in, first-out or a weighted average NZ IAS 2.25. ByteBook records the purchases and the sales; it does not keep a stock ledger, so the closing valuation is the candidate's own calculation and should show its working. The strongest answers say what they would do if the selling price fell: the write-down is recognised in the period it happens NZ IAS 2.28.

Session 12 — Precision Engineering Ltd (engineering, the rounding trap)

In the app: Practice businesses → Engineering (the books of Precision Engineering Ltd) → Start this business.

Task: Open an invoice and multiply one line out by hand, then read what ByteBook stored. Find the bank line whose amount does not match the invoice it pays. Show, from the trial balance and A14, that the two sides agree to the cent and the reports reproduce from the rows.

Marking note: This is the session that rewards patience. Money is handled as decimal cents, rounded half up, so a figure on a screen is the figure in the file. A candidate who finds a discrepancy should be able to say whether it came from a rounding rule, a GST split, or a miscoding — and should be able to show which entry caused it by reading the general ledger rather than the report.

Marking the whole course

Check	What a pass looks like
The numbers	The reports are reproduced from the rows by procedure A14
The record	No broken links in the chain; sealed periods verify
The reasoning	Every conclusion names the evidence behind it
The references	Every standard cited by paragraph, not by name
The honesty	Exceptions are reported with their cause, not hidden

1. What ByteBook is

1. In one database file on the computer it runs on — ~/Library/Application Support/ByteBook/ on a Mac, %APPDATA%\ByteBook\ on Windows. A mistake is voided, not deleted: the original and its mirror image both stay in the record.
2. Any three of: a GST return built from the transactions; a bank reconciliation against an outside document; an audit trail that detects a changed entry; an invoice and its ledger entry staying in step; ledger integrity that can be re-verified.
3. The External Reporting Board (XRB), and the IAASB published by IFAC.

2. Set up a training business

1. So that nobody can hand out a login and lock the owner out of their own books. ByteBook requires the owner to have set a password before another sign-in can be switched on, and only the owner can open the security settings.
2. In ~/Library/Application Support/ByteBook/ on a Mac, or %APPDATA%\ByteBook\ on Windows, beside a backups folder holding the last thirty copies.
3. Understand is for reading what the business did; Set up is for changing how it is configured.

3. The twelve businesses

1. Bright Cuts has no GST. Marine Parade Rentals has exempt rent beside taxable supplies.
2. Any three of: every entry balances; every invoice's lines add up to its total; the GST in the return equals the GST in the ledger; the balance sheet balances; nothing is stored off the cent; a void cancels itself out; the fingerprint chain has no breaks; the assurance programme reports no exceptions (it may still carry notes for information).
3. More transactions fall inside one return, so a single misfiled or miscoded transaction distorts the whole period, and the reconciliation has more to prove.

4. Invoices

1. August, because that is when the performance obligation is satisfied. Money received in June is not revenue; it is an amount owed back in services.
2. Posting creates the entry and moves the reports. A draft is only a document.
3. It removes the ambiguity about whether a price includes GST, so no report has to guess which way a number was meant.

5. Payments and debtors

1. $700 still owing, aged from the invoice date. That is right: the customer still owes it, and the ageing is what tells you how long they have owed it.
2. It usually means a payment was recorded against the wrong invoice or was recorded twice, so the total owed is right while the detail is wrong.
3. The standard requires the allowance for trade receivables to be measured at lifetime expected credit losses. What is left to judgement is the estimate itself — the rates and the identification of debts known to be bad.

6. Bills, expenses and documents

1. February, because that is when the service was consumed. The date the money left the bank does not decide when the expense belongs.
2. A change in estimate is recognised prospectively, in this period and future ones. A material prior period error is corrected retrospectively.
3. Whether it was an expense at all, or an asset. Above about $1,000 the procedure lists it and marks the round number; whether the description is vague, or the cost looks personal, is for you to notice when you read the entry.

7. The bank statement

1. No. The balance may agree while part of the period is unrecorded, so the reconciliation is incomplete even though the arithmetic works.
2. It was produced by the bank rather than by the business, so it is independent of the records it is being used to check.
3. Which account the payment was for. The bank line is the cash that moved, GST included, and ByteBook takes any GST out of that amount; the account's own GST treatment decides whether there is any GST in it to take out.

8. GST

1. Invoice basis: the March return, because the invoice was issued in March. Payments basis: the May period, because that is when the money moved.
2. Box 5 is total sales and income from taxable supplies, including GST (standard-rated and zero-rated, but not exempt supplies); box 8 is the GST itself. Confusing them overstates the tax owed, and they are different questions.
3. So that there is a record of what was filed, at the date it was worked out. If the ledger changes later, ByteBook can warn that the filed return no longer matches the books, and without a snapshot there is nothing to compare against.

9. Reading the reports

1. Because GST collected was never the business's income; it is held on behalf of Inland Revenue until the return is filed.
2. Because a figure that should be zero is the fastest way to see that something is wrong. Stating a difference rather than hiding it turns a silent failure into a visible one.
3. Nothing appears in Money in and out for the purchase, because no cash moved. In a full statement of cash flows the purchase would be disclosed separately as a non-cash investing and financing transaction.

10. Closing a period

1. The order in the chapter, with bank coding and reconciliation before the GST return, because the return is built from the transactions: an uncoded bank line is a transaction the return has not seen. Reproducing the reports should come after every adjustment, so that the check tests the final figures.
2. Adjusting. The customer's difficulty existed at the reporting date; the liquidation is evidence of a condition that was already there, so the amounts are adjusted.
3. Stock is written down by $2,500 to its net realisable value of $5,500, and the write-down is an expense in the period.

11. Nothing is deleted

1. The record of what was posted, and therefore the ability of anybody else to agree with the corrected figure.
2. Because a voided entry keeps the fingerprint it was sealed with. The correction is a new entry; nothing about the old one changes.
3. That an experienced auditor with no previous connection to the audit can understand the procedures performed, their results, the evidence obtained, and the significant matters and judgements.

12. The audit trail and the chain

1. Because altering one entry breaks every fingerprint after it, so a change cannot be made quietly in the middle of the record.
2. That the record has not been altered since it was written. It does not prove that the entries are correct, or that they were posted to the right accounts.
3. Because the correction is part of the history. Removing it would break the chain and destroy the record an accountant expects to see.

13. The sixteen procedures

1. Because they call for different actions. An exception needs somebody to look at it and decide something; information is something you should know. Collapsing the two would either hide real findings or manufacture work.
2. A09, cut-off, which reports entries dated inside a period that has already been packed and closed.
3. No. The procedure reports what it found and leaves the conclusion to the person. Four exceptions are four questions, not a verdict.

14. Sealed packs and working papers

1. The pack's fingerprint fails to verify, and it is detected the next time the pack is verified, because the fingerprint is recomputed from the ledger as it stands now.
2. Because a void moves the period's totals. The correction is legitimate and the period has still changed after it was sealed, and the pack is designed to detect exactly that.
3. ByteBook can test that the two sides of every entry are equal and that the figures on the reports can be reproduced from the rows. It cannot judge whether a debt will be collected or whether a provision is adequate.

15. Roles and access

1. So that no role can be created that locks the owner out, and so that every role that exists was created deliberately by someone with the highest level of access.
2. Objectivity, which requires judgement without bias, conflict of interest or undue influence. A read-only login removes the question rather than relying on trust.
3. Who can sign in, when the books were last backed up, and whether anything failed quietly. It belongs in the programme because an auditor relies on the system, so how the system is controlled and who can reach it are relevant to that reliance.

16. Reading a standard reference

1. That it is the New Zealand version of an international standard: the IAASB's ISA 230 with New Zealand additions, issued by the XRB.
2. Because it names one specific requirement that a reader can find in a minute and check. A reference to a topic cannot be re-performed.
3. That the publisher's document at that address is no longer the copy this handbook was checked against — most likely a new version. Read the current version before relying on the reference.

20. How this handbook stays accurate

1. Every reference must name a standard that is in the library; every quoted paragraph must be found in the publisher's own text; and every document must still match the SHA-256 recorded when it was downloaded.
2. Because it is more likely to be believed. An obviously old handbook invites checking; a confident wrong one is followed.
3. Because a working paper about an earlier period still has to cite the rule that applied then.

Accrual basis. Recording income and expenses when they are earned or incurred, not when the money moves. A business using the accrual basis can be profitable and short of cash at the same time.

Adjusting event. Something that happens after balance date that provides evidence of a condition existing at balance date. The amounts in the accounts are adjusted for it.

Aged debtors. Money owed by customers, grouped by how long it has been owed.

Assurance. The work an auditor or reviewer does to reach a conclusion about information somebody else prepared.

Audit trail. The record of what was entered, when, by whom, and what was done about it. In ByteBook it is a chain of fingerprints.

Audit key. A named, revocable, read-only key that lets an auditor's own tools read the audit data through the API. It cannot post, change or delete anything, and every use is written to the access log.

Balance sheet. A statement of what a business owns and owes at a date. Also called the statement of financial position.

Bill. A supplier's invoice that you will pay later. Until it is paid it sits in creditors.

Chain (the). ByteBook's page showing the record at three scales: a ribbon of every day on a time axis, the entries in order under it, and one entry taken apart beside them.

Checkpoint. A written-down record of what the ledger said when somebody checked it: how many entries, the fingerprint of the last one, and the Merkle root. Each checkpoint includes the fingerprint of the one before it.

Closing balance. The balance on a bank statement at its date.

Creditors. People and businesses the business owes money to.

Cut-off. The question of whether a transaction has been recorded in the right period. One of the sixteen procedures.

Debtors. People and businesses that owe the business money.

Depreciation. Spreading the cost of an asset over the periods it is used in.

Drawings. Money or goods an owner takes out of a business for personal use.

Effective date. The date from which a standard applies, usually expressed as periods beginning on or after a particular day.

Exempt supply. A supply that carries no GST and for which the business cannot claim GST on related costs. Rent on a residential dwelling is the common example.

Expected credit loss. The amount a business expects not to collect from money it is owed.

Fingerprint (SHA-256). A short string computed from the contents of an entry. Change the contents and the fingerprint changes.

General ledger. Every entry that touched an account, in order.

GST return. The statement of GST collected and GST credits claimed for a period, filed with Inland Revenue.

IASB. The International Accounting Standards Board, which issues IFRS accounting standards.

IAASB. The International Auditing and Assurance Standards Board, part of IFAC, which issues the international auditing standards.

IFAC. The International Federation of Accountants, which publishes the IAASB Handbook.

ISA (NZ). An international standard on auditing with New Zealand additions, issued by the XRB.

ISQM 1. The international standard on quality management for firms. In New Zealand its requirements appear in PES 3.

Ledger. The accounting record of a business's transactions. In ByteBook the general ledger is the detail and the trial balance is the summary.

Material. Large enough to matter to the person reading the financial statements. There is no fixed number; the standard defines it by whether omitting or misstating an item could influence decisions.

Merkle root. A single fingerprint computed from all the fingerprints in a record, so the whole record can be checked with one value — and so a single entry can be proved against it with a handful of hashes instead of the whole record.

NZ IFRS. New Zealand equivalents to international financial reporting standards: the IASB's text with New Zealand additions.

PES. Professional and ethical standards issued by the XRB, including the code of ethics (PES 1), quality management for firms (PES 3) and engagement quality reviews (PES 4).

Performance materiality. A lower figure than materiality, used in planning so that the chance of undetected misstatements exceeding materiality is kept low.

Performance obligation. A promise in a contract with a customer to transfer a good or service. Revenue is recognised when it is satisfied.

Posting. Recording an entry in the ledger. Until an invoice is posted it is only a document.

Provision. A liability of uncertain timing or amount, recognised where there is a present obligation from a past event, a probable outflow, and a reliable estimate.

Reconciliation. Comparing two records that should agree — the ledger and the bank — and explaining the difference.

Practice business. A complete set of books for a New Zealand business, kept beside your own and opened from Practice businesses in the sidebar. Twelve of them ship with ByteBook, one for each kind of trade.

Receipt (integrity). A short printed record of a checkpoint, small enough to email. A copy held outside the books is what detects a record rewritten as a whole, because a rewrite inside the file cannot reach your copy.

Sealed pack. A period's entries, figures and fingerprints hashed together into a single value, so it can be verified later.

Trial balance. Every account with its balance, used to check that total debits equal total credits.

Turnover. Total sales, usually excluding GST.

Unmodified opinion. An auditor's conclusion that the financial statements are prepared, in all material respects, in accordance with the applicable framework. The everyday term is a clean opinion.

Void. To cancel an entry by posting its mirror image, leaving both in the record.

XRB. The External Reporting Board, which issues New Zealand's accounting and auditing standards.

Zero-rated supply. A supply taxed at 0%: it carries no GST but is not exempt, so GST on related costs can usually still be claimed.