Marketplace Usage Correction: What Each Cloud Allows

Marketplace usage correction is what a seller does after a cloud marketplace accepts more usage than the buyer should pay for. AWS, Microsoft and Google Cloud offer no self-service way to retract an accepted record, so the correction is a credit against the buyer’s later usage before the bill, or the marketplace’s own route after it.

---

Say a deploy ships a unit bug that multiplies one buyer’s API calls by ten. For six hours every record is well formed, every record comes back accepted, and nothing alerts, because nothing failed. The marketplace will bill what it accepted.

Most metering advice covers records the marketplace refuses, where the response tells you whether to fix rejected usage records or retry them. An accepted record is the opposite problem: on AWS and Microsoft you can’t resend it smaller, or send a negative one to cancel it out.

This post covers only that case: SaaS usage the marketplace accepted that was wrong, cloud by cloud, before and after the bill.

What is marketplace usage correction?

Marketplace usage correction is making a buyer whole after a cloud marketplace has accepted over-reported usage. A marketplace checks that a record is well formed and on time, not that its quantity is true, so an accepted record is billable whatever the number says.

That makes acceptance the dividing line. A rejected record never bills. An accepted one does, and on AWS and Microsoft it can’t be replaced for that hour, so the correction has to happen elsewhere: on the buyer’s later usage, or on the invoice once it’s issued.

How does wrong usage get accepted?

Through records that are valid in every field except the quantity. Four patterns to check first, two of which the providers’ own documentation warns about:

• A unit or multiplier error. The product counts megabytes and the dimension is priced per gigabyte, or a conversion multiplier doesn’t match the dimension’s price. Every record passes validation.
• A replay stamped into a new hour. AWS de-duplicates identical usage records “to prevent double charges.” A replay that stamps the same usage into a different hour is a different record, and it can bill a second time.
• Usage the plan already includes. Microsoft tells publishers to “only send usage events to Microsoft for the usage that is above the base fee.” Emit from the first unit and the buyer pays for quantity their plan already covers.
• Two identities during a migration. For sellers moving AWS metering to Concurrent Agreements, AWS warns: “Sending metering records with both ProductCode and LicenseArn for the same customer within the same hour will result in duplicate billing.”

Can you send a negative or corrected usage record?

Not on AWS or Microsoft. AWS sets a minimum usage quantity of 0, Microsoft rejects any quantity “lower or equal to 0,” and neither accepts a replacement record for an hour it has already accepted. Google Cloud’s partner documentation describes no way to correct or retract a usage report.

	AWS Marketplace	Microsoft Marketplace	Google Cloud Marketplace
Negative quantity	No: Quantity has a minimum of 0	No: InvalidQuantity at 0 or below	Not documented
Replace an hour already reported	No: a different quantity for the same customer, dimension and time returns DuplicateRecord and isn’t honored	No: one event per resource, dimension and hour; a second returns 409 Duplicate	Not documented
Reporting window	Under 24 hours; last month’s usage until 06:00 UTC on the 1st	The past 24 hours	Within one hour; month-end usage by 1 AM Pacific the next day
Who refunds metered charges	You, with a billing adjustment on the issued invoice; AWS may also refund metering errors itself	Not granted: “Refunds aren’t granted for metered usage”	Google, on a refund request you file
Your lever	Usage credit before the bill; a self-service billing adjustment after	Usage credit, plus a Partner Center support ticket for a “wrong usage event”	Usage credit before the bill; a refund request in Partner Support Desk after

The second row decides everything else. AWS put it plainly in September 2026: after it’s submitted, “a record for a customer, dimension, and hour can’t be amended.” The same guidance is to aggregate each hour’s usage and submit it after the hour has completed, and that gap is where a sanity check on the quantity belongs. Once a record is accepted, there is nothing left to validate.

How do you correct usage before the bill?

Credit it against the buyer’s later usage. Usage credit is a dollar allowance on the buyer’s entitlement that is spent against their metered usage before that usage is billed, so the marketplace is simply sent less. It is the one correction that works the same way on every cloud, because it changes only what you report next.

Timing decides how clean it is. AWS’s monthly usage invoices bill the previous calendar month, Microsoft bills overage on the next billing cycle, and Google’s month-end cutoff is 1 AM Pacific on the 1st, so an over-report and its credit can fall in the same period. If the buyer’s later usage in that period covers the credit, the invoice comes out at what they actually used.

How Suger applies usage credit

In Suger you add usage credit to an entitlement from the Console or with the addEntitlementCredit API. Four rules decide whether it does what you intend:

• It’s spent first. Suger offsets each incoming usage record against credit, then against the entitlement’s commit, then against any included quantity.
• It only reaches metered usage. On an entitlement with no usage-based metric, credit has no effect.
• It only goes up. Amounts must be positive, and a credit can’t be decreased or reverted once added. A wrong amount needs Suger support.
• One credit source per buyer. If your metering or billing service also issues credits for the same usage, adding Suger credit on top can credit the buyer twice.

An illustrative example: the bug reported 50,000 calls an hour for Globex instead of 5,000, for six hours, on a dimension Globex pays $0.01 per call for. That is 270,000 calls too many, or $2,700 at Globex’s price. Add $2,700 of usage credit to Globex’s entitlement and its next $2,700 of metered usage is absorbed instead of billed. Price the credit at the buyer’s own rate, not list: the credit is in dollars, and a private offer can set its own per-unit price.

What the Chargebee usage sync does on its own

