How to Split Revenue Between Two SaaS Companies (Without Arguing Over Dashboards)

Short answer: to split revenue between two SaaS companies, tag every sale with where it came from at the moment of payment, split it automatically by a rule both sides agreed before the first sale, and pay each side into its own account. Don't count clicks and send invoices at the end of the month, and don't let the money sit in one shared pot. Most revenue shares between two apps fail because one of those three steps is done by hand.

Here is how it used to go, and for most small software companies how it still goes. Two apps that share customers agree to send each other users. They swap links. Somebody says "we'll sort out the money later". Nobody tracks who sent whom, so nobody gets paid, so nobody keeps the integration working. Six months later one side changes an endpoint, the link breaks, and nobody notices because nobody had a reason to look.

The idea was fine. The plumbing was missing.

Why do most revenue shares between two apps fall apart?

They fail in a chain, and each link breaks the next.

Tracking fails first. A link swap counts clicks, and clicks are not sales. When a customer arrives through a partner, signs up a week later on a different device and pays a month after that, a click-based system has usually lost them. Each side ends up with its own number, and the two numbers don't match. (We wrote a whole post on why partner numbers disagree. The short version: neither side is lying, they are just counting different things.)

Payment fails second. If the split depends on someone exporting a report, agreeing it with the other side and raising an invoice, it depends on someone remembering. In month one they do. By month four the amounts are small, the reconciliation is annoying and the invoice quietly stops being sent.

Maintenance fails third. This is the expensive one. An integration needs a day of engineering every time an API changes on either side. That day competes with roadmap work that has a revenue number attached to it. If the integration has no revenue number attached, because the payment chain broke in step two, it loses. We've argued before that this is why most integrations rot: the party doing the most durable work is the one with no money attached.

So a revenue share that only works on paper is worse than no revenue share at all. It gives both sides a reason to resent each other.

How does an automatic revenue split actually work?

Three steps, all of them in the payment itself.

1. Tag the sale at the payment

The record of where a customer came from should sit on the charge, not on a click. When a customer buys through the integration, the payment carries a tag that says which integration (and therefore which partner) it came through. Attribution then becomes a fact recorded by the system that moved the money, not an argument between two analytics tools.

This one change removes most disputes. You no longer reconcile two dashboards, because there is one source of truth and it is the same one your accountant reads.

2. Split it automatically, by a rule agreed up front

The split happens when the payment happens, using a rule both sides signed before anything was sold. That rule says what share goes to whom, on which products, for how long. Nobody calculates anything at month end, and nobody decides whether this particular sale "counts".

Because the rule is fixed in advance, there is nothing to negotiate when the money arrives. That is the point. The negotiation happens once, when both sides are optimistic and the numbers are zero.

3. Pay each side into its own account

Each company receives its share in its own account. The money never sits in a shared pot that someone has to divide later, and neither side holds the other's money for a month.

This sounds like an accounting detail. It's actually what makes the arrangement safe enough to start with a stranger. If there is no pot, there is nothing to fight over and nothing to run off with.

When all three steps happen in the payment, the argument about whose dashboard is right never starts.

Who should collect the payment?

Someone has to take the customer's money before it can be split. There are two workable shapes, and the right one depends on whose checkout the customer uses.

With Stripe, both shapes are built on Stripe Connect. Connect lets a platform create a charge and route parts of it to other connected accounts, and keep a fee if it is the platform. Both companies need their own Stripe account. Neither needs to build a payout system.

What you should avoid is the third, informal shape: one side collects everything and promises to pay the other "monthly". That is the handshake with extra steps.

What do you need to agree before the first sale?

The split is only as good as the rule behind it. Agree these in writing while the numbers are zero:

1. The percentage. What share the partner gets of each attributed sale. There is no universal number. On Ordana's widget directory, for example, the widget's owner sets the host's share anywhere from 10% to 90%, because what's fair depends on who carries the customer relationship.
2. What counts as revenue. Name the products or prices in scope. "All revenue" sounds generous until a customer who came through the integration later buys something unrelated.
3. Share of all revenue, or only of new value. You can split everything in scope, or only revenue above a baseline measured when the agreement starts. The second option, value-added revenue, suits partners who already share many customers.
4. Duration and cap. How long the share runs per customer, and whether it stops at a ceiling.
5. Refunds and chargebacks. If the customer gets their money back, the share comes back too. Write down when.
6. Who supports what. Whoever owns the screen the user is looking at takes first-line support, and the partner owns the layer underneath with an agreed response time.
7. How either side leaves. What happens to existing customers and to the integration if one company ends it.

