Thursday, October 15, 2026

What is an audit trail? How to keep one your auditors can follow

Procapy Team

Three weeks into the annual audit, the external auditors send their sample: forty payments from last year. One is Rp 81,900,000 to a printing vendor on 14 March. The auditor wants to know who asked for it, who approved it, what was delivered and why the bank account on the payment differs from the one on the vendor’s invoice.

The request is in an email thread. The approval was an “ok” on WhatsApp from a marketing manager who left in June. The signed delivery note is in a binder in the warehouse. The bank account was changed after the vendor emailed a letter, two days before the payment run, by someone using the AP team’s shared login. Putting it together takes two days, and the vendor confirms they did receive the money. The auditor writes it up in the management letter anyway, because nobody can show that a payment to the wrong account would have been stopped.

Every one of those answers is part of an audit trail, and this one was scattered across email, chat and a binder, with the most important part missing. This guide explains what an audit trail is, what a good one records, how auditors use it, a worked example of one payment traced end to end and how to build a trail that answers the auditor’s questions before they’re asked.

What is an audit trail?

An audit trail is the record of everything that happened to a transaction: who did what, when and what changed, together with the evidence for each step. For a supplier payment, it runs from the purchase request through approval, the purchase order, the goods received, the invoice and the payment to the entry in the general ledger. For an expense claim, it runs from the receipt to the reimbursement.

The term is used in two ways. In the narrow sense, it means a system’s activity log: the timestamped list of actions on a record. In the wider sense, it’s the whole chain of documents and decisions behind a number in the accounts. Auditors need both: the documents show what happened, and the log shows that nobody changed the story afterwards.

Auditors use the trail in two directions:

Vouching starts from an entry in the ledger and works back to the evidence, to check that what was recorded really happened.
Tracing starts from the source documents and works forward to the ledger, to check that what happened was recorded.

A trail that only works one way answers half the questions.

What a good audit trail records

For every action on a transaction, a good trail shows:

Who: a named person, or a named system or agent, never a shared login.
What: the action itself, such as created, edited, approved, rejected, paid or posted.
When: the date and time, recorded by the system rather than typed in.
Before and after: for every change, the old value as well as the new one.
Why: a reason for anything unusual, such as an override, an exception or a late entry.
The evidence: the source document attached to the transaction, not stored somewhere it has to be found.
The link to the ledger: a reference from the transaction to its journal, and back.

And the trail itself needs four properties. It can’t be edited or deleted, by anyone. It’s complete, so actions taken outside it don’t exist. It’s kept for as long as the law and your auditors need. And someone who wasn’t there can read it and understand what happened.

A worked example: one payment, traced

Here is the Rp 81,900,000 payment from the opening, as a complete trail would show it. Marketing ordered 2,000 printed catalogues at Rp 42,000 each:

Date	What happened	Rp ’000
3 Feb	Marketing executive requests 2,000 catalogues	84,000
4 Feb	Marketing manager approves the request	84,000
5 Feb	Procurement issues the purchase order	84,000
24 Feb	Warehouse records 1,950 catalogues received	81,900
26 Feb	Invoice for 2,000 arrives; AP matches it to 1,950	81,900
27 Feb	Finance manager approves the invoice	81,900
10 Mar	Vendor’s new bank account approved after a call-back
14 Mar	Finance director releases the payment; it posts to the ledger	81,900

Against this trail, the auditor can check each of the questions they care about:

Did it happen? The warehouse recorded the delivery, with a named person and a date.
Was it authorised? Each approval was given by someone with the authority for Rp 84 million under the company’s approval matrix, and nobody approved their own request.
Is the amount right? The vendor invoiced 2,000 catalogues, but only 1,950 arrived. Three-way matching approved 1,950 × Rp 42,000 = Rp 81,900,000 and held back Rp 2,100,000 for the missing 50, until a credit note or the rest of the delivery arrives.
Is it in the right period? The catalogues arrived on 24 February, so the cost and the liability belong in February, even though the cash left in March.
Were duties separated? Seven people touched the transaction, and none of them both approved and paid. The bank account change was entered by AP, confirmed by calling the vendor on the number already on file and approved by the finance manager, not by whoever entered it.
Can it be followed both ways? The payment in the ledger refers to the invoice, and the invoice to the purchase order and the receipt.

The trail in the opening broke in three places: the approval, the delivery record and the bank account change. The money went to the right place. The trail just couldn’t prove it would have stopped it going anywhere else.

Why audit trails break in practice

