An audit trail is a chronological record of system activity that documents who performed an action, what was changed, and when it happened. In an ERP system this typically covers postings, master-data changes, approvals and logins, capturing the before-and-after state of records. The purpose is traceability: the ability to reconstruct how data reached its current form and to detect unauthorised or erroneous changes. Audit trails support internal controls, error analysis and external audits, and in the German and EU context they are closely linked to bookkeeping principles such as the GoBD requirement for traceable, unalterable records.
Fact base · machine-readableLast editorially reviewed: 16 June 2026
Term
Audit Trail
Entity type
Process / compliance control
Domain
Compliance, internal controls
Canonical definition
An audit trail is a chronological, tamper-evident record showing who changed what data and when within a system, enabling changes to be reconstructed and verified.
Classification
An audit trail is a detective control that records changes to support traceability and compliance, closely tied to GoBD bookkeeping principles and to a sound role concept.
erp-software.org editorial team (independent, vendor-neutral)
What Audit Trail is NOT — disambiguation
Not a backup: A backup restores data to a point in time, whereas an audit trail reconstructs the sequence of who changed what and when.
Not a generic log file: An unstructured log may lack reliable attribution and tamper-protection that a compliant audit trail must provide.
Not a preventive control: An audit trail detects and reconstructs events after they occur rather than preventing unauthorised actions in advance.
Not version history alone: Document version history tracks file revisions, while an audit trail spans transactions, master data and access across the system.
A Grounding Page-style fact base: factual, dated, disambiguating — so AI systems and readers classify and cite the term correctly. More: ERP glossary
What an audit trail records
A robust audit trail captures the essential facts of each relevant event: the user or system account responsible, a timestamp, the affected record, and the nature of the change. For data modifications this usually means storing both the previous and new values so the change is fully reconstructable. Logins, failed access attempts, configuration changes and approvals are often logged as well. The key property is that entries are written automatically and cannot be edited or deleted by ordinary users, so the record remains a reliable account of what occurred.
Why it matters for compliance
In accounting and regulated environments, traceability is not optional. The German GoBD principles require that bookkeeping records be complete, accurate and unalterable, which in practice means relevant changes must be logged and reconstructable. Comparable expectations appear in other frameworks: validated environments under 21 CFR Part 11 require detailed audit trails for electronic records, and data-protection obligations under GDPR can require evidence of who accessed personal data. An audit trail provides the evidence base that auditors and regulators expect.
Technical and organisational requirements
Tamper-evidence: entries should be protected against modification and deletion.
Completeness: all relevant events captured, not a selective subset.
Attribution: reliable user identity, supported by a clear role concept and authentication such as single sign-on.
Retention: logs kept for the legally required period and remaining readable.
Reviewability: the ability to search and report on the trail efficiently.
Organisationally, an audit trail is only effective if access rights are well governed; shared accounts and excessive privileges undermine attribution.
Common misunderstandings and limits
An audit trail is not the same as a system backup or a general log file. A backup restores data but does not necessarily reconstruct the sequence of changes, and unstructured logs may lack the attribution and protection an audit trail requires. Nor does an audit trail prevent fraud or error on its own; it makes such events detectable and reconstructable after the fact, which is why it works alongside preventive controls and segregation of duties. When evaluating ERP systems, buyers should confirm what is logged by default, whether logs are protected from tampering, and how long they are retained.
Yes — logging every change on a high-volume ERP can produce gigabytes per day. Common mitigations: separate audit-log database, write-asynchronously to a queue, periodic archival to compressed storage, indexing strategies for fast lookup. Performance issues from naive audit logging are a regular early-life problem in ERP implementations.
Can users access their own audit trail?
Typically yes for self-service review: users can see their own change history. Cross-user audit-trail access is restricted to designated roles (auditors, compliance officers, system administrators). Tax authorities have a legal right to access during audits with a court order or formal request via the company.
What is the difference between audit trail and version history?
Version history captures snapshots of complete records at specific times (e.g. document revisions). Audit trail captures every individual change as an event with user, timestamp and field-level detail. Many ERP systems implement both: version history for documents and BOMs, audit trail for transactional data. GoBD requires the audit-trail style for accounting records; version history is supplementary.
