Marketplace Usage Report Failed After Acceptance

Acceptance makes a buyer a customer; it doesn’t make every hour of their usage billable. When AWS, Microsoft or Google Cloud refuses usage because it doesn’t count the customer as billable, its own result code tells you why, and that decides whether the usage can still be billed and what fixes it.

---

Globex accepted Acme’s private offer in March. In July, a marketplace usage report for Globex failed: the usage passed every check on Acme’s side, and the marketplace refused it anyway. The buyer accepted, so why does the marketplace say they aren’t billable, and is that usage gone?

It depends on the code. Each cloud returns its own result when it won’t bill a customer, and some results point at your record while others point at the customer’s account. AWS put the stakes plainly when it announced its metering agent skill as generally available on September 30, 2026: “common mistakes such as mismatched dimension names or invalid timestamps create billing gaps discovered days later.” The rejections here turn on the customer, not the dimension or the clock.

Two related posts own the rest: AWS’s API exceptions, timestamp windows, batching and retries are in why AWS rejects usage records, and which to retry, and usage a marketplace accepted that turned out wrong is in correcting usage a marketplace already accepted.

What does it mean when a marketplace says a customer isn’t billable?

It means the marketplace refused the usage because of the customer’s state at that hour, not the shape of your record. A not-billable rejection is a marketplace refusing usage for a customer it doesn’t count as active and billable when the usage happened. Acceptance is a moment and billability is a state, and two situations put them out of step, with a third that only looks like them:

• Billing hasn’t started. On AWS, the subscribe-success notification “signals when the seller can begin sending metering records,” and a future-dated agreement gets it “on the agreement start date (and not agreement sign date).” On Microsoft, a plan with manual activation leaves a purchase “successfully purchased but not yet activated by the publisher” until you activate it.
• Billing has stopped. The agreement ended or was canceled, Microsoft suspended the subscription because “a customer’s payment for the SaaS service wasn’t received,” or the customer’s Google Cloud billing was disabled or their project deleted.
• The look-alike: the record names the wrong customer. An invalid identifier or resource is your data, not the buyer’s state, and on AWS it returns the same status as a customer with no active agreement. Read the cause; don’t assume it.

What did each marketplace reject, and can you still bill it?

AWS returns CustomerNotSubscribed; Microsoft returns ResourceNotActive, ResourceNotFound or ResourceNotAuthorized; Google Cloud returns one of three services.check errors. Which one you got decides whether the usage can still be billed, and what the fix is.

Marketplace result	What it means for the customer’s access	Can that usage still be billed?	The fix
AWS CustomerNotSubscribed: invalid identifier	Not in question: the record carried an identifier AWS calls invalid	Yes, if a corrected record reaches AWS inside its submission window	Correct the identifier; AWS says invalid records “should be fixed before being resubmitted”
AWS CustomerNotSubscribed: no active agreement or subscription	None: the agreement has ended, or hasn’t started	No. AWS takes final usage only within an hour of the end, and “Future UsageRecords for this customer will fail until the customer subscribes to your product”	Check the agreement’s dates, revoke access if it ended, and meter again once the customer subscribes
AWS CustomerNotSubscribed: suspended AWS account	AWS: the customer “is not able to use your product”	Not as reported: the record “was not honored,” and AWS documents no later route	Contact the buyer; AWS documents no fix for this cause
Microsoft ResourceNotActive	Microsoft: the ISV “should not provide service to the customer”	No: the platform “will not recognize or charge for any usage or activity until the resource becomes active again”	Activate a purchase you never activated; otherwise wait for reinstatement, or a new purchase after a cancellation
Microsoft ResourceNotFound	Not in question: “The usage resource provided is invalid”	Yes, if a corrected event reaches Microsoft inside its reporting window	Send the right resource; for a SaaS offer, the resourceId is the SaaS subscription ID
Microsoft ResourceNotAuthorized	Not in question: “You aren’t authorized to provide usage for this resource”	Only for a resource that is yours, inside Microsoft’s reporting window	Confirm the resource belongs to an offer you publish before you resend
Google Cloud SERVICE_NOT_ACTIVATED	Google: “The consumer hasn’t activated the service”; stop providing service until it’s resolved	Not while the error stands: Google’s flow reports only when checkErrors[] is empty	Confirm the consumerId is this entitlement’s usageReportingId; if it is, the customer activates the service
Google Cloud BILLING_DISABLED	Google: “The consumer cannot access the service because billing is disabled”; stop providing service until it’s resolved	Not while the error stands: no report goes out with a check error	The customer re-enables billing
Google Cloud PROJECT_DELETED	Google: “The consumer’s project has been marked as deleted (soft deletion)”; stop providing service until it’s resolved	Not while the error stands: no report goes out with a check error	Raise it with the customer; the project is theirs
AWS Success, on a dimension added after a private offer was accepted	Unaffected; the dimension just isn’t in their agreement	No: the call “will succeed, but the buyer will not be billed”	Check GetAgreementTerms; bill it through a replacement offer the buyer accepts

