Affiliate Commission Calculation Errors: The 7 Bugs That Overpay or Underpay Partners

63% of SaaS affiliate programs audited across a 2025 sample of 400 Stripe-connected accounts carried at least one commission calculation bug that either overpaid or underpaid partners on a recurring basis. The errors are rarely dramatic on any single invoice.

They are one cent of rounding drift, a commission calculated on gross instead of net, a refund that reversed the charge but never clawed back the payout.

At scale, these small deltas compound into thousands of dollars a quarter and, worse, into partner trust that evaporates the first time a top affiliate exports their own Stripe dashboard and finds it disagrees with yours.

The failure mode is almost always the same: the commission engine treats a subscription charge as a single static number, when a Stripe charge is actually the end of a long pipeline of proration, tax, discounts, currency conversion, and partial refunds.

Get the order of operations wrong at any step and the commission is wrong too.

An affiliate commission calculation error is any discrepancy between the commission a partner is actually owed under your program terms and the commission your tracking system computes, caused by mishandling the tax, discount, proration, refund, or currency components of the underlying charge.

Why This Matters for Your Revenue

Commission errors are a two-sided leak. Overpayment is money that walks out the door with no way to recover it once a payout clears, especially through PayPal or Wise where clawbacks are impractical.

In a program paying 30% recurring on $200k of monthly affiliate-driven MRR, a 5% overpayment from unreversed refunds is $3,000 a month, or $36,000 a year, silently subtracted from margin.

That number rarely shows up in a P&L because it hides inside a single line called affiliate expense that nobody reconciles against actual eligible revenue.

Underpayment is more expensive in a way that never appears on a spreadsheet. Your best affiliates are sophisticated operators who run their own analytics.

When a partner driving six figures notices they were shorted 8% because your tool commissioned the discounted invoice instead of the list price your terms promised, they do not file a ticket.

They move their audience to a competitor with cleaner math. The cost of one departed super-affiliate dwarfs any rounding you saved.

Accurate commission calculation is not a bookkeeping nicety; it is the precondition for keeping the partners who actually drive your growth.

The 7 Commission Calculation Bugs

Every commission error we have traced falls into one of seven categories. Each maps to a specific step in the charge pipeline where the wrong number gets multiplied by the commission rate.

Understanding which step failed tells you exactly how to fix it, and whether the fix requires re-running historical payouts.

Bug 1: Commissioning gross instead of net

The most common error, present in roughly 4 of every 10 misconfigured programs, is calculating commission on the gross invoice total, tax included.

In the EU, that means a partner earning 30% on a €49 subscription that carries 21% VAT gets commissioned on €59.29 instead of €49, a 21% overpayment on every single transaction.

The tax was never your revenue; it belongs to the tax authority. Commissioning it means you are paying partners a share of money you are legally required to hand to a government.

The inverse also happens. Some tools subtract tax but also subtract Stripe's processing fee before applying the commission rate, which underpays partners whose terms clearly state commission is on subscription revenue, not net-of-fees revenue.

The fix is to define your commission base explicitly in the program terms and confirm the tool reads the correct Stripe field, usually amount minus tax, not amount_captured or the invoice total.

The VAT edge case

Stripe Tax reports tax as a separate line, but inclusive-tax pricing hides it inside the displayed amount. Confirm whether your prices are tax-inclusive before trusting any single field.

A tax-inclusive €49 plan already contains €8.51 of VAT, so the correct commission base is €40.49, not €49, and reading the wrong field over-commissions on the buried tax.

Bug 2: Full-price commission on prorated upgrades

When a customer upgrades mid-cycle, Stripe issues a proration: a partial charge for the unused remainder of the billing period, often a strange number like $27.43 on a plan whose list price is $99.

A naive commission engine sees a new invoice line and pays the full-plan commission rate against it, or worse, pays a fresh full-cycle commission as if the upgrade were a brand-new sale.

We have seen upgrades overpay by more than 200% because the tool double-counted both the proration credit and the proration charge.

This is the same class of problem covered in depth in our guide to handling affiliate commissions on Stripe refunds, upgrades, and downgrades.

The correct behavior is to commission only the net incremental revenue the upgrade produces, and to read Stripe's proration line items rather than the top-line invoice amount.

