Invoice automation changes how finance teams process bills. What it doesn’t automatically change is the quality of the record those decisions leave behind. The audit trail failures that automation introduces are often invisible until an auditor, a fraud investigation, or a regulatory review surfaces them - at which point reconstructing what happened becomes expensive and sometimes impossible.
Most finance teams implementing automation focus on speed and accuracy of extraction. What they miss is that the audit trail requirements in an automated environment are more demanding than in a manual one, not less, because the volume of decisions being made without direct human review is larger.
What happens when you record the approval but not the verification?
The most frequent gap in automated AP systems is an audit trail that shows who approved an invoice but not what was checked before approval. An approval event without a verification record is not a control. It is a signature with no substance behind it.
A finance manager at a healthcare provider in Queensland described how this gap created a specific problem during a compliance review. The team could show that an invoice had been approved. They couldn’t show that the supplier’s changed banking details had been reviewed before it was approved. The automation had cleared the exception. There was no record of who cleared it or why. The compliance reviewer treated the exception resolution as undocumented - which, for audit purposes, it was.
Good audit trail design captures both the approval event and the pre-approval steps: whether the supplier’s bank details were validated against historical records as part of internal controls, whether the invoice was matched against a purchase order, whether any exceptions were flagged and how they were resolved. If these steps happen manually outside the system - in an email, by phone, by informal review - they don’t appear in the trail.
Exception handling that routes to email
Many automation implementations treat exception resolution as an informal step. Someone receives a flag, makes a decision, and clears it without that decision being recorded in the system. An exception flag resolved by email is not in the audit trail. An exception flag resolved by a verbal conversation with the supplier is not in the audit trail. The trail shows that the exception existed and was cleared. It doesn’t show how.
This gap is material in any audit or investigation, because the exception is exactly the moment where the highest-risk decision is made. A flagged invoice - one where the bank details changed, or where the amount exceeds the approver’s threshold, or where the invoice number matches an existing bill - requires a documented resolution, not just a cleared status. The reason the flag was cleared, who reviewed it, and what additional verification was done should all be captured in the system.
The split trail problem
Many automation implementations create a trail in the AP tool but not in the accounting system. When invoices are published to Xero or MYOB, they arrive as clean, approved bills. The record of what happened before they arrived doesn’t transfer.
This creates a split trail: the AP tool has the pre-approval history, the accounting system has the ledger record, and there is no link between them. Understanding what a modern AP system needs to do helps explain why a unified trail matters. During an audit, the finance team needs to cross-reference two systems to reconstruct what happened for a single invoice. For a business processing hundreds of invoices a month, that reconstruction becomes impractical. The pre-approval audit trail - covering extraction, coding, validation, exception handling, and approval routing - needs to be accessible regardless of whether the reviewer is starting from the AP tool or the accounting system.
Shared logins and what they destroy
Shared logins eliminate the audit trail’s usefulness as a control mechanism. This is a common AP fraud vulnerability that auditors flag immediately. If two people use the same account to approve invoices, the record shows the account name, not the individual. In an audit, this is a segregation of duties failure regardless of what actually happened.
This is a segregation of duties failure that is more common in smaller Australian businesses than finance teams usually acknowledge. The typical scenario: a business purchased one seat of their approval software to keep costs down and set up shared credentials for the accounts team. The workflow functions. The trail doesn’t. Every approval shows the same account name, making it impossible to confirm that the person approving had authority for the amount, or that the approver and the invoice entry weren’t the same person.
What does good audit trail design look like?
A defensible audit trail in an automated environment needs to be complete (every action on every invoice is recorded from receipt to publication), attributable (every action is linked to a specific, identifiable user - not a shared account), and immutable (records cannot be edited or deleted after the fact, even by administrators). Timestamps should be system-generated. Exception resolutions should include a documented reason. The trail should connect events in the AP automation tool with the corresponding records in Xero or MYOB.
The data retention question should be resolved before go-live, not after. Under ATO record-keeping requirements, businesses must retain tax records for five years from the date the record is created or the transaction is completed. If the AP automation software’s default retention window is shorter than five years, records may be purged before they are needed for compliance.
Sources: ATO - Record-keeping requirements for business · ASIC - Financial reporting obligations
Further reading: How to Build an Audit-Ready Approval Matrix · Why Delegation of Authority Matters More Than Automation Speed · Best AP Automation Software Australia 2026