You're reviewing last month's affiliate statements and something's off. The CRM shows $47,500 in commissions earned. Your payment processor settled $43,200. Your accounting GL recorded $44,100. Which one's right? They all are—and none of them are. This is payout drift, and at 50+ affiliates, it costs most SaaS teams 8–12% monthly in reconciliation labor, chargebacks, and silent leakage. The leak isn't a bug. It's the architecture. Affiliate commission data crosses nine separate handoff points—from conversion tracking through final GL settlement—and each one introduces timing skew, rounding loss, or incomplete sync. We've audited this for teams managing $500K to $5M in annual affiliate spend. Here's where the drift happens and how to close it. Why the three-system mismatch happens Your CRM tracks when a commission is earned , your payment processor records when it's scheduled for payout, and your accounting system posts when it actually settles. The gap between "earned" and "settled" is where most drift lives. A concrete example: On March 15, affiliate Alice drives a $10,000 deal. Your CRM marks $500 commission as earned immediately. Alice's commission is tagged for payout on March 31 (your standard monthly cadence). But Stripe's default D+2 settlement means the funds don't land in your account until April 2. Your accounting team, following cash-basis rules, doesn't record the payout in the GL until April 3 when the Stripe settlement report is imported. Meanwhile, your CRM shows $500 as owed on March 15, your payment processor shows it scheduled March 31, and your GL shows $0 until April 3. A bank auditor looking at March's GL would think you paid nothing—or worse, that the amount is missing entirely. At scale (100+ monthly payouts), this creates reconciliation chaos: finance spends 20–30 hours monthly cross-checking systems, payments get held pending "investigation," and affiliates dispute payouts because they see different balances in their dashboards. The nine handoff points where drift accumulates We mapped these from real audit trails across 12 SaaS platforms. Each is a place where data either doesn't sync or syncs with a timing lag: Conversion tracking to CRM commission record. Your attribution tool (Segment, Branch, custom pixel) marks a conversion; your CRM is supposed to ingest it and create a commission record. If the ingest fails silently or runs on a 4-hour batch, conversions from 8 p.m. Tuesday might not appear in the CRM until 12 a.m. Wednesday. During that gap, the commission is "real" in your analytics but doesn't exist in your CRM, so it won't appear on the payout worksheet. CRM commission rate lookup. Alice's commission is 7% of deal value. But if she downgraded to a 5% tier last month and your CRM didn't sync that tier change from your membership/subscription system, the commission record still shows 7%. When you reconcile, there's a $100 overpayment baked in that no one catches until the annual audit. Deal status change to "ready for payout" flag. A deal won't generate a commission payout until it's marked "closed-won" or an equivalent status. If your sales team marks a deal closed but doesn't change the status in the field your payout system monitors, the commission sits dormant. One team we worked with had five status fields (Salesforce native, internal custom field, CRM secondary status, Slack export, and a Google Sheet). The payout system watched one. Commissions for $200K in deals never fired because they were marked closed in four fields but not the fifth. Payout worksheet generation to payment processor upload. You export a CSV of payouts from your CRM or payout platform and upload it to Stripe Connect or your processor of choice. If the CSV column order is wrong, or a field isn't quoted correctly, the processor might skip a row or truncate a decimal. One client's "amount" column was formatted as text instead of numeric; the processor read "500.00" as a validation error and dropped every record with two decimal places. It took three weeks to notice. Payment processor booking to settlement. Stripe, 2Checkout, and Razorpay all have different settlement delays. Stripe defaults to D+2 (funds arrive two business days after payout). Razorpay can do next-day. 2Checkout varies by country and payment method. If you're batching payouts on the 30th but your processor's settlement window doesn't align with your GL close date (usually the 25th or end of month), the payout month in your processor doesn't match the GL month. You book a March 30 payout but it settles April 2; do you record it as March or April? Most teams record it incorrectly, creating a phantom line item. Settlement file import to GL posting. Your payment processor generates a settlement report (CSV or API). You or your accounting software imports it and creates GL entries. If the import script doesn't handle partial settlements, chargebacks, or fee deductions, the GL won't match the processor. One client's Stripe settlement inc