Suger’s Chargebee integration applies the same rule automatically. Every hour it reports the overage Chargebee has priced, then settles each billing window against its invoice once the window closes. An amount already reported can’t be pulled back from the marketplace, so if the invoice’s metered line, net of Chargebee discounts, comes to less than Suger reported, Suger adds the difference to the entitlement as credit, and if the invoice is voided after Suger reported its window, it credits the whole reported amount. The credit shows in the entitlement term’s Credit and Used Credit fields, and one rule follows for your team: don’t also add credit by hand for the same discount or voided invoice, or the buyer is credited twice.

How do you correct usage after the bill?

Through the marketplace, and each one handles it differently: AWS lets you adjust the invoice yourself, Microsoft grants no refunds for metered usage, and Google refunds on a request it verifies. For the identifiers and evidence each route asks for, see what each cloud requires for a marketplace credit request.

AWS: adjust the invoice. The seller of record can apply a billing adjustment to the invoice from the Agreements page in AWS Partner Central, or through the Billing Adjustments API. On an unpaid invoice it comes off the amount due; on a paid one it is applied “as either credit memos or cash refunds.” It is irreversible once processed, and on a Channel Partner Private Offer only the channel partner can submit it.

AWS also has a policy of its own. For products metered through its Metering Service, “AWS can issue refunds on your behalf for software charges resulting from software metering errors,” and where errors are common across buyers, AWS “reserves the right to determine an appropriate refund for each buyer.” That is a term you accept by using the Metering Service, not a lever you pull, and a reason to have your own per-buyer numbers ready when an error spans many buyers.

Microsoft: open a ticket, and don’t promise a refund. Microsoft’s publisher FAQ is unambiguous: “Refunds aren’t granted for metered usage,” and it names metered billing for SaaS and Azure Apps. Its metered billing guide lists “an error or bug on your side (ex. wrong usage event)” among the reasons to open a Partner Center support ticket, but neither page says what a ticket can reverse. Open one, and make the buyer whole with usage credit unless Microsoft corrects the charge itself. Not both.

Google Cloud: request the refund. File a refund request through Partner Support Desk, naming the customer and the dates. Google “verifies what we actually charged your customer for those dates” and tells you the credit amount, then offsets it against your future payments.

Should you credit the buyer or refund them?

Credit them when the invoice hasn’t gone out and they’ll keep using the product on the same entitlement. Use the marketplace’s route when the invoice is out and the buyer wants money back, or when too little usage is left for a credit to be spent against.

Situation	Remedy	Why
The period hasn’t been invoiced	Usage credit for the over-reported amount	Later usage absorbs it, with no ticket and no invoice adjustment
Invoiced, on AWS	Billing adjustment on that invoice	Self-service, and it settles the invoice itself
Invoiced, on Microsoft	Support ticket, then usage credit	Refunds aren’t granted for metered usage
Invoiced, on Google Cloud	Refund request in Partner Support Desk	Google verifies the charge and sets the amount
The entitlement is ending, or usage is winding down	The marketplace’s route, not a credit	A credit only pays back through later usage

Whichever you choose, four steps keep it clean:

1. Stop the emitter first. Size the correction after the bug is fixed, or the number keeps moving.
2. Size it from what the marketplace accepted, per buyer, dimension and hour, at that buyer’s price. AWS returns a MeteringRecordId for each metering event and shows usage in Marketplace Insights within 24 hours; Microsoft’s usage events API lists what it recorded.
3. Tell the buyer before the invoice does. A spike they didn’t cause, followed by usage charges below what they consumed, reads as two errors unless someone explains it.
4. Use one remedy per over-report. A credit and a refund for the same amount pays the buyer back twice.

Frequently asked questions

What is marketplace usage correction?

Marketplace usage correction is making a buyer whole after a cloud marketplace accepted over-reported usage. AWS, Microsoft and Google Cloud offer no self-service way to retract an accepted record, so the fix is a credit on later usage or the marketplace’s own route after the invoice.

Can you send negative usage to cancel an over-report?

Not on AWS or Microsoft. AWS sets a minimum usage quantity of 0, Microsoft rejects any quantity of 0 or lower, and neither accepts a replacement record for an hour already reported. Google Cloud documents no way to retract a usage report either.

Does Microsoft refund metered usage charges?

No. Microsoft’s publisher FAQ says refunds aren’t granted for metered usage, including metered billing for SaaS offers. Its metered billing guide lists a wrong usage event as a reason to open a Partner Center support ticket.

Will AWS refund a buyer for a metering error?

It can. AWS’s refund policy says AWS can issue refunds on your behalf for software charges caused by metering errors, and where errors affect many buyers, it may set each buyer’s refund itself. The seller of record can also apply a billing adjustment to the issued invoice.

How do you correct over-reported usage on Google Cloud Marketplace?

Before the invoice, credit the buyer’s later usage. After it, file a refund request in Partner Support Desk with the customer and the dates. Google verifies what it charged for those dates, sets the credit amount, and offsets it against your future payments.

When is a usage credit better than a refund?

When the invoice hasn’t gone out and the buyer will keep using the product on the same entitlement. The credit is spent against their next usage, so no ticket is needed. If their usage is ending, use the marketplace’s own route instead.

Takeaways

• An accepted usage record is billable. AWS and Microsoft won’t take a negative or replacement record, and Google documents no way to retract one.
• Before the invoice, credit the buyer’s later usage at their own price. It corrects the period without a ticket.
• After the invoice, it’s per cloud: a billing adjustment on AWS, a Partner Support Desk refund request on Google Cloud, and on Microsoft, which doesn’t refund metered usage, a support ticket.
• Use one remedy per over-report. A credit and a refund for the same amount pays twice.

Usage credit, entitlement terms and the metering that feeds them sit together in Suger’s marketplace billing and metering automation, so an over-report caught before the invoice is corrected on the buyer’s next usage, without a support case.