How ERP Audit Trails Actually Work, and Where They Fall Short
During a routine SOX audit, a mid-size public company's external auditors asked for the audit trail showing who had changed a specific vendor's banking details three weeks before a $47,000 payment went to an account that turned out to be fraudulent. The company's ERP had audit logging enabled — but only for financial transaction records, not for master data changes like vendor bank account fields. The change that mattered most wasn't logged at all. This is a specific, common gap: most people assume "we have audit trails turned on" means everything of consequence is captured, and in a default configuration, it usually isn't.
What an ERP audit trail actually is
An audit trail is a chronological record of who did what, when, to which record, and — for a well-configured system — what the value was before and after the change. It's built by the ERP logging specific events (a record being created, modified, deleted, or a status changed) alongside metadata: the user ID, timestamp, IP address or session info, and the old versus new value of whatever field changed. This is different from a general system log or activity log, which might just record that "user X logged in" without capturing the substance of what they changed once inside.
What gets logged by default versus what has to be explicitly configured
Most ERP systems log financial transaction records reasonably well out of the box — journal entries, invoice postings, payment runs — because that's the category auditors check most often and vendors build compliance features around it. What's frequently not logged by default, and has to be explicitly turned on:
- Master data changes: vendor bank details, customer credit limits, employee pay rates, price list changes. These are exactly the fields most attractive to fraud, precisely because they're quieter and less routinely reviewed than transaction records.
- Permission and role changes: who granted themselves or someone else elevated access, and when. Without this logged, a user who temporarily grants themselves approval authority, does something with it, then reverts the permission, can leave close to no trace.
- Configuration changes: approval workflow thresholds, automated posting rules, tax calculation settings. A change to an approval threshold from $5,000 to $50,000 can be more consequential than any individual transaction, and it's easy to miss in a system only logging transactional activity.
- Read access to sensitive data, as opposed to just write/change access. Some regulated data categories require tracking who viewed a record, not just who edited it — this is a separate logging capability many systems don't enable by default.
How auditors actually use this data
External and internal auditors typically don't review every logged change — the volume makes that impractical for anything beyond a small company. Instead, they sample: pulling a statistically representative set of transactions or changes within a period and verifying the audit trail shows appropriate approval, segregation of duties, and no unauthorized changes. For SOX-regulated companies specifically, auditors check whether the audit trail itself is tamper-resistant — whether a user with database-level access could theoretically alter or delete log entries, which would invalidate the trail's reliability regardless of what it captured.
This is why audit trail configuration is a genuine control, not paperwork: a company that can't produce a clean audit trail for a sampled transaction, or whose logs could plausibly have been altered, gets flagged as a control deficiency even if nothing was actually wrong with the underlying transaction — the absence of provable evidence is itself the finding.
The gap that catches companies most often: segregation of duties
A functioning audit trail tells you who changed what. It does not, by itself, tell you whether that person should have been able to make that change given everything else they're allowed to do in the system. The classic example: a single user with both vendor master-data edit access and payment-processing access can create a fake vendor, process a payment to it, and every individual action logs cleanly and correctly — the audit trail is technically complete, and still misses the actual problem, because the problem is the combination of permissions, not any single logged action.
Catching this requires a segregation-of-duties review layered on top of the audit trail, not the audit trail alone: a periodic check of which users hold combinations of access that shouldn't coexist (create vendor + approve payment, create PO + approve PO, edit price list + approve customer credit). Most mid-market ERPs don't flag this automatically; it has to be run as a deliberate, recurring access review, ideally quarterly for higher-risk combinations.
Making logs actually tamper-resistant
"Tamper-resistant" gets used loosely, so it's worth being specific about what actually achieves it. The baseline, available in most mid-market ERPs, is a dedicated audit log table that regular user roles, including most administrators, have no write or delete access to, with log-modification rights restricted to a tightly controlled service account that itself is monitored. A stronger version, more common in larger or heavily regulated environments, streams audit events to a separate system entirely — a write-once log aggregation platform or SIEM tool outside the ERP's own database — so that even someone with full database administrator access to the ERP itself can't quietly edit the historical record, because the authoritative copy lives somewhere they don't control. For a company handling sensitive financial data or subject to SOX, PCI-DSS, or similar frameworks, exporting audit logs to a separate, access-controlled system on a scheduled basis is a relatively low-cost step that meaningfully strengthens the "could this have been altered" answer auditors specifically probe for.
What different regulatory frameworks actually expect
The specifics vary by which framework applies, and it's worth knowing the emphasis of each rather than treating "audit trail" as one uniform requirement. SOX (for public companies) focuses heavily on financial transaction integrity and segregation of duties around anything touching revenue recognition or financial reporting. PCI-DSS, relevant for any ERP handling payment card data, requires tracking access to cardholder data specifically, including read access, with retention requirements around how long those logs must be kept. GDPR and similar data-protection frameworks care about who accessed personal data and why, which pushes toward the read-access logging most systems don't enable by default. A company subject to more than one of these frameworks — common for a mid-size company handling both financial reporting and customer payment data — needs to configure logging against the union of all applicable requirements, not just whichever one its compliance team happens to be most familiar with, since gaps tend to show up exactly at the boundary between frameworks that nobody was explicitly assigned to own.
A practical checklist for reviewing your own audit trail setup
- Confirm master data changes are logged, not just transaction postings — specifically vendor banking details, customer credit terms, and price lists.
- Confirm permission/role changes are logged with before-and-after values, not just a generic "user permissions modified" entry with no detail.
- Confirm the logs themselves are tamper-resistant — check whether anyone with elevated database access could edit or delete audit log entries, and if so, that's a finding worth escalating regardless of whether it's ever been exploited.
- Run a segregation-of-duties report at least quarterly, checking specifically for the high-risk permission combinations listed above.
- Test retrieval, not just capture. Pull a sample audit trail entry from six months ago and confirm someone can actually produce it in a readable format within a reasonable time — logs that exist somewhere but can't be efficiently retrieved don't hold up well under actual audit pressure.
The company in the opening example fixed the gap by enabling master data change logging retroactively and adding a segregation-of-duties review to their quarterly close process. The fraud itself was a hard lesson, but the deeper finding for their audit committee wasn't the fraud — it was that "we have audit trails" had been treated as a complete answer to a security question for years, when it was actually only a partial one, true for transactions and false for exactly the kind of quiet master-data change that mattered most.