At a 150-person distribution company using Oracle Fusion, year-end fieldwork uncovered manual journals posted over several months to an expense account that should have remained inactive. Oracle Fusion had retained the user credentials, timestamps, and entry history for every posting. The records were available, but no controller had reviewed them during the period. The audit trail therefore served as evidence after the fact rather than as a control that could have prompted earlier investigation.
That distinction should shape how finance teams approach ERP logging in 2026. A retained log satisfies an evidence requirement when an auditor requests it. An actively reviewed log supports the close by directing attention to unusual activity while it can still be investigated. The difference is not whether the ERP captured the event. It is whether the organization has defined which events matter, assigned responsibility for reviewing them, and recorded the outcome.
What an ERP Audit Trail Actually Records
"Audit trail" is not a single data set. ERP environments generally expose several logging layers, each with a different control purpose. Separating those layers helps finance and technology teams identify which records belong in journal entry monitoring, access reviews, configuration controls, and master-data procedures.
Journal entry history: This layer identifies the person or process that posted a journal, the posting time, the workstation or API session, the original values, and later edits or reversals. In SAP S/4HANA, relevant records are available through document change history and ACDOCA. Oracle Fusion provides journal approval workflow history and GL audit tables. NetSuite users can consult the Audit Trail page and transaction history.
User access history: Security logging covers login activity, role assignments, permission changes, and grants of elevated access. It is distinct from journal history and usually resides in the ERP security module or a connected identity management system. A journal review cannot, by itself, establish whether the poster was appropriately authorized at the time.
Configuration change history: This record tracks alterations to ERP settings, such as account structures, chart of accounts changes, posting period controls, and approval workflow rules. These changes warrant careful treatment because one configuration decision can influence the handling of many later transactions.
Master-data change history: Data-level logs show amendments to vendor records, customer records, and bank account details. Those events are especially relevant to segregation of duties and fraud controls, even though they do not appear as journal postings.
Journal activity receives the greatest attention because it is frequent and closely tied to the close. That emphasis should not cause teams to disregard access, configuration, or master-data records. Each layer describes a different route by which financial reporting risk can arise.
The Passive Log Problem
A passive log is complete enough to retrieve but disconnected from timely decision-making. It is consulted after an exception, during an investigation, or in response to an auditor's request. The underlying event was recorded, yet nobody used the information to prevent the issue or investigate it during the reporting period.
In the Oracle Fusion example, the audit trail contained each manual posting, its timestamp, and its user credentials. The entries remained unnoticed because no one had a period-close procedure for reviewing the log. An external auditor later obtained a trial balance by account and found a balance on an account expected to be zero. The system had logged the activity correctly. The control environment had not converted those records into an actionable signal.
This distinction also affects remediation. A retrospective search may explain what happened, but it cannot restore the opportunity to question an entry before the close or before downstream reporting relied on it. An effective process gives reviewers a defined population, prioritization rules, an owner, and a way to document resolution.
Practice 1: Specify Audit Events That Need Prompt Review
Reviewing every audit event with the same urgency is neither practical nor useful. Finance teams should establish risk tiers that connect particular events to a review deadline and an accountable reviewer.
Events requiring prompt attention include manual journals posted to accounts restricted or closed in the current period, entries made outside normal business hours by accounts without scheduled-posting authorization, changes or deletions to previously approved journals, and postings made by accounts that recently received elevated permissions. These conditions do not prove an error or fraud, but they justify timely examination while supporting context remains available.
A weekly review can cover manual entries above the team's defined materiality threshold, reversals of prior-period items that do not reference the original entry, and activity in selected high-risk accounts. Intercompany clearing, prepaid expenses, and contra-revenue accounts are examples of populations that may merit this treatment.
Monthly review or close-period sampling is suitable for lower-risk populations, including routine subledger transfers, recurring journals that match their templates exactly, and entries produced through established approval workflows without unusual characteristics. The tiering decision should be documented rather than left to the reviewer's personal judgment each month.
Practice 2: Distinguish Automated Postings from Manual Journals
System-generated and manual journals should not be treated as one homogeneous risk population. Subledger transfers, automated recurring templates, and ERP-native processes follow defined logic and normally produce structurally consistent output. If an automated process is misconfigured, it may generate a systematic error, but repeated structure can make that pattern easier to identify.
Manual journals involve human decisions about the account, amount, period, and supporting explanation. Their variability reflects both the circumstances of the entry and the judgment of the preparer. A review that mixes manual and automated postings forces the team to spend attention on routine system activity while making unusual human-entered items harder to isolate.
The review population should therefore give precedence to manual entries. Within that population, additional priority belongs to journals prepared by users with elevated access and to entries that fall outside the normal posting pattern for the account. Rule-based monitoring can apply these filters when a journal is posted, rather than requiring a controller to sort through the full log during close. Centinel's product reads audit trail data through read-only APIs from SAP, Oracle Fusion, and NetSuite for this type of rule-based journal entry monitoring.
Practice 3: Configure the ERP to Produce Usable Audit Data
Audit trail usefulness depends partly on system design. The following configuration choices improve the information available to reviewers and strengthen the evidence supporting the control.
Make journal descriptions mandatory: Requiring a description on manual journals is a basic control that is often left optional. A meaningful explanation gives a reviewer immediate context. Without one, the reviewer must infer purpose from the account, amount, and posting date. Description fields can be required in SAP and Oracle, while NetSuite memo fields can be made mandatory for each journal entry type.
Use hard closes for posting periods: A prior period that is only soft-closed may still accept entries after review has finished. That creates a difference between the ledger population examined during the close and the final trial balance. A hard close after sign-off helps ensure that the reviewed period and the final ledger remain aligned.
Require approval above a threshold: Manual journals above a defined materiality threshold should pass through an approval workflow. The resulting history records both the poster and the approver. That two-step evidence is stronger than a single-user posting record when the entry has a higher financial reporting impact.
Alert on account-specific exceptions: ERP platforms commonly support exception alerts for selected accounts. Rules covering intercompany clearing, suspense, deferred revenue, and other designated high-risk accounts can route activity to an appropriate reviewer soon after posting instead of waiting for a later discovery.
Practice 4: Put Audit Trail Review on the Close Checklist
An undocumented expectation will not produce consistent review. Audit trail work should appear as a named close task with an owner, a population, a deadline, and a completion standard. It should be managed alongside reconciliation sign-offs and other close controls, not treated as an optional investigation.
The completion language needs to be precise. "Review the audit trail" does not define a test or establish when the work is finished. A stronger instruction is: review all manual entries over $25,000 posted to accounts 6000 to 6999 during the period, confirm that each has a description and supporting documentation, and mark flagged items as resolved. The wording identifies what must be examined and what evidence the reviewer must retain.
A documented review also creates an operating-effectiveness record. It shows who performed the work, when it was completed, which items were identified, and how exceptions were resolved. The close management platform can track this task in the same manner as other sign-offs. That record is more useful than reconstructing an informal review from emails or producing raw ERP extracts with no stated conclusion.
What External Auditors Look For in the Audit Trail
External auditors testing journal entry controls generally focus on three areas. They seek evidence that manual entries were reviewed and approved, assurance that the audit trail is complete rather than missing suspicious sequence numbers or timestamps, and samples of higher-risk entries whose supporting documentation agrees with the posted amounts.
A team that reviews audit activity throughout the year enters this testing with contemporaneous evidence. Higher-risk journals have already been examined, exceptions have an owner and resolution, and explanations were written when the issue arose. A team that waits until audit fieldwork must identify the population, investigate anomalies, and recreate the rationale months after the postings were made.
Active audit trail management is not a substitute for an external audit. It does not remove the auditor's responsibility to test controls, select samples, or form an independent conclusion. Its value is different: it changes the audit interaction from a first-time discovery exercise into a verification exercise. Auditors can assess whether the documented process operated as intended instead of beginning with the question of what happened and why.
ERP logging has an unusual control characteristic: the posting event is generally captured by default, so the underlying record may be complete even when the review process is weak. Completeness alone does not make that record useful to finance. Its control value depends on the organization's ability to define meaningful exceptions, direct them to a responsible reviewer, and preserve the resulting analysis within the close process.