Business Challenge
Finance asks a reasonable question: can each department get its own invoice? The platform team opens Cost Management + Billing, finds that a Microsoft Customer Agreement billing account can hold several billing profiles and that each one produces its own monthly invoice, and creates four. Engineering, marketing, data, corporate IT. It takes about ten minutes and it does exactly what was asked.
The next invoice cycle produces two surprises. The total across the four invoices is higher than the single invoice was, for the same consumption. And a reservation bought with shared scope, which had been covering virtual machines across the estate, is now only discounting some of them.
Neither is a misconfiguration. Both are the documented behaviour of a billing profile, and both follow from the same fact: a billing profile is not a heading on a page. It is the unit Azure aggregates usage over, so it decides which price tier your consumption reaches and how far a shared discount travels.
A billing profile and an invoice section both look like ways to group costs, and the portal presents them one under the other. They are not the same kind of thing. Adding an invoice section changes how an invoice is laid out and who may create subscriptions. Adding a billing profile creates a second invoice and, with it, a second pricing pool. Grouping is free; splitting is not.
Architecture
#9 established that a Microsoft Customer Agreement puts three levels above the subscription. This post is about what each one owns.
Billing account — the agreement, and the ceiling on everything below
The billing account holds the commercial relationship: the sold-to details, and the country/region and currency that every billing profile beneath it inherits and cannot change. It is created at sign-up, and at that moment exactly one person has access to it — the user who signed up. Everything else is granted deliberately.
Two properties make this scope worth being careful with. Creating billing profiles requires billing account owner or contributor, so it is the level at which the invoice structure itself is decided. And permissions granted here inherit onto every profile and section below and cannot be removed at the lower level, because the lower assignment does not exist to remove — it is a consequence of the higher one. Microsoft's own guidance is to grant at the profile or section instead when that is all somebody needs.
Billing profile — one invoice, and one pricing pool
A billing profile represents an invoice and the billing information attached to it: payment methods, bill-to address, an optional PO number that prints on the invoice. A monthly invoice is generated at the beginning of the month for each profile, covering the previous month's usage and purchases.
It also carries three things that are not about paperwork at all:
- Azure plans are enabled here automatically when the profile is created, and every invoice section under it can use them. That is what a subscription is created against.
- Purchase policies live here. Disable reservation or Marketplace purchases on a billing profile and no subscription billed to it can make them.
- Usage aggregation happens here, which is the subject of the next section.
One operational detail worth knowing before an invoice goes overdue: past-due notifications go only to users with a role on that billing profile — owner, contributor or invoice manager. A second billing profile with nobody attached to it is a second invoice nobody is warned about.
Invoice section — a heading on the invoice, and the place vending is delegated
An invoice section is a grouping of costs within one profile's invoice. Every billing profile has one by default, and each section appears on the invoice with the charges it incurred that month. Creating more requires billing profile owner or contributor.
The reason this matters to an architect rather than to an accountant is the role list. Azure subscription creator — role ID 30000000-aaaa-bbbb-cccc-100000000006, whose entire permitted task is creating Azure subscriptions — exists at the invoice section scope and nowhere else. If a team is to create its own subscriptions without being able to see or touch anything else, an invoice section is the container that makes that grant possible.
It is also a deliberately narrow role. A subscription creator can create subscriptions and can cancel only the ones they created. They cannot read invoices, change section properties or see the rest of the account.
Why This Architecture Holds Up
Three consequences follow from the structure above, and only the first one is obvious.
Azure aggregates usage monthly for each billing profile separately, so tiered pricing is worked out per profile. Microsoft's own example: 100 TB of block blob storage on one profile bills 50 TB at 1.84 per TB and the next 50 TB at the second-tier 1.77, for a total of 180.5. Split that same 100 TB evenly across two profiles and each one bills 50 TB entirely at the first-tier 1.84 — 92.0 apiece, 184.0 in total. Identical consumption, 1.94% more, because of a decision made about invoice layout.
At 100 TB that is a rounding error. At the volumes where tiered pricing actually bites, and multiplied across every metered service with a tier, it is a standing tax on an organisational preference. It is also invisible in the usual place people look: each individual invoice is correct, and nothing on it says what the unsplit total would have been.
Shared reservations stop at the profile
A reservation with shared scope applies to subscriptions in a single billing profile and is not shared across profiles. Move half your virtual machines onto a second invoice and half your reservation coverage evaporates — with no error, and no change to the reservation itself.
Delegation only exists at the section
Subscription creator is an invoice section role. A landing zone that vends subscriptions per team needs a section per team, or it needs to hand out billing profile contributor — which also grants payment methods, policies and invoices.
Moving costs asymmetrically
An invoice section owner or contributor can move a subscription to a different section. Moving it to a different billing profile needs profile or account level rights. Sections are cheap to reorganise; profiles are a finance conversation.
Some things never move
You cannot change the invoice section for a reservation, a savings plan, or seat-based subscriptions. A reorganisation moves the subscriptions and leaves those where they were, which is exactly the sort of residue that makes a cost report stop reconciling.
The past is not editable
Re-linking a subscription to a different section or profile takes effect on the next invoice. Existing invoices cannot be amended to reflect it. So a cost-allocation model that is wrong for six months stays wrong for six months in the billing data, and any correction has to be applied downstream in whatever the organisation reports from. That is the strongest argument for getting the section layout roughly right early — not that it is hard to change, but that changing it is not retroactive.
The transition maps the old shape onto the new one rather than asking you to design it: departments become invoice sections, and department administrators become owners of the sections created for them. EA accounts have no equivalent and are not carried over — their subscriptions land in the invoice section for their department, and account owners become Azure subscription creators on it. So the structure an organisation ends up with is the one its EA had, inherited rather than chosen, which is worth reviewing rather than assuming.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Grouping costs by department, team or project | Invoice sections under one billing profile | Sections group without splitting the pricing pool. One invoice, one aggregation, headings for each group. |
| A second billing profile | Only when a genuinely separate invoice is required — a different legal entity, a different PO, a different payment method | It creates a second pricing pool and a second reservation boundary. Do it for a commercial reason, not a reporting one. |
| Letting teams create their own subscriptions | An invoice section per team, with Azure subscription creator granted on it | That role exists only at section scope, and it is narrow: create subscriptions, cancel only your own, see nothing else. |
| Where to grant finance and platform access | The lowest scope that covers the person's remit | Billing account roles inherit downward and the inherited assignment cannot be removed lower down. Over-granting here is not reversible in place. |
| Buying reservations with shared scope | Confirm which billing profile the covered subscriptions bill to first | Shared scope means shared within one profile. A later invoice split silently strips coverage from everything that moved. |
| Fixing a wrong cost allocation | Re-link now and correct history downstream | Changes apply to the next invoice only; issued invoices are never amended. The billing data keeps the old shape permanently. |
| Inheriting a structure from an EA transition | Review the sections you were given before building on them | Departments became invoice sections automatically. That mapping preserved the old org chart, which may not be the one you want to bill against. |
Closing Thought
The billing hierarchy looks like the most inert part of Azure — three nested containers whose only job is to make an invoice legible. Two of the three are load-bearing. The billing profile is the boundary Azure aggregates usage across, so it prices your estate and bounds your shared discounts. The invoice section is the only place the subscription-creation role exists, so it decides whether self-service is possible at all.
Both of those are decided by whoever answers a question from finance about invoice formatting, usually in an afternoon, usually without an architect in the room. It is worth being in the room.
#11 moves from what you are billed to what you are allowed: quotas and limits — which scope each one is counted at, which are hard and which are adjustable, and how to raise the ones that can be raised.
Comments