The estimate in the previous lesson said €17,450 a month. Contoso Airlines' July invoice says €17,800. A 2% deviation is an excellent estimate, but that is not the achievement: the achievement is that there is now an estimated figure to compare against, and a list of assumptions that explains every difference. What Nuria Peña needs from here on is the opposite of a hypothesis: what was actually spent, on which resource, by which team, on which day and why it is going up.

That is the job of Microsoft Cost Management, the free tool included with any Azure subscription. This lesson walks through all of it: the billing hierarchy and why it always gets confused with the resource one, cost analysis with its groupings and its forecast, the real breakdown of Contoso's invoice, the difference between actual and amortized cost, budgets with alerts and with automated responses, allocation between teams with the centro-coste tag, scheduled exports and anomaly detection. This is where the tagging discipline sown in module 1 and enforced by the hereda-centro-coste policy from module 4 pays off — with interest.

Reminder: every euro figure in this lesson is illustrative and fictitious. Real Azure prices change frequently and vary by region, currency and commercial agreement. Always check them in the official calculator.

1. The billing hierarchy versus the resource hierarchy
2. Cost analysis: views, groupings and forecast
3. The real analysis of Contoso's invoice
4. Actual cost versus amortized cost
5. Budgets, alerts and action groups
6. Automating the response to an exceeded budget
7. Cost allocation: showback, chargeback and what belongs to nobody
8. Scheduled exports and analyzing the cost data
9. Anomaly detection
10. Why the invoice never matches to the cent
11. Permissions: who gets to see cost
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

This is the classic confusion, and it produces half an hour of bewilderment in every organization that opens Cost Management for the first time. There are two different hierarchies, with different purposes, and they do not map onto each other.

The four billing levels, in Contoso's case:

• Billing account: the contract with Microsoft. Contoso has one, tied to its Microsoft Customer Agreement.
• Billing profile: the unit that generates an invoice, with its own payment method and its own currency. Contoso has one, Contoso Airlines Global.
• Invoice section: the grouping within the invoice, designed to separate departments. Contoso has two: Operaciones de plataforma and Proyectos digitales.
• Subscription: Contoso Airlines - Producción hangs off the first section; Contoso Airlines - Desarrollo and the Contoso Miles one hang off the second.

And the practical consequence to internalize: the invoice section and the management group are different things and they may not line up. A management group is a governance container where policies and RBAC are applied; an invoice section is a line in an accounting document. Contoso deliberately kept them aligned to stay sane, but nothing forces that, and in large organizations they diverge. If somebody asks "why doesn't the Contoso-Produccion management group appear on the invoice?", the answer is: because the invoice does not know it exists.

Cost analysis is the central screen in Cost Management. You open it from a subscription, a resource group, a management group or the billing profile itself, and the scope you choose governs everything you see.

The controls that matter:

The three views Contoso keeps saved and consults every week:

1. vista-coste-diario-produccion: daily granularity, grouped by service, scoped to Contoso Airlines - Producción. This is the one that reveals a jump on the exact day it happens, and therefore the one you cross-reference with AzureActivity to find out what changed.
2. vista-por-centro-coste: accumulated, grouped by the centro-coste tag, across the whole billing profile. This is Nuria's view.
3. vista-desarrollo-por-propietario: scoped to Contoso Airlines - Desarrollo, grouped by the propietario tag. This is the one that stops anybody leaving a machine running on a Friday.

Views are saved, shared with the team and pinned to the portal dashboard, exactly like the Azure Monitor workbooks in module 7. And here is where the tagging discipline pays off — in the good sense: grouping by tag only works if the tag is there. A resource with no centro-coste lands in a bucket called "untagged", and that bucket is precisely the money nobody claims. At Contoso that bucket was 34% of the spend before the hereda-centro-coste policy; after the assignment with the Modify effect started inheriting the tag from the resource group, it dropped to 3%.

