Audit Trail
An audit trail is the complete, chronological record of every change in a system: who changed which record from which value to which value and when – documented in a way that cannot be altered after the fact.
An audit trail is the complete, chronological record of every action and data change in an IT system – traceable along the pattern of "who changed what from which value to which value and when". Each entry links a timestamp, a unique user, the affected transaction or record, and the old and new state. The decisive point is that this log data cannot be modified or deleted once written.
In an ERP context, the audit trail thus forms the technical basis for traceability and audit-proof records. In the event of a dispute, a tax audit or an error, it answers the question of how a record reached its current state – without having to rely on verbal statements or assumptions.
At a glance
- Records who changed what, from which value to which value, and when
- Core principle: unalterable after the fact (append-only, no deletion)
- Basis for audit-proof records and GoBD compliance in the ERP
- Covers master data, postings, documents and permissions
- Differs from a plain system log through business-level traceability
How an audit trail works
An audit trail is created when the system automatically generates a log entry for every relevant action – in parallel with the actual data change and without any input from the user. The user can neither switch off this recording nor manipulate it afterwards; that is precisely what distinguishes an audit trail from a voluntary note.
Technically, this is often solved via database triggers, a dedicated change table (change log) or an append-only event log. Immutability is key: entries are only added, never overwritten. Corrections are therefore made not by deleting, but through a new posting or reversal that is also logged.
What information an entry contains
A complete audit-trail entry includes at least: a precise timestamp (ideally with time zone), the unique user identifier, the type of action (create, change, delete, approve), the affected object with its record ID, and the value before and after the change. Context data such as tenant, IP address or the triggering interface is often added as well, so that automated changes made via an API remain attributable too.
Why an audit trail matters
The main benefit is traceability. When a stock level suddenly no longer adds up, a sales price is wrong or an invoice shows an unexpected value, the audit trail makes it possible to reconstruct exactly which change led to this state, when and by whom. That shortens troubleshooting from hours to minutes and replaces finger-pointing with solid facts.
Beyond that, an audit trail meets compliance and security requirements. It provides the evidentiary basis for tax audits, external auditors and internal audit, and it acts as a deterrent: those who know that every change is permanently logged handle sensitive data more carefully. Not least, the trail helps to detect unauthorized access or unusual patterns – such as mass changes outside business hours.
Value for error analysis and trust
Beyond mere compliance, a tangible operational value emerges: support and accounting teams resolve data conflicts faster because they can prove the history of a record rather than reconstruct it. Trust between departments also grows when every automated mass change – say from an overnight import – is transparently attributable and does not linger as an anonymous "system change". The trail thus turns from a control instrument into a tool for everyday collaboration.
Audit trail in the ERP system
An ERP system manages a company's central values – master data, stock, orders, documents and postings. Changes to this data have direct financial and operational consequences, which is why an audit trail is particularly relevant here. Modern ERP systems log not only postings in accounting, but also changes to article master data, price lists, the customer master and assigned permissions.
Because ERP processes increasingly run automatically via interfaces, the audit trail must also capture API-driven changes. An order imported from the shop via a REST API or a stock synchronization triggered by a webhook belong in the log just as much as a manual entry – otherwise blind spots arise. Evaluation is ideally filtered by user, object or time period, so that the trail remains practically usable in day-to-day work.
Distinction: audit trail vs. system log
A technical system or server log documents above all the operating state: logins, errors, performance, warnings. An audit trail, by contrast, is business-oriented and permanent: at the level of business data, it answers who changed which commercial record. Logs are often rotated and overwritten after days or weeks; an audit trail, on the other hand, must remain tamper-proof and preserved throughout the statutory retention period.
Audit trail and audit-proof records in the DACH region
In Germany, the obligation to keep a traceable record of tax-relevant data derives from the GoBD (principles for the proper management and retention of books in electronic form). Among other things, they require traceability, immutability and complete logging of changes – a cleanly implemented audit trail is the central building block for meeting these requirements technically. Closely related is the procedural documentation (Verfahrensdokumentation), which describes how the log is kept and evaluated.
In Austria and Switzerland, comparable principles of proper bookkeeping apply, even if the legal bases have different names. For point-of-sale systems, additional rules apply – in Germany the technical security device (KassenSichV/TSE), in Austria the RKSV. Common to all of them is the core idea of the audit trail: once recorded, transactions may not be altered without trace after the fact.
Limits and good practice
An audit trail is only as valuable as its completeness and analyzability. A log that records everything but cannot be searched is of little help when it matters. Likewise, the trail itself must be protected against deletion and manipulation – an administrator who can remove log entries devalues the entire concept.
Data protection must also be considered: because the trail records, on a personal basis, who performed which action, it is subject to the GDPR. Access to the logs should be governed by a permissions concept and itself be logged again. Good practice is also to set retention periods deliberately and to regularly transfer the trail into a tamper-proof backup. For particularly sensitive data, it can make sense to log not only changes but also plain read accesses – for example, to prove unauthorized viewing of personnel or pricing data.
Example
Real-world example: the wrong sales price
A retail company with a connected online shop discovers that a bestselling article was sold at a far too low price for two days. Instead of guessing, the team lead opens the audit trail and filters on the affected article master.
The trail shows it clearly: the previous day at 17:42 the price was changed from €89.00 to €8.90 – by an employee who had made a typo during a manual import. Old value, new value, time and user are documented without gaps. The company corrects the price, can quantify the damage exactly and adjusts the import process. Without an audit trail, the cause would have remained days of guesswork.
Frequently asked questions
Matching ERP systems
Related services
Questions about Audit Trail in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.