Move Brand Registry selling roles to global Account IDs

A global identifier simplifies one part of Brand Registry administration. It does not make the underlying access relationships self-explanatory.

Amazon says that, beginning July 29, 2026, Brand Registry Administrators use an Account ID rather than a Merchant Token when assigning or modifying selling roles. The Account ID is a single worldwide identifier. Amazon points Account Owners to Settings, then Manage Accounts, and says an Owner can also find it through User Permissions.

The operational task is to connect that identifier to the correct brand, legal entity, store footprint, benefit, approver, and revocation path.

Define the change narrowly

This update concerns Brand Registry selling roles.

Do not interpret it as proof that Merchant Tokens have disappeared from every API, reporting, financial, or integration workflow. Do not merge selling roles with ordinary Seller Central user permissions. They may intersect in a person’s work, but they answer different access questions and should have separate records.

Amazon identifies affected users as Brand Registry Administrators, accounts that already have a selling role, and accounts that need one to access brand selling benefits. Examples in the announcement include A+ Content, Stores, and Vine. Start with those intended outcomes. A role request without a named business need is not ready for approval.

Build the relationship map first

Create one row for every brand-to-selling-account relationship.

Record the trademark owner, Brand Registry account, Administrator, selling legal entity, Account ID, stores operated, current role, requested role, expected benefit, business owner, and last review date. Include agencies and distributors, but identify whether they own the selling account or merely perform work for it.

The worldwide Account ID reduces repeated identifiers across stores. It can also make an incorrect grant travel farther than an operator expects. Reconcile the ID with entity records, tax and payout ownership, known storefronts, and the Account Owner before making a change. Never accept an Account ID sent in an unverified chat as sufficient identity evidence.

Flag dormant relationships, duplicated grants, former agencies, and brands whose commercial agreement no longer supports access.

Separate identity from authority

Knowing which account is involved does not answer what that account should be allowed to do.

Define a small role catalog that links each Brand Registry selling role to approved tasks, prohibited tasks, requesters, approvers, and review frequency. Use the least authority that enables the named benefit. A contractor preparing A+ Content should not receive broader access merely because another team may later need Stores or Vine.

Keep the Account Owner, Brand Registry Administrator, and commercial owner visible as distinct responsibilities. One person may occupy several positions, but the record should still show who verified identity, who approved the brand relationship, and who accepted the operational result.

For sensitive or cross-entity grants, require evidence that the trademark owner or authorized brand representative supports the relationship.

Test the benefit after assignment

An accepted role change is not proof that the intended workflow functions.

Run a narrow acceptance test in the relevant store. Confirm that the assigned account can reach the expected Brand Registry benefit and that unrelated brands or functions did not become available. Use a low-impact action, such as opening the appropriate creation workflow or verifying the eligible brand list, before attempting a production submission.

Capture the Account ID, brand, role, store, person running the test, timestamp, expected result, and observed result. If access is missing, diagnose the relationship rather than stacking additional roles until something works. If access is broader than requested, treat that as a defect and reduce it.

Test from the grantee’s actual login context; an Administrator’s view cannot prove the grantee’s outcome.

Make removal an ordinary workflow

Role governance fails when grants are documented but removals depend on memory.

Set review triggers for employee departure, agency termination, distributor change, entity sale, brand transfer, store closure, and long inactivity. Give each grant a review date and a named owner. Maintain a step-by-step revocation route and periodically test it with a low-risk account.

Preserve approval and removal evidence outside a single Administrator’s inbox. Measure unmatched Account IDs, stale grants, failed benefit tests, overdue reviews, and time to revoke. These are better control signals than the raw number of users.

Where a relationship spans several brands, review each brand independently. A valid role for one brand does not justify carrying access into another.

The Operator Read

Amazon’s worldwide Account ID can make Brand Registry selling-role administration more consistent across stores. The identifier is only the key; it is not the access decision.

Map every brand relationship, verify the Account ID with the Account Owner, separate identity from authority, test the exact benefit, and make revocation routine. Keep selling roles distinct from general Seller Central permissions and from other uses of Merchant Tokens.

The migration is complete when every grant can be explained, tested, reviewed, and removed—not when every old identifier has merely been copied into a new field.