Building Audit Trail Systems for Accounts Payable Approval Workflows
An internal audit team I worked with flagged an accounts payable process where the approval hierarchy existed on paper, in a policy document nobody had opened in two years, but not in the system that actually processed payments. Anyone with vendor-entry access could create a new vendor and push a payment through without a second set of eyes ever seeing it. No fraud had happened yet. The exposure was sitting there waiting for someone to find it, either an auditor or someone with worse intentions.
The Gap Between Policy and System
Most AP fraud and most AP audit findings don't come from sophisticated schemes. They come from this exact gap: the company has an approval policy, but the ERP or AP automation tool isn't configured to enforce it. Someone writes "all invoices over $10,000 require director approval" in a policy manual, and the system has no idea that rule exists. Approval happens by habit and goodwill, not by system control, which means it's exactly one busy week away from breaking down.
Building a real audit trail starts with making the approval hierarchy a property of the system, not a document. That sounds obvious, but I've walked into more than one AP department where the policy and the system had drifted apart over years of org changes, and nobody had gone back to reconcile them.
What a Real Audit Trail Captures
An audit trail that actually holds up under scrutiny, whether from an external auditor, an internal investigation, or a regulator, needs to capture more than "approved" or "rejected." It needs:
- Who took the action, tied to an authenticated user identity, not a shared login
- What the invoice looked like at the moment of that action, including amount, vendor, GL coding, and any attachments, because invoices sometimes get edited after initial entry
- The timestamp, in a format that can't be altered after the fact
- The specific approval rule that routed the invoice to that approver, so you can later prove the routing logic was correct and not manually overridden
- Any delegation or out-of-office reassignment, because approvals routed through a delegate need to show both the original approver and the delegate
The last point trips up a lot of implementations. When an approver is on vacation and delegates authority to someone else, most systems either block the approval entirely, which creates a bottleneck, or silently reassign it without logging that a delegation happened. Neither is acceptable from an audit standpoint. The trail needs to show explicitly that Approver A delegated to Approver B for the period in question, with a record of who authorized that delegation.
Designing the Approval Matrix as Data, Not Logic Buried in Code
I've seen approval hierarchies hardcoded directly into workflow rules inside tools like Coupa, SAP Ariba, or a custom Power Automate flow. This works until the org chart changes, which for most mid-size companies happens every few months. When the hierarchy lives as hardcoded conditional logic, every reorg requires a developer or admin to go back into the workflow builder and manually update routing rules, and it's easy to miss an edge case.
The better pattern is to externalize the approval matrix into a table: dollar thresholds, GL account category, entity, and the corresponding approver or approver role. The workflow engine reads from this table at runtime rather than having the hierarchy baked into its own logic. When someone changes roles, you update one row in the table instead of hunting through workflow definitions. This also means the audit trail can reference the exact version of the approval matrix that was in effect when a given invoice was processed, which matters if the matrix changes between when an invoice was submitted and when it was approved.
Handling the Exceptions Honestly
Every AP process has legitimate exceptions: emergency payments that need to go out same-day, invoices from a new vendor that hasn't finished onboarding yet, corrections to a miscoded invoice after initial approval. The temptation is to build an "override" button that lets someone bypass the normal flow, and then not audit-log the override with the same rigor as normal approvals, because it feels like a one-off.
Every override needs to log more detail than a normal approval, not less: who invoked it, what the normal approval path would have been, and a required justification field that isn't a free-text box people can leave blank or fill with "urgent." I've made this a required dropdown of specific reason codes, with a free-text field only enabled for the "other" category, and that "other" category gets flagged for review by the controller monthly, specifically because unstructured override reasons are the first thing an auditor pulls when they're looking for control weaknesses.
What This Looks Like When It's Working
The measure of success isn't a clean SOC 2 report, though that follows. It's that when the CFO asks "who approved this $85,000 invoice to a vendor we've never used before, and why," the answer takes thirty seconds to pull up instead of a week of digging through email threads and asking around the department. I've sat in enough post-incident reviews to know that the companies who recover fastest from a payment error or an attempted fraud are the ones whose audit trail was designed before they needed it, not reconstructed after.
