A fintech network managing 87 affiliates discovered in their monthly close that 12% of payouts—roughly ₹35K monthly—had vanished into timing gaps, currency rounding errors, and duplicate entries that no one caught until settlement hit their bank account three days late. By then, the drift had compounded across three payment processors and two currencies. That leak is not unusual. At scale (50+ affiliates), payout reconciliation breaks because it lives in a spreadsheet, settlement happens asynchronously across multiple rails, and nobody owns the drift. This playbook gives you nine checkpoints to audit in real time, tested against 1,000 live payouts across Stripe, Razorpay, and 2Checkout. Why 12% drifts undetected until settlement Affiliate payout leaks happen in five predictable places: Settlement timing: Stripe batches settle 2–4 days after payout; Razorpay settles next business day. If you reconcile daily against the settlement register, not the transaction log, you miss in-flight payouts. Currency rounding: A ₹1,247.50 payout converts to USD at your merchant rate, then the affiliate's bank converts again at their rate. The 0.2–0.8% spread per transaction compounds across 1,000 payouts to ₹2K–₹8K monthly. Duplicate entries: Failed payout retries, manual adjustments, and webhook replays create ghost transactions that accounting doesn't flag if payout records aren't deduplicated before reconciliation. Late-posted transactions: Chargebacks, refunds, and adjustments post 5–30 days after the payout, creating reconciliation breaks if your audit window is too short. Processor fee variance: Stripe charges 0.25% + ₹9 on payouts; Razorpay charges flat 0.5%. If you budget one way and your processor bills another, the gap hides in GL reconciliation. At 87 affiliates paying out ₹2.9L monthly, a 12% drift equals ₹35K monthly or ₹420K yearly. Most teams discover it at audit, not in ops. Checkpoint 1: Daily settlement register vs. transaction log Do not reconcile against your processor's settlement register alone. The register shows settled funds only; in-flight payouts are invisible until settlement completes. Daily action: Export both the settlement register and the full transaction log from each processor (Stripe, Razorpay, etc.). Match transaction IDs between the two. Any payout in the transaction log but not in the settlement register is in-flight. Flag in-flight payouts with an expected settlement date based on your processor's SLA (Stripe +2 days, Razorpay +1 day). Alert if a payout exceeds the SLA by >1 day—that signals a failed settlement. Tool: A simple SQL query or automation can flag rows where settlement_date is NULL or past SLA. Most teams do this monthly; do it daily to catch drift early. Checkpoint 2: Currency conversion variance threshold Every forex conversion is a loss. If you payout in USD and your affiliate banks in INR, two conversions happen: yours (at your Stripe/Razorpay rate) and theirs (at their bank rate). That 0.3–0.8% spread per transaction bleeds ₹2K–₹5K monthly at scale. Daily action: For each payout, log the conversion rate you used, the amount in originating currency, and the amount received by the affiliate (from their bank statement or invoice). Calculate the implied conversion rate: received ÷ sent. Flag any variance >0.5% from your processor's stated rate. That indicates a hidden fee or affiliate bank markup. Set a monthly threshold: if cumulative FX variance exceeds ₹1K, audit all conversions for that affiliate. Example: You send $100 USD at 83.2 INR/USD = ₹8,320. Affiliate's bank credits ₹8,245. Implied rate: 82.45. Variance: 0.9%. That's a red flag—either your processor or their bank is taking extra spread. Checkpoint 3: Deduplication before posting Webhook retries, manual reversals, and reconciliation uploads create duplicates. A payout issued once but recorded twice inflates your payout liability and breaks reconciliation until someone notices the imbalance months later. Daily action: Before posting payouts to your GL, deduplicate by transaction ID + amount + date. Flag any duplicate entries and quarantine them in a "review" bucket. Manually verify duplicates against your processor's transaction log: if the processor shows only one transaction, delete the duplicate. If the processor shows a reversal + reissue, merge them into a net adjustment. Log all deduplication decisions in a "reconciliation log" with date, affiliate, reason, and approver. Most dupes come from webhook replays (Stripe retries failed webhooks up to 5 times) or manual adjustments. A simple GROUP BY transaction_id catches most of them. Checkpoint 4: Settlement timing window Your processor settles on their schedule, not yours. If you reconcile daily but only count settled funds, you're excluding millions in in-flight payouts. At scale, that creates a rolling reconciliation debt. Daily action: Define three buckets: issued (payout created, awaiting processor confirmation), in-flight (processor acknowledged, settling