Two warnings about tags in cost analysis that get learned the hard way. First: tags are not applied retroactively. Tagging a resource today does not re-tag last month's cost, so the history before the policy remains unallocated. Second: not every resource type propagates the tag to its usage record; some costs — traffic, certain network meters — reach the analysis untagged by nature, and those need the allocation from section 7.

From the command line, scope and queries are handled like this:

--type accepts ActualCost and AmortizedCost (section 4); --dataset-grouping accepts type="Dimension" for dimensions such as ServiceName, ResourceGroupName or ResourceLocation, and type="TagKey" for tags. The combination of these two queries answers the two questions that always get asked: "what are we spending on?" and "whose is it?".

With the first query run over the month of July, grouped by resource and sorted from largest to smallest, the result (illustrative and fictitious figures):

The readings of this table are the essence of the lesson:

• Five resources concentrate 48% of the invoice. This is the universal pattern: spending concentrates. Optimizing in alphabetical order, or starting with whatever annoys us most, is a waste of time. You start at the top.
• The third most expensive item is not a business service: it is observability. log-contoso-pro costs more than the entire bookings website. That does not mean it is wrong — it means it has to be sized deliberately, with the three levers from 07-02.
• The sixth item has no resource. Data transfer out remains invisible in any view grouped by resource; it only appears when you group by meter.
• The 40% "rest" is where silent waste lives: orphaned disks, unassociated IPs, forgotten environments. None of it hurts individually, which is exactly why nobody looks at it. That is the territory of Azure Advisor and Resource Graph (08-04).

A nuance Nuria grasped immediately and that is always worth explaining: the first two items are not a problem. They are the price of correct, signed-off architecture decisions. The problem would be not knowing they exist.

Cost Management offers two metrics that give different figures for the same month, and understanding the difference avoids sterile arguments with finance:

The effect is counterintuitive until you see it: with an active reservation, the actual cost of a VMSS can be €0 for months, which suggests the resource is free. It is not; it was paid for upfront. If allocation between teams were done with actual cost, the team that bought the reservation would carry everything and the others would enjoy apparently free resources.

Contoso's rule: actual cost to reconcile the month's invoice; amortized cost for everything else — per-resource analysis, allocation by centro-coste, unit cost calculation and month-to-month comparison. The saved views from section 2 use amortized, and it is written in their description so nobody gets confused.

A budget in Azure does not block anything. It is a threshold that fires notifications and, optionally, automation. It is worth saying out loud because the opposite expectation is common: "we set a €20,000 budget and we have spent €23,000". Yes, because a budget warns, it does not cut you off.

Contoso's budgets, derived from the estimate with the buffer from 08-01:

Three design decisions sit behind that table. First: there is a threshold on forecasted cost, not only actual, because warning at 100% of what has already been spent is by definition too late; the forecast tells you mid-month that the trend does not fit. Second: the low thresholds (50-60%) are not alarms, they are early signals, and they go to email, not to ag-guardia-contoso. Third: there is a budget per tag, which is how you budget a project that does not have its own subscription.

thresholdType accepts Actual and Forecasted, and contactGroups is what reuses ag-equipo-contoso, the action group created in 07-01: same Teams channel, same recipients, same severity discipline. There is no reason to invent a new channel for cost alerts; there are many reasons not to.

In production, a budget alert is information: a person decides. In development, Contoso decided it can be an action, because the risk of getting it wrong is acceptable and the pattern — somebody left something running — is always the same.

The action group invokes a runbook in aa-contoso-operaciones (07-04) that deallocates everything tagged horario=laborable in rg-contoso-reservas-dev, and posts the breakdown by propietario to Teams. Four indispensable safeguards before letting something like that touch resources:

• Scope bounded by tag and by subscription. The runbook filters on entorno=desarrollo and aborts if it finds any resource with entorno=produccion.
• Idempotence and a dry-run mode, exactly as it was built in 07-04.
• Warn before acting: the first time the threshold is crossed it warns; only if it is crossed again in the same month does it act.
• Documented reversibility: how you switch things back on, and who is allowed to.

