Revenue Attribution IDs: Where AWS Decides What a Deal Was Worth

AWS Partner Revenue Measurement has been explained, where it has been explained at all, as a tagging exercise. Put a product code on a resource, AWS meters the consumption, a number appears. The pitch is that a claim gets replaced by a fact.

That account is accurate and incomplete, and the missing part is the part with money attached. Product-level attribution tells AWS how much consumption your product drives. It does not tell AWS how much of that consumption belongs to a particular deal — and deal-level incentives, which is most of the funding a partner actually chases, are paid against deals.

The mechanism that closes that gap is called a Revenue Attribution ID. AWS has documented it — there is a page in the PRM onboarding guide, a developer guide, and a full public API. What is missing is anyone talking about it: as of August 2026 we could find no partner-tooling vendor writing about it, and the trade coverage of PRM does not mention it at all. It is also, on inspection, the most consequential thing in the whole system — and it contains a wrinkle that undercuts the tidy story about facts replacing claims.

What it is, mechanically

A Revenue Attribution ID is an identifier created in AWS Partner Central that associates AWS Marketplace offers and ACE opportunities with a Marketplace product listing, so AWS can determine the revenue generated by those specific offers and opportunities. A Marketplace listing can be associated with a single Revenue Attribution ID — though, as we will see, the console also lets you declare that infrastructure is shared across several listings and skip product selection entirely.

There are two ways to use it. As a deal-level overlay on an existing product-level PRM implementation: you create the ID, associate the applicable offers and opportunities, and supply monthly cost-allocation percentages, which maps revenue already being measured onto the deals you are claiming against. Or as a standalone identifier, used directly in place of a product code as a resource tag value or inside a user agent string, associating consumption to specific deals at the point of measurement.

If you have already implemented PRM, none of this is rework. AWS is explicit: if your tag value or user agent string carries a Marketplace product code, that implementation stands. The design intent is a mapping layer that eliminates re-tagging.

What the console actually asks you

It lives in AWS Partner Central in the Console, under Sell → Revenue attribution — a sibling of Opportunities and Private offers rather than anything buried in a billing screen, which tells you how AWS is thinking about it. The creation flow is three steps: provide revenue attribution and product details; add deal entities and cost allocations; review and create.

Step one asks for a name — unique, 1 to 128 characters, letters, digits, periods, underscores and hyphens — and an optional description of up to 1,024 characters. That is a small detail with a large implication: these are named objects you will be reading back in a list months later, so the naming convention is worth deciding once, before somebody creates fifteen of them called revattr-final-2. Put the customer and the deal in the name. Use the description for the allocation basis.

Then it asks how to identify the product, and offers three choices. Choose from your AWS Marketplace listings. Enter a Marketplace product ID directly, for a product sitting in a connected primary or subsidiary account. Or — and this is the one that is not in the documentation — “This revenue attribution is for multiple products”, described as: the underlying product and infrastructure is shared across multiple Marketplace listings, continue without specifying a product.

That third option matters more than its placement suggests. The written guidance says a Marketplace listing can be associated with a single Revenue Attribution ID, which reads as a one-product-per-ID world and leaves anyone with several listings running on one shared platform wondering which listing to pick. The console answer is that you do not pick: you declare the sharing and allocate below it. If you have three listings on one estate — a common shape for anyone who has grown by packaging rather than by rebuilding — that is your route, and you would not learn it from the docs.

Step two is where the real work sits. AWS calls the offers and opportunities deal entities, and this is the step that consumes the monthly cost-allocation percentages.

The wrinkle: the split is self-reported

Now the part worth slowing down for.

Where two or more offers or opportunities are active against the same Revenue Attribution ID in the same billing month, AWS allocates that month’s attributed revenue based on the cost-allocation percentage you provide for each one. Sixty per cent to Offer A and forty to Offer B in June means June’s attribution splits sixty-forty.

Read that against the premise of the whole programme. PRM exists because partner contribution has been self-asserted and inconsistently adjudicated, and AWS wants measured facts instead. At the product level that is exactly what it delivers — the meter does not care what you think. But at the deal level, where the incentives are, the division of that measured total is a number the partner types in.