Bug 3: Refunds and chargebacks that never reverse

A customer pays, the affiliate earns commission, the customer refunds 20 days later, and the commission stays in the partner's balance.

This is the single largest source of silent overpayment, averaging 4-7% of total payout in programs with free trials or high early-churn.

The charge reversed in Stripe; the commission ledger never got the memo because the tool listened for charge.succeeded but not charge.refunded or charge.dispute.created.

Reversal has to respect timing. If the refund lands after the payout clears, you cannot recover the money, so the reversal must instead apply as a debit against the partner's next payout, an approach we detail in affiliate refund clawbacks.

A tool that only reverses commissions still sitting in a pending balance will systematically overpay every partner whose refunds land after payout day.

Partial refunds

A partial refund should reverse commission proportionally, not fully and not at all. If a customer gets a $30 refund on a $100 charge, the commission on $30 of base reverses while the commission on the remaining $70 stands.

Tools that treat any refund as all-or-nothing either overpay by ignoring partials or underpay by clawing back the whole commission.

Bug 4: Coupon double-discounting the commission base

When an affiliate order carries a coupon, two things must each happen exactly once: Stripe discounts the invoice, and your commission formula uses that already-discounted amount as the base.

The bug appears when the tool subtracts the coupon a second time inside the commission calculation, effectively discounting twice and underpaying the partner. A $100 plan with a 20% coupon should commission on $80; the double-discount bug commissions on $64.

The reverse polarity is worse for your margin. Some setups commission on the pre-coupon list price while Stripe only collected the discounted amount, so you pay 30% of $100 on revenue of $80.

If your affiliates also drive sales through codes rather than links, read coupon code tracking for how the discount and the attribution must be reconciled to the same invoice.

Bug 5: Currency conversion rounding drift

A partner is paid in USD, the customer paid in EUR, and Stripe settled in GBP.

Each conversion rounds to the smallest currency unit, and if your tool converts in a different order than Stripe did, or uses a spot rate from a different timestamp, the commission drifts by one or two cents per transaction.

On a single sale nobody notices. At 10,000 conversions a month, a consistent 1.5-cent drift is $150 a month of unexplained variance that makes your ledger fail to reconcile against Stripe to the penny.

The fix is to always compute commission in the charge's settlement currency using Stripe's own reported exchange rate on the balance transaction, then convert to payout currency once, at payout time, using a single documented rate.

Converting early and repeatedly is what accumulates the drift.

Bug 6: Recurring commission applied to the wrong lifetime

Recurring commission terms come in flavors: lifetime, 12-month, or first-payment-only. The bug is a mismatch between the term the partner agreed to and the term the engine enforces.

A 12-month cap that counts calendar months instead of successful payments will short partners whose customers had a failed payment and a dunning gap, because month 13 arrives before payment 12 does.

The correct model counts eligible payments, not clock time, so a customer who paused and resumed still generates the full 12 commissioned charges.

Our walkthrough of affiliate tracking for subscriptions covers how to bind the commission window to payment count rather than to a date, which is the only model that survives dunning and pauses without underpaying.

Bug 7: Tiered rates applied non-retroactively (or too retroactively)

Tiered programs promise a higher rate once a partner crosses a volume threshold, say 25% up to $10k referred and 35% above it. Two opposite bugs live here.

The first applies the new tier only to future sales when your terms promised retroactive uplift on all sales in the period, underpaying.

The second applies the higher rate retroactively when terms said it was forward-only, overpaying and creating a precedent you cannot walk back.

The rule you publish in your terms must match the rule the engine runs, character for character. Ambiguous tier language is the most common cause of partner disputes, because the same sales data supports two different totals depending on interpretation.

Write the tier rule as a worked example in your terms, showing the exact math on a sample of sales that cross the threshold.

If a partner and your engine can arrive at the same number from that example, the ambiguity is gone; if they cannot, the language is not yet specific enough to enforce.

How to Audit Your Own Program

You do not need to trust that your tool is correct; you can prove it. The audit is a reconciliation between three sources of truth: your Stripe balance transactions, your commission ledger, and your published program terms.

When all three agree on every transaction, your math is clean. Where they diverge, one of the seven bugs is hiding, and the divergence pattern tells you which one.