The Logic Apps alternative (logic-contoso-presupuesto) is just as valid and sometimes preferable: the visual flow lets you insert a human approval in the middle, with a button in Teams, without writing code. The rule Contoso wrote: automation that switches things off, only in development; automation that warns, everywhere.

Sharing cost out between teams comes in two flavors, and confusing them starts fights:

Contoso started with showback for two quarters and moved to chargeback afterwards, which is the sensible order: charging somebody an amount they do not understand is the best way to make them reject the whole system.

The vehicle is the centro-coste tag, with CC-1042 for the bookings project and CC-2077 for Contoso Miles. With the hereda-centro-coste policy applying a Modify effect from the "Base de gobernanza de Contoso" initiative, 97% of the spend gets allocated automatically.

That leaves the 3% and, above all, it leaves the real problem: shared costs. Whose is fw-contoso-hub-pro? And log-contoso-pro? And fd-contoso-global? They belong to nobody, or to everybody, which is the same thing. That is what Cost Management's cost allocation rules exist for: they take the spend from a source — a subscription, a resource group or a set of tags — and split it among targets using a criterion:

The three golden rules Contoso adopted after the first argument: the criterion is agreed before it is applied, it is written down, and simple and accepted beats exact and disputed. Splitting proportionally to spend is imperfect but understandable; a model with fifteen coefficients is fairer on paper and nobody can defend it in a meeting.

The portal's cost analysis keeps limited history and does not let you cross cost with business data. That is what the scheduled export exists for: Cost Management drops a file into a storage account every day.

The destination is stlagocontosopro, the Data Lake from module 3, and from there the data is just data: syn-contoso-analitica-pro queries it with serverless SQL over the files in the container, it gets joined with the table of bookings sold and out comes the unit cost that 08-05 will work on. Watch the irony: querying that lake badly with Synapse serverless costs money, so cost analysis itself has a cost. Contoso partitions by date and reads only the current month.

The columns of the exported file that get used most:

Two other ways of getting at the same data. The Cost Management API (Microsoft.CostManagement/query and /exports) lets you integrate it into your own tooling, with the caveat that it is rate-limited and is not designed for massive interactive querying. And the Power BI connector for Cost Management, which is what Nuria uses: it connects to the billing profile, pulls the usage detail and lets her build the monthly report without depending on anybody. When finance can answer its own questions, engineering stops being a bottleneck — and that, in itself, is half of a FinOps culture.

Cost Management includes anomaly detection based on the subscription's historical spending pattern. It is not a fixed threshold: it learns the usual shape of the spend and warns about significant deviations, with an explanation of the service and scope causing it. It is free and it is configured as an anomaly alert with recipients.

It complements the budget, it does not duplicate it:

That example is real inside the story: nobody would have noticed the extra €150 a day inside a €20,000 budget, and yet it was sqlpool-contoso left switched on and forgotten after a one-off analysis. A budget detects the big problem; an anomaly detects the problem early. The workflow when it fires: look at the daily view grouped by service, identify the day, cross-reference with AzureActivity in log-contoso-pro to find out who changed what, and act.

Sooner or later, somebody compares cost analysis with the invoice PDF and finds a difference. The causes are well known and none of them is a bug:

• Period: the invoice covers the billing period, which does not always match the calendar month.
• Taxes: cost analysis shows amounts excluding VAT; the invoice includes it. It is the most common difference and the easiest to explain.
• Credits and discounts: promotional credits, Enterprise balances and negotiated discounts are applied on the invoice, not always in the analysis.
• Rounding: rounding happens per usage line, and there are tens of thousands of lines.
• Third-party Marketplace purchases: they appear on the invoice and are shown separately in the analysis.
• Reservations: the upfront payment appears in full in actual cost and spread out in amortized (section 4).
• Data latency: usage takes a few hours to consolidate; the last days of the month get adjusted.

The rule: cost analysis is for deciding; the invoice is for paying. Expecting them to match to the cent is a waste of time. What does have to match is the order of magnitude and the trend, and if they do not match there, then there really is something to investigate.

