AI Agent Marketplace Billing, Revenue Sharing, and Settlements

Three structural features separate agent marketplace billing from every other type of software billing. Understanding them determines what the infrastructure must support from day one.

Multi-Party Transactions

In standard SaaS, one vendor sells to one customer. In a marketplace, the platform facilitates a sale between a developer and a customer. Two financial relationships exist simultaneously: the customer pays the platform, and the platform owes the developer. Every billing system that handles only the customer-facing side of that relationship will create reconciliation problems on the developer-facing side.

This is not an edge case. It is the normal operating state of every agent marketplace transaction.

Agent-Level Attribution

A single customer request may invoke multiple agents from different publishers. A workflow that drafts a proposal, validates data, and formats a deliverable might touch three agents from three different developers. Each agent may carry a different pricing metric (tokens consumed, task completions, compute time) and a different revenue share arrangement. The billing system must attribute usage and revenue to each agent independently, then consolidate a single customer-facing invoice.

Without agent-level attribution in the event schema, the data needed to calculate developer settlements does not exist at settlement time. It cannot be reconstructed after the fact. Agent-level identity is a platform capability rather than a schema convention — see Zuora AI at zuora.com/products/ai/ for how the agents are identified and instrumented.

Outcome Variability and Partial Completion

AI agents do not always complete their tasks. An agent that fails halfway through a workflow raises a billing question with no default answer: did the customer receive value? Is partial effort billable? What does the developer get paid for incomplete work? These questions do not arise in subscription billing. Marketplace billing requires explicit policies for each scenario, and the billing system must enforce those policies at the transaction level, not in a manual exception process.

A Concrete Scenario

A company operates a marketplace with 50 third-party AI agents. A customer runs a workflow that touches four agents from three different developers. The workflow completes successfully.

Before money moves, seven things must happen:

1. Each agent’s usage is captured as a distinct billing event carrying the agent ID, developer ID, customer ID, usage quantity, and timestamp.
2. Each event is rated against the price schedule for that agent.
3. Revenue is calculated per agent, then aggregated into a customer invoice total.
4. The platform’s commission is deducted per developer.
5. A customer invoice is generated for the full amount.
6. Developer payouts are calculated net of the platform fee and queued for settlement.
7. Tax is applied based on who is the seller of record for each party in the transaction.

None of those steps is complicated in isolation. Together, at scale, across thousands of customers and hundreds of developers, they require infrastructure that was built for this model rather than adapted from it.

There are three primary structures for splitting revenue between a platform and its developers. Each has different implications for billing data requirements, invoice format, and settlement complexity.

Revenue Share (Percentage Split)

The platform retains a percentage of gross revenue from each transaction, and the developer receives the remainder. A common split for mature marketplaces is 70% to the developer, 30% to the platform, though this varies considerably by agent category and exclusivity.

Billing data required: Gross revenue per transaction, customer ID, agent ID, developer ID. The percentage split is stored in the developer’s contract record and applied at settlement time, not at invoice time. The customer-facing invoice shows the full agent service price; the revenue split is internal.

Settlement cadence: Monthly is standard at early stage. Weekly becomes necessary as developer payout volume grows and developers begin managing cash flow against their earnings.

Auditability requirement: Developers will dispute settlement calculations. The platform must be able to produce the raw transaction records that support each line of the settlement statement. A summary payout with no line-item support is a common source of developer disputes.

Fixed Commission (Per-Transaction Fee)

The platform charges a fixed dollar amount per transaction or per invocation regardless of transaction value. The developer receives the remainder.

Billing data required: Transaction count per developer per period, fixed fee schedule per agent category or tier.

Complexity: Low on the billing side. Higher on the developer relations side. Fixed commissions create pressure when transaction values vary widely: a high-value and a low-value agent pay the same absolute fee, which compresses net margin on the low-value end and can push high-value developers to negotiate custom rates.

Tiered Payout (Volume-Based Developer Share)

The developer’s revenue share percentage increases as their transaction volume grows. For example: 65% share at under $10K monthly volume, 72% at $10K to $50K, 78% above $50K.

Billing data required: Running monthly volume total per developer, tier thresholds from the developer contract, explicit tier transition rules.

Critical policy question: Does the higher rate apply retroactively to the full period when a threshold is crossed, or only to transactions after the crossing? That policy must be stated in the developer contract and enforced consistently in the billing system. Retroactive application creates settlement complexity; prospective application creates developer complaints. Neither is wrong, but inconsistent application creates both.

