Controller's playbook: SOX-ready outflow controls in five working days

You are the controller or accounting lead. SOX 404 (or a pre-IPO controls program standing it up) just put outbound payments in scope, and you have realized that refunds, credits, and payouts on Stripe are happening with no written policy, no documented segregation of duties, and no audit-grade evidence. This playbook is a five-working-day path from that starting point to a defensible control set.

It is paced for a controller who is also doing four other things; each day is two to three hours of focused work plus async waiting on other people.

Day 1: scope and document the surface

Pull a one-page list of every Stripe outflow surface that touches your books. Standard answer: refunds, goodwill credits and adjustments, payouts, Stripe Connect transfers (if you are a platform), application-fee refunds, and dispute evidence submissions. Add AI agents as a row if any are wired to refund or credit.

For each row, write the current state in plain language: who initiates, who approves (if anyone), what dollar thresholds exist informally, and where the record currently lives. Most rows will read like 'CS rep initiates, no formal approval, record lives in Stripe dashboard and the rep's Slack message.' That is fine. The point is to write the actual state, not the aspirational one.

This document is the SOX walkthrough narrative. Auditors will ask for it on day one of fieldwork; having it ready before they ask saves a week.

Day 2: stand up a written policy

Convert the implicit policy from day one's narrative into a written one. Two pages. Per-surface thresholds (refunds over $X require manager approval; refunds over $Y require finance approval), reason-code rules (no goodwill credit over $Z without approval), volume caps (no more than N refunds per agent per day), and the segregation-of-duties statement (the person initiating a refund cannot be the sole approver above the second threshold).

Get the head of CS and the head of finance to sign off in writing. Two-line email is fine; what matters is a timestamped record that two leaders agreed to the policy.

Save the policy with a version number (v1.0 is fine for now). Every future edit becomes a new version. This is the single thing auditors care about most in the first walkthrough.

Day 3: pick the enforcement mechanism

The policy on paper is not the control. The control is whatever stops a refund from going out when it violates policy. Three options exist in the wild: process-only (manager reviews every refund manually before it ships), homegrown automation (Zapier or Retool flow that posts approval requests to Slack), or a purpose-built policy engine.

Process-only fails external audit at scale unless you can produce signed approval records per decision; manual review without a system to capture sign-off is not evidence. Homegrown automation passes if the task-history retention is sufficient (Zapier's 90 days is not) and if the approval records are stored as durable evidence. A purpose-built engine ships those records by default.

Pick the option that matches your refund volume. Under ~50 governed refunds per month and a tight team: process-only with disciplined Slack records can work for one audit cycle. Above that, automation is the lighter lift than manual review at scale.

Day 4: stage evidence for the auditor

Pre-build the audit evidence packet. The four things the external auditor will ask for: (1) the policy document with version history; (2) a list of all refunds above the policy threshold for the test period, with the approver name for each; (3) the segregation-of-duties statement and proof that the initiator/approver split was enforced; (4) an exception report (refunds that broke policy and how each was resolved).

If you are using a tool like Axiru, exports of items 2 and 4 are one button. If you are running process-only or homegrown, this is the day to assemble them into a shared folder. The auditor wants CSV or PDF, not screenshots.

Add the AI agent surface to every export if applicable. The auditor question on AI agents has become standard in the last 12 months and you do not want to be improvising it on the call.

Day 5: walkthrough rehearsal with finance and CS

Schedule a 30-minute working session with the head of CS and the head of finance. Walk through one refund end to end as if you were the auditor: request comes in, identity of the requestor, policy reference, threshold check, approver identity, decision record, Stripe execution. Make sure both leaders can explain their side in plain language.

If anyone stumbles, it is a sign the policy was written more aspirationally than reality. Fix the gap (or update v1.1 of the policy to match reality) before the auditor walkthrough.

End of day 5: you have a written, signed, versioned policy, an enforcement mechanism, pre-staged evidence, and a rehearsed narrative. That is the smallest defensible setup and it is enough for first-cycle SOX testing.

What to expect from external audit

First-cycle SOX testing on this surface usually pulls a sample of 25 to 40 refunds and tests each against the policy. The pass rate target is high (one finding per sample is usually walkable; multiple is not). The most common findings: missing approver record on borderline cases, threshold ambiguity ('over $500' vs '$500 and over'), and AI agent activity not covered in the policy.

All three are cheap to fix in v1.1 of the policy. Plan for one revision cycle after the first audit; treat it as expected, not failure.

What to do after the first cycle

Once the first SOX cycle is clean, the controllership work shifts from rollout to monitoring. Monthly exception report, quarterly policy review (is the threshold still right?), and an annual policy refresh tied to the audit window.

If you outgrow process-only or homegrown automation between cycles, the migration is straightforward: Axiru runs in shadow mode for 30 to 60 days alongside whatever you have today, you compare decision-by-decision, then cut over. No big-bang risk.