This is not a flaw so much as an unavoidable consequence. There is no way for AWS to observe which of two concurrent customer deals drove which share of a pooled infrastructure bill; only the partner knows how their own architecture allocates. But it means the evidence economy has a self-report at its centre, and the self-report has moved from did I influence this deal — a question a human used to weigh — to what percentage of this measured revenue is this deal, a question that will increasingly be answered by an automated payout with no human in the path at all.

There is a further asymmetry worth noticing. AWS states that deal-level revenue attribution remains internal to AWS. You supply the percentages; the dashboard continues to show only aggregated product-level and service-level revenue. So this is a number you are accountable for and cannot inspect the consequences of — which makes the allocation model the only artefact you control, and the only evidence you would have if the split were ever questioned.

Which changes what discipline is required. A percentage you can defend with an allocation model is a different artefact from a percentage that made the claim add up. The first is a methodology; the second is a number chosen to produce an outcome, and it will look like one whenever anybody reconstructs it.

Why AWS built it: payouts without reviewers

AWS gives two reasons. The first is administrative: mapping revenue to specific deals reduces the reporting and reconciliation burden that currently rests on manual inputs. The second is the one to pay attention to — Revenue Attribution IDs allow for automated payment approvals when a deal meets a certain revenue milestone, replacing reporting and reconciliation that today rests on manual inputs.

An incentive that pays out when a pipeline observes a milestone has no submission, no reviewer, and no discretion. For partners who have spent years assembling claim packs and chasing reconciliation, that is straightforwardly good news, and the time it gives back is real.

The trade is that discretion cut both ways. A claim that was 90% right and imperfectly evidenced could be discussed with someone who understood the account. A milestone that does not trigger does not generate a conversation; it generates nothing, which — as with every other part of PRM — is indistinguishable from having done nothing. The judgement that used to happen after the fact now has to happen before, in how the deal was structured and how the allocation was set.

The multi-tenant SaaS answer nobody published

Ask a multi-tenant SaaS partner how PRM applies to them and you will usually get some version of: it does not, cleanly. Their customers share infrastructure. There is no per-customer resource to tag, so tagging yields one undifferentiated pool of consumption, which is fine for a product-level number and useless for anything a customer-specific incentive attaches to.

Revenue Attribution IDs are the answer, and it is a specific one. Create one Revenue Attribution ID per product. Associate the relevant AWS Marketplace offers or ACE opportunities for each customer. Provide monthly cost-allocation percentages reflecting each customer’s share of your infrastructure consumption for that billing month.

And note that AWS does not present this as optional for you. The cost allocation percentage is stated as required for multi-tenant SaaS products, including partner-hosted components in hybrid deployments where customers share infrastructure inside partner accounts. If that describes your architecture, this is not an enhancement to consider later; it is the mechanism.

The pooled bill stays pooled at the meter and gets divided in the mapping layer. Which puts a real obligation on the allocation model, and it is worth being honest that most multi-tenant products do not have one ready. Per-tenant cost attribution is a well-known hard problem — compute is lumpy, storage is cumulative, and the tenant driving the most queries is rarely the tenant paying the most. If your finance team has never produced a per-customer cost of goods, this is the moment that becomes a revenue question rather than an accounting curiosity.

There is a related capability worth knowing about: the AWS Marketplace Revenue Share API, a set of PRM APIs that let partners programmatically declare what portion of a product’s revenue is generated through AWS Marketplace for a given period, with a percentage and an effective date window, which AWS then uses to attribute revenue correctly. For anyone selling through both Marketplace and direct contracts, that is the declaration that stops the two being conflated.

The prerequisites, and the one that bites

Five conditions. You must have migrated to AWS Partner Central in the Console, hold at least one AWS Marketplace product listing, and have implemented at least one PRM capability — and note that here AWS names only Resource Tagging or User Agent String, not Marketplace Metering. For Marketplace offer associations you need a valid buyer account ID.

The fifth is the one that will catch partner organisations out. To associate an ACE opportunity, that opportunity must be in Launched stage with a customer AWS Account ID specified.

Read that as an operational requirement rather than a form field. Customer AWS account IDs are frequently missing from ACE records — nobody needed them for the opportunity to progress, so nobody chased them. They are now a precondition for attaching revenue attribution to the deal, which means the account ID has to be captured during the engagement, by whoever is in the room, rather than reconstructed afterwards by someone who was not.

There is an API, and it tells you what this really is

The Partner Central Revenue Measurement API exposes all of this programmatically — CreateRevenueAttribution, allocation listing and updates, and a bulk StartRevenueAttributionAllocationsTask for partners with more deals than a wizard can reasonably handle.