Approvals outside the system. A yes in a meeting, a thumbs-up in a chat group or an email to one person. The approval exists, but not anywhere an auditor can find it nine months later.
Shared logins. When the AP team shares one account, every entry was made by “finance”, and the log can’t tell you who.
Logs that can be changed. A posted entry can be edited or deleted without a trace, or an edit overwrites the old value instead of keeping it.
Evidence in several places. The receipt in the expense tool, the approval in email, the contract in a shared drive and the journal in the ERP, linked by nothing but a file name.
Master data with no history. Vendor bank details, approval limits and user roles change without a record of who changed them, which is exactly where payment fraud starts.
Paper that fades. A thermal receipt is blank after a year or so, and the photo of it is on a phone that has since been replaced.
A trail that stops at the ledger. The expense or AP system and the ledger share no reference, so matching a journal to its source is a manual search.

Audit trails in Indonesia

Records are kept for years. Indonesian tax law requires books, records and the documents behind them to be kept for ten years, and a tax audit can ask about a transaction long after the people involved have moved on. A trail that lives in an employee’s inbox or on thermal paper won’t last that long.
Tax documents belong on the same trail. Input VAT can only be credited with a complete and correct faktur pajak, and where you withhold PPh 23 on a service, the withholding slip (bukti potong) is part of the same payment’s story. Keep them with the invoice they relate to, not in a separate tax folder.
Electronic records count as evidence. The electronic information and transactions law (UU ITE) recognises electronic documents as legal evidence, as long as they can be accessed and displayed and their integrity can be shown. A log that nobody can edit is how you show integrity.
WhatsApp approvals. Approving by chat is quick and common, but the chat sits on someone’s personal phone and leaves with them. A screenshot shows a message, not an approval anyone can verify.
The trail holds personal data. Expense claims and activity logs record employees’ names, spending and movements, which the personal data protection law (UU PDP) covers. Give auditors access to the entities and periods under review, not to everything, and keep a record of what they open.

Signs your audit trail needs work

You probably need to look at your trail if any of these sound familiar:

Approvals are given by chat, email or in meetings, and recorded nowhere else.
More than one person uses the same login to the accounting system or the bank portal.
A posted transaction can be edited or deleted without leaving a trace.
Nobody can say who last changed a vendor’s bank account, or when.
Answering one item in an audit sample takes an hour, because the evidence is in several places.
Receipts are kept on paper, and the older ones have faded.
A month that has been closed can still be changed.

To an auditor, an approval nobody can find is an approval that never happened.

How to build an audit trail your auditors can follow

Move every approval into one system. Agree that an approval given by chat or in a meeting doesn’t count until it’s recorded on the transaction, and write that into your approval policy.
Give everyone their own login. That includes the accounting system and the bank portal. A shared account turns every action into “admin”.
Attach the evidence at the start. Capture the receipt or invoice when the spend happens, and keep it on the transaction rather than in a separate drive.
Log changes to master data. Every change to vendor bank details, approval limits and user roles should be recorded, and a bank account change approved by a second person after a call to a number you already have.
Correct by adding, not overwriting. Fix a wrong entry with a reversal or an amendment that keeps the original and records the reason.
Link every journal to its source. Each journal should carry a reference to the transaction behind it, and each transaction to the journal it created.
Lock closed periods. Once a month is closed, nothing in it should change; late items go into the next month with a note. The month-end close checklist covers the rest of the close.
Trace a few transactions yourself. Each quarter, pick five payments and follow them back to the request, and five invoices forward to the ledger. Wherever you get stuck, your auditor will too.

How Procapy helps

In Proca to Pay and Capy Expense, every transaction carries its own evidence: the source document, the data ProcAI read from it, the GL and cost centre coding, and every approval, comment and attachment. Every action is logged with who did it and when, from submission, edits, approvals and rejections to coding changes, the sync to your ledger and payment. Edits create a new version and keep the old one, and nobody, including an administrator, can rewrite what happened. Proca Agents log each action with its reasoning, in the same trail as your team’s own.

Receipts are captured when the spend happens and stored as the original image with the data read from it, with retention periods set per entity to match the local requirement. Creating a transaction, approving it, releasing payment and changing vendor bank details are separate roles, the system stops one person holding conflicting roles on a single transaction and every change to the role setup is logged. Closed periods are locked, and approved transactions post to your ERP or accounting system with a reference on both sides.

Your auditors can have their own read-only access, limited to the entities and periods under review, and everything they open is logged as well. Random or stratified samples can be drawn by amount, vendor, category or period, with the complete file for each item exported in one pass. The audit page covers the rest. Book a 30-minute walkthrough, bring the sample request from your last audit and we’ll pull the evidence for it live.

Back to blog