Affiliate Payout Audit

Affiliate Payout Audit

Audit one affiliate/partner commission payout run before release: recompute the math, verify the rules, and report findings with recommended holds and corrections. Assume the activity already passed fraud screening - this skill checks whether the payout is _correct_, not whether it is _legitimate_.

No named, affiliate-native reconciliation framework exists; platforms ship locking and dispute mechanics, not a methodology. The method here borrows openly from adjacent finance disciplines:

• Account reconciliation (preparer/reviewer).
• Three-way match - platform export vs billing/order system vs CRM, the affiliate analogue of PO/receipt/invoice.
• Revenue assurance.
• Segregation of duties / four-eyes (maker-checker).
• SOX ICFR / COSO - where the program sits inside a public company.

Say this plainly to the user; never present a branded framework.

Interview

Ask before auditing anything. One question per message; offer multiple-choice answers when possible. Skip anything the user already answered.

• B2B SaaS recurring revenue-share, B2C ecommerce order-level CPA, or both?
• Commission structure in force: rate model, tier method (marginal or retroactive), per-partner-type overrides, promo/bonus windows, new-customer gating, sub-affiliate overrides, grandfathered legacy rates?
• Payout cadence, and this run's exact period boundaries - dates and timezone?
• Which data exports exist, and what is the internal source of truth: billing system, order database, or CRM closed-won?
• Validation/locking window length? What event releases a commission from pending to approved?
• Is any line in this run already paid, or is everything still reversible?
• Minimum payout threshold, currencies involved, FX handling policy?
• Tax-form status per payee - collected, missing, expired?
• Known historical error types and past partner disputes?
• Who calculates the run, and who releases the funds? Same person or different?
• Materiality threshold? Is the program subject to external financial-controls requirements (public-company ICFR)?
• By what date must the audit result land, and is the release date itself movable?
• One-off or compounding: fix this run only, or leave standing controls behind - a reusable recompute script, a reserve policy, a longer validation window?
• Effort ceiling: review hours available, whether you can execute code over the exports, whether finance can co-sign, and how much partner-relationship capital this run can spend?

Missing period boundaries, source of truth, or commission structure block the audit - insist before recomputing anything.

The last three answers re-rank every menu below:

• A hard release date promotes the cheap gates and drops full-population recompute.
• A compounding mandate promotes both full-population recompute and the fix-it-forward rung.
• No code access deletes full-population recompute outright.
• No finance co-signer deletes direct recovery from this run.

The Audit Sequence

Run the checks in order; each gate assumes the previous one passed. The underlying lifecycle is the same five-gate machine everywhere: pull/export → reconcile to source of truth → verify rate/tier per line → dedupe → lock → pay.

When the release date won't fit all twelve. The numbering is a dependency order, not a priority order. To spend a short budget well, rank the gates by errors caught per hour:

• efficiency: dedup (6) > reconcile and comparability (3-4) > lifecycle window (8) > rate/tier recompute (7) > currency, tax, thresholds (9)
• value: reconcile and comparability (3-4) > dedup (6) > rate/tier recompute (7) > lifecycle window (8) > currency, tax, thresholds (9)
• effort: rate/tier recompute (7) - an hour with code, a week by hand > reconcile (3-4) - an hour on clean exports, a week on messy ones > lifecycle window (8) == currency, tax, thresholds (9) - an hour each, date arithmetic and a checklist > dedup (6) - near-zero with code over the key set
• compliance cost: currency, tax, thresholds (9) - a payee paid without a valid tax form is a filing problem, not just a money one > maker-checker (12) - the sign-off is the evidence an external control test asks for > every other gate == none, because being wrong there costs money, not a filing

Maker-checker (12) is never the gate you drop: it costs one scheduling and a second reader, and its absence is what let every error in the negative example ship.

Rate/tier recompute is what this order starves - highest value of the arithmetic gates, most expensive by hand. Promote it to first when:

• a partner has disputed a tier
• the run straddles a retroactive breakpoint
• the structure changed mid-period

The order is a default, not a law, and it shifts with who executes it: a network exporting full machine-readable logs collapses (6) and (7) to near-zero and moves both up; no billing-system access puts (3-4) out of reach and makes (7) the whole audit.

1. Freeze the run scope. Record run ID, period start/end, timezone, date basis (transaction vs validation vs amendment date), currencies, materiality threshold, and every data source. Ambiguous scope → stop and resolve; every later check depends on it.
2. Pull the exports on the declared date basis. Platform/network conversion export plus the internal source-of-truth extract for the same period. If you can analyze an uploaded spreadsheet or CSV, load both; otherwise ask the user for line counts, totals, and specific lines to read out.
3. Comparability gate. Before comparing or summing any two numeric sources, confirm they share the same event definition, date basis, time window, timezone, currency, counting method, and dedup identity. Any mismatch → normalize first, or report the numbers side by side with their definitions and refuse to compute a total. Detail in references/reconciliation-and-dedup.md.
4. Reconcile totals to the source of truth. Compare line count and money value: platform export vs billing/orders/CRM. Pass = totals match within materiality. Fail = a gap that must be explained line by line before anything is approved - never "close enough".
5. Work the exception queue. Records in one system but not the other, matched on stable IDs only.

• In platform, not in billing: possible over-credit, hold and investigate.
• In billing, not in platform: untracked sale, expect an inbound partner dispute and decide credit policy explicitly.

1. Dedupe. One deterministic key per conversion (order ID / transaction ID / subscription ID). Quarantine empty or malformed keys. Collapse dual tracking (platform pixel + in-house tracker) to one canonical source. Check no key appears in the prior run - period straddle pays twice.
2. Verify rate and tier per line. Recompute expected commission from raw inputs using the terms in force at the original transaction date: tier method and boundary operator, partner-type overrides, promo windows against start/end datetimes, new-customer gating, sub-affiliate overrides, grandfathered rates. If you can execute code, recompute every line; otherwise recompute the sampled lines by hand. Math in references/rate-and-tier-verification.md.
3. Verify lifecycle state per line. Every line must have cleared its validation/locking window or been explicitly released; reversals for in-window refunds/churn must already be applied; refunds that landed after lock must appear as forward-period negative adjustments, not vanish. Rules in references/lifecycle-and-clawback.md.
4. Verify currency, rounding, tax, and thresholds. FX strike date matches policy, rounding to 2 decimals at the end, sub-threshold balances carried forward, tax forms on file for every payee in the run. Detail in references/currency-tax-and-payment.md.