SOX Compliance Checklist: The Control Activities That Actually Fail Audits

A SOX checklist that lists every control your team already knows it needs is not the one that holds up at audit. The failures happen at execution, where approvals get rubber-stamped, reconciliations live in spreadsheets, and the audit trail is reconstructed during fieldwork from email threads and memory. A defensible checklist is organized around how each control activity produces verifiable evidence in the systems where the work actually runs.

The framework below covers the same control families every Big Four SOX template lists. The difference is in what each line is asked to prove, and where the proof lives when the auditor asks for it.

What SOX actually requires of finance operations

Two sections of the statute do most of the work for finance.

Section 302 requires the CEO and CFO to personally certify, in each periodic report, that the disclosure controls and procedures are designed and operating effectively, that the financial statements fairly present the financial condition of the company, and that material weaknesses have been disclosed to the auditor and the audit committee.

Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting (ICFR), and requires the external auditor to attest to that assessment for non-smaller-reporting-company filers. The PCAOB standard that governs how auditors test ICFR is AS 2201.

Most public companies structure their control environment around the COSO Internal Control Integrated Framework. The SEC accepts other suitable frameworks, but COSO is the default and the framework auditors are most fluent in. Adopting COSO is not a legal requirement; it is the path of least friction.

SOX applies to all SEC-registered public companies, with specific accommodations for smaller reporting companies and emerging growth companies. Treating it as a problem only for large filers is a common first-year misread. Private companies preparing for IPO, sitting under a public-company parent, or operating under acquisition or financing covenants often adopt SOX-style controls voluntarily because the buyers and lenders expect them.

The checklist that follows is organized by control family. Each family lists the activities, then the evidence the activities must produce. The evidence question is where most teams lose the audit.

Entity-level controls

These are the controls that set the tone for everything else. Auditors look at them first because weakness here changes how they test the rest.

• A documented control environment: code of conduct, ethics policy, whistleblower process, board and audit committee oversight, charter documents.
• An annual risk assessment refreshed against the current business, with named owners for each identified risk.
• Change management for financial systems, chart-of-accounts changes, and process changes that affect reporting.
• Evidence of management review for key financial reports, with reviewer identity and date captured.
• Documented escalation paths for control deficiencies, with remediation timelines tracked.

Entity-level controls fail at audit when the policy document exists but the evidence of it operating does not. A code of conduct nobody signed, a whistleblower hotline nobody can name, a risk assessment dated three years ago. The fix is treating each control as a recurring activity with an artifact, not as a one-time policy.

Access controls and segregation of duties

This is the family that catches the most teams off guard, because the controls live across IT, finance, and HR and the evidence sits in multiple systems.

• User access reviews on a stated cadence (quarterly is the common bar) for every in-scope financial system, with the reviewer’s identity and the date captured against each access list.
• Separation of initiation, approval, and posting in the AP, revenue, and journal entry workflows. No single user can both create and approve a transaction in any in-scope cycle.
• Privileged access logging in the ERP and adjacent systems, with periodic review of admin activity.
• A documented joiner-mover-leaver process for finance system access, with evidence that access is revoked or modified within a stated window of the HR change.
• Documented exceptions where segregation cannot be achieved (small teams, after-hours coverage), with a compensating control and management review.

The honest read here, which most SOX guides will not say plainly, is that segregation of duties is the control most likely to be cited as a deficiency in companies under 200 people, because the team is too lean to fully separate the duties. The defensible posture is not pretending otherwise. It is documenting the exception explicitly, describing the compensating control, and capturing the management review that closes the loop.

Approval controls with verifiable evidence

This is the family where the audit-trail question gets concrete.

• Approval workflows that capture named approver and timestamp on every approval, not just the final one in a chain.
• Approval thresholds tied to a documented delegation of authority matrix, refreshed on a stated cadence.
• Exception routing that requires explicit review when transactions fall outside the standard rule, instead of rubber-stamp approval through volume.
• For automated approvals (system-driven posting under a threshold), documentation of the rule that fired and the inputs it evaluated.
• Evidence retention for the entire approval cycle, not just the approved record.

A real example. Bill approvals captured in email threads are reconstructable but expensive at audit. Bill approvals captured against the bill record inside the accounting system, with approver identity and timestamp stamped at the moment of approval, are not reconstructable because they were never lost. The first pattern survives audit by spending a controller’s October on it. The second pattern survives audit because the evidence is already there.

A pattern that produces this kind of evidence at the moment of work, rather than reconstructing it later, is a workflow that posts an approval request into the channel approvers already use, captures the response against the bill record, and writes the approver identity and timestamp back to the system of record. See the FlowRunner workflow guide on capturing every bill approval with named approver and timestamp into QuickBooks and Slack for the structural pattern.

The same pattern shows up across ERPs. On Acumatica, the controls live in the AP approval cycle and the evidence in the bill record audit log; see automated AP controls with reviewer identity captured. The structural question, not the platform, is what the auditor cares about. If you are still defining the upstream piece, the underlying PO approval workflow shapes most of what the approval evidence will look like at audit.

Reconciliation and close-cycle controls

The close cycle is where reconciliation evidence either exists or has to be reassembled.

• Balance sheet reconciliations performed for every account on a stated cadence, with preparer and reviewer captured per account and per period.
• Bank, merchant processor, and intercompany reconciliations with decision history retained for every reconciling item.
• Journal entry approval before posting, with supporting documentation attached to the entry, not stored separately.
• A close checklist with sign-offs at each milestone, dated, and tied to the named individual.
• Quarterly and annual review of the reconciliation process itself, looking for accounts that consistently roll forward with unexplained items.