That last row never shows up as a rejection: AWS accepts the record, and the gap appears only when you compare what you metered with the agreement’s terms.

AWS: CustomerNotSubscribed

CustomerNotSubscribed is AWS’s result for a usage record it didn’t honor because “The CustomerIdentifier specified is not able to use your product.” It comes back per record, in the Results of a BatchMeterUsage call, with one of three causes: the identifier is invalid, it “does not have an active agreement or subscription with this product,” or “The customer’s AWS account was suspended.”

Because future records for that customer fail too, a meter that keeps running after an agreement ends produces this result every hour until someone stops it. The end is sharp: AWS gives usage-based products one hour of final reporting after an entitlement ends, and “After this period, the BatchMeterUsage API rejects reported usage and you cannot bill the customer.” For a suspended account AWS documents no fix. Its closest guidance comes with the advisory event AWS can raise for conditions including “buyer account closure, compromise, abuse, or fraud”: “Contact the buyer directly and assess whether to revise their access.”

New SaaS products no longer meter by CustomerIdentifier: “Starting June 1, 2026, new SaaS products must use CustomerAWSAccountId (instead of CustomerIdentifier), LicenseArn (instead of ProductCode).” On those records, a license that doesn’t match the customer, or usage outside its activation period, gets InvalidLicenseException, an HTTP 400 error on the call. Switching AWS metering to LicenseArn covers that change.

Microsoft: ResourceNotActive, ResourceNotFound, ResourceNotAuthorized

ResourceNotActive is Microsoft’s batch status for a usage event against a customer resource that “is not in an active or billable state,” for example “due to suspension, nonpayment, or an incomplete activation process.” The single-event API rejects the SaaS version with a 400: “SaaS subscription isn’t in Subscribed status.”

The fix depends on the subscription’s state, which the SaaS fulfillment API’s Get subscription call returns as saasSubscriptionStatus:

• PendingFulfillmentStart: purchased, never activated. This one is yours. On a plan with manual activation you must call the Activate Subscription API, and “The customer isn’t billed unless this API call is successful.” A purchase left unactivated for 30 days is voided.
• Suspended: payment not received. Microsoft recommends limiting or blocking the customer’s access, requires the account be kept recoverable, and gives the customer a 30-day grace period. If payment arrives, the subscription is reinstated and “the customer is billed again.”
• Unsubscribed: canceled. “After a subscription is canceled, you can’t reactivate it,” so billing this customer again takes a new purchase.

ResourceNotFound and ResourceNotAuthorized point at your side of the call instead, so check the event before you question the customer.

Google Cloud: SERVICE_NOT_ACTIVATED, BILLING_DISABLED, PROJECT_DELETED

Google Cloud surfaces these before the report, not after. Its flow is to call services.check and, “if the checkErrors[] object is empty,” call services.report. For these three errors, Google recommends “that you stop providing your service to the customer until the error is resolved,” and it is specific about the bill: “If a customer’s service is disabled before the startTime of a report Operation, the services.check API call sends an error in the checkErrors[] object, and the customer isn’t charged for the corresponding interval.”

