Invoice configuration for AWS Billing Transfer
Use invoice configuration to decide which of your entities receives each transferred organization's invoice, and under which tax profile and seller of record.
AWS Billing Transfer lets a management account hand billing responsibility for its whole organization to an account outside that organization. It does not merge the transferring organizations into one bill: the bill transfer account receives distinct invoices for each organization that transfers its bill to it. Every one of those invoices, though, is issued to the bill transfer account itself, under its tax settings and seller of record. That suits a partner that trades as a single legal entity, but not a distributor that resells through regional subsidiaries, where an EMEA customer's invoice belongs with the EMEA subsidiary and the EMEA seller of record. AWS invoice configuration changes who an invoice is issued to, and it supports billing transfer directly: a unit can name entire transferring organizations and route their invoices to a receiver account that carries the right tax identity.
What the two features do together
Invoice configuration groups charges into invoice units. Each unit names an invoice receiver (the account the unit's invoices are issued to) and a rule listing the accounts whose charges belong to it. Accounts outside any invoice unit keep receiving invoices exactly as before.
On its own, an invoice unit is an intra-organization tool. Paired with billing transfer it becomes the mechanism AWS documents for supporting multiple tax settings and sellers of record across the organizations that transfer bills to you. AWS recommends creating a member account inside your bill transfer account, designating it the invoice receiver, and mapping one or more transferring organizations to it. Repeat that per jurisdiction or per seller of record and each transferring organization is invoiced under the entity that should be billing it.
A unit changes who is invoiced and by which AWS entity, not how the bill is settled. Invoice units inherit the payer account's payment method and terms. Out-of-cycle bills and subscription purchase invoices follow the same routing to the receiver as the monthly invoice, and you can associate a purchase order with each unit to keep the procure-to-pay trail separate per business entity. If the payer has opted in to daily invoice consolidation, the consolidated daily invoice honors the unit preferences that are active at the end of that day.
One bill transfer account or several
Two different accounts get called a receiver around this setup, so separate them before deciding on a structure. The bill transfer account is the payer: the management account that sent the transfer invitations the other organizations accepted, receives the resulting invoices, and pays them. Partner programs often call it the program management account (PMA), and in a two-level transfer the AWS documentation also calls the account at the top of the chain the bill receiver; that is the same payer role one level up. The invoice receiver named in an invoice unit is something else: an account inside the payer's own organization, usually a member account although the payer itself is allowed, that is the bill-to on the unit's invoices. It supplies the tax identity, legal name, and address printed on the invoice, and it pays nothing. The payer does.
Whether one bill transfer account can serve every regional entity, or each entity needs its own, then comes down to what has to differ between them: the currency and payment instrument, or the payment terms and the credit relationship itself.
Different currencies and payment instruments need only one bill transfer account. Invoice configuration issues each unit's invoices to the regional entity's receiver account, from that receiver's seller of record, and lets each unit carry its own purchase order. Payment profiles on the payer then attach a currency and a payment method to each seller of record: invoices from Amazon Web Services EMEA SARL in euros by SEPA direct debit, invoices from Amazon Web Services, Inc. in US dollars from a US bank account, invoices from the Singapore seller of record in Singapore dollars. AWS documents payment profiles for this case specifically, a bill transfer account that used invoice configuration to assign different tax profiles to the bills it pays. Each invoice states the USD base amount next to the payment-currency amount and the exchange rate AWS applied, so the regional entity pays in its own currency while the USD figure reconciles with Cost Explorer and the Cost and Usage Report. Without payment profiles, every invoice falls back to the payer's default payment preference: one currency and one instrument for everything.
Different payment terms, or separate credit lines, need separate bill transfer accounts. AWS grants payment terms per payer account, and both features inherit them: invoice units inherit the payer's payment method and terms, and a payment profile changes the currency and instrument but not the terms. Net 30 for one regional entity and net 60 for another cannot coexist inside one organization. Liability follows the same boundary: the management account and member accounts are jointly and severally liable for all charges accrued while joined in the organization, under one credit relationship with AWS. Where the regional subsidiaries are separate legal entities that must contract, be assessed for credit, and be liable independently, each has to be its own payer, which means its own bill transfer account.
Running several bill transfer accounts costs operational effort rather than pricing. The billing transfer documentation states that volume discount tiers, Reserved Instances, and Savings Plans are calculated at the level of each individual organization whether or not it transfers its bill, so splitting payers forfeits no discount aggregation. What multiplies is everything else. Each bill transfer account is its own organization with its own Billing Conductor billing groups, Cost and Usage Reports and Cost Explorer views, IAM baseline, tax and payment setup, and partner program registration. Moving a customer between regions becomes a withdrawal and a new invitation, aligned to calendar months and accepted at least 24 hours before the start date, instead of moving a transfer between invoice units. Any central finance view has to be assembled across accounts. Capacity is rarely the deciding factor: the inbound transfer quota is adjustable up to 1,000 external organizations per bill transfer account. The rest of this guide describes the setup inside one bill transfer account; it applies unchanged within each account if you run several.
Linked accounts and bill source accounts
An invoice unit rule carries two separate account lists, and the distinction between them determines whether a rule validates. Both are plain arrays of 12-digit account IDs, so the field an ID belongs in is not visible from the value itself.
LinkedAccounts holds member accounts inside your own organization. BillSourceAccounts holds management accounts of other organizations that delegated their billing to your payer account through billing transfer. The InvoiceUnitRule reference is explicit that bill source accounts, unlike linked accounts, can be payer accounts belonging to other organizations. The delegation does not need to be direct, either: when a reseller that transfers its bill to you has customers of its own that transfer their bills to it, those customers' management accounts are also valid entries, because their bills roll up to you through the intermediate transfer. Each list accepts up to 1,000 account IDs.The two lists are not mutually exclusive. A single rule can populate both, and both persist:
1
2
3
4
"Rule": {
"LinkedAccounts": ["555555555555"],
"BillSourceAccounts": ["333333333333"]
}Here
555555555555 is a member account of your own organization and 333333333333 is the management account of an organization that transferred its bill to you. That combination is useful when one business entity covers both; a unit involves billing transfer whenever BillSourceAccounts is populated, regardless of what else the rule holds. Expect the two halves to be invoiced separately, though: in a test payer, a unit holding one linked account and one bill source produced two invoices to its receiver every month, one for the in-organization account and one for the transferred organization, both issued by the receiver's seller of record.A typical reason to combine the two is a partner that runs shared services or a SaaS product for the organizations that transfer their bills to it. Say
555555555555 hosts a managed security platform, or the control plane of a SaaS application, and the customer organization behind 333333333333 consumes it. Putting both in one unit sends the platform account's invoices and the customer organization's invoices to the same receiver, so the regional entity that sells the service is billed, under its own tax identity, for both the customer's AWS usage and the shared infrastructure behind the service. Invoice configuration routes whole accounts, though, so it does not split the platform's charges across the customers that use it. Passing a share of that cost to each customer is a showback or chargeback decision, made for example with custom line items in AWS Billing Conductor, which add a flat or percentage charge to a customer's pro forma bill.A misplaced account fails validation rather than being rerouted: an external management account submitted in
LinkedAccounts is rejected outright. The same account may also appear in only one invoice unit's rule across the whole payer.Before you start
You need a bill transfer account (the payer account whose transfer invitations the other organizations accepted; the invoice units live in this account) already holding at least one accepted billing transfer: the console flow selects from your accepted transfers, and the API validates every bill source against them. Both organizations must be in all-features mode for the transfer itself, and the transfer must be accepted, not just invited. It does not need to have started, though: an accepted transfer qualifies immediately, even when its start date is still weeks away, so you can prepare invoice units ahead of an onboarding.
You also need a member account under the bill transfer account to act as the invoice receiver. Create it first and give it the tax settings the unit's invoices should be issued under, because a unit's accounts inherit the receiver's.
The console and the API also accept the payer itself as receiver, but for a transferred organization that leaves the invoice as it was. In a test payer, a transferred organization's invoices were identical before and after it was placed in a unit received by the payer: the same addressee, issuing entity, and bill-to block, matching the invoices of a transfer that is in no unit. Naming the payer matters in two narrower cases. AWS requires the payer to receive any unit that holds the payer's own charges, and because a unit can carry its own purchase order, a unit received by the payer can put a separate purchase order on one transferred organization's invoices.
⚠️ Decide the invoice unit name and invoice receiver before you create the unit. Neither can be changed afterwards, and correcting either one means deleting the unit and recreating it.
Create the unit in the console
The billing transfer flow differs from the standard one at the point where you choose contents, so follow the transfer-specific path in Creating invoice units .
- Open the AWS Billing and Cost Management console and choose Invoice configuration.
- In the Invoice units section, choose Create invoice unit.
- Enter an Invoice unit name that is unique within your account.
- Under Invoice receiver, choose the member account that should receive the invoices. The payer is listed too; see Before you start for why it rarely helps. The form then shows the receiver's business legal name and address and, under Invoice issuer, the Service Provider: the AWS entity that will issue this unit's invoices. Check it here, before the unit exists.
- In the Invoice unit contents table, choose Add contents. The panel that opens offers both accounts and billing transfers.
- Choose the Billing transfers tile, then select the transfers to include. The panel lists only transfers that are not already in a unit, so a transfer you expected but cannot find is assigned elsewhere.
- Choose Create invoice unit.
The configuration takes effect immediately, and the grouping appears on the invoice issued at the start of the next month. Afterwards the invoice configuration page carries a snapshot history showing which billing transfers sat in each unit over a given date range. A Billing transfers tab lists every transfer the payer can place, including second-level transfers that roll up through a reseller, with its associated invoice unit. An empty Invoice unit cell is the quickest way to spot a transfer that has not been assigned.
Create the same unit with the AWS CLI
The API takes the bill source accounts directly, which makes it the better route for anything repeatable. Substitute your own IDs for the placeholders below.
1
2
3
4
5
6
aws invoicing create-invoice-unit \
--name "EMEA-Resellers" \
--description "Transferring organizations invoiced by the EMEA entity" \
--invoice-receiver 222222222222 \
--rule '{"BillSourceAccounts":["333333333333","444444444444"]}' \
--region us-east-1Run this from your bill transfer account,
111111111111 in these examples. 222222222222 is the member account beneath it that will receive the invoice, while 333333333333 and 444444444444 are the management accounts of the organizations that transferred their bills to you. The call returns the new unit's ARN.The CLI also offers
--tax-inheritance-disabled, but do not set it on a unit that contains bill source accounts: both CreateInvoiceUnit and UpdateInvoiceUnit reject the flag with Tax inheritance must be enabled for invoice units with Usage Consolidation Accounts (Usage Consolidation Accounts, or UCA, is the service's term for the accounts listed in a unit's rule). Inheriting the receiver's tax settings is the point of pairing the two features, and the service enforces it. The flag only works on units whose rule holds nothing but LinkedAccounts; the tax behavior is covered below.Read your configuration back
Listing the units in a payer account tells you what exists and, through the rule, which of them are wired to billing transfer.
1
2
aws invoicing list-invoice-units --region us-east-1
aws invoicing get-invoice-unit --invoice-unit-arn <UNIT_ARN> --region us-east-1The list call filters on bill source accounts directly, so you can find which invoice unit a transferred organization is billed under without paging through every unit. Both calls also accept an
AsOf timestamp (--as-of in the CLI), the API equivalent of the console's snapshot history, so you can reconstruct how a unit was configured during a past billing period.1
2
3
aws invoicing list-invoice-units \
--filters '{"BillSourceAccounts":["333333333333"]}' \
--region us-east-1Check permissions before delegating this task to a role that uses managed read-only access. At the time of writing, the AWS managed
ReadOnlyAccess policy does not include invoicing:ListInvoiceUnits; its invoicing coverage is limited to fetching invoice PDFs, reading email delivery preferences, and listing invoice summaries, so a principal relying on that policy alone gets AccessDeniedException on these read calls. Managed policies change, so check the current contents yourself:1
2
3
4
5
6
aws iam get-policy-version \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \
--version-id "$(aws iam get-policy \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \
--query 'Policy.DefaultVersionId' --output text)" \
--query "PolicyVersion.Document.Statement[].Action[]" --output text | tr '\t' '\n' | grep invoicingGrant
invoicing:ListInvoiceUnits, invoicing:GetInvoiceUnit, and invoicing:BatchGetInvoiceProfile (used in the verification below) explicitly to whichever role is expected to audit this configuration.Tax settings and seller of record
Tax inheritance is the main reason to pair invoice configuration with billing transfer, so it helps to know exactly which account's tax profile applies. The deciding factor is the invoice issuer, the AWS seller of record that issues the unit's invoices:
- When the invoice issuer is Amazon Web Services, Inc., you can select Apply tax settings to all accounts in invoice unit so the unit's accounts inherit the invoice receiver's tax settings instead of the payer's.
- When the invoice issuer is not Amazon Web Services, Inc., the unit's accounts inherit the invoice receiver's tax settings automatically.
- When no unit-level inheritance applies and the payer is enabled for tax inheritance, members inherit the payer's settings.
In the API this is the
TaxInheritanceDisabled flag on the unit, and the console reflects the result on the Tax settings page. For a unit that contains bill source accounts the flag is not just off by default; the API refuses to set it, so a unit built on billing transfer always inherits.That is what makes one invoice unit per jurisdiction workable: the receiver you place at the head of each unit carries the tax identity for everything mapped into it. The quickest way to see which seller of record a receiver resolves to is
batch-get-invoice-profile, covered under Verify the result.Limitations to design around
These are the constraints that affect how you structure invoice units, all documented in Creating invoice units .
- The invoice unit name and invoice receiver are fixed at creation; changing either means delete and recreate.
UpdateInvoiceUnitdoes not even accept those two fields. - An account can appear in only one invoice unit's rule at a time, though one account can be the receiver for several units. Reusing an account fails with
The following accounts are assigned more than once, and unlike the transfer-relationship error below, this one names the account. - An account listed in one unit's rule cannot be the receiver of a different unit, unless it is also the receiver of the unit it belongs to.
- Units exist within a single payer account or organization.
- New accounts are never added to a unit automatically; add them through the console or the Invoicing API.
- Invoice consolidation applies at the payer level only, never per invoice unit.
Verify the result
The configuration in force when the month closes decides the whole month's invoice, so a correction only has to land before the month ends. The UpdateInvoiceUnit reference states it directly: AWS uses the latest configuration at the end of the month. There is no proration across a mid-month change. In a test payer, a unit deleted and recreated with a different receiver on the fourth of the month put the entire month's transferred charges on the new receiver's invoice, issued on the second of the following month, and the previous receiver's invoices for that month carried nothing from the transferring organization.
In the console, open the unit's details page and confirm that the intended transfers appear under Invoice unit contents (each row is typed Account or Billing transfer), that the receiver details shown are the ones you want printed on the invoice, and that Service Provider names the AWS entity you expect. Inherit invoice receiver tax settings should read Activated for a unit built on billing transfer. Then check the Billing transfers tab for any unassigned transfer you meant to include.
The snapshot history, reachable from View configuration snapshot history, shows the units as they stood at any past date and time. It is the console counterpart of the
--as-of option covered earlier, and the place to confirm what a unit contained during a billing period that has already been invoiced.
The CLI answers the question that matters most before the month closes, which AWS entity will issue each receiver's invoices.
batch-get-invoice-profile works for any member account of the bill transfer account and returns the Issuer, the AWS entity recorded as that account's invoice issuer, together with the receiver name and address:1
2
3
4
aws invoicing batch-get-invoice-profile \
--account-ids 222222222222 111111111111 \
--query 'Profiles[].[AccountId,Issuer,ReceiverAddress.CountryCode]' \
--output table --region us-east-1Run it from the bill transfer account and compare the receiver's
Issuer with the payer's own. In a test payer, a receiver whose profile reported Amazon Web Services EMEA SARL received its unit's invoices from that entity while the payer's own invoice for the same month came from Amazon Web Services, Inc. If the issuer is not the entity you expected, look at the receiver account's address and tax settings rather than at the unit: the unit only decides which account receives the invoice, and that account decides who issues it. Like the two read calls above, invoicing:BatchGetInvoiceProfile is not in the managed ReadOnlyAccess policy.Once the invoices are issued in the first days of the following month,
list-invoice-summaries shows how the month was split. Selecting the bill transfer account's own ID returns every invoice issued under it for the period, including the receivers', so one call covers the whole payer:1
2
3
4
5
aws invoicing list-invoice-summaries \
--selector ResourceType=ACCOUNT_ID,Value=111111111111 \
--filter 'BillingPeriod={Month=8,Year=2026}' \
--query 'InvoiceSummaries[].[AccountId,BillSourceAccounts[0],InvoiceId,Entity.InvoicingEntity,BaseCurrencyAmount.TotalAmount]' \
--output table --region us-east-1Each row's
AccountId is the account the invoice was issued to, BillSourceAccounts names the account whose charges it covers, and Entity.InvoicingEntity is the AWS entity that issued it. For a unit built on billing transfer, invoices covering a transferring organization in the unit are issued to the receiver, carry the receiver's entity, and name that organization's management account as their bill source. Invoices for the unit's linked accounts are also issued to the receiver but name the payer as their bill source, as the payer's own invoices do. A transfer that is not in any unit still has invoices of its own, issued to the payer under the payer's entity. Selecting a receiver's ID instead narrows the list to that receiver's invoices. This call is in ReadOnlyAccess, so an auditor can run it without extra grants. The invoice PDF itself, available with get-invoice-pdf, is the final word on what the receiver sees: for a transferred organization it carries a Usage Account ID and Relationship Name block naming the transferring management account and the name the transfer was given, and the charge detail is allocated to that account.The invoice receiver's own API view is narrower than the payer's. Run from the receiver account, the same
list-invoice-summaries call returns nothing until the filter also carries ReceiverRole=BUYER, which lists the invoices issued to that account together with Estimate- entries for periods still in progress; and get-invoice-pdf from the receiver fails with AccessDeniedException for the receiver's own invoices. In the console, the receiver's Bills page lists the same invoices with a download action on each row, so a receiver that only needs the documents can use the console, while anything that retrieves PDFs programmatically should run in the bill transfer account.
Both the payer and the invoice receiver can download the resulting invoices from the Bills page, and invoices are emailed to the billing contacts configured on the unit. Refunds and credit memos are issued to the account the original invoice went to.
Troubleshooting
ValidationException: accounts do not have valid transfer relationships
Adding a transferred organization to an invoice unit can fail with a
ValidationException, reported with the reason nonMemberPresent:1
2
3
An error occurred (ValidationException) when calling the UpdateInvoiceUnit
operation: One or more UCA accounts do not have valid transfer relationships
with the BTABTA is the bill transfer account that owns the invoice unit; UCA stands for Usage Consolidation Accounts, the service's name for the accounts listed in your rule (the same term appears in the tax-inheritance error quoted earlier). The error means at least one account in the BillSourceAccounts you submitted does not have a qualifying billing transfer with the account that owns the unit.The qualifying conditions are broader than the direct transfer list alone:
- A transfer qualifies from the moment it is
ACCEPTED, even if itsStartTimestampis still in the future. You can build invoice units for next month's onboarding today. - A
REQUESTEDinvitation does not qualify. Until the other side accepts, its source account is not a valid bill source. - A
WITHDRAWNtransfer keeps qualifying until itsEndTimestamppasses. End dates land on month boundaries, so an account whose transfer was withdrawn mid-month stays valid until the month closes, then starts failing. - A bill source must be a management account. A member account inside a transferring organization is never a valid bill source, even though the transfer covers its charges. Placing one of your own member accounts here produces this same error, not the wrong-field message below.
- Second-level sources qualify. If a mid-tier reseller transfers its bill to you and its own customers transfer to it, those customers' management accounts are valid bill sources in your units even though they never appear in your own inbound transfer list.
Match on the message, not the reason code.
nonMemberPresent is also returned for the unrelated wrong-field error described below, so the reason alone does not tell you which problem you have. This failure also comes back with no fieldList, whereas the wrong-field error populates fieldList with the offending account; an absent fieldList means you are looking at the set-wide transfer-relationship check.The check runs across the entire submitted set, and the error does not identify which account failed. That matters when updating an existing unit, because
UpdateInvoiceUnit resubmits every account already in the unit alongside the one you are adding. If an older account's transfer was withdrawn and its final month has ended, the update fails even though the new account is valid.Validate every account in the payload, not just the new one. List the transfers the bill transfer account currently holds and compare:
1
2
3
4
aws organizations list-inbound-responsibility-transfers \
--type BILLING --region us-east-1 \
--query "ResponsibilityTransfers[?Status=='ACCEPTED'].[Id,Source.ManagementAccountId]" \
--output textTwo details affect the comparison. The CLI does not auto-paginate this operation: a payer with a long transfer history gets 50 results and a
NextToken, and a valid account will look missing unless you keep calling with --next-token until the token disappears. And direct transfers are not the complete set: for each transfer ID in the output, list-inbound-responsibility-transfers --type BILLING --id <transfer-id> lists the transfers one level below it, whose source accounts are also valid. Anything present in your BillSourceAccounts array but absent from the combined direct and second-level results is the cause.⚠️ Before concluding that a transfer has failed to propagate, confirm the exact contents of the request you sent. Because the error covers the entire submitted set, the failing account may not be the one you changed.
An account you added earlier has silently disappeared from the unit
UpdateInvoiceUnit treats Rule as a complete replacement, not a delta. Submitting a rule containing one account leaves the unit with exactly that one account and discards everything else that was in it. There is no add or remove operation.Always read the current rule, modify it, and write back the full list:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ARN=<UNIT_ARN>
CURRENT=$(aws invoicing get-invoice-unit \
--invoice-unit-arn "$ARN" --region us-east-1 \
--query 'Rule.BillSourceAccounts' --output json)
UPDATED=$(python3 -c "
import json, sys
accounts = set(json.loads(sys.argv[1]) or [])
accounts.add(sys.argv[2])
print(json.dumps({'BillSourceAccounts': sorted(accounts)}))
" "$CURRENT" 444444444444)
aws invoicing update-invoice-unit \
--invoice-unit-arn "$ARN" --rule "$UPDATED" --region us-east-1If a unit's contents differ from the changes you intended, review the full rules submitted in recent updates. Use a point-in-time
AsOf read, or the console's snapshot history, to see what the unit held during an earlier period.ValidationException: selected linked accounts are not under the payer
This failure comes from placing an account in the wrong rule field, and it is distinct from the one above even though the reason code matches:
1
2
3
An error occurred (ValidationException) when calling the UpdateInvoiceUnit
operation: Selected Linked Accounts <[333333333333]> are not under the
Payer <111111111111>Putting an external management account into
LinkedAccounts fails because that list only accepts members of your own organization. Move those account IDs into BillSourceAccounts; both lists can stay populated in the same rule, so this is a move, not a choice between them.This error carries the same
nonMemberPresent reason as the transfer-relationship failure above, but it names the offending accounts in the message and repeats them in fieldList. Use that to tell the two apart: named accounts indicate a wrong-field problem, while "one or more" with no fieldList indicates a transfer-relationship problem across the whole submitted set. Note that the named error only fires for LinkedAccounts violations. The reverse case, one of your own member accounts placed in BillSourceAccounts, comes back as the set-wide transfer-relationship error, not this one.Your API calls or CloudTrail events appear to be missing
AWS Invoicing is a global service reached through a single endpoint in
us-east-1, and invoice unit ARNs carry no region at all, only the bill transfer account that owns the unit (arn:aws:invoicing::111111111111:invoice-unit/...). Passing a different --region does not fail and does not scope anything; the request still resolves to the us-east-1 endpoint and returns the same global data.CloudTrail records these events in
us-east-1. Searching for CreateInvoiceUnit or UpdateInvoiceUnit in another region returns nothing, so search us-east-1 before concluding that the calls never arrived.Further reading
- Customizing your invoice preferences with AWS invoice configuration
- Creating invoice units with AWS invoice configuration
- InvoiceUnitRule API reference
- BatchGetInvoiceProfile API reference
- Transfer billing management to external accounts
- Billing transfer quotas
- Billing transfer best practices
- Using payment profiles
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article