- An aws marketplace disbursement is a cash payout, not your booked revenue — AWS collects from the buyer, deducts a listing fee, and pays you on a schedule tied to when the buyer actually pays.
- The gross-to-net delta (buyer paid vs. you received) is expected: it is the listing fee plus any taxes AWS withholds. Treating that delta as a discrepancy wastes hours; treating a real timing or metering gap as “the fee” hides money.
- Three seller reports do the reconciliation work: the disbursement report, the collections/billing report, and the sales-and-usage report. Tie each disbursement line back to an agreement before you accept the number.
- A fixed monthly reconciliation routine — not an ad-hoc scramble at quarter close — catches the discrepancies while they are still one or two line items instead of a quarter’s worth of drift.
A buyer’s invoice says $120,000. The disbursement that lands in your bank two months later says $102,000. Nothing is broken — that is a 15% listing fee doing exactly what it is supposed to do. But if your finance team booked $120,000 as revenue and expected $120,000 in cash, you now have an $18,000 “variance” that someone will spend an afternoon chasing. Multiply that across every agreement, every partial payment, and every private offer with a non-standard fee, and you have the single most common source of month-end friction in a marketplace finance close. This is how an aws marketplace disbursement actually moves from buyer to bank, and the routine that reconciles it without the afternoon.
What a disbursement actually is (and is not)
Start with the vocabulary, because conflating two of these terms is where most reconciliation errors begin. A booking is the contract value when a buyer accepts an offer. Collection is AWS receiving cash from that buyer against their AWS bill. A disbursement is AWS paying you — after collection, after deducting its listing fee, on its own schedule. These are three different events, on three different dates, for three different amounts. Your accrual revenue follows the booking; your cash follows the disbursement; and the reconciliation lives in the gap between them.
The core mechanic is that AWS is the merchant of record. The buyer pays AWS as part of their consolidated AWS invoice, AWS holds those funds, and only then does it pass your share along. That means a signed agreement worth six figures can sit for weeks with a disbursement of $0 — not because anything failed, but because the buyer has not paid AWS yet. If you have ever worked through the mechanics of the AWS Marketplace Management Portal, you have seen the agreement appear instantly while the money takes its time. That lag is the feature, not the bug.
“What did we book?” and “What were we paid?” are different questions with different owners and different dates. Revenue recognition answers the first; disbursement reconciliation answers the second. If your team uses one number to answer both, the variance you cannot explain is almost always a timing difference between them, not lost money. For the accrual side, see our cloud marketplace revenue recognition guide.
The path a dollar takes: collection to bank
Follow a single agreement end to end and the four steps are always the same, even though the amounts and dates shift. Understanding the sequence tells you exactly which report to open when a number looks wrong.
Buyer is invoiced
The charge appears on the buyer’s monthly AWS bill — the committed contract amount, metered usage, or both. This is when AWS collects, but the timing follows the buyer’s billing cycle, not your close.
Buyer pays AWS
The buyer settles their AWS invoice on their own payment terms — often net-30 or later. Nothing disburses to you until this happens. A slow-paying buyer delays your cash even though your booking closed on day one.
AWS deducts the listing fee
AWS subtracts its listing fee (and withholds any applicable taxes) from the collected amount. What remains is your net disbursement. The fee percentage can vary by program — standard listings, CPPO channel deals, and enterprise-negotiated rates are not all the same.
AWS disburses to your bank
On the next disbursement window after funds clear, AWS pays the net to your registered bank account and records the line in the disbursement report. This is the number that should tie back to the original agreement — through the fee, minus timing.
The two places this sequence bites are step 2 and step 3. Step 2 introduces timing risk: your accrual booking and your cash disbursement can land in different months or even different quarters, and if you do not model that lag you will forecast cash you have not been paid. Step 3 introduces amount risk: if you assume a flat listing fee across every deal, a CPPO channel offer or a renegotiated enterprise rate will produce a net that does not match your expectation — and you will misread a correct fee as a discrepancy. If the fee side is fuzzy, the marketplace fees breakdown across AWS, Azure, and GCP lays out how each program deducts.
The disbursement report tells you what you were paid. It does not tell you what you were owed. Only tying each line back to its agreement does that — and that tie-back is the entire job.
The three reports, and what each one is for
AWS exposes several seller reports, but reconciliation leans on three. Using the wrong one for a given question is why teams conclude “the reports don’t match” when in fact they are measuring different events.
| Report | Answers the question | Keyed on |
|---|---|---|
| Sales & usage | What did buyers get charged, and for which agreement and dimension? | Billing event / agreement ID |
| Collections & billing | What has AWS actually collected from buyers so far? | Invoice / payment status |
| Disbursement | What did AWS pay us, net of fees, and on what date? | Disbursement ID / bank deposit |
The reconciliation is the join across these three: a disbursement line traces back to one or more collected invoices, each of which traces back to a sales-and-usage record tied to an agreement. When the chain is intact, gross-minus-fee equals net and you move on. When it breaks — a collected invoice with no matching disbursement after the window should have cleared, or a disbursement whose net is smaller than the fee alone would explain — that is the discrepancy worth investigating.
The dangerous case is a real gap wearing the costume of a normal deduction. If usage metering under-reported for a month, the buyer was charged less, AWS collected less, and your disbursement is correspondingly smaller — but nothing in the disbursement report flags why. It looks like a slightly larger fee. The only way to catch it is to reconcile the disbursement back to expected usage, not to accept the net at face value. A missing metering record never announces itself in the payout line.
A monthly reconciliation routine that scales
Reconciliation fails when it is event-driven — someone reconciles only when finance asks, which means only after a number is already wrong in a report someone else has seen. Make it calendar-driven instead. The routine below takes a focused block once a month and keeps the discrepancy surface small.
- Export the current disbursement report and the collections report for the same period on a fixed calendar date
- For every disbursement line, confirm the gross-to-net delta matches the expected listing fee for that deal type (standard vs. CPPO vs. negotiated), not a single assumed rate
- Flag any collected invoice with no disbursement after its window should have cleared — that is stuck cash, not lost cash, but it belongs on a watchlist
- Reconcile disbursed usage revenue against your own metering emitter’s records to catch under-reported usage that looks like a larger fee
- Tie each net disbursement to the originating agreement ID so accrual bookings and cash can be aged against each other
- Log unexplained variances above a materiality threshold and carry them forward; most resolve next cycle as timing, and the ones that don’t are your real exceptions
Consider a mid-market data-infrastructure ISV running two AWS listings, one standard and one sold largely through channel partners on CPPO terms. Their finance team reconciled against a single assumed listing fee. For a full quarter, every channel disbursement came in “short” against that assumption, generating a variance line each month that someone re-investigated from scratch and eventually wrote off as “marketplace fees.” The nets were correct the entire time — CPPO simply carries a different deduction. Once they keyed the reconciliation to deal type, the phantom variance disappeared and the one genuinely stuck invoice they had been ignoring finally stood out.
Now take a typical usage-heavy ISV with a Pay-As-You-Go dimension. Their meter emitter silently dropped records for four days mid-month. Buyers were under-charged, AWS collected less, and the disbursement arrived smaller — roughly the size a slightly higher fee would produce. Because their routine reconciled the disbursement against expected metered usage rather than accepting the net, the four-day gap surfaced as a specific, dated shortfall instead of vanishing into “fees.” The money for those four days was gone either way — AWS meters what it receives — but they caught it in the same month and fixed the emitter before it recurred.
Build your cash forecast off the disbursement schedule, not the booking date. A booking closed in March against a net-30 buyer with a disbursement window on top can realistically land as cash in May. Finance teams that forecast cash on bookings chronically over-predict near-term inflows and then treat the shortfall as a reconciliation problem. It isn’t — it’s the payout timeline behaving normally. Model it once and stop re-litigating it every month.
When to stop doing this by hand
A single-listing seller with a handful of agreements can run this routine in a spreadsheet, and should — the discipline matters more than the tooling at that scale. The math changes when you add clouds, channel programs, and volume. Every new listing multiplies the reports; every CPPO partner adds a fee variant; every additional cloud adds a payout schedule with different windows and different report formats. The join across sales, collections, and disbursement that one analyst can hold in their head for one listing becomes a standing monthly project across three.
That is the point where reconciliation stops being a task and becomes an operational function — and the point where an ISV should decide whether to staff it or automate it. Tying every disbursement line back to its agreement, normalizing fee variants across programs, and aging cash against accrual bookings is exactly the kind of work that rewards a system built for it. Automatum’s platform reconciles disbursements against agreements and metering across AWS, Azure, and GCP so the monthly pass is a review, not a rebuild. If you just want to sanity-check the fee side of a specific deal first, the marketplace fee calculator models the gross-to-net delta in a couple of minutes.
Disbursement reconciliation is a spreadsheet — until you have three clouds and a dozen channel partners.
Automatum ties every disbursement back to its agreement, normalizes listing-fee variants across standard, CPPO, and negotiated deals, and ages cash against your accrual bookings — across AWS, Azure, and GCP. See how it fits your finance close on the platform overview.
See Automatum in Action →Frequently Asked Questions
Common questions about AWS Marketplace disbursements and reconciliation.
What is an AWS Marketplace disbursement?
An aws marketplace disbursement is the cash AWS pays a seller after collecting from the buyer and deducting its listing fee. It is not the same as booked revenue: the booking happens when a buyer accepts an offer, but the disbursement happens only after the buyer pays AWS and a disbursement window clears, net of fees and any withheld taxes.
Why is my disbursement smaller than the buyer was charged?
The gross-to-net delta is normally the AWS listing fee, plus any taxes AWS withholds. The fee percentage varies by program — standard listings, CPPO channel offers, and enterprise-negotiated deals can each deduct differently. The delta only signals a problem if it is larger than the expected fee for that deal type, which usually points to under-reported usage rather than the fee itself.
How long after a sale does AWS disburse?
AWS disburses only after the buyer pays their AWS invoice and the disbursement window clears. Because buyers often pay on net-30 or longer terms, cash can land a month or more after the booking closed. Forecast cash off the disbursement schedule rather than the booking date, or you will over-predict near-term inflows.
Which seller reports do I use to reconcile disbursements?
Three: the sales-and-usage report (what buyers were charged, by agreement), the collections report (what AWS has actually collected), and the disbursement report (what AWS paid you, net of fees). Reconciliation is the join across all three — tracing each net disbursement back through a collected invoice to a sales-and-usage record tied to a specific agreement.
Keep tightening your marketplace finance motion
Guides on the portal, revenue recognition, and how fees deduct across clouds.
