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 45-60 days after the customer pays the cloud
• 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 — 3% marketplace fee (up to 5% on some AWS deals) is netted
8. Cloud disburses to you — net revenue arrives on a monthly cycle, typically 45-60 days after customer billing
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 reflect this lag. A marketplace deal closed in January with annual billing doesn't produce cash until March (AWS) or later. For high-growth ISVs, this shifts working-capital requirements meaningfully.

Fee netting and reporting

Each cloud deducts its marketplace fee from disbursements:

• AWS — 3% base, up to 5% on some categories. ISV Accelerate qualifying deals drop to 1.5%
• Azure — 3% on Transact offers
• GCP — 3% base; Premier tier can qualify for reduced fees on co-sold deals

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 — on AWS, fees vary by category and deal type. Modeling expected fees per deal (based on deal type, co-sell status, tier) 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 past 50 deals. Use a unified platform.

Frequently asked questions