By month 6, most affiliate programs running on spreadsheets and Stripe have a problem: the numbers no longer match. A few commission records diverge here, a refund doesn't flow back there, and suddenly your affiliate is owed ₹2,500 but your spreadsheet says ₹2,200. Multiply that across 20 affiliates and you're managing reconciliation chaos instead of scaling your program. This drift isn't laziness—it's architecture. Spreadsheets assume linear commission logic: order comes in, commission triggers, payout flows. Stripe doesn't work that way. It tracks transactions, refunds, disputes, and adjustments separately. When a customer upgrades mid-month, downgrades, or charges back, Stripe records the change instantly. Your spreadsheet, if it even catches it, records it in the next manual audit cycle. Here's how to find the leak, quantify the damage, and move beyond spreadsheet reconciliation before it costs you credibility with your affiliate network. Why spreadsheet affiliate payouts fail at scale The math breaks in three places: Proration and midcycle changes. An affiliate refers a customer who upgrades from ₹5,000/month to ₹8,000/month on day 15. Stripe prorates the charge. Your spreadsheet either missed the upgrade entirely, recorded the full ₹8,000 as new commission, or logged it as two separate line items that don't reconcile to Stripe's payout logic. Refunds and chargebacks. A customer disputes a charge 40 days after purchase. Stripe reverses the transaction and adjusts the next payout. Your spreadsheet still shows the original commission because nobody ran a "reversals" tab last Tuesday. Timing misalignment. Stripe settles funds on Thursday. Your affiliate payout spreadsheet calculates on Friday. A transaction that lands Thursday evening appears in Stripe's payout but not in your week's calculation. By the time you notice, you're two cycles behind. The result: by month 6, most affiliate programs have a 5–12% drift between what Stripe actually paid and what the spreadsheet owes. Some of that is hidden in "we'll reconcile later" rows that never get reviewed. Audit your current drift: the four-step Stripe file check Before you redesign anything, measure the leak. Export your Stripe payout history. In Stripe Dashboard, go to Payouts → download the full ledger as CSV for the last six months. You'll get columns: date, amount, type (charge, refund, fee), description, balance change. Build a Stripe-source-of-truth total. Filter for type = "charge" or "refund". Sum all charges; sum all refunds; net them. This is what Stripe actually processed. Note the date range—critical for next step. Pull your affiliate payout spreadsheet totals for the same date range. Sum all commissions you recorded. Compare to Stripe's net. Find the delta. If Stripe says ₹50,000 net but your spreadsheet says ₹51,200, you have a ₹1,200 unaccounted-for difference. That's 2.4% drift in one month. At 12% annual, something is systematically broken. Now dig into the reconciliation file—the spreadsheet where you're supposed to match Stripe's transactions to your affiliate records. Most teams never fully build this because it's tedious. The gap usually sits in: Refunds that landed in Stripe but not in the "reversals" column. Proration adjustments that Stripe recorded as separate line items but your affiliate commission rules treated as a single event. Fees or disputes that reduced the payout but weren't deducted from the affiliate's balance. Spot the three most common drift sources Proration and subscription changes An affiliate refers a customer on March 8 for a ₹10,000/month subscription. Commission triggers: ₹500 (5%). On March 20, the customer upgrades to ₹15,000/month. Stripe prorates the difference and charges ₹3,387 for the remaining 11 days of March. Your spreadsheet either: Doesn't see the upgrade (most common): affiliate is owed ₹500. Sees it as a new referral and records ₹675 (5% × ₹15,000), overstating commission. Manually adjusts to ₹500 + ₹169 (5% × ₹3,387) = ₹669, but records it in two rows that confuse the payout logic. Stripe's payout file shows two transactions: the original charge plus the proration adjustment. If your spreadsheet doesn't separate these, reconciliation fails. Refunds with no reversal logic An affiliate's referred customer initiates a refund on day 18. Stripe processes it instantly and reduces your next payout by the full refund amount. Your spreadsheet has no "refunds" column—or worse, has one, but nobody checked it when calculating month 2 payouts. The affiliate was paid ₹500 in month 1 for a sale that was later reversed. In month 2, Stripe deducted ₹500 from the payout pool, but your spreadsheet still owes the affiliate ₹500 because the refund never got recorded. Chargeback fees and disputes A customer disputes the original charge. Stripe flags it, investigates, and after 10 days, reverses the transaction and charges a ₹500 dispute fee. Your spreadsheet knows about the refund (maybe) but doesn't touch the commissi