2026-03-27 · Azure Cost

How to Read an Azure Cost Management Billing Export

Azure Cost Management lets you export detailed billing data as a CSV, but the file you get back is not immediately obvious to work with. Column names are verbose, some columns overlap in confusing ways, and the cost column you want depends on whether you have reservations or savings plans in play.

This is a breakdown of what the Azure Usage Details export contains, which columns actually matter, and how to use them to find the source of a cost increase.

Where to Get the Export

Go to Cost Management in the Azure portal. From the left nav, choose Exports and create a new export with type Usage Details. You can scope it to a subscription, resource group, or management group. Set the format to CSV and choose a daily or monthly recurrence.

For cost spike analysis, you want two months of data: the month where the spike happened and the prior month for comparison. Download both and you have what you need.

Alternatively, you can use the one-time download inside Cost Analysis. Set the date range to a custom range covering two billing periods, then export from there.

The Columns That Actually Matter

Azure exports contain a lot of columns. Most of them are metadata or reserved for specific scenarios. Here are the ones you will use for cost analysis.

Date is the usage date for the row. Use this to group charges by billing period or by day when looking for when a spike started.

ServiceName and ServiceFamily identify the Azure service. ServiceFamily is the broad category like Compute, Storage, or Networking. ServiceName is more specific, like Virtual Machines or Azure SQL Database. For initial triage, ServiceName is the right grouping column.

MeterName and MeterCategory are the most important columns for detailed analysis. MeterCategory is similar to ServiceName. MeterName is specific: it tells you exactly what type of resource or operation generated the charge. Examples include D8s v5 for a specific VM size, LRS Managed Disks for locally redundant disk storage, or Data Transfer Out for egress. When you see a spike in a service, the MeterName tells you which component of that service drove it.

Quantity is the usage amount for that row. The units vary by meter: hours for compute, GB for storage, GB transferred for egress, millions for API operations.

UnitPrice is the effective price per unit after discounts. If you have a reservation covering a VM, the UnitPrice here will reflect the reservation rate, not pay-as-you-go.

CostInBillingCurrency is the actual cost charged in the currency your account is billed in. This is the column to use for summing up charges and comparing periods.

PayGPrice is the pay-as-you-go list rate for the meter before any discounts. Comparing PayGPrice against UnitPrice tells you whether a reservation or savings plan is in effect for a given row.

PricingModel tells you how the resource is being charged: OnDemand, Reservation, SavingsPlan, or Spot. This is useful for filtering to just on-demand charges to see what you would be paying without commitments.

ResourceName and ResourceId identify the specific resource. Use these after you have found the service and meter that caused the increase to pin it to a particular VM, database, or storage account.

ResourceGroupName is the resource group containing the resource. Useful when your subscriptions are organized by team or environment.

How to Use the Export for Spike Analysis

The core process is the same as AWS CUR analysis: compare two billing periods grouped by the same dimensions and sort by the largest cost increase.

Start by loading both months of Usage Details into a spreadsheet or a quick SQL query. Group by ServiceName and sum CostInBillingCurrency for each period. The service with the largest increase is your starting point.

Filter to that service and repeat the grouping by MeterName. The meter with the largest increase tells you exactly what type of charge drove it: if the service is Virtual Machines and the meter is D8s v5, someone spun up or left running more D8s instances than the prior month.

For volume versus price analysis, compare Quantity and UnitPrice across periods for the same meter. If quantity went up and unit price stayed flat, the spike is usage growth. If quantity is flat but unit price jumped, a reservation expired or pricing changed. If both moved, you need to split the delta into its two components.

Common Gotchas

Reservations appear as a separate charge type. When you buy a reservation, you will see an ReservationId populated on rows where that reservation is being applied. Rows without a ReservationId under a service that should be covered may indicate that usage exceeded your reservation capacity and fell back to on-demand rates.

Taxes are included in the export. Filter out rows where ChargeType equals Tax before doing cost analysis, otherwise tax changes can inflate your deltas.

The export covers one subscription at a time by default. If you have multiple subscriptions under an enterprise agreement, you need to export at the management group level or combine multiple exports to get a complete view.

The Limit of Manual Analysis

The approach above works, but building the comparison logic, handling CSV parsing, and doing the volume versus price decomposition correctly takes real time to get right. Edge cases pile up: new services with no prior period, reservations creating duplicate line items, tax rows inflating deltas.

If you are doing this once to investigate a specific spike, a focused SQL query or a pivot table gets you there. If it keeps happening and you want answers in seconds rather than an hour of query writing, that is the gap BillSpike fills. It supports Azure FOCUS exports today alongside AWS CUR files — upload your Usage Details export in FOCUS format and you get the same ranked driver breakdown, volume versus price attribution, and plain-English summary.


Analyze your own AWS cost spike at billspike.io