Access to cost is governed by the RBAC from module 4, with the particularity that there are cost-specific roles that grant no access to the resources at all:

Two details that avoid surprises. First: under a Microsoft Customer Agreement, access to the invoice is granted in the billing hierarchy, not in the resource one — that is, being Owner of the subscription does not give you access to the invoice PDF. Second: there is a billing-account-level option that hides prices from subscription users; if a colleague can see usage but not amounts, that is almost certainly it and not a role problem.

Assigning the role to the Microsoft Entra ID group and at the management group, rather than person by person and subscription by subscription, is the same good practice from module 4 applied here.

• Confusing the billing hierarchy with the resource one. The invoice section is not a management group, and a management group does not appear on the invoice.
• Believing a budget blocks spending. It does not. It warns, and at most it triggers automation you build yourself.
• Analyzing cost with ActualCost when you have reservations. You will see apparently free resources and absurd allocations. Use AmortizedCost for everything except reconciliation.
• Grouping by tag before you have reliable tagging. The "untagged" bucket will tell you the truth about your governance, and it will not be pleasant.
• Expecting tagging today to fix the history. It is not retroactive.
• Fighting over the cent of difference between the analysis and the invoice instead of looking at taxes, period and credits.
• Splitting shared costs with no prior written agreement. It is the longest and least productive argument in FinOps.
• Tip: create a daily view grouped by service today and pin it to the dashboard. It is the one that tells you when something changed, which is usually more useful than how much.
• Tip: switch anomaly detection on even if you have budgets. They detect different things.
• Tip: give Cost Management Reader to plenty of people. Hidden cost does not get optimized, and nobody has ever broken anything by looking at an invoice.

Exercise 1. Design the set of budgets for Contoso Miles (centro-coste=CC-2077), which has €900/month approved and shares a subscription with other projects. State the scope, filters, thresholds, threshold type, recipients and what automation you would put in place — and what you would not.

Exercise 2. Cost analysis shows €17,800 in July and the invoice says €21,900. List the possible causes in order of probability and describe how to check each one.

Exercise 3. Marta has to split July's shared costs between CC-1042 and CC-2077: fw-contoso-hub-pro (€1,010), log-contoso-pro (€1,640) and bastion-contoso-pro (€205). She knows that CC-1042 generates 85% of the direct spend and 78% of the GB ingested, and that both teams use the bastion occasionally. Propose the split, justify each criterion and explain what objection you expect from each team.

Solution 1: since the subscription is shared, the scope has to be the subscription with a filter on the centro-coste=CC-2077 tag; a resource group budget is no good if the project has resources in several. Thresholds: 50% actual as an early signal to the project lead only; 80% actual to the lead and to Marta; 100% forecasted to Nuria, because warning about the trend mid-month is the only thing that allows a reaction; and 110% actual as a record that it has overshot. Recipients by email plus contactGroups pointing at ag-equipo-contoso, without using ag-guardia-contoso: a budget overrun never justifies waking anybody up. Automation: nothing that switches anything off, because the project has production resources and Contoso's criterion is that automated shutdown is only for development; a Logic App that posts the breakdown by propietario to Teams and opens a ticket, yes. An indispensable prerequisite: verify that the hereda-centro-coste policy covers the project's resource groups, because a budget filtered by tag only sees what is tagged, and an untagged resource would spend off the radar.

Solution 2: in order of probability. (1) VAT: 17,800 × 1.21 = €21,538, very close to the difference; cost analysis shows amounts excluding tax and this is almost certainly the main cause. You check it by looking at the tax line on the PDF. (2) A billing period different from the calendar month: you check it in the invoice header and rerun the analysis with a custom range that matches. (3) Third-party Marketplace purchases — a virtual firewall image, a license — which appear on the invoice and are listed separately in the analysis. (4) The wrong scope: the analysis was run over one subscription while the invoice covers the entire billing profile, which also includes Contoso Airlines - Desarrollo; you check it by switching the scope to the billing profile. (5) Consolidation latency if the analysis was run before the month closed. (6) Credits applied in one direction or the other. The method: reproduce the analysis with scope "billing profile", a range equal to the invoice period, type ActualCost and no filters, and compare then; the remaining difference will be taxes.