The failure mode here is the reconciliation spreadsheet that has the right numbers but no preparer name, no review evidence, no decision log on the items that did not reconcile cleanly. An automated reconciliation pattern that records the preparer, the reviewer, and the per-item decision as the close runs produces evidence in the form auditors expect. The FlowRunner workflow on reconciling Stripe payments against QuickBooks invoices with decision history retained per step is a concrete example.

Preventive and detective controls in procure-to-pay

The procure-to-pay cycle carries some of the highest fraud and error risk, which is why auditors look hard at the preventive controls.

• Vendor master validation and duplicate detection before bill creation, with the validation evidence retained against the bill.
• Three-way match (PO, receiver, invoice) where applicable, with mismatches routed for explicit review rather than waived.
• Outlier detection on payment amounts, unusual vendor patterns, and round-dollar invoices, with exception decisions logged.
• Bank account change verification for vendors, with the verification path documented for each change.
• Documented segregation between vendor master maintenance, invoice entry, and payment release.

Preventive controls that fire at the moment of the transaction and route exceptions for review produce a cleaner audit footprint than detective controls that catch the same issue weeks later in a journal entry reversal. The FlowRunner pattern on vendor validation and duplicate checks before bill creation is the structural example for this control family.

IT general controls that support the financial controls

ITGCs are tested because the financial application controls are only reliable if the systems they run in are reliable.

• Logical access management for in-scope systems, with provisioning, modification, and termination tied to documented approval.
• Change management for the financial systems and adjacent integrations, with separation between developers and the production push.
• Computer operations: backup procedures with periodic restore testing, batch job monitoring, incident response.
• Audit logging retention aligned to the audit period, with retention controls preventing premature deletion.
• SOC 1 or SOC 2 reports collected for material third-party systems that touch financial reporting, reviewed annually.

ITGCs are where the audit asks how you know your system is doing what you say. Vendor SOC reports answer most of that question for hosted systems. For systems you operate, the answer is your own change management and access management evidence.

Building the audit trail before the auditor asks

Here is what most SOX guides will not say out loud. The cost of audit is mostly the cost of reconstruction. The substantive testing fee, the controller’s late nights in the period before fieldwork, the back-and-forth with the audit team on evidence requests: those add up because the evidence was not where it needed to be when the auditor asked for it.

Auditors ask the same questions every year. Approver identity, timestamp, supporting documents, exception rationale, the system the activity happened in, the access list at the time it happened. If those answers are captured at the moment of the transaction, in the system of record, the evidence request is a query. If they are not, the evidence request is a project.

The pattern that closes this gap is unglamorous. Capture approver identity, timestamp, and exception rationale at the moment of the transaction. Store the evidence against the record it relates to, in the system that owns the record. Route exceptions for explicit review rather than waiving them at volume. Retain the decision history alongside the data.

This is where the discrete control activities stop being enough. SOX is not a problem any one system solves, because financial reporting touches the ERP, the AP system, the close tool, the bank, the merchant processor, the HR system, the access provisioning system, and the channels finance actually works in (email, Slack, the accounting platform). The control activities live inside those systems. The work between them, where approvals route, where reconciling items get explained, where exceptions get escalated, is where evidence quietly fails to get captured. No single system of record sees the seam between systems. An orchestration layer is the category that does: a layer above the systems of record that listens for what they emit, routes the human-judgment moments to the people who need to see them, and writes the resulting evidence back into the system that owns the record. FlowRunner is built for that layer.

That positioning is not a SOX certification. SOX compliance is the issuing company’s responsibility, not a vendor’s, and no automation tool satisfies Section 404 by itself. The role a workflow layer plays is producing the evidence the company’s control activities are designed to produce, in the form auditors expect to receive it.

Putting the checklist into practice

For first-year SOX teams and teams refreshing a stale program, the priority order that holds up empirically is:

1. Map each control activity to the system that owns the evidence. Not the policy document, the system. If the evidence does not live somewhere queryable, that is the gap to close first.
2. Start with the families that draw the most audit findings: approvals, access, and reconciliations. These are where material weakness findings concentrate.
3. Design for exceptions, not the happy path. The control activity that holds up is the one that handles the unusual case explicitly, not the one that assumes everything fits the rule.
4. Bring the external auditor in early on control design. A 30-minute conversation in February is cheaper than a finding in October.
5. Prioritize design over breadth. A small number of controls designed to produce verifiable evidence is more defensible than a long list of controls operating on faith.

A clean SOX checklist is a list of activities, each producing an artifact, each artifact living in a system where the auditor can find it without asking the controller to dig. That is the version of the checklist worth the time to build.

Quick answers

What does a SOX compliance checklist need to cover?

At a minimum: entity-level controls, access and segregation of duties, approval evidence with named approver and timestamp, reconciliation trails, preventive and detective controls in procure-to-pay, and IT general controls supporting the financial systems. The activities are not the hard part; the evidence each activity produces is.

Does SOX apply to private companies?

SOX directly applies to SEC-registered public companies, including smaller reporting and emerging growth companies with specific accommodations. Private companies preparing for IPO, acquisition by a public company, or operating under financing or contractual covenants often adopt SOX-style controls voluntarily.

What is the difference between SOX 302 and SOX 404?

Section 302 requires officers to certify the disclosure controls and the accuracy of financial reports each period. Section 404 requires management to assess and attest to the effectiveness of internal controls over financial reporting, and the external auditor to test those controls per PCAOB AS 2201.