Marketplace Billing & Revenue Operations.

What makes marketplace billing different

In direct sales, you invoice the customer, you chase payment, you recognize revenue when cash clears (or earlier, under ASC 606). The flow is: contract → invoice → collection → recognition.

In marketplace sales, the cloud provider becomes the merchant of record. They invoice the customer against an existing cloud contract, they collect payment, they deduct the marketplace fee, and they disburse net revenue to you on a cadence they control. The flow is: contract → marketplace entitlement → metered usage → cloud invoice → cloud collection → net disbursement → your recognition.

This changes three things for finance teams:

• Cash timing shifts — you're paid on the provider's payout schedule, after it bills the customer, not on the date the deal closes
• Revenue visibility becomes indirect — you see disbursements, not customer invoices
• Reconciliation becomes critical — the gap between what your product metered and what the cloud disbursed is where revenue gets lost

Every finance team building marketplace billing infrastructure has to solve for these three shifts explicitly.

The transaction flow, end to end

A typical marketplace transaction follows this lifecycle:

1. Private offer sent — custom-priced agreement delivered to the buyer's cloud account
2. Offer accepted — buyer accepts in their marketplace console; entitlement is created
3. Product provisioned — your SaaS account gets created or associated, typically via API
4. Usage occurs — customer uses the product; for metered deals, your product reports consumption
5. Cloud invoices customer — the marketplace charges appear on the customer's regular cloud bill
6. Customer pays cloud — payment flows through their existing cloud contract
7. Cloud deducts fee — the provider's marketplace fee (3% on a standard SaaS deal, lower on large private offers and qualifying renewals) is netted
8. Cloud disburses to you — net revenue arrives on the provider's payout schedule (see the table below)
9. You reconcile — match disbursement against expected revenue; recognize accordingly

Each stage can fail or drift. A Cloud GTM platform handles the engineering and reporting layer so finance has clean disbursement data and metered usage both tied to CRM opportunities.

Disbursement timing by cloud

Cash-flow modeling needs to follow these schedules: cash arrives after the provider has billed the customer — and on AWS, only once the customer has paid — not on the date the deal closes. For high-growth ISVs, this shifts working-capital requirements meaningfully.

Fee netting and reporting

Each cloud deducts its marketplace fee from disbursements:

• AWS — public offers: 3% for SaaS, 20% for server products (AMI, container, machine learning). Private offers: 3% under $1M total contract value, 2% from $1M, 1.5% from $10M and on all renewals. Channel partner private offers add 0.5%
• Microsoft — 3% store service fee on transact offers, discounted 50% on qualifying private offer renewals
• Google Cloud — 3% on standard offers and new private offers under $1M, 2% from $1M, 1.5% from $10M and on qualifying channel shifts, migrations and native renewals

Two accounting questions finance needs to answer:

1. Gross vs net revenue recognition — recognize the full customer-paid amount (gross) with the fee as a cost line, or recognize only net disbursement? Most GAAP-aligned ISVs recognize gross. Under ASC 606, this depends on principal vs agent analysis — consult your auditor.
2. Fee variability — fees vary by deal type and total contract value, and on AWS also by deployment method, channel partner offers and buyer region. Modeling the expected fee per deal is important for forecasting.

Revenue recognition policy for marketplace deals

Establish a dedicated revenue recognition policy for marketplace transactions before volume forces ad-hoc decisions.

Key policy elements:

• Trigger for recognition — service delivery (usage, time), not cash receipt. A paid marketplace annual subscription recognizes ratably over the service period.
• Timing of recognition start — typically offer-acceptance date (when customer contractually commits) or provisioning date (when service begins), depending on performance obligation wording.
• Gross vs net — documented with principal vs agent reasoning per ASC 606.
• Fee accounting — marketplace fees as cost of revenue (gross recognition) or netted against revenue (net recognition).
• Refunds and cancellations — how mid-term cancellations unwind; how partial refunds reconcile with already-recognized revenue.
• Multi-year deals — treatment of upfront vs ratable payment schedules, deferred revenue balances.

Document the policy, get auditor sign-off, and train RevOps + finance on execution.

Metering integration — the hidden risk

For usage-based products, metering is where revenue either lands safely or gets lost forever.

Each cloud has its own metering API:

• AWS Marketplace Metering Service — hourly usage submission with retries; customer billed based on your reports
• Azure Marketplace Metered Billing API — usage events submitted within 24 hours; stricter dimension governance
• GCP Service Control / Procurement API — usage reported per Service Control quota

Three architectural requirements for metering reliability:

1. Durable event pipeline — usage events go to a durable queue before submission, not directly to the cloud API. If the API is down, events don't drop.
2. Retries with exponential backoff — transient API failures should retry automatically. Persistent failures should alert on-call.
3. Monitoring and dead-letter queues — submission failures route to DLQ. Monitor DLQ depth and investigate non-zero values fast.

The cost of a silent metering failure is permanent lost revenue. This is not a layer to cut corners on. Suger's metering infrastructure handles all three clouds with built-in durability, retries, and reconciliation.

The reconciliation workflow

Reconciliation compares three data sources each month:

1. Metered usage — what your product reported to the cloud's metering API
2. Cloud disbursement report — what the cloud actually billed the customer and paid out to you
3. CRM contract data — what the original private offer or subscription terms said should happen

Mismatches fall into three categories:

• Metering vs disbursement — you reported X, cloud billed Y. Root cause: delayed usage events, cloud-side timing differences, or genuine data loss.
• Disbursement vs contract — cloud paid different amount than contract should have generated. Root cause: rate changes, customer refunds, cross-period adjustments.
• Contract vs metering — contract says one rate, metered usage shows another. Root cause: pricing misconfiguration, wrong SKU selected, plan mismatch.

Investigate every mismatch. Most small drifts compound — ignoring $500 discrepancies for 12 months turns into $6K+ unrecovered revenue.

Finance team setup for marketplace billing

At $100K marketplace ARR, one RevOps person can manage reconciliation manually. At $1M+, specialization becomes necessary.

Typical ownership model at scale:

• RevOps / Deal Desk — owns the reconciliation workflow, CRM contract data, and private offer configuration
• Finance (Controller) — owns the revenue recognition policy, GL postings, and monthly/quarterly close
• Engineering — owns metering pipeline reliability, monitoring, and cloud API integrations
• Marketplace Operations (at scale) — a dedicated role that sits between RevOps and Finance, managing day-to-day disbursement tracking and multi-cloud reconciliation

Without clear ownership, issues fall through the cracks. Name a DRI for each function.

Common billing mistakes

1. No dedicated rev rec policy

Finance treats marketplace the same as direct sales, misses principal/agent considerations, and gets audit findings later.

2. Metering without monitoring

Silent failures accumulate unrecoverable revenue loss. Instrument first, launch second.

3. Ignoring disbursement lag in cash-flow models

Treating marketplace cash as if it arrived on deal-close date breaks working capital planning.

4. Reconciliation only at year-end

Year-end reconciliation of 12 months of discrepancies across three clouds is a nightmare. Do it monthly.

5. Fragmented data across clouds

Manually aggregating AWS, Azure, and GCP disbursement reports in spreadsheets doesn't scale as deal volume grows. Use a unified platform.

Frequently asked questions