Solution 3: log-contoso-pro is split proportionally to GB ingested (78%/22%): €1,279 to CC-1042 and €361 to CC-2077. It is the most defensible criterion because the quantity being split is exactly the one that gets billed, and it is measurable with the Usage table grouped by _ResourceId (07-02); if a team disputes it, you show them the query. fw-contoso-hub-pro is split proportionally to direct spend (85%/15%): €859 and €152. It is not exact — the firewall processes gigabytes, not euros — but measuring traffic by origin would require flow logs and their own ingestion, which would cost more than the precision it adds; it is documented as an accepted approximation. bastion-contoso-pro is split in equal shares: €102.50 each, because usage is occasional, not measurable without effort, and the amount is small; arguing about it costs more than paying it. Expected objections: CC-2077 will argue that the firewall was deployed before Miles existed and that its traffic is marginal — answer: the criterion is proportional to spend, it is reviewed every six months, and if they bring a better measurement it gets changed; CC-1042 will argue that it pays 85% of an infrastructure that enables others — answer: that is the flip side of the unit cost going down for everybody when it is shared. And the underlying rule: the split is agreed before the month closes and published in the monthly review (08-05); it is never communicated for the first time alongside the amount.

You can now tell the two hierarchies apart — billing account, profile, invoice section and subscription, against management group, subscription, resource group and resource — and you know they only touch at the subscription, which explains half a dozen questions that always come up. You can use cost analysis with its real controls: scope, date range, daily or accumulated granularity, grouping by service, location, resource group, meter and tag, filters, forecast and saved views, with Contoso's three views as a template. And you have seen the exact value of tagging: the "untagged" bucket went from 34% to 3% thanks to the hereda-centro-coste policy from module 4, with the two warnings that tags are not retroactive and that certain meters never carry them.

You have the real breakdown of Contoso's invoice: €17,800 in July, with five resources concentrating 48% — sql-contoso-reservas-pro with its replica, aks-contoso-operaciones, log-contoso-pro, vmss-api-disponibilidad-pro and fw-contoso-hub-pro — data transfer out as the sixth item with no resource to look at, and a 40% long tail where the silent waste lives. You know that spending concentrates and that this is why you optimize from the top down, and that the most expensive items are not necessarily problems: they are architecture decisions with a visible price. You can distinguish actual cost from amortized cost and why, with reservations in place, actual cost lies about what each resource costs.

Operationally you carry Contoso's budgets with their thresholds on actual and forecasted cost, reusing ag-equipo-contoso, the automated response in development with the Detener-IniciarEntornosDev runbook and its four safeguards, and the rule that governs them: automation that switches things off only in development, automation that warns everywhere. You know how to allocate with showback before chargeback, with centro-coste as the vehicle and allocation rules for shared costs, preferring a simple agreed criterion to an exact disputed one. And you know how to get the data out — daily exports to stlagocontosopro, the API and Power BI — how to switch on the anomaly detection that found sqlpool-contoso running, how to explain why the invoice does not match to the cent, and how to hand out cost permissions without granting access to the resources.

With the invoice measured and allocated, the conversation changes its question. It is no longer "how much are we spending?", but "how much of this could we not spend without changing anything we do?". And the first answer, the biggest and the most immediate, does not require touching a single line of architecture: it is enough to commit. db-reservas, the aks-contoso-operaciones nodes, the Premium v3 plans and the VMSS baseline have been running for months at pay-as-you-go rates, the most flexible and the most expensive there is. The next lesson is about reservations, savings plans, spot instances and Azure Hybrid Benefit: what they are, how they differ, how much they discount, what Contoso commits to buying and what it deliberately leaves on demand — and why reserving before the architecture stabilizes is the most expensive way there is to save money.