Our integration partnership agreement checklist goes through each of these clauses.

Manual invoicing, affiliate software or a payment-level split?

All three are legitimate. They suit different situations, and it's worth being honest about when the simpler option is enough.

If you have one partner and three sales a quarter, an invoice is fine. If you run a referral programme where creators send traffic to your pricing page, affiliate software is built for exactly that.

The payment-level split earns its keep when your product lives inside someone else's: a widget in their app, a capability their users pay for without leaving. Link tracking struggles there. In one of our own integrations, our product sat inside a partner's app, and 32% of the founders who clicked through signed up. The partner then put four affiliate links next to ours, and it fell to 7%. A product that looks like part of the host converts. A link that looks like an ad doesn't. We wrote up that drop in detail.

What changes with three or more products?

The same three steps, applied per sale.

When several products serve one customer, each sale is still tagged with where it came from, and each product's share is still computed from the rule it signed. Because nothing is pooled, adding a fourth product does not change what the first three earn on their own sales. That is the property that lets a scenario collaboration grow from two members to five without renegotiating everything.

Pool the money and every new member reopens every old agreement. That is why multi-party deals built on a shared pot rarely get past two members.

Common mistakes when splitting revenue between companies

• Splitting profit instead of revenue. Profit depends on the other company's costs, which you can't see and shouldn't have to audit.
• No baseline. If you share customers already, decide whether the share applies to all of their revenue or only to the new part. Otherwise the first big invoice starts a fight.
• Forgetting fees. Payment processing and any platform fee come out of the total. Agree whether shares apply before or after them.
• A shared pot. Even a temporary one. Someone ends up holding someone else's money.
• Refunds left undefined. The first refund after a payout becomes an awkward email.
• No exit. Partnerships end. Agreeing how, while everyone is friendly, costs ten minutes.

Where Ordana fits

Ordana handles the commercial half: the contract both sides sign, the tag on the charge, the automatic split through Stripe, and each member paid into their own account. When a startup sells its feature as a widget inside another product, Ordana can also run the billing and split each sale between the widget's owner and the host.

The members still build their own side of the integration. With a coding agent that's typically a day's work: one integration of ours went live 24 hours after both sides said yes. If you want to try the mechanics on a real partnership, start on Ordana and set up the rule before the first sale.

Frequently asked questions

How do you split revenue between two companies?

Record where each sale came from on the payment itself, split it automatically by a rule both companies agreed before the first sale, and pay each company into its own account. That removes month-end reconciliation, invoices and shared pots, which are where most revenue-sharing arrangements break down.

What is a fair revenue share between two SaaS products?

There is no standard figure. It depends on who owns the customer relationship, who carries support and how much of the value each product delivers. Widely cited partner benchmarks put referral partners at around 10–20% of first-year revenue and resellers at 20–40% of ongoing revenue. On Ordana's widget directory, the widget's owner sets the host's share between 10% and 90%.

Can Stripe split a payment between two companies?

Yes. Stripe Connect lets a platform create a charge and route parts of it to other connected Stripe accounts, and take a fee if it is the platform. Each company needs its own Stripe account. Either one of the companies or a platform in between can be set up to collect the payment and route the shares.

What happens to a revenue share when a customer gets a refund?

That depends on the agreement, which is why you should write it down before the first sale. The usual rule is that a refund or chargeback reverses the share on that sale, and the deduction comes from the partner's next payout within an agreed window.

Do both companies need to use the same payment provider?

For a split at the payment, the company or platform that collects the money must be able to pay out the partner's share, so it is easiest when both sides have accounts on the same provider. If they don't, you are back to invoicing. That is workable for low volume and fragile beyond it.

Related reading:

• Partner Attribution for SaaS: When Your Numbers and Theirs Don't Match: why two partners' dashboards disagree.
• Integration Partners Get Paid Nothing, and That's Why Integrations Rot: the case for paying integration partners at all.
• What to Put in an Integration Partnership Agreement: the clauses behind the rule.
• Revenue share partnerships: how revenue shares between software companies are structured.