Refund controls under SOX 404 and ICFR: the smallest defensible setup

Refunds and payouts are outbound cash. SOX 404 and the related ICFR framework require documented, tested controls over the financial reporting that touches outbound cash. In a Stripe-native company, that surface is bigger than most controllers initially scope it.

Here is the smallest defensible setup we have seen pass external audit.

Control 1: a written, versioned policy

Auditors want a policy document and a way to prove which version was in effect when a given decision was made. A Google Doc is fine for the first; you need a system for the second. Axiru's policy engine versions every saved edit and stamps the version onto every decision receipt; any equivalent setup is acceptable.

Control 2: segregation of duties on refund approval

The person who initiates a refund cannot also be the sole approver above a defined threshold. The threshold is yours to choose; the policy needs to document it and the system needs to enforce it. A CS rep refunding their own queue without a second pair of eyes above a meaningful dollar value is the canonical SOX finding.

Control 3: an evidence trail per decision

Every decision needs a signed record: requestor identity, policy version, decision inputs, approver identity (or auto-approve flag), outcome, timestamp. The record needs to be tamper-evident (append-only, hash-chained, or equivalent). Stripe metadata alone is not sufficient evidence; the policy layer needs its own record.

Control 4: exception monitoring

A way to surface refund activity that broke policy or that triggered an approval. Volume by approver, volume by reason code, volume by AI agent identity. Audit asks for this report annually; you should be running it monthly anyway.

What does not count

Stripe dashboard exports alone, Zapier task history (90-day retention), Slack thread screenshots, and 'we trust our team' do not pass external audit. We have seen all four in walkthroughs; none of them are evidence in the auditor's vocabulary.