Summary

  • AWS Marketplace says an existing SaaS integration that submits the same customer's usage for the same hour under both ProductCode and LicenseArn will cause duplicate billing. Its two deduplication schemes use different record identities.
  • New SaaS products have been required to support Concurrent Agreements integration since 1 June 2026. Existing integrations may continue, but any migration must assign each customer, agreement, dimension and hour to one reporting path.

Two keys fit the meter. That is the problem.

AWS Marketplace sellers submit SaaS usage records, and AWS calculates the buyer's bill from those records and the product's prices. For a product without Concurrent Agreements, the platform deduplicates by product, customer, hour and pricing dimension. With Concurrent Agreements, it deduplicates by license, customer, hour and dimension. The new unit is an agreement identified by LicenseArn, because one customer can hold several active agreements for the same product.

The migration hazard is printed in AWS's own seller guide. Retrying a record against the same license is subject to normal deduplication. Sending the same usage window once with ProductCode and again with LicenseArn is not. AWS says it will cause duplicate billing, and instructs existing integrations moving to license-based metering to avoid both identities for the same customer within the same hour. The old sender and the new sender may each believe it is doing its job. The invoice sees two jobs.

The date matters, but its scope matters more. AWS says new SaaS products must support the updated Concurrent Agreements integration from 1 June 2026. It says existing integrations can continue. This is not a claim that every old seller had to migrate on that date. It is a warning for sellers who do change the path: the transition needs a cutover by usage hour, not a vague switch in a deployment checklist.

A clean cutover starts with the record key. For each buyer account, pricing dimension and hour, determine which agreement receives the usage and which sender alone may report it. The LicenseArn comes from ResolveCustomer during registration. Under license-based metering, AWS says to leave ProductCode out of the request-level payload and identify the agreement in each UsageRecord. If a customer holds two agreements, the assignment cannot be made from the product name alone.

The record is harder to repair after submission than a spreadsheet cell. AWS says a reported dimension quantity, even zero, cannot be amended. Repeated submissions for the same customer, dimension and hour are not added together under one identity; the first billed quantity survives a retry with a different quantity. These rules make the migration rehearsal consequential: a test should verify that the old path has stopped for a selected hour before the new path starts sending that hour's usage.

Buyers have a view, but it arrives after the seller's action. AWS says its billing console shows dimension line items and cumulative cost, while the Cost and Usage Report can expose per-unit detail if enabled. Neither is real-time. CloudTrail can verify the seller's API calls. To prove a specific duplicate charge, one would need the submitted records for the customer, license, dimension and hour and the settled billing lines. AWS's public warning establishes the mechanism; it names no affected buyer.

The small-looking identifier change moves control over the bill. Once an agreement, rather than a product, is the billing unit, the seller's routing decision decides where a usage hour lands. A buyer who has two active agreements needs that routing to be legible. A seller who runs two reporting identities at once may make one hour look like two. Marketplace convenience does not reconcile the records for them.

Sources