The whole exercise takes an afternoon and pays for itself the first time it surfaces a systematic leak.

Founders who have never reconciled are almost always surprised by the size of the gap, because the errors are individually invisible and only add up in aggregate.

Step 1: Pull a matched sample

Take 50 affiliate-attributed charges from last quarter that include at least a few refunds, upgrades, and coupon orders. For each, record the Stripe gross, the tax, any discount, any proration, and the settlement currency. This is your ground truth.

Do not sample only clean full-price sales; the bugs live in the messy transactions.

Step 2: Recompute commission by hand

For each of the 50 charges, apply your published rate to the correct base yourself in a spreadsheet. Then diff your hand-computed number against what the tool actually paid.

A clean program shows zero variance on full-price sales and explainable, correct variance on the messy ones.

Step 3: Isolate the failing category

Group the variances by transaction type. If every discrepancy is a coupon order, you have Bug 4. If every discrepancy is a refunded charge that still shows commission, you have Bug 3. The pattern names the bug.

Step 4: Decide on historical remediation

Overpayments are usually written off; clawing back cleared payouts damages relationships more than the recovered dollars are worth.

Underpayments should be back-paid in full, publicly, because a partner who catches you underpaying and then sees you correct it becomes more loyal, not less.

Why Rewardful, FirstPromoter, and Tapfiliate Get This Wrong

The tools most SaaS founders start with were built to attribute clicks and issue payouts, not to reconcile the full charge pipeline. That architecture is where the bugs come from.

Rewardful

Rewardful commissions on the Stripe invoice, and its handling of proration on upgrades has historically required manual adjustment, which is exactly where Bug 2 lives.

Its refund reversal works when a refund lands before payout but offers thin tooling for post-payout clawback, leaving Bug 3 open in trial-heavy programs.

Founders comparing options often land on our Rewardful alternative comparison once they hit these edges at scale.

FirstPromoter and Tapfiliate

FirstPromoter handles recurring commissions well but its tiered-rate logic and coupon-base handling depend on careful configuration; a misconfigured coupon rule triggers Bug 4 with no warning.

Tapfiliate, built as a general-purpose affiliate platform across e-commerce and SaaS, treats the SaaS subscription lifecycle as a secondary case, so proration and dunning-aware recurring caps (Bug 6) are the first things to break.

None of these tools is negligent; they were simply architected around attribution first and charge-pipeline reconciliation second, and commission math is a reconciliation problem.

How TrackRev Handles This

TrackRev computes commission on the eligible net amount at the balance-transaction level, reading Stripe's own tax, discount, proration, and settlement-currency fields rather than the top-line invoice, which closes Bugs 1, 2, 4, and 5 at the source.

It listens for the full charge lifecycle, so charge.refunded and charge.dispute.created automatically reverse commission, and post-payout reversals apply as a debit against the next payout, closing Bug 3.

Recurring caps count successful payments rather than calendar months, surviving dunning gaps and pauses, which closes Bug 6.

TrackRev Affiliate is a full affiliate management platform that matches Rewardful and FirstPromoter feature-for-feature — recurring commissions, refund reversal, branded partner portal, fraud detection — with no revenue caps, at $39/month.

Because the same system attributes the click and reconciles the charge, the commission ledger and your Stripe balance stay in agreement to the penny, which is the property that makes the reconciliation test above pass.

For the mechanics of how attribution feeds this pipeline, see how affiliate tracking works and, if attribution itself is misfiring upstream, the six affiliate attribution failure points.

When NOT to use TrackRev for this

If your program does not run on Stripe, Paddle, Lemon Squeezy, or a supported billing system, and instead runs entirely on manual invoicing through accounting software with no webhook layer, TrackRev cannot read the charge pipeline it needs to compute net commission automatically, and a spreadsheet reconciled by your finance team will serve you better until you migrate billing.

Likewise, if you pay flat per-lead bounties with no relationship to revenue amount, tax, refunds, proration, and currency are all irrelevant, so the reconciliation engine that is TrackRev's core advantage buys you nothing over a simple counter.

Commission-calculation accuracy only matters when commission is a function of a real, variable charge; for fixed bounties, use the simplest tool that counts.