Complexity: High. Tier calculations, retroactivity rules, and mid-month tier visibility for high-volume developers require the billing system to maintain a running state for each developer’s period-to-date volume.

Model Comparison

Metering for AI agents differs from standard API metering in three ways that materially affect billing.

Composite Invocations

A single customer-facing request often generates many downstream agent calls. If an orchestration layer routes a request to four sub-agents, the billing system must record four distinct usage events, each attributed to the correct agent and developer. Aggregating into a single event attributed to the orchestration layer is faster to implement but makes developer settlement calculation impossible and makes dispute resolution unresolvable.

The event schema must carry enough information to reconstruct the full invocation graph if the customer or developer disputes the billing.

Asynchronous Completion

Many agent tasks do not complete synchronously. A customer submits a task, the agent runs for minutes or hours, and the result arrives later. The billing event should be generated at task completion (when value was delivered), not at submission (when the request was made). That timing difference affects how usage is aggregated into billing periods and how credits are deducted from prepaid balances. A task submitted on the last day of the month but completed on the first day of the next month belongs in the period of completion for billing purposes, unless the contract specifies otherwise.

Partial Billability

When an agent fails or produces a result the customer rejects, the platform must have a defined policy for what portion of the usage is billable. Some platforms bill for compute consumed regardless of outcome. Others bill only on successful completion. Either is defensible, but the policy must be explicit in customer agreements and enforced consistently in the billing system.

Required Event Schema

Every agentic billing event should carry the following fields to support multi-party attribution and downstream reconciliation:

For a detailed walkthrough of how usage events move through metering, rating, aggregation, and invoicing, see AI Billing for Usage-Based Products: Metering, Invoices, Credits, and Chargeback. Zuora’s usage-based billing infrastructure handles the metering and rating layer for this event data.

Tax in a marketplace creates two questions that do not arise in standard SaaS billing. Getting either one wrong creates liability that is expensive to unwind.

Is the Platform the Seller of Record?

The seller of record (SoR) is the entity legally responsible for the sale and for collecting and remitting applicable tax (VAT, GST, sales tax) to the relevant authority. In a marketplace, the platform can be the SoR (it sells to customers on behalf of developers) or a payment intermediary (developers sell directly to customers, and the platform handles payment processing only).

Most enterprise AI agent marketplace operators choose to be the SoR for two reasons. First, it simplifies the customer experience: one invoice, one tax treatment, one entity to hold accountable. Second, it reduces compliance risk from developers who may not manage their own tax obligations correctly in every jurisdiction where the platform operates.

The trade-off is that SoR status creates remittance obligations across every jurisdiction where the platform sells. SoR classification and its implications in each market should be confirmed with legal counsel, as rules differ materially between EU member states, US states, and non-Western markets.

Zuora’s e-invoicing and tax compliance automation handles tax calculation, application, and e-invoicing requirements across jurisdictions for platforms operating as the SoR.

How Are Developer Payouts Handled for Tax Reporting?

In the United States, a platform that pays a developer more than $600 in a calendar year must file a 1099-NEC. Different withholding and reporting rules apply under FATCA for developers who are not US persons, requiring W-8BEN or W-8BEN-E documentation at developer onboarding.

For international developer ecosystems, the platform must collect tax residency data from every developer before any payout is made, apply the correct withholding rate, and deduct that withholding from the settlement amount before disbursement.

The practical consequence: developer onboarding must include a tax classification step. Platforms that defer this to a post-launch manual process will find it unmanageable past a few dozen developers. The billing and payout system must store tax classification per developer and apply it automatically at settlement time.

Three scenarios generate refunds or disputes in an agent marketplace. Each flows through the revenue share differently, and each requires specific billing system capabilities to resolve correctly.

Scenario 1: Agent Fails to Complete a Task

The customer receives no value. Standard policy is a full refund of the charged amount. The credit memo is issued to the customer for the full invoice line amount. The developer’s settlement is reduced by the corresponding net payout amount. If the developer’s settlement for the period has already been paid, the platform may need to claw back the amount from the next settlement cycle.

Billing system requirement: The platform must be able to trace each customer-facing charge back to its originating event record, agent ID, and developer ID. Without that trace, the refund cannot reduce the correct developer’s settlement balance.

Scenario 2: Customer Disputes Quality of Output

The agent completed the task but the customer is dissatisfied with the result. This is a policy decision, not a billing system decision. The three standard approaches are full refund (high cost to developer relationship), partial refund (shared accountability), or no refund (usage-based principle: you pay for compute consumed, not for satisfaction). Whatever the policy, the billing system must support partial credit memo issuance against a specific invoice line item, with the partial amount flowing back through the revenue share to the developer’s settlement.

Scenario 3: Developer Disputes Platform Attribution

The developer believes the platform’s attribution of usage to their agent is incorrect, typically an over-attribution claim where they believe they have been charged back more than their agent actually consumed. Resolution requires the raw event log: the event_id records, the invocation graph, and the rated amounts at each step. This is why the event schema must be stored and queryable, not just aggregated into period totals. Period totals cannot resolve attribution disputes.

Settlement reporting is the process of calculating what each developer is owed at the end of each billing period, reconciling that against invoiced customer revenue, and generating the payout records that trigger actual payment. It is where billing complexity becomes finance complexity.

What a Settlement Statement Must Include

A developer settlement statement must show, for each developer, for each period:

• Gross customer revenue attributable to their agents
• Platform fee as a dollar amount (not just a percentage; dollar amounts are what developers verify against their own records)
• Tax amounts withheld, if applicable
• Credits or clawbacks from prior-period refunds
• Net payout amount
• Transaction-level detail or a downloadable transaction log supporting the gross revenue figure

The transaction-level detail is required in practice for any developer treating their marketplace earnings as business revenue. In our experience a summary-only statement generates disputes that grow with the payout size.

Reconciling Settlement Against Recognized Revenue

The settlement total for a period must reconcile against the revenue recognized from the same transactions. That reconciliation requires four figures:

1. Total customer invoiced amount for the period (sum of all agent service charges)
2. Total platform revenue (sum of all platform fee deductions across all developer settlements)
3. Total developer payouts (sum of all net developer amounts)
4. Total refunds and credits issued during the period

The sum of platform revenue plus total developer payouts plus tax collected plus net credits should equal total customer invoiced amount. Any difference is either an unreconciled credit, a refund not matched against a settlement, or a billing event that was rated but not invoiced.

Zuora’s revenue recognition software and revenue subledger infrastructure connect the customer billing side to the recognized revenue side, providing the reconciliation layer that finance teams need to close each period cleanly.

ERP and Accounts Payable Integration

Developer payouts are outbound payments, not accounting entries. They must integrate with the accounts payable system that executes the bank transfer or payment to the developer’s configured payout method. The settlement statement is the input to that AP process. Zuora’s Quote-to-Cash infrastructure connects billing data to downstream financial systems, including ERP integrations that route settlement outputs to accounts payable workflows.

The build-vs-buy question for marketplace billing is not primarily a technology question. It is a scope question.

What is feasible to build in-house: A simple revenue share on a single product type where all agents use the same pricing model and all developers have the same commission rate. If the developer count is under 20 and the pricing model is stable, a custom settlement calculation on top of a standard billing system is workable.

What breaks at scale: Multi-agent attribution breaks when invocation graphs become complex. Developer tax reporting breaks when the developer base spans multiple jurisdictions. Settlement reconciliation breaks when refunds, partial credits, and tier adjustments create exceptions the custom system was not designed to handle. Audit trails break when the raw event log was not designed for queryability from the start. The counterweight is implementation speed: quote-to-cash implementation can be compressed to weeks rather than quarters, which changes the build-versus-buy arithmetic more than licence cost does. See zuora.com/products/milo/.

The compounding cost of technical debt in billing systems is high. Marketplaces that build their own settlement logic often find it needs rebuilding as volume and jurisdiction spread grow, commonly within 18 to 24 months. The rebuild cost in engineering time, finance remediation of incorrect settlements, and developer trust repair almost always exceeds the initial cost of purpose-built infrastructure.

Zuora’s AI Monetization Suite and AI-powered billing and revenue platform were built to handle multi-party monetization at enterprise scale, including the marketplace scenarios covered in this guide. For companies in the architecture phase, the right question is not whether to use purpose-built infrastructure but which settlement mechanics to define before the first developer is onboarded.

AI agent marketplaces represent a new category of financial infrastructure problem. The revenue sharing, settlement, multi-party attribution, and developer tax reporting mechanics described in this guide do not exist in standard SaaS billing systems because those systems were not built for them. Companies that treat marketplace billing as an extension of their existing billing setup encounter the gap when developer disputes, tax misclassification, and settlement reconciliation errors begin accumulating.

The companies that get this right treat marketplace billing infrastructure as a product decision made before launch, not an engineering problem addressed after the first developer payout. The event schema, the settlement cadence, the SoR election, and the refund policy all need to be defined and tested before scale makes them expensive to change.

Book a demo with Zuora to see how the AI Monetization Suite applies to your specific marketplace model.