Audit Trail in ERP Systems
An audit trail is a chronological, tamper-evident record of all relevant changes in an ERP system: who did what, when, from where, and what the data looked like before. For US companies, the audit trail underpins compliance with the Sarbanes-Oxley Act (SOX) and supports defensible books and records under IRS rules and US GAAP — without it, the reliability of digital records can be challenged during an external audit, an SEC examination or an IRS examination. Audit trails also support internal compliance, fraud detection and operational troubleshooting.
What must be logged
For financially relevant transactions (everything affecting the general ledger and tax-relevant balances): user ID, timestamp (date and time), action type (create / read / update / delete), affected record, old value, new value, source (workstation IP or username), and a session identifier. For lower-relevance operations: at least user, timestamp and action. The audit trail itself must be immutable — appending records is allowed, modifying or deleting past entries is not.
Retention periods
There is no single US retention rule; the period depends on which framework applies. Under Sarbanes-Oxley, records and supporting documentation underlying audited financial statements must generally be retained for 7 years. The IRS expects business records that support a tax return to be kept at least 3 years, 6 years where income is understated by more than 25%, and 4 years for employment-tax records. For SEC-regulated broker-dealers, SEC Rule 17a-4 requires general-ledger and accounting records to be preserved for 6 years in a non-rewriteable (WORM) format or, since the 2022 amendments, in a system with a complete time-stamped audit trail of all modifications and deletions. Many companies standardize on a 7-year (or longer) retention baseline to cover all of these. Note that retention applies to the audit trail itself, not just to the records it documents — if you delete the audit-trail entries early, the affected records lose their evidential value.
How ERP systems implement audit trails
Strong implementations: SAP S/4HANA uses change documents and document journals with built-in immutability; Microsoft Dynamics 365 Business Central tracks via change-log entries on monitored tables; Oracle NetSuite, Sage Intacct, Acumatica, Epicor and Infor provide configurable audit-logging and field-level change tracking suitable for SOX environments. Lightweight or heavily customized systems often require add-on modules or careful configuration to reach full, tamper-evident audit-trail behavior, so it is worth confirming the depth of native logging during vendor evaluation rather than assuming it.
Compliance frameworks beyond SOX
The Sarbanes-Oxley Act is the most-encountered driver of audit-trail design for US public companies, but several adjacent frameworks impose their own audit-trail expectations. SOX Section 404: management (and, for larger filers, the external auditor) must assess and report on internal control over financial reporting — a complete, accessible audit trail is core evidence that only authorized users changed financial-relevant data and when. SOC 1 / SSAE 18 attestation: when an ERP or accounting function is outsourced to a service provider, a SOC 1 (SSAE 18) report from the provider documents the relevant controls, including its audit-trail mechanism, for your auditor to rely on — the practical US counterpart to a software-control attestation. 21 CFR Part 11 (FDA): for pharma, biotech, medical devices and food, electronic records and signatures must be linked to user accountability and a secure, computer-generated, unalterable history — see GxP validation. HIPAA: for healthcare and any system touching protected health information, audit controls that record access to and changes in electronic records are an explicit safeguard. ISO 27001 Annex A (logging and monitoring): requires that operating-system, application, and database administrator activity is logged and reviewed. The implication for ERP selection: a single, unified audit trail across all modules is easier to operate and audit than module-specific logs — ask vendors specifically how they implement cross-module correlation.
Operating an audit trail in practice
A well-operated audit trail has three operational layers. (1) Configuration: which tables and fields are logged, at what level of detail. Over-logging produces noise; under-logging produces gaps. Mid-market practice: full audit on all financially relevant tables (general ledger, AR, AP, fixed assets, inventory-valuation movements, payroll), summary audit on master data (customers, suppliers, items) capturing user, timestamp, before/after values, partial audit on operational tables (orders, deliveries) capturing create/delete events only. (2) Storage and immutability: dedicated audit-log tables with INSERT-only privileges, replicated to write-once-read-many (WORM) storage for records that must satisfy SOX or SEC retention. Typical volume: 5–50 GB per year for a mid-market ERP, mostly compressible. (3) Review and forensics: automated detection rules flag suspicious patterns (after-hours master-data changes, payment routings to new accounts within 24 hours of supplier-bank-detail changes, segregation-of-duties violations). During a SOX walkthrough or external audit, testers typically request the audit-trail extract for a sample of 5–20 specific transactions — the ERP must produce a complete, human-readable extract within hours, not days. Modern ERP suites all support this; legacy custom systems often do not, which is a common reason for ERP-replacement projects.
Beyond the ERP boundary — correlating cross-system events
A modern ERP audit trail alone is necessary but rarely sufficient for the full forensic picture. Mid-market and enterprise operations increasingly correlate ERP audit events with adjacent system logs to detect multi-stage incidents that a single audit trail cannot reveal. Typical correlated sources: identity-provider sign-in logs (who logged in from where, with what MFA factor), VPN connection logs, endpoint EDR logs, email-gateway records, document-management retrieval logs, payment-gateway authorization logs. The correlation engine is typically a SIEM or a data-lake-style security analytics platform — Microsoft Sentinel, Splunk, Elastic Security, Google Chronicle, IBM QRadar. The ERP forwards its audit log via syslog or a vendor connector; the SIEM normalizes and stores it alongside other logs. Sample multi-stage detection: (1) a phishing email targets the AP team, (2) the recipient's endpoint shows a credential-theft indicator, (3) the same user logs in from an unusual geolocation an hour later, (4) the supplier-bank-detail audit log shows a master-data change to redirect payments, (5) a payment run is initiated 30 minutes after that change — the pattern of a business email compromise (BEC) fraud. No single log shows the full chain; correlation across them does. With the SEC's cybersecurity disclosure rules, the FTC Safeguards Rule and state breach-notification laws raising the bar for detection and reporting, this capability is increasingly business-as-usual. Mid-market companies typically operate it through a managed SOC (security operations center) service rather than building in-house.