← back to all posts
Financial Controls· SOX · PCAOB· 5 min read

The SOX walk-through: evidence from a hash-chained history

AS-1105 evidence integrity is a sentence in the standard. With a hash-chained history log, it is one check you can run.

Every quarter, every US public company has the same week. The external auditor — PCAOB-registered, paid by you, beholden to standards that say they have to find something — sits down with the controller and starts asking. Walk us through this revenue-recognition entry. Show us the approval chain. Prove the supporting evidence hasn't been modified since Q3 close.

In most stacks, this is a three-week project. Your ICFR documentation is spread across SharePoint, NetSuite, Workiva, and DocuSign. The auditor asks for fourteen things. Your team finds twelve. The other two take a week to track down. Your big-four firm bills you SOX-advisory uplift while they wait. Material weakness risk if anything is missing. Restatement risk if a control demonstrably failed.

The financial cost is real — $150,000 to $300,000 per walk-through cycle. The strategic cost is bigger. A material-weakness disclosure affects your stock price. A restatement triggers shareholder litigation. The CEO's and CFO's 302/906 certifications get more nervous every quarter, because nobody on the inside fully trusts that nothing has been silently edited.

What the auditor is actually testing

AS-1105, the PCAOB standard on audit evidence, has one core requirement: the evidence must be reliable. In SOX terms that's three things.

  1. The journal entry as it stood at close. Not the entry as it stands today. Not the entry from a backup somebody made. The entry, with every supporting field, as the system held it at Q3 close.
  2. The approval chain. Every signature, every authority delegation, every dual-approval check.
  3. Non-modification. The evidence must be provably unmodified between close and today.

If your stack is a bitemporal graph with a chained audit log, all three become one query.

The reconstruction

MATCH (je:JournalEntry) AT RECORDED '2026-09-30T23:59:00Z'
  WHERE je.id = '2026-Q3-44218'
OPTIONAL MATCH (je)-[:APPROVED_BY]->(a:Approver) AT RECORDED '2026-09-30T23:59:00Z'
OPTIONAL MATCH (je)-[:SUPPORTED_BY]->(d:Document) AT RECORDED '2026-09-30T23:59:00Z'
OPTIONAL MATCH (je)-[:TESTED_BY]->(c:ControlTest) AT RECORDED '2026-09-30T23:59:00Z'
OPTIONAL MATCH (je)-[:MATERIALITY_BY]->(m:Threshold) AT RECORDED '2026-09-30T23:59:00Z'
RETURN je, collect(a), collect(d), c, m

Each MATCH clause reads the financials graph as it was recorded at 23:59 on September 30: the entry, each approver with their delegation authority at that moment, the supporting documents including the ASC 606 memo, the control test that ran on the entry, and the materiality threshold check.

The non-modification check

The auditor wants to know that the entry, the approval chain, and the control evidence have not been edited between close and today. Each committed node and relationship write is appended to the graph's history log with the SHA-256 hash of the previous record, so two checks answer the question:

GET /graphs/{name}/audit/verify
→ {"status": "clean", "records": 48213, "last_seq": 48213}   (illustrative values)
MATCH (je:JournalEntry {id: '2026-Q3-44218'})
CALL db.history(id(je)) YIELD version, timestamp, validFrom
RETURN version, timestamp, validFrom ORDER BY version

The first re-hashes the whole history log and returns clean or the first broken record; it has no date window. The history log is not signed or anchored outside the server, so the check does not detect a rewrite of the whole log, or removal of the most recent records, by someone with write access to the server. The second lists each version of the entry with the time it was recorded, so a legitimate change after close shows up as a new version.

The lineage walk

The auditor's third question is "what other entries depend on the same control?" If each journal entry is linked to the control it relied on with a DERIVED_FROM edge, a pattern match finds them:

MATCH (je:JournalEntry)-[:DERIVED_FROM*1..3]->(c:Control {id: 'C-312'})
RETURN je.id

In the illustrative walkthrough, twenty-three other entries share control C-312.

The 302/906 certification

Every quarter, the CEO and CFO sign certifications attesting to the design and operating effectiveness of the company's internal controls. The history check and the as-recorded queries give the certifying officers the entries and control tests as recorded, and the result of the history check. Whether the controls were designed and operated effectively remains the officers' and auditors' judgement.

The numbers

The figures in this post and in the walkthrough are illustrative.

Illustrative walkthrough on the SOX tab.

See the walkthrough

Step through the illustrative walkthrough.

The full illustrative flow, ending with the chain verification. It is pre-rendered, runs in any browser, and does not connect to an engine.

Open the Financial Controls walkthrough →