How to Calculate Partner Revenue Share from Stripe (Without the Quarterly Scramble)

It usually starts the same way. A partner emails: "Hey — is our Q2 payout ready?" And you open the same spreadsheet you swore you'd clean up last quarter, re-export a few Stripe CSVs, and start reconstructing a number that someone outside your company is going to scrutinize line by line.

Paying revenue share to partners, affiliates, or publishers is one of the most exposed numbers a business produces. Internal commissions are tense enough — but at least everyone works for the same company. With partners, the person on the other side has their own records, their own incentives, and no visibility into your Stripe account. If your number and their expectation don't match, you have to explain the gap. That conversation goes a lot better when your math is clean, current, and traceable back to source.

This post walks through how to calculate partner revenue share from Stripe data reliably: what "net revenue" actually means, the three things that quietly break payouts, and how to set up a process you don't have to rebuild every quarter.

Calculating commissions for your own sales reps instead? That's a related but distinct problem — see The Cleanest Way to Calculate Sales Commissions from Stripe Data.

Revenue share is a trust problem before it's a math problem

The calculation itself is simple: net revenue × share percentage. The hard part is everything feeding that formula.

A partner who feels shorted by even a few dollars will ask how you got there. So the goal isn't just a number — it's a number you can defend months later, reproduce on demand, and tie back to specific Stripe records. That standard rules out anything fuzzy or manually patched together, which is exactly where most ad-hoc spreadsheet processes end up over time.

The number that matters is net, not gross

Almost no revenue-share agreement is calculated on gross. The amount a customer paid is not the amount your business kept. Before you apply a partner's percentage, you typically need to strip out:

• Stripe processing fees — a real cost on every transaction

• Refunds — money that left again, sometimes weeks later

• Discounts and credits — coupons, proration, account credits that reduce what was actually collected

• Taxes — almost never part of commissionable revenue

What's left is net revenue, and that's what your agreement percentage should multiply. Getting this right is the difference between a payout your partner trusts and one they dispute. The trouble is that gross, fees, refunds, and discounts live in different Stripe objects — charges, invoices, invoice line items, refunds — so assembling clean net revenue by hand means joining several exports and hoping nothing shifted between downloads.

What Stripe gives you — and what it doesn't

Stripe is excellent at recording financial events. It knows your invoices, payments, line items, fees, and refunds. What it has no concept of is the business logic on top:

• which partner drove which customer

• each partner's share percentage or tier

• holdbacks, caps, or minimum thresholds

• how you treat a refund that lands after you've already paid

That layer is yours to build. Stripe gives you the raw, accurate inputs; you supply the attribution and the rules.

The three things that quietly break partner payouts

1. Treating gross as net. Paying a partner 20% of gross when your agreement says net of fees overpays on every transaction. It's a small leak per charge that compounds across a quarter — and it's awkward to claw back once a partner has seen the higher number.

2. Refunds that arrive after payout day. This is the big one. You run the report on the 1st, pay the partner on the 3rd, and a refund posts on the 5th against revenue you already shared. Now last quarter's "final" number is wrong. Worse, the most common way to pull Stripe data — filtering by creation date — can miss records that changed after they were created, so the refund may not even show up in your next pull unless you specifically look for it.

3. Mixing up which date counts. Stripe gives you several timestamps: when an invoice was created, when a payment succeeded, when a payout settled. Revenue share calculated on "invoice created" and reconciled against "payment received" will never tie out. Pick one time basis per agreement and apply it consistently.

A worked example

Say you run a quarterly revenue-share program with three partners, each at a negotiated rate. Pulling net revenue (gross minus refunds and Stripe fees) by partner, the table looks like this:

Notice Partner Gamma. Without subtracting that $15 refund, you'd pay revenue share on $84.85 of net instead of $69.85 — overpaying by a couple of dollars on one small account. Multiply that pattern across a real partner base and a full quarter, and the gap between "gross-ish" and "actually net" becomes a number worth getting right.

The point of a table like this is that every figure traces back to specific Stripe line items. When a partner questions the payout, you can show exactly which customers, charges, and refunds produced it.

Where the manual version starts to strain

Spreadsheets are genuinely the right tool for this. They're transparent, flexible, and easy to audit — which is exactly what revenue share needs. The strain isn't the spreadsheet; it's the data feeding it.

Every quarter you re-export the same Stripe reports, re-join them, re-check that a late refund didn't move a number, and rebuild the same pivots. As the partner base grows and agreements get more specific, that recurring export-and-reconcile ritual becomes the actual job — and the place errors sneak in.

The fix is to stop treating the data pull as a manual task. If clean Stripe data — charges, invoices, line items, refunds, payouts, with fees and net already alongside — simply stays current in your spreadsheet, then your partner logic sits on top as stable formulas. You add a partner mapping and a rate, and the payout table recalculates itself. Late refunds update the underlying rows instead of silently invalidating last period's report.

A setup that holds up over time

1. Keep Stripe data synced into Google Sheets, refreshed automatically, so you're never re-exporting CSVs or working from a stale snapshot.

2. Define net revenue once — gross minus fees, refunds, discounts, and taxes — and reuse that definition everywhere.

3. Map partners to customers (by customer ID or subscription ID) in their own tab, kept separate from the raw Stripe data.

4. Fix your time basis and refund policy per agreement, and write them down so every quarter is calculated the same way.

5. Produce an auditable payout table that ties back to line items and survives a partner's questions months later.

Do this once and quarterly revenue share stops being a scramble and starts being a refresh.

Stop rebuilding partner payout reports from CSV exports. SyncStaq keeps your Stripe billing data — gross, fees, refunds, net, and invoice line items — synced into Google Sheets every hour, so revenue share and reconciliation run on data you can trust. Start a 14-day free trial.

Related reading: How to See Total Revenue by Customer in Stripe and The Cleanest Way to Calculate Sales Commissions from Stripe Data.