All three describe the customer’s own project or billing, so the resolution is theirs, once you’ve confirmed the report’s consumerId is this entitlement’s usageReportingId, the value Google’s usage report expects.

How does Fours show a usage report the marketplace rejected?

In Fours, the usage record group shows a red Report Failed status in the Usage Metering table. Fours’ usage metering documentation describes this post’s case exactly: a group “can pass Fours’ validation and still be rejected later by the cloud marketplace.”

Hover the status for plain-language guidance. For errors Fours recognizes, the tooltip explains the cause and the next steps; the documentation’s two examples are the buyer no longer being subscribed and the marketplace rejecting the customer’s license or subscription state. Previously, the failure reason sat only in Fours’ internal logs.

How should you triage a not-billable rejection?

Work from the code to the customer, in four steps:

1. Name the marketplace’s result. AWS returns it per record in Results, Microsoft per event in the batch response, and Google in checkErrors[]. AWS is plain about whose job that is: “You’re responsible for ensuring that your product’s metering records are successfully transmitted and received.”
2. Separate the record from the customer. An invalid AWS identifier, ResourceNotFound and ResourceNotAuthorized are about your side of the call, and the marketplace’s reporting window keeps running while you fix them. Everything else in the table describes the customer.
3. Bring access in line. Microsoft says not to provide service to an inactive resource, Google recommends stopping service until a check error is resolved, and on AWS an ended agreement is the point where the “ISV begins revoking customer entitlements.”
4. Hand the commercial fix to the account owner. A renewal, a payment, re-enabled billing or a replacement offer is a conversation with the buyer, not a change to the meter.

Frequently asked questions

Why would a buyer who accepted an offer not be billable?

Because acceptance and billing start at different moments. On AWS, metering can begin at the subscribe-success notification, which a future-dated agreement receives on its start date, not its sign date. On Microsoft, a SaaS purchase on a manual-activation plan isn’t billed until you call the Activate Subscription API.

What does CustomerNotSubscribed mean on AWS Marketplace?

It means AWS didn’t honor the usage record because the customer it names can’t use your product: the identifier is invalid, there’s no active agreement or subscription, or the customer’s AWS account was suspended. AWS says future records for that customer fail until they subscribe again.

Can you bill usage that Microsoft rejected as ResourceNotActive?

No. Microsoft says the platform won’t recognize or charge for any usage until the resource becomes active again, and that you shouldn’t provide service meanwhile. If the cause is a purchase you never activated, calling the Activate Subscription API starts the customer’s billing cycle.

What should you do when Google Cloud returns BILLING_DISABLED?

Stop providing service until the error is resolved, as Google recommends, and don’t send the usage report: Google’s flow calls services.report only when services.check returns no errors. The error means the customer’s billing is disabled, so the fix is on their side.

Can you resend usage a marketplace rejected as not billable?

Only when the cause was your record, and the marketplace’s reporting window is still open. When the customer wasn’t billable, a resend fails the same way: AWS fails future records until the customer subscribes, and Microsoft charges nothing until the resource is active again.

How does Fours show a usage report the marketplace rejected?

The usage record group shows a red Report Failed status in the Usage Metering table. Hover the status for plain-language guidance: for errors Fours recognizes, the tooltip explains the cause and the next steps.

Takeaways

• Acceptance isn’t billability. AWS metering can start at subscribe-success, which a future-dated agreement gets on its start date, and Microsoft bills a manual-activation purchase only once you activate it.
• Read the cause, not just the code: AWS returns CustomerNotSubscribed both for an invalid identifier and for a customer with no active agreement.
• Usage refused for a not-billable customer stays unbilled; a resend fails the same way until the customer’s state changes.
• Microsoft and Google tell you to stop providing service while the error stands. On AWS, an ended agreement is when you revoke entitlements.
• A dimension added after a private offer was accepted returns Success on AWS and bills nothing. Check GetAgreementTerms before you meter it.

Fours validates, aggregates and reports your usage to the right marketplace, and when a marketplace rejects a usage record group downstream, the group shows Report Failed, with the cause and next steps on hover for errors Fours recognizes. See how that fits your metering in Fours’ billing and metering automation.