Alongside it sits the Marketplace Revenue Share resource, which answers a different question: what portion of a product’s total revenue is collected through AWS Marketplace. One share per product, identified by Marketplace product ID, with one or more allocations each declaring a percentage and an effective date window. Only one active allocation may apply at a time, no two active allocations may overlap, and updates use optimistic locking against a version that increments on every mutation. There is a Sandbox catalog for testing.

Those design choices are more revealing than they look. Non-overlapping dated allocations, version-checked updates, soft deletes rather than hard ones, an audit trail of created and modified timestamps: this is not reporting infrastructure. It is the shape of a system built to be replayed and reconciled after the fact — which is exactly what you would build if the numbers were going to drive automated payouts and somebody would eventually need to reconstruct why a given month paid what it paid.

Renewals, and why these are long-lived objects

When an offer or opportunity ends and a new one replaces it, AWS’s recommended pattern is to keep the same Revenue Attribution ID: stop adding monthly cost-allocation percentages for the expired deal, start adding them for the new one. No resources are re-tagged. Where different deals are associated in different months, each month’s revenue follows that month’s association — Offer A in April, Offer B in May.

The consequence is that a Revenue Attribution ID is not a set-up-and-forget artefact. It is a durable object with a monthly input, outliving individual deals and accumulating a history that will be read by an automated payout process. It needs an owner, and the owner is not engineering. Engineering ships the instrumentation once. Somebody has to supply percentages every month, notice when a renewal changes the allocation, and reconcile the result — which is RevOps work, on a monthly cadence, and it does not currently exist in most partner organisations.

A single ID can also carry both Marketplace offers and ACE opportunities, and AWS treats them identically for attribution purposes, splitting on the percentages regardless of type. That matters for the common shape where part of the customer base transacts through Marketplace and part is tracked through ACE.

Where this rejoins ACE

Step back and the structural point is clearer than the mechanics suggest.

ACE and PRM have been described as separate systems measuring separate things — ACE the relationship, PRM the consumption. That was true until the moment an identifier existed that associated an ACE opportunity with measured revenue. The Revenue Attribution ID is that identifier. It is the join.

And a join changes what each side is worth. An ACE opportunity used to be a registration: it earned visibility, a partner manager’s attention, perhaps routing to a seller. Associated with a Revenue Attribution ID, the same opportunity becomes the thing a revenue allocation attaches to. Deals never registered in ACE are not merely uncredited relationally; they have no object for a deal-level incentive to attach to at all.

Which quietly raises the cost of the sloppiest habit in partner operations — registering opportunities late, thinly, or not at all because the paperwork felt like overhead relative to the benefit. That calculation was defensible when the benefit was attention. It is not defensible when the opportunity record is a payout key.

What to do

Create them before you need them. There is no re-tagging cost and no implementation risk — a wizard, an association, and a monthly percentage. The cost of having one you did not need is approximately zero. The cost of not having one when a deal-level incentive lands in 2027 is the incentive.

Write the allocation methodology down before the first percentage.Not the percentages — the method that produces them. Whatever you use, the test is whether someone else could apply it to next month’s data and reach the same answer. If they could not, you do not have a methodology, you have a number.

Give them an owner in RevOps, not engineering. Monthly input, renewal-sensitive, audit-relevant. It belongs next to whoever already reconciles pipeline, not next to whoever wrote the Terraform.

Fix ACE registration discipline now. Every deal-level incentive from 2027 needs an offer or an opportunity to attach to. An unregistered deal is not a lost mention; it is a payout with nothing to bind to.

Do the per-tenant cost work if you are multi-tenant SaaS. This is the longest lead-time item on the list, and it is the one that cannot be done in the week a claim is due.

The PRM guide covers what Partner Revenue Measurement is, the three implementation methods and the prerequisites, and carries the method decision rule and the troubleshooting table for when attribution reads zero.

The thing worth remembering

PRM is described as replacing claims with facts, and at the product level it does. But the layer where the money is decided runs on a percentage you supply, feeding an approval process with nobody in it.

That is not a reason for cynicism about the system. It is a reason to treat the allocation model as a first-class artefact rather than a month-end chore — because it is the last place in this architecture where partner judgement still enters the record, and it is about to be the place where partner judgement is worth the most.