When a platform resells AI agent capacity — charging downstream customers and passing earnings to the partners that built those agents — it faces a money problem that runs in both directions. The inbound side (subscriptions, invoices, usage charges) is well understood. The outbound side, tracking what each agent has earned, computing platform fees, and transferring net proceeds to the right party, is far less discussed and far more likely to go wrong. Revenue monitoring covers this second side: visibility into earnings, recurring revenue metrics, top customers, and a payout flow that settles balances through a managed transfer service. For the FinOps practices that govern the inbound spend side of this picture, see FinOps for AI agents: controlling token and tool costs.
The two-sided ledger and earnings attribution
Most billing discussions center on collecting money from customers. For a marketplace or reseller platform, that is only half the ledger. An organization that deploys agents on your platform generates revenue when its agents complete tasks, answer queries, or fulfill automations. That revenue belongs partly to the deploying organization and partly to the platform that hosts, routes, and governs the agents.
Getting this accounting right matters for several reasons. Partners need accurate, auditable statements of what they have earned. The platform needs a clean separation between gross revenue (what customers paid) and net revenue (what remains after paying out partners). Any payout flow that does not enforce balance gates and proper ledger entries is an invitation to over-disbursement — paying out more than has actually been collected. For context on how the inbound side of this ledger works, see subscriptions, invoices, and contracts for AI platforms.
Revenue monitoring answers the question: for each organization, how much has been earned, by which agents, in which periods, and how much can be withdrawn right now?
Every time an agent generates revenue, that event is recorded as an earning. Each record captures the gross amount and the platform fee, with the net amount being what flows to the deploying organization. The split is computed in integer cents to avoid floating-point rounding errors that compound over thousands of transactions.
Idempotency on earning records matters here. If a downstream event is delivered more than once — a common occurrence with any webhook-driven billing system — recording the same earning twice would overstate the balance. The correct design assigns a transaction identifier to each earning event and enforces uniqueness at the database level, so duplicate deliveries are silently ignored rather than double-counted.
This append-only ledger is the foundation on which all revenue metrics and payout calculations are built.
MRR, ARR, and what the metrics actually measure
Monthly Recurring Revenue and Annual Run Rate are the two metrics most commonly requested by finance teams and investors. They mean something specific in a pure subscription business: contracted, predictable recurring revenue. In an agent marketplace where revenue is usage-based, the meaning shifts.
A sensible proxy for MRR in a usage-based model is the total earnings in the current calendar month. ARR is then that figure annualized. These are not true recurring revenue figures in the subscription sense — usage can spike or drop — but they give a directionally correct picture of scale and trajectory.
Understanding the approximation is important. If a partner's agents had an unusually active month due to a one-off campaign, the MRR figure for that period will be elevated. Trend analysis across several months is the appropriate way to use usage-based revenue metrics, not point-in-time readings.
Praesidia's performance view exposes both MRR and ARR alongside the earnings time series, so spikes and trends are visible in context rather than buried in a single aggregate number.
Customer visibility: who is driving revenue
Aggregate revenue figures answer "how much." Customer breakdowns answer "from whom." For a marketplace, knowing which downstream customers account for the largest share of agent usage matters: large customers represent concentration risk and are the most sensitive to disruptions.
The top customers view surfaces the highest-spending accounts within an organization's scope, drawing from the same earnings ledger. It is organization-scoped by default, so a partner sees only their own customer base — they cannot access revenue data from other deploying organizations on the platform.
The available balance and its calculation
Before a payout can be requested, the system must know how much is actually available. The available balance is not simply the sum of all earnings. It is earnings minus payouts that have already been initiated — specifically, payouts that have not failed. A payout that is requested but still processing represents committed funds; a payout that failed is returned to the available balance.
Computing this correctly requires reading earnings and payouts under a consistent snapshot so that concurrent requests do not both see the same available balance and each race to claim it. A balance gate that locks the organization's row before computing and debiting prevents two simultaneous payout requests from creating an overdraft. Praesidia enforces this gate atomically, so the balance check and the ledger debit are inseparable — no concurrent request can interleave between them. For how spend visibility feeds into proactive budget management, see credits and cost monitoring for agent spend.
Requesting a payout
Before a payout can be initiated, the organization must link a Stripe Connect account. Stripe Connect requires each payee to complete an onboarding flow that collects identity and banking information and satisfies Know Your Customer requirements — handled by Stripe, not the platform, keeping sensitive financial data out of the application's database. The platform generates an onboarding link, redirects the partner to it, and confirms completion via webhook. If onboarding is incomplete, payout requests are blocked before any Stripe API call, preventing partial transfers that would require manual reconciliation.
Once a Connect account is linked, an organization owner or billing admin can request a payout of any amount up to the available balance. The request goes through a unified payout path that:
- Confirms the requested amount does not exceed the available balance.
- Records the payout in a ledger with an initial status of requested.
- Initiates the Stripe Connect transfer.
- Updates the payout record as the transfer moves through processing to completed or failed.
The ledger is append-only. Each state transition is a new record rather than an in-place update, so the full history of every payout is preserved. If a transfer fails, the failure reason is recorded and the amount is effectively returned to the available balance for the next payout calculation.
The payout status sequence — requested, processing, completed, failed, cancelled — gives the partner full visibility into where their funds are in the transfer pipeline without requiring them to log into Stripe directly.
Payout history and reconciliation
Every payout is visible in a paginated history ordered by date, showing amount, method, status, and — for failures — the reason. For partners, this is the authoritative bookkeeping record. For platform operators, it is the audit surface for dispute resolution.
The combination of the earnings ledger and the payout ledger means the available balance can be reconstructed from first principles at any point: sum all earnings, subtract all non-failed payouts, and the result is the withdrawable balance. That auditability is a property of the append-only design — it cannot be achieved when records are updated in place.
Scoping and access control
Revenue data is sensitive. The earnings and payout surfaces require the organization to have the agent monetization feature enabled, and access within an organization is restricted to owners and billing administrators. Ordinary members cannot view revenue figures or request payouts.
Critically, all queries are scoped to the requesting organization. A partner cannot query earnings or customer data for any organization other than their own. Cross-tenant leakage at the revenue layer would be a serious incident — it would expose not just financial figures but the identities and spending patterns of another organization's customer base. For a deeper look at how tenant isolation is enforced across the platform, see tenant isolation and row-level security.
This scoping is enforced structurally, so the restriction holds regardless of how the API is called.
Common questions
How is the available balance kept accurate when multiple payout requests arrive simultaneously?
The balance check and the ledger debit are performed atomically, so concurrent requests serialize rather than race. Each request operates against the fully committed state of the ledger, preventing double-disbursement regardless of how many simultaneous requests arrive.
Does the MRR figure reflect subscription revenue or usage?
For agent marketplaces, MRR is computed as total earnings in the current calendar month. This is a usage-based proxy, not a contracted recurring revenue figure. It is accurate for trending and scale visibility, but should not be treated as committed revenue in the way that a subscription MRR would be. Viewing the figure alongside the time-series chart on the performance page gives the most useful context.
What happens to a payout if the Stripe Connect transfer fails?
The payout record is updated to a failed status and the failure reason is recorded. Because the available balance calculation excludes failed payouts, the amount becomes available again for a subsequent payout request. No manual reconciliation step is required — the ledger self-corrects when a failure is recorded. Partners can see the failure reason in their payout history and address any underlying Stripe Connect issues before requesting again.
How should I handle tax obligations on partner payouts? Tax handling for marketplace payouts depends on jurisdiction and whether partners are individuals or legal entities. Stripe Connect's tax reporting features integrate with the same Connect account used for transfers, so the onboarding flow that collects KYC information also captures the data needed for annual reporting. The platform does not compute or withhold tax — that responsibility falls to the operator — but the complete earnings ledger provides the transaction-level detail needed to fulfill reporting obligations. For how the broader billing infrastructure supports accurate financial records, see reliable billing with Stripe webhooks and dunning.
For more on how the inbound billing side works — subscriptions, invoices, and metered usage — see subscriptions, invoices, and contracts for AI platforms.