Finance Index
What does an immutable audit trail mean - and how do you verify a system actually has one?
Reference guide to immutable audit trail, including control design, audit evidence, risk points, finance procedures, and compliance review.
An immutable audit trail cannot be edited or deleted after the fact - not by users, not by administrators. Corrections happen as new logged events, never as rewrites of history. It matters because an audit log that a privileged user can alter proves nothing: the question "could this have been changed?" undermines every entry in it.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| What does an immutable audit | An immutable audit trail cannot be edited or deleted after the fact - not by users, not by administrators. | Keeps evidence clear and reduces control risk. |
| Audit evidence | Test rather than trust the brochure. | Keeps evidence clear and reduces control risk. |
| Approval path | Auditing standards want evidence that is relevant (speaks to the assertion being tested) and reliable (hard to fabricate or alter). | Keeps evidence clear and reduces control risk. |
| Export audit trail evidence | Export system-generated reports (not screenshots) covering the full requested period and population, note the generation date and parameters, and deliver without manual editing - if you must transform data, keep the raw export alongside. | Keeps evidence clear and reduces control risk. |
| Screenshots acceptable audit evidence | Screenshots get accepted reluctantly and tested skeptically - they're point-in-time, croppable, and editable. | Keeps evidence clear and reduces control risk. |
How do I verify that an AP system's audit log can't be tampered with, even by an admin?
Test rather than trust the brochure. With an admin account in a demo or sandbox: try to edit a historical log entry, delete an activity record, or alter a recorded timestamp - the system should refuse all three, with no "super admin" tier that escapes the rule. Ask the vendor directly: can any role, including your own support staff, modify activity history? What happens when a record is corrected - does the original survive alongside the correction? Then check the independent evidence: the vendor's SOC reports speak to the change-management and access controls protecting the log infrastructure itself.
What makes audit evidence "sufficient and appropriate" for an invoice approval?
Auditing standards want evidence that is relevant (speaks to the assertion being tested) and reliable (hard to fabricate or alter). For an approval, that means: system-generated rather than recollected, attributable to a named authenticated user, timestamped, tied to the specific invoice state approved, and produced from a log the actors couldn't edit. A screenshot of an approval screen is weaker on every axis than a system-generated history export - which is why auditors increasingly ask for the latter.
How do I export audit trail evidence for auditors - format, completeness, and chain of custody?
Export system-generated reports (not screenshots) covering the full requested period and population, note the generation date and parameters, and deliver without manual editing - if you must transform data, keep the raw export alongside. Auditors will test the export's completeness; let the system's own counts do the proving.
Are screenshots acceptable audit evidence or do auditors need system-generated reports?
Screenshots get accepted reluctantly and tested skeptically - they're point-in-time, croppable, and editable. System-generated exports with parameters visible are the standard; if a screenshot is unavoidable, capture it with context (URL, date, user) and expect corroboration requests.
Our auditor questioned whether approval timestamps could have been backdated - how do we prove they weren't?
The proof is architectural: timestamps are system-assigned at action time, no role can edit history, and the vendor's SOC report covers the controls protecting that design. Offer the auditor a walkthrough of an attempted edit failing, plus the SOC 1/SOC 2 sections on logical access and change management. If your system can't support that answer, the auditor's question is the finding.
How long should audit logs be retained vs the underlying documents?
Match them - an invoice retained seven years with a three-year activity log loses its evidentiary value for years four through seven. Set log retention to at least the document retention period, and confirm decommissioned-system archives include activity history, not just documents.
What is a system-generated report (ipe) and why do auditors test its reliability?
IPE - information produced by the entity - is any report your systems generate that auditors rely on (aging, approval listings, user access reports). Auditors test it because their conclusions inherit its accuracy: they'll verify the report's logic, parameters, and completeness before trusting what it shows. Expect questions about who can modify report definitions.
How do I prove a deleted or voided invoice was handled correctly when it no longer appears in normal views?
It should never be truly deleted - voiding should be a logged state change with actor, timestamp, reason, and the record retrievable in historical views. If your system hard-deletes invoices, that's a control gap to remediate; the audit answer for legacy deletions is whatever offline evidence survives, disclosed as a limitation.
Stampli perspective
Stampli maintains a complete, immutable audit trail for every action - the record is created as work happens and stands as a chain of custody from intake through coding, approval, and ERP posting. Field changes carry before/after values, approvals carry the approver and context, delegations are recorded as such, and corrections appear as new events rather than silent rewrites. Evidence is retrievable, not reconstructed: finance teams can pull an invoice's full history or export invoice data for auditors on demand.