Skip to content
Audit readiness

Audit Trail: How the Auditor Follows One Bill

Is everything in order?

Audit a supplier for free

What is an audit trail?

An audit trail is the record your accounting system keeps of what happened to each transaction, step by step: when a bill arrived, who entered it, who approved it, who changed it afterwards and which payment settled it, each with a user name and a time the system wrote itself. Auditors use it to check that your process runs the way you say it does, and they trust it only as far as it can say who did what. For the bookkeeper, a good audit trail means any bill can be opened and its history read out from first line to last without anyone having to remember a thing.

Check one supplier invoice against what you agreed to pay, free: the proof the payables line of the request list asks for.

Is everything in order?

Audit a supplier for free

What does the auditor do with it?

Early in the audit, the auditor learns how your transactions move from the first document into the financial statements, as AU-C 315, the AICPA’s standard on assessing risk, requires: how a bill starts, is recorded, approved and paid, and which people and systems handle each step. Asking staff is not enough on its own, so the auditor also watches and inspects. The usual way is a walkthrough, following one transaction from start to finish through your records, which AU-C 315 says will usually show whether a control such as an approval is really in place.

The history screen is information your own system produced, and AU-C 500, the AICPA’s standard on audit evidence, asks the auditor to judge whether such information is relevant and can be trusted, and to get support that it is accurate and complete when they plan to rely on it. Part of that support is the checks behind the system itself: who can log in, and who can change its programs and data.

Worked example: one bill at Ashcombe Industrial Supply

Ashcombe Industrial Supply is an invented company, and in this example the auditor picks one $18,400 bill from Harrow Packaging and reads its history with the bookkeeper:

  • 3 March: the PDF arrives in the payables inbox.
  • 4 March: the AP clerk enters the bill under their own login.
  • 6 March: the operations manager approves it, within a $25,000 limit.
  • 2 April: the controller releases the bank run that pays it, and the bank shows $18,400 leaving the same day.
  1. ReceivedThe PDF arrives on 3 March.
  2. EnteredThe AP clerk enters it on 4 March.
  3. ApprovedThe operations manager approves it on 6 March.
  4. Bank details changedHarrow’s account is changed on 31 March, under a shared login.
  5. PaidThe bank run on 2 April sends $18,400 to the new account.
The auditor follows one $18,400 bill from the inbox to the bank, and every step needs a name and a date.

One line does not hold up. On 31 March, two days before the run, Harrow’s bank account was changed under a shared login that three people use, with no second approval, and the payment went to the new account. The history shows that a change happened but not who made it, so for that step the auditor cannot rely on the system’s own record.

Where does an audit trail break?

Two places are the most common, and the first is an approval given outside the system, in a chat message or a hallway, so the bill shows as approved with nothing behind it. The second is an edit after approval: an amount that moves from $18,400 to $18,900, or bank details changed under a shared login or with no log entry at all.

When the record is doubtful, AU-C 500 has the auditor decide whether to change or add procedures to settle it. At Ashcombe that meant calling Harrow on the number in its contract to confirm the new account, then reading every bank-detail change made that year, because a shared login casts doubt on all of them, not only this one. The bill was fine, but one missing name cost the bookkeeper a week of extra requests.

How do you keep the trail whole?

You keep it whole by making sure every step a bill takes is done inside the system, under one person’s own login, so the history can always name who acted and when:

  • One login per person. A shared login makes every change made under it anonymous, however careful the people sharing it are.
  • Approve in the system. An approval anywhere else leaves no record the auditor can rely on.
  • Treat a bank-detail change like a payment. Record who asked for it, confirm it with the supplier on a number you already hold, and have a second person approve it.
  • Keep the document with the entry. The bill, its approval and its payment should be one search away.

This is where Ressura helps the bookkeeper show that everything is in order. The Master Data Module logs every change to a supplier’s bank details with who changed it and when, and flags it. The Cash & Bank Module flags a payment to a new or changed account, and a payment above the limit you set that has no recorded approver. So when the auditor opens a bill, its history already has a name on every line.

For the sample of bills that comes after the walkthrough, read how audit sampling works.

Sources

  1. AU-C 315, the AICPA’s standard on assessing risk
On this page