Metering is the least glamorous part of selling through a cloud marketplace and the part most likely to cost you money. Nothing errors. No alert fires. You simply get paid less than you earned, and because the gap is distributed across hundreds of small discrepancies, nobody notices until someone finally reconciles a quarter properly.
Here is where it goes wrong.
Entitlement is not the same as purchase
The first distinction to get straight: what a customer bought and what they are allowed to use are two separate records, and only one of them lives in your system.
When someone purchases your SaaS product, AWS sends them to a registration URL you host with a token. You resolve that token to get the customer identity and their entitlement — which product, which dimensions, what quantity, what term. Then you provision accordingly.
Three things make this harder than it sounds:
- Entitlements change mid-term. Upgrades, seat changes, additional dimensions. Your provisioning has to react to a change you did not initiate.
- Cancellation is a state you have to handle. An agreement that ends while your system still has the customer provisioned is a customer getting your product for free.
- The same human may appear twice. A customer who buys again, or buys a second product, is a new entitlement against an existing account in your system. Getting this mapping wrong creates duplicate tenants and support confusion.
Reporting usage
If your pricing has any metered component, you report consumption to AWS and AWS bills it. The obligation is entirely yours, and the rule is unforgiving: what you do not report is not billed.
The failure modes are consistent across every implementation I have seen:
- Missed reporting windows. Usage has a deadline. Late records may not bill at all, which means an outage in your metering pipeline is directly a revenue loss, not just an operational incident.
- Idempotency failures. Retries are necessary and retries that double-count are a defect. Over-reporting is as bad as under-reporting, because it produces customer billing disputes that cost more than the revenue.
- Period boundary and time zone errors. A usage record attributed to the wrong period lands in the wrong invoice. Month-end is where this shows up, and it is always a time zone assumption somewhere.
- Dimension drift. Your product adds a feature, your listing’s dimensions do not change, and usage of the new feature is reported against the wrong dimension or not at all.
Treat your metering pipeline with the same seriousness as your billing system, because it is your billing system.
Where money actually leaks
In rough order of how much they cost:
- Unreported usage from pipeline gaps nobody monitored.
- Trials that never converted — the customer moved to paid, your system kept treating them as a trial, and nothing was metered.
- Cancelled agreements still provisioned — free service, indefinitely.
- Dimension mismatches between your product and your listing.
- Rounding and unit confusion — reporting in the wrong unit is a quiet multiplier in either direction.
None of these appear on a dashboard. All of them appear in a reconciliation.
Reconciliation, and why aggregate totals hide the problem
Here is the test. Take last month’s AWS disbursement report. Can you explain, per customer, why that number is what it is?
Most companies can explain the total to within a few percent and cannot explain any individual line. That is not reconciliation, it is a plausibility check — and a few percent across a growing book is real money.
Proper reconciliation means matching, per customer and per period:
- What you provisioned
- What you metered
- What AWS billed
- What AWS disbursed
- What your own ledger says
Each step can diverge from the next, and each divergence has a different cause. Aggregate totals let offsetting errors cancel out, which is why they feel reassuring and tell you nothing.
AWS made this materially easier this month. The new seller data feed for customer agreements reports agreement-level detail, which is the join key you need to connect a disbursement back to a specific customer and term. If your reconciliation has been working from summary reports, this is the upgrade path.
Multiply by three
Everything above describes one marketplace. If you sell on more than one cloud, you have the same problem three times with three different APIs, three sets of units and deadlines, and three report formats that do not share a schema.
Three independent paths where revenue can silently go missing, and three reconciliations that have to agree with one general ledger. This is the point at which “we’ll handle it with a script” stops being true.
What a working setup looks like
- Entitlement changes handled as events, not as a nightly reconciliation job
- Metering with idempotency keys and a monitored, alerting pipeline
- Per-customer reconciliation, automated, with a variance report somebody reads
- Cancellation wired to deprovisioning
- One data model across clouds rather than one per cloud
That last point is the reason CloudX’s marketplace platform exists — metering and revenue behind a single interface, with per-customer revenue reconciliation and agreements across clouds in one record. Integrations and API covers getting that data into your own systems, and the pricing model choices that create the metering obligation in the first place are in what AWS Marketplace actually is.
The summary
Metering is revenue-critical infrastructure that most teams build once and then stop watching. Report on time, make retries idempotent, wire cancellation to deprovisioning, and reconcile per customer rather than in aggregate. The money you are losing is not in the total — it is in the lines you have never looked at.