Ledger Integrity: Auditing ERP System Database Logs in Corporate Fraud

Enterprise ERP platforms are marketed as tamper-evident, and at the application layer they largely are. A posted SAP financial document in BKPF (header) and BSEG (line items) cannot be edited through the standard transaction. A correction requires a reversal document through FB08, which leaves its own trail. Oracle-based ledgers behave similarly through their application forms.

That guarantee lives in the application code, not in the data. The underlying tables sit in a relational database that a user with database credentials can modify with a direct UPDATE, INSERT, or DELETE statement. A SQL edit issued outside the application never triggers the application's business logic, so it typically writes no change document and fires no application validation. This is the core fraud vector this article addresses: an alteration that is invisible to anyone who only reads the application's own audit reports.

The practical consequence for counsel is direct. When opposing experts point to a clean application audit log as proof that records were untouched, that log answers a narrower question than it appears to. It confirms nothing entered through the front door was altered. It says nothing about the back door. Verifying integrity means reconciling what the application recorded against what the database engine recorded underneath it.

SAP maintains several logs that a forensic extraction should target, each with different coverage and different blind spots.

• Change documents (CDHDR and CDPOS). CDHDR holds the change header (object, user, date, time, transaction) and CDPOS holds the field-level before and after values. These are written by application logic. A direct database edit does not generate them, so their absence around a suspicious record is itself a signal, not an all-clear.
• Table change logging (DBTABLOG). Controlled by the profile parameter rec/client and a per-table flag. When enabled, it logs changes to customizing and selected tables at the database interface layer. Confirm early whether logging was switched on for the tables in scope and when, because a defendant can disable it, act, and re-enable it.
• Number range intervals (NRIV). Financial documents draw sequential numbers. A gap in an otherwise contiguous sequence, or a document whose number is out of order relative to its posting timestamp, can indicate a deleted or back-dated record.
• Security Audit Log (SM20 / SM19) and system logs. These capture logon events, transaction starts, and use of sensitive authorizations. They help establish who had the access to perform a direct edit and when.

Preserve these through native, read-only extraction rather than screen exports where possible, and record the extraction method. How the data left the system is part of its provenance.

Oracle records every committed data change in its redo log, and older changes move into archived redo logs if archivelog mode is on. This is the record that matters most, because it captures the direct SQL edits that bypass the application.

• LogMiner reconstructs the actual DML from redo and archived redo, exposing the statement, the database user, the timestamp, and the ordering by System Change Number (SCN). An edit that appears here but has no matching application change document is the signature of an out-of-band alteration.
• ORA_ROWSCN exposes the SCN of the last change to a row. With row-level dependency tracking enabled it is per row, otherwise it is block-level. Mapping it through SCN_TO_TIMESTAMP gives an approximate time of last modification that does not depend on any application-controlled date field.
• Flashback query and flashback transaction can reconstruct prior row states from undo data, within the retention window, and can identify the transaction that changed a row.
• Unified Audit Trail and Fine-Grained Auditing, where configured, log statement execution independently of the application.

Every one of these has a retention limit. Redo logs cycle and archived logs get purged on a schedule. The forensic value of this layer decays with time, which makes early, specific preservation the single highest-leverage action in an ERP fraud matter.

No single log proves manual alteration on its own. The proof is a mismatch between two layers that should agree. The mechanism is a cross-layer reconciliation.

1. Pull the application record of change. For each record in scope, collect the change documents, table-log entries, and the internal audit fields the application maintains, such as created-by, changed-by, and changed-on.
2. Pull the database record of change. For the same rows, extract the redo or archived-redo evidence through LogMiner and the ORA_ROWSCN, or in SAP the DBTABLOG and underlying database logs.
3. Compare event for event. A committed DML in the redo log with no corresponding application change document means the row moved without the application knowing. That is the finding.
4. Check the actor and the path. Application changes run under the ERP's technical or service account. A direct edit usually runs under a named DBA or personal database login. A change attributed in the app's audit field to one user, but executed in redo under a different database user, is a strong indicator of impersonation or back-door editing.

The reason this works is that the two layers are written by different subsystems at different times. Forging one without the other requires editing the redo stream itself, which is far harder to do cleanly and tends to leave its own damage.

Beyond the presence-or-absence reconciliation, several patterns recur in genuine cases of direct table manipulation.

• Timestamp divergence. The application's changed-on field can itself be overwritten by SQL, so a fraudster may set it to a plausible historical value. The SCN-derived time from ORA_ROWSCN is much harder to align to that fake value. A row whose application date says one thing and whose SCN timestamp says another is a red flag.
• SCN ordering conflicts. SCNs are monotonic. A row that claims an earlier business date but carries a later SCN than rows around it was written after the fact.
• Sequence gaps. Missing or non-contiguous document numbers in a range that should be dense.
• Orphaned or unbalanced entries. Ledger line items that no longer tie to their header, or a posting whose debits and credits net incorrectly because only one side was edited.
• Logging that toggles around the event. Table logging or auditing disabled shortly before the suspect window and re-enabled after.

Treat any one of these as a lead, not a conclusion. The defensible finding is the convergence of several, tied back to a specific actor and access path.

The strongest analysis is worthless if the evidence handling is impeachable. ERP forensics adds wrinkles that ordinary file-level custody does not.

• Preserve at the right layer. A standard litigation hold on documents will not stop redo logs from cycling or archived logs from being purged. The preservation demand must name the specific artifacts: archived redo logs, DBTABLOG, change documents, audit trails, number range tables, and relevant point-in-time backups, with the retention settings for each.
• Extract read-only and record the method. Work from forensic copies or database snapshots, never the live production tables. Document whether extraction used native database utilities, a snapshot, or an application export, because the method affects what the data can prove.
• Hash on acquisition. Generate SHA-256 values for extracted datasets at the moment of collection and re-verify before analysis and before production. SHA-256 is preferred over MD5, which has known collision weaknesses.
• Log the handoffs. Maintain a custody record of who accessed each copy, when, and why, from acquisition through expert analysis.
• Account for retention windows. Note the date each log type would have begun overwriting relevant entries, so the record reflects what was recoverable versus what was already gone before the hold attached.

This is procurement and buyer education, not legal advice, and no methodology guarantees a court will admit its output. What a defensible engagement does is align the work with the standards a court applies.

Under Federal Rule of Evidence 702 and the Daubert framework, expert methodology is tested for reliability: whether the technique can be and has been tested, its known error characteristics, and general acceptance in the field. In jurisdictions still applying Frye, general acceptance carries the weight. The cross-layer reconciliation described here maps to those criteria because it rests on documented database internals, redo and SCN mechanics, that are reproducible and independently verifiable rather than on proprietary judgment.

Practically, that means an expert should be able to restate the extraction steps, the tools and versions used, the hashing performed, and the exact log-to-log comparisons, such that a second qualified examiner could repeat them and reach the same result. Reproducibility is the currency. When you retain or vet a forensic accounting or ERP examiner, weigh whether their report would survive that reproduction test, and treat any claim of certainty about a future admissibility ruling as a caution flag rather than a selling point.