The Outcome Ledger

In the first episode of this series, I promised a framework for the question every episode since has circled: when an agent surfaces a deal, one partner influences it, another embeds in it, and a third delivers it, who gets paid? I called it the Outcome Ledger. This is the episode where it gets built.

Two weeks of Act III set up the problem precisely. Episode 10 found that every attribution system in production recognizes two kinds of partner contribution, sourced and influenced, while real deals now also run on embedded and orchestrated contributions that no vendor's data model can hold. Episode 11 followed the same deal to the point where it misses and found that no partner agreement we reviewed was written for more than two parties or for an agent. Credit has no structure for four parties, and accountability has no structure for four parties. Both problems are accounting problems, and both have the same missing piece: a shared record of who contributed what, proven how, and paid against which outcome.

The Outcome Ledger in one sentence

The Outcome Ledger is a record of contribution events, logged per party, human or agent, weighted by role, and settled against attested outcomes.

Each clause of that sentence is a rule, and each rule answers a failure this series has already documented. Logging answers the notes field Episode 10 found standing in for multi-party credit. Weighting answers the three-way split between first-touch, last-touch, and multi-touch models that PartnerStack and Wynter found across 100 companies. Settling against outcomes answers the gap between who gets paid at signature and who is on the hook when the result does not arrive. The framework is deliberately simple enough to run in a spreadsheet, and it is imperfect by design. Every number in it is a published default, set out to be argued with.

Rule 1: log the contribution, with its evidence

A contribution event is a single row: which party contributed, whether a person or an agent did the work, which of the four contribution types it was (sourced, influenced, embedded, or orchestrated), and the evidence that it happened.

Two details carry most of the weight. First, an agent's work is booked to the party that operates it, the same principle as the first accountability clause in Episode 11. An agent never holds a ledger line of its own; its operator does, and its operator answers for it. Second, every event names its evidence at the moment it is logged. Agents are, if anything, easier to credit than people under this rule, because they leave logs by default. A partner manager's introduction over coffee leaves nothing behind unless someone writes it down; a prospecting agent's flag on an account leaves a timestamped record.

Rule 2: weight by role, grade by evidence

Each party scores once per contribution type, at the best evidence it can show. The score is the role weight multiplied by the evidence grade.

The default role weights are these:

The evidence grades are these:

The self-reported grade of zero is the most contested choice in the framework, and it is intentional. Episode 1's prediction was that self-reported co-sell will stop earning incentive dollars at every major hyperscaler by the end of 2028. A ledger that paid on assertion would simply rebuild deal registration with more rows.

Rule 3: settle against attested outcomes

The ledger divides a pool. It creates none. The pool is whatever the vendor already budgets for partner credit on a deal of that size, and it is released in tranches as outcomes are attested: some at the transaction, the rest as the customer confirms adoption and value milestones. Each tranche is split by the ledger shares. A tranche whose milestone misses is never released, and the money that was never earned stays unearned. What the ledger adds is a record of why the milestone missed, which is the evidence Episode 11's fourth clause needs to settle the unpaid work between partners.

One deal, four parties: the worked example

BlueThread Research built the example below from typical published rates, so it reads like a common deal. The parties are fictional; the economics are standard.

The deal. A software vendor sells a $200,000 first-year contract to an enterprise customer through an AWS Marketplace private offer. AWS's published listing fee for a SaaS private offer under $1 million in contract value is 3 percent, so $6,000 goes to the marketplace before any partner is paid. The vendor's partner pool is 20 percent of first-year contract value, $40,000, the rate Jason Lemkin's SaaStr guidance on enterprise referral commissions gives for a partner who brings a qualified opportunity.

The four parties.

• Harbor Point Advisory, a referral partner. Its prospecting agent flagged the account, and its partner manager made the introduction.
• Meridian Integration, a systems integrator. It ran the technical validation that moved the deal to close.
• Quillon Data, a technology partner. Its data connector is built into the workflow the customer actually receives.
• Relay Ops, a platform partner. Its orchestration agent runs the onboarding workflow that coordinates the other contributions after the sale.

The ledger.

That produces ledger shares of 37.2 percent for Harbor Point, 31.9 percent for Quillon, 21.3 percent for Relay, and 9.6 percent for Meridian. Meridian's claim that it orchestrated the rollout stays on the ledger, visible to every party, and earns nothing until something other than Meridian's own account can show it happened.

The settlement. The $40,000 pool releases in three tranches: 40 percent ($16,000) when the marketplace transaction is recorded, 30 percent ($12,000) when the customer attests the 90-day adoption target, and 30 percent ($12,000) when the customer attests the 180-day value target. The first two clear. The third misses, and the workflow logs trace the shortfall to a configuration change in the orchestrated workflow. The final payouts:

Now run the same deal under registration logic. Harbor Point registered it first, so Harbor Point is paid the full $40,000 at signature. Quillon, Relay, and Meridian receive nothing from the vendor's pool, and the vendor pays in full for an outcome the customer never confirmed. The ledger pays four parties $28,000 over 180 days, ties every dollar to evidence a CFO can inspect, and holds back the $12,000 the outcome did not earn.

The case against it, and where it holds

Four objections deserve a real answer, and the first is the one that will decide whether anyone adopts this.

The sourcing partner earns less. In the example, Harbor Point goes from $40,000 to $10,426, and a partner that lives on referral fees will notice. Two things are true at once. The ledger is pool-agnostic, so a vendor that wants sourcing partners whole can size the pool larger, and the ledger then becomes the case for that budget, because every dollar in it is attached to evidence. And a sourcing partner whose pay depends on the outcome has a reason to source deals that will actually land, which is the behavior outcome-based funding is trying to buy.

The weights are arbitrary. They are, and the framework says so. What matters is that weights are agreed before the deal, written into the teaming agreement alongside Episode 11's responsibility schedule, and applied the same way every time. A disputed default published in advance beats an undisputed number invented at compensation time.

Evidence can be gamed. A partner that knows system-verified events pay will generate system events. The one-score-per-type rule limits the damage, since a party earns its best evidence once per type regardless of how many events it logs, and the zero grade for self-reporting removes the cheapest form of inflation entirely.

It costs too much to run. For most deals, it does, which is why the threshold discipline from Episodes 10 and 11 applies here too: run the ledger only on deals above a set value or with more than two parties. Below the line, the old sourced-or-influenced call is fine. Above it, most of the evidence already exists in systems the parties own, the CRM, the marketplace record, the integration logs, the agent logs. The ledger's main cost is agreeing to read them together.

The Operator Move: run one closed deal from last quarter through the ledger

Twenty minutes, one spreadsheet. Pick a deal from last quarter that involved more than one partner, tool, or agent.

1. List every party that touched the deal, and book any agent's work to the party that operates it.
2. Log each party's strongest contribution per type (sourced, influenced, embedded, orchestrated), with the evidence you could actually produce today.
3. Grade the evidence at 1.0, 0.6, or 0, and multiply by the default weights.
4. Split the partner credit you actually paid on that deal by the resulting shares, and compare the two answers.
5. Mark which outcome milestones the customer has attested, and note how much of what you paid would still be unearned under tranche settlement.

The gap between step 4 and what you actually paid is the size of the argument your team has not had yet.