What SOX 404 and 802 Actually Require (Beyond the Checklist)

SOX compliance content usually arrives in one of two flavors: a legal summary too abstract to implement against, or a vendor checklist too self-serving to trust. Here’s the middle version — what the two sections that matter most for a general ledger actually require, and what a system has to do, not just claim, to satisfy them.

SOX 404: Internal Controls, Specifically Segregation of Duties

Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting. In ledger terms, the control that gets tested most often is segregation of duties: the person who can post a transaction shouldn’t be the same person who can approve or reverse it, unsupervised.

The common implementation is a permissions matrix in the UI — clerk, approver, admin — enforced by hiding buttons the current role shouldn’t use. That’s a real control, but it’s a UI control: it stops accidental misuse, not a determined one, and it’s only as strong as every screen that happens to check the role correctly.

The alternative: enforce the check in the command handler itself, server-side, on every command regardless of which client sent it. A ReverseJournalEntry command checks the caller’s role before it does anything else — not because the UI hid the button, but because the handler refuses the command outright for a role that isn’t authorized to issue it. There’s no client to audit for “did they remember to check.”

SOX 802: Audit Trail and Document Retention

Section 802 criminalizes altering, destroying, or falsifying records relevant to a federal investigation, and by extension pushes companies toward retention policies that make “we don’t have that record anymore” an unlikely defense.

Most systems answer this with backups and an audit-log table — a separate table that records “user X changed field Y at time Z.” The problem: an audit-log table is still just a table. It can be edited, truncated, or fall out of sync with the data it’s supposed to be describing, and usually nothing structurally prevents that.

The alternative: make the primary data store append-only. If a journal entry is wrong, you don’t edit the row — you can’t, there’s no update path — you post a new reversing entry. The “audit trail” isn’t a separate log describing what happened to the real data; it is the real data, in its original, unmodified form, permanently.

Why the Distinction Matters

A checklist can tell you a system “has RBAC” and “has an audit trail.” Both statements are true of almost every ledger on the market. The question worth asking in due diligence isn’t whether those features exist — it’s whether they’re enforced by the data model or by the UI, and whether “the audit trail” is the actual data or a description of it. That’s the difference between a control you have to trust and a control you can verify.