Start with the idea, then look at the pieces inside it.

A billing account is the top-level record of your commercial relationship with Microsoft for buying Azure and other Microsoft cloud services. It holds the agreement you signed or accepted, the people who may manage the money side, the payment details, and the invoices. Everything that costs money in Azure eventually traces back to a billing account.

It is important to separate two ideas that beginners often mix. The technical side of Azure answers “What did we build, and who can manage it?” The billing side answers “Who pays, how do they pay, and which invoice does this cost appear on?” A subscription is the link between the two sides. It holds technical resources and is attached to a billing arrangement.

Money problems in the cloud are rarely about price. They are usually about confusion.

A single developer experimenting at home hardly needs a billing structure. A company with thirty teams, several countries, and a finance department needs much more. Finance wants one clear invoice per department. Managers want to know their own spending. Security wants to ensure that only trusted people can change payment details. Auditors want records.

Without a thoughtful billing setup, companies end up with scattered personal credit card subscriptions, invoices nobody can match to a team, unexpected charges, and delays when someone leaves and takes the only access to the bill with them.

Billing has its own vocabulary. Learn these terms once.

Different customers sign different kinds of agreements.

The kind of billing account you have depends on how you bought Azure. Microsoft has updated its commercial models over the years, so some older types still exist beside newer ones. The list below is a beginner’s map. Always confirm the current options on Microsoft’s official billing pages, because naming and availability change over time.

How to tell which type you have

In the Azure Portal, the Cost Management + Billing area shows your billing accounts and indicates their type, such as individual, Microsoft Customer Agreement, or Enterprise Agreement. If you see words like billing profiles and invoice sections, you are probably on a Microsoft Customer Agreement. If you see enrollment, departments, and accounts, you are likely on an Enterprise Agreement.

The modern model uses clear layers.

In a Microsoft Customer Agreement, the billing account is the top. Under it you create one or more billing profiles. Each billing profile gets its own invoice and its own payment method. Under each profile you create invoice sections, which group the costs inside that invoice. Subscriptions are then created under an invoice section, so their charges appear on that line of the right invoice.

flowchart TD
    BA["Billing Account - agreement with Microsoft"] --> BP1["Billing Profile - North America - own invoice and payment method"]
    BA --> BP2["Billing Profile - Europe - own invoice and payment method"]
    BP1 --> IS1["Invoice Section - Engineering"]
    BP1 --> IS2["Invoice Section - Marketing"]
    BP2 --> IS3["Invoice Section - Operations"]
    IS1 --> S1["Subscription - Engineering Production"]
    IS1 --> S2["Subscription - Engineering Development"]
    IS2 --> S3["Subscription - Marketing Website"]
    IS3 --> S4["Subscription - Operations Tools"]
    

Why have more than one billing profile?

Companies create multiple billing profiles when they need separate invoices. Common reasons include different countries or legal entities that must be billed separately, different currencies, different payment methods, or different cost centers whose finance teams want their own invoices.

Why have invoice sections?

Invoice sections do not create separate invoices. They create separate lines and totals inside one invoice. This is perfect when finance wants one monthly invoice for the company, but also wants to see sub-totals for engineering, marketing, and operations.

Large organizations often have a long-standing model with its own words.

An Enterprise Agreement, or EA, is a contract between Microsoft and a large organization, usually lasting three years. The organization commits to a certain level of spending, often in exchange for better prices. The structure uses an enrollment at the top, departments beneath it, accounts under the departments, and subscriptions under the accounts.

flowchart TD
    ENR["Enrollment - the Enterprise Agreement"] --> D1["Department - Finance Systems"]
    ENR --> D2["Department - Product Engineering"]
    D1 --> A1["Account - owner is a finance lead"]
    D2 --> A2["Account - owner is an engineering lead"]
    D2 --> A3["Account - owner is a data team lead"]
    A1 --> SUBA["Subscription"]
    A2 --> SUBB["Subscription"]
    A2 --> SUBC["Subscription"]
    A3 --> SUBD["Subscription"]
    

EA roles

The simplest billing account, and where many learners begin.

When an individual signs up for Azure on the web with a credit card, a billing account of the simple individual type is created. The person who signed up becomes the account administrator. This person can see the bill, update the card, and create or cancel subscriptions attached to the account. Subscriptions under it are billed to the same card at the end of each billing period.

This is the most important idea for avoiding confusion and risk.

Azure uses two different permission systems that are easily confused. Azure role-based access control, or RBAC, decides who can manage Azure resources, such as creating a virtual machine or deleting a database. Billing roles decide who can manage the money side, such as viewing invoices, changing payment methods, or creating new subscriptions.

Roles in a Microsoft Customer Agreement

Roles can be given at the billing account, billing profile, or invoice section level, and they flow downward. Typical roles include Owner, who can manage everything at that level, Contributor, who can manage most things except access, Reader, who can only view, Invoice manager, who can view and pay invoices at billing profile level, and Azure subscription creator, who can create subscriptions under an invoice section.

What happens between running a server and receiving an invoice?

Every Azure service measures its use in units called meters. A virtual machine is metered by the hour or second, storage by the gigabyte per month, and network traffic by the gigabyte leaving Azure. Each resource sends its usage records to the Azure billing system continuously. At regular intervals, these records are combined, priced using the rates from your agreement, adjusted for discounts and credits, and attached to the subscription and billing structure.

sequenceDiagram
    participant R as Azure Resources
    participant M as Metering System
    participant P as Pricing and Discounts
    participant B as Billing Account Structure
    participant C as Cost Management
    participant F as Finance Team
    R->>M: Send usage records continuously
    M->>P: Combine usage by meter and time
    P->>P: Apply price, reservations, credits, and taxes
    P->>B: Attach charges to subscription, invoice section, and profile
    B->>C: Make cost data available for analysis
    C-->>F: Show daily costs, budgets, and forecasts
    B->>F: Produce invoice at end of billing period
    

Billing periods and delays

A billing period is the span of time covered by one invoice, usually a month. Cost data in the portal is not always instant. It can arrive with delays of several hours, and final numbers may change slightly as usage records are completed. Do not panic if today’s number looks incomplete.

Currency, tax, and invoices

The invoice currency is decided by the billing profile or agreement. Taxes such as sales tax or value added tax depend on the country and the legal details of the buyer, and they appear as separate lines. Large organizations can download invoices, usage files, and tax documents from the portal, and many connect them to their accounting systems.

Payment methods

Who may create a subscription, and where does it land?

When someone creates a new subscription, they must choose where its charges will go. In a Microsoft Customer Agreement, they select the billing account, billing profile, and invoice section. In an Enterprise Agreement, they use an enrollment account. A person needs the proper billing permission to do this. Without it, the option may be missing or blocked.

Transferring billing ownership

Sometimes a subscription needs to be billed to a different place. For example, a project moves between departments, a start-up is acquired, or a personal test subscription becomes an official one. Azure supports billing ownership transfer in many cases, where the new owner accepts the subscription into their own billing arrangement. Not every combination of agreement types supports a transfer, so always read the current instructions.

Cancelling and what happens to charges

Cancelling a subscription stops future charges for new usage, but any usage already recorded in the billing period is still billed. Also, long-term commitments such as reservations may continue separately, because they are billed on their own. Check each item before you assume costs will stop.

The billing account is the best place to see the whole picture.

Microsoft Cost Management lets you view and analyze spending at different scopes. A scope is the level you are looking from. You can look at one resource group, one subscription, an invoice section, a billing profile, or the entire billing account. The higher the scope, the bigger the picture, and the more permission it requires.

flowchart TD
    BAS["Billing Account scope - whole company view"] --> BPS["Billing Profile scope - one invoice"]
    BPS --> ISS["Invoice Section scope - one department"]
    ISS --> SUBS["Subscription scope - one environment or product"]
    SUBS --> RGS["Resource Group scope - one project"]
    RGS --> RS["Resource scope - one item"]
    

Useful tools

Showback and chargeback

Showback means showing each team how much it spent, without moving money. Chargeback means actually billing the team’s internal budget for its usage. Both rely on clean structure, either through separate invoice sections and subscriptions, or through consistent tags, which are small name-and-value labels, such as “cost-center” and “owner,” placed on resources.

Start with the questions finance will ask.

A good structure answers practical questions. How many invoices does finance want each month? Do any countries or legal entities need separate invoices? Which teams need separate cost views? Who needs authority to create subscriptions? Which cost centers will pay?

The money side deserves protection as much as the technical side.

Someone with high billing permissions can change payment methods, create many subscriptions, or move subscriptions to other places. Someone who gains full Azure access can also create expensive resources in minutes. Both risks need controls.

• Limit billing owners. Keep the number of people with owner rights at billing account level very small.
• Use groups where possible. Where the billing system supports groups, assign roles to groups so people can be added and removed easily.
• Protect the accounts. Require multi-factor authentication, where a second proof such as a phone approval is needed, for anyone with billing authority.
• Avoid personal accounts. Use work accounts tied to the company directory, so access ends when employment ends.
• Watch for changes. Send billing and activity logs to central monitoring and alert on new subscriptions, role changes, and sudden spending jumps.
• Control who can create subscriptions. Allow it only through a request process, or an automated one, so every new subscription has an owner, a budget, and a name that follows the rules.
• Use Azure Policy. Restrict regions and expensive sizes where sensible, and require cost tags.
• Keep contact information current. Make sure the billing contacts and notification emails belong to shared mailboxes or active staff, not to a person who may leave.

More structure brings clarity and also effort.

The central trade-off

A simple structure is fast to start and easy to explain, but it may blend costs together. A detailed structure shows costs precisely, but requires more care to set up and keep tidy. The sensible middle path is to start simple, mirror the way the business is organized, and add layers only when a real need appears, such as a new country or a new department that wants its own numbers.

These mistakes appear again and again.

Most problems have simple explanations.

A short list for a healthy billing setup.

• Know your agreement type. Confirm whether you have an individual, Microsoft Customer Agreement, Enterprise Agreement, partner, or reseller arrangement.
• Design with finance. Build profiles and invoice sections around real invoices and cost centers.
• Use company accounts only. Tie billing access to work identities and groups.
• Keep owners few and backed up. Document who they are and how to reach them.
• Separate billing and technical roles. Grant each carefully and review both regularly.
• Align subscriptions with the billing layout. Mirror departments and environments consistently.
• Require tags. Enforce owner, project, and cost-center tags with Azure Policy.
• Set budgets and alerts. Do it at the billing, subscription, and project levels, with real recipients.
• Review commitments. Track reservations, savings plans, and prepaid balances, and check their usage.
• Check invoices monthly. Compare them with cost analysis and investigate surprises quickly.
• Automate subscription creation. Use a standard request flow that sets names, budgets, tags, and roles.
• Re-verify contacts and payment methods every quarter.

How different organizations use billing accounts.