Billing accounts and hierarchies

A billing account is the provider-side entity that receives invoices and pays for a group of accounts, subscriptions or projects: on AWS the management account of an organization, on Azure the billing account with its billing profiles, on Google Cloud the Cloud Billing account. The hierarchy beneath it decides who receives an invoice, whose usage is pooled for volume discounts, how far reservations reach and who sees which cost. It is the first layer of cost allocation, before any tag.

How it works

AWS

Every organization in AWS Organizations has a management account that pays the charges of all member accounts; export columns and older pages call it the payer account. Consolidated billing produces one bill per seller of record and combines usage across all accounts, so volume discounts, Reserved Instances and Savings Plans are shared, at no extra fee. The management account controls discount sharing under Billing preferences, in the section Reserved Instances and Savings Plans discount sharing preference by account: on or off per account, or for groups of accounts defined with Cost Categories. Separate invoices come from AWS invoice configuration: invoice units are mutually exclusive groups of accounts with a receiver account, up to 500 per payer account, each with its own invoice, billing contacts and purchase orders. They inherit the payer's payment method and terms, AWS states that management and member accounts are jointly and severally liable, and changes take effect from the next month's invoice. In CUR 2.0 the paying account sits in bill_payer_account_id, the using account in line_item_usage_account_id and the invoicing entity in bill_invoicing_entity.

Azure

A billing account is created at sign-up, and its type sets the hierarchy. Under the Microsoft Online Services Program (pay-as-you-go) the invoice is generated per subscription. Under an Enterprise Agreement the billing account is the enrollment, with optional departments, accounts that each have an account owner, and subscriptions; the invoice is generated per enrollment. Under a Microsoft Customer Agreement the billing account holds billing profiles and invoice sections. A billing profile represents an invoice with its payment method and billing address and receives its own invoice at the start of each month; an invoice section groups cost within that invoice, and subscriptions and purchases such as Marketplace products attach to it. Microsoft creates one of each automatically and more can be added, with two consequences: tiered prices are calculated per billing profile, not aggregated across profiles, and reservations with shared scope apply only within one profile. Subscriptions can move between invoice sections; reservations, savings plans and seat-based subscriptions cannot, and a move leaves existing invoices unchanged. A Microsoft Partner Agreement has billing profiles, one per currency, and the CSP partner's customers. An MCA enterprise account can add associated billing tenants so that users in other Microsoft Entra tenants get roles on the billing account. In the cost details, BillingAccountId, BillingProfileId (EA enrollment, pay-as-you-go subscription or MCA billing profile), InvoiceSectionId (EA department or MCA invoice section) and SubscriptionId carry the hierarchy; the console's scopes are covered in Azure Cost Management and Billing.

Google Cloud

Google keeps the resource hierarchy and billing apart. The hierarchy runs from the organization resource at the root through folders to the projects that hold the resources, and IAM roles are inherited downwards. The Cloud Billing account sits alongside: it defines who pays for a set of resources, is linked to one or more projects and pays through a Google payments profile. Ownership of a billing account is limited to one organization, but it can pay for projects in other organizations. Subaccounts are intended for resellers; the parent account pays and must be on invoiced billing. Each account runs in one currency (see Invoice currency and exchange rates). When a project moves to another billing account, charges before the move go to the old account and charges after it to the new one. The export carries billing_account_id, project.id and, in project.ancestors, the path through folders and organization.

The equivalents

FOCUS calls the paying entity BillingAccountId, assigned by the invoice issuer, and the using entity SubAccountId, assigned by the service provider. Its appendix on grouping constructs maps the providers as the table shows and names no equivalent for Azure EA.

What it means for your cost

The hierarchy is the cost allocation that works without tags: every export reliably carries the member account, subscription and project, and anything finer needs tags and labels. Account boundaries drawn along teams, products or environments yield much of the allocation straight from the billing data; boundaries drawn by history leave the work to tags.

Three decisions follow from the hierarchy. The number of invoices: every invoice unit, billing profile and Cloud Billing account produces its own document each period, built as Anatomy of a cloud invoice describes. The reach of discounts: on AWS, reservations and Savings Plans apply across the organization as far as sharing is active; on Azure MCA within one billing profile, which is also where tiered prices are calculated. A second billing profile can therefore cost more than a second invoice section, which separates the cost on the same invoice. Visibility: the management account, the Azure billing account and the Cloud Billing account see everything; below them the consoles' scopes, on AWS in Cost Explorer, decide who sees what.

A move between payers splits the history. A member account that leaves its organization loses access to the Cost Explorer data from its time there, while the management account keeps it; how long exports hold the past is the subject of the page on billing data retention. What the agreement above the billing account governs is in Enterprise agreements and private pricing.

Where it goes wrong

• A second billing profile instead of an invoice section. Symptom: after two departments are separated, storage cost rises without extra usage and a reservation covers less than before. Cause: Azure calculates tiered prices per billing profile and applies shared-scope reservations only within one profile.
• Discount sharing switched off. Symptom: one account pays on-demand rates while reservations sit unused in the next. Cause: sharing is deactivated for one of the accounts under Billing preferences, or Restricted Group Sharing keeps the discount inside a group; the export then shows the usage as Usage instead of DiscountedUsage or SavingsPlanCoveredUsage.
• Payer confused with user. Symptom: all cost lands on the management account or the billing account, and allocation by team stays empty. Cause: the report groups by bill_payer_account_id or billing_account_id instead of line_item_usage_account_id or project.id.
• Moved in mid-month. Symptom: two invoices for one month, and neither matches the team's export. Cause: Google bills charges from before a project move to the old billing account, changes to AWS invoice units take effect only on the next month's invoice, and on Azure a move leaves existing invoices unchanged.

Sources

Read on 2026-10-16. AWS Consolidating billing for AWS Organizations, Reserved Instances, Reserved Instances and Savings Plans discount sharing, Customizing your invoice preferences with AWS invoice configuration, Quotas and restrictions, Bill columns, Line item columns; Microsoft View your billing accounts in Azure portal, Organize your invoice based on your needs, Manage billing across multiple tenants, Understand usage details fields; Google Cloud About resource hierarchy, Cloud Billing overview, Enable, disable, or change billing for a project, Structure of Standard data export; FOCUS 1.4 Billing Account ID, Sub Account ID, Grouping Constructs for Resources or Services.