Billed Cost vs Amortized Cost: Why Your Cloud Reports Don’t Match

On November 6, 2026, AWS added support for amortizing the upfront fee for EC2 Capacity Blocks for ML in CUR 2.0 and Cost Explorer. Until then the fee appeared as a single charge on the purchase date. In the amortized view it is now spread across the duration of each reservation, so you can see the cost of each instance launched into a block and the cost of capacity nobody used.

The update is a useful reminder of a broader FinOps problem: one month of cloud spend can produce several different-looking numbers depending on whether you are looking at the invoice, a non-amortized analytical view, or an effective-cost view. This post explains why the invoice, Cost Explorer and your FinOps dashboard can disagree, and how to reconcile them in a way you can show to finance.

The short answer: billed cost follows the cash, amortized cost follows the usage

Billed cost, also called cash-basis cost, records a charge when it hits the bill. AWS puts it plainly: “Billing data is always presented on a cash basis.” Buy a one-year, all-upfront Savings Plan in September and the whole fee lands in September. It is the right basis for validating and paying an invoice, and for forecasting cash.

Amortized cost is an effective-cost view that spreads eligible upfront and recurring commitment fees over the relevant period and attributes them to the usage they cover. In AWS’s words, Cost Explorer’s amortized view reflects “the effective cost of the upfront and monthly reservation fees spread across the billing period.” It is better suited to asking what a workload costs over time.

Both views are valid, for different questions. For the same eligible commitment economics, billed and amortized views generally represent the same underlying spend over the relevant term. What changes is when and where that cost is recognized. Neither is the invoice, though: the invoice also reflects tax, credits and refunds and follows its own finalization schedule. Refunds, credits, unused commitment, provider-specific treatment and report scope can all separate any two totals, which is why a reconciliation needs named steps rather than a hunch.

A translation table: AWS, Azure and FOCUS

The names are close without being identical. Google Cloud is left out of this table on purpose, because its model does not translate; the Google Cloud section below explains why.

Read the first two AWS rows as different things. Billing data is the invoice and the Bills page. Cost Explorer’s unblended cost is the cost of the usage, with discounts broken out as their own line items when you group by charge type, and commitment fees on the day they are charged. It is an analytical view, not the invoice, which also carries tax, credits and refunds. On Azure, Actual Cost includes reservation purchases and gives covered usage an effective price of zero, while Amortized Cost has no purchase records. The FOCUS cell on the unblended row says “nearest” because the two are defined differently: unblended is a rate multiplied by usage, while BilledCost is what the invoice issuer invoiced, and it is zero for a charge that a covering charge fully covers.

AWS worked example 1: an all-upfront Savings Plan

Suppose you buy a one-year, all-upfront Savings Plan in September for $8,760, an illustrative $1.00-per-hour commitment paid in full on day one, and your workloads use all of it. AWS describes this case: the purchase “will be spread evenly across the 12 months of the commitment term” in the amortized view.

On a cash basis, finance sees one large SavingsPlanUpfrontFee in September and nothing after, so October’s compute looks nearly free. On an amortized basis every month carries $730, allocated to the usage the plan covered. In this example, where the commitment is fully used, the term totals match. The month-by-month story does not.

AWS worked example 2: a partial-upfront Reserved Instance

AWS’s Cost Explorer documentation uses a smaller case: a Partial Upfront t2.micro Reserved Instance on a one-year term, $30 upfront and a $2.48 monthly fee. By default, Cost Explorer shows RI fees “as a spike on the day that you’re charged.” Switch to amortized costs and, for a 30-day month, the chart shows a daily effective rate of $0.165.

Our arithmetic, as a check: $30 over 12 months is $2.50 a month, which with the $2.48 recurring fee is about $4.98 a month, or roughly 16.6 cents a day, in line with AWS’s figure. In the CUR 2.0 rows, the $30 is a Fee line item, the monthly charge is an RIFee line item, and covered usage appears as DiscountedUsage with an unblended rate of zero. The amortized figure sits on those usage rows as reservation_effective_cost.

Watch for unused capacity. In the amortized daily view, Cost Explorer shows “the unused portion of your upfront reservation fees and recurring RI charges on the first of the month,” and AWS suggests grouping by purchase option to see how much went unused. A first-of-month spike is not necessarily a purchase. It can be the unused part of a reservation.

Reading the AWS line items

A CUR query can misstate totals when it sums the wrong cost column or keeps one half of a paired set of rows. These are the line item types behind most of those mistakes, paraphrasing AWS’s CUR 2.0 documentation.

• ◦Fee and SavingsPlanUpfrontFee. The upfront payment for an RI or Savings Plan, shown in full on the purchase date.
• ◦RIFee. The monthly recurring RI fee. It can be $0 for all-upfront RIs but still carries the amortization columns.
• ◦DiscountedUsage. Usage covered by an RI. The unblended rate is 0 on covered EC2 and RDS lines, so it looks free in unblended cost.
• ◦SavingsPlanRecurringFee. Recurring hourly charges for a No Upfront or Partial Upfront plan, added on the purchase day and then on the first day of each billing period.
• ◦SavingsPlanCoveredUsage and SavingsPlanNegation. Covered usage is the on-demand cost a Savings Plan covers, and negation items offset it. They come as a pair, so filtering out one half gives the wrong total.

The reconciliation bridge: from invoice to amortized cost

A usable reconciliation starts at the number you owe and walks toward the number your report shows, naming every difference on the way. Not every step applies to every account; with no credits, commitments or refunds, most of this is zero. Here is what can sit between an invoice and a cost report, using AWS’s documentation.

• ◦Estimated versus finalized. Billing data and Cost Explorer data refresh at least once a day, possibly on different cadences, so month-to-date figures can differ. AWS can also update a CUR after finalization if it applies a credit or refund for the month after finalizing the bill.
• ◦Refunds and tax. The Bills page excludes refunds in its charges-by-service view, while Cost Explorer includes them. If part of your tax is refunded, the Bills page keeps the full tax amount and Cost Explorer shows the post-refund amount.
• ◦Credits and discounts. Credit, Discount and BundledDiscount are separate line item types. line_item_net_unblended_cost is the after-discount cost and appears only when your account has a discount in that period, so mixing net and non-net columns is a quiet way to be wrong.
• ◦Commitment timing and unused commitment. Upfront fees land on the purchase date in a cash view and are spread in an amortized one. The part of a commitment that no usage absorbs has to appear somewhere, and where depends on the view.
• ◦Service grouping. Cost Explorer splits EC2 into “EC2 - Instances” and “EC2 - Other” and groups data transfer by service, while billing data groups it under a single “Data Transfer” service.
• ◦Rounding and granularity. Cost Explorer can offer hourly and resource-level data, while billing data is monthly with no resource detail. When they differ, AWS says the invoice is the final amount you owe.
• ◦Scope and filters. Different accounts, regions, tags, date ranges or time zones. CUR usage timestamps are in UTC, so a month boundary can move.

Work through it in this order: invoice, then adjustments, then a billed analytical view, then a commitment-timing adjustment, then the amortized or effective view. The numbers below are illustrative; the reconciliation method is the point.

The first three steps tie a cash-basis view back to the invoice, which is the check finance cares about at close. The last two move commitment cost in time and across workloads, so for the commitments involved they should net out over the term rather than add or remove cost. If the cash-basis total still does not tie after those adjustments, check scope, timing, finalization, grouping, rounding and cost-column selection before assuming there is a data problem.

Why Cost Explorer and the CUR can disagree

AWS draws the line this way. Billing data, on the Bills and Payments pages and in the invoice, answers what you owe. Cost Explorer is an analytical view for deep-dive analysis, with more granular dimensions and “features that might show differences when compared to billing data,” such as amortized costs and different service grouping. CUR 2.0, delivered through AWS Data Exports, exposes the detailed rows and columns you need to reconstruct or analyze either view.

Neither is more correct; they answer different questions. The risk in a CUR query is mechanical: summing the wrong cost field, or filtering only one side of covered and negation pairs, produces a number that is internally consistent and wrong. A common reason a CUR-based figure does not match Cost Explorer is that one is on a cash basis and the other on an effective basis, and nobody chose that.

Choosing a cost basis for each job

There is no universally correct cost basis. The right basis depends on the financial question being answered. Using one basis for every question, then being surprised when the answers disagree, is the common mistake.

Whatever you choose, label every report with its basis and its credit and tax treatment. A label settles most of these arguments in seconds.

Azure: Actual Cost and Amortized Cost

Azure keeps two datasets for reservations. Actual Cost reflects charges on the billing basis and includes reservation and savings plan purchases where applicable, with an effective price of zero for usage that receives the reservation discount. Amortized Cost allocates those purchases across the resources and time period that benefit: it replaces that zero with the prorated hourly cost of the reservation, adds an UnusedReservation charge type, and has no purchase records. Cost analysis defaults to Actual cost.

Two caveats for reconciling. Costs in Cost Management are estimates until an invoice is generated and can still change until the period closes, and the costs shown exclude taxes, credits and support, so a Cost Management total is not the invoice total. And exports vary by scope: they offer actual, amortized and FOCUS datasets, with FOCUS combining actual and amortized costs, but management group scope supports only usage charges, and MOSP billing scopes do not support FOCUS datasets.

Google Cloud: no amortized view to translate

Google Cloud does not expose a first-class amortized view the way AWS and Azure do, at least not in the billing export documentation we reviewed, and forcing its terms onto the AWS model would mislead. Google bills committed use discount commitments as a monthly fee, so the purchase-day spike that dominates AWS and Azure reservation discussions does not arise in the same way.

In the BigQuery billing export, the cost field is the cost “inclusive of any negotiated discounts,” and credits are a separate repeated field; Google’s examples compute net cost as cost plus credits. Commitment fees appear as cost rows (Google’s sample queries match SKU descriptions beginning “commitment”), and the benefit as credits such as COMMITTED_USAGE_DISCOUNT or FEE_UTILIZATION_OFFSET. The practical question on Google Cloud is therefore cost before or after credits, not billed versus amortized. Google’s FOCUS export is labelled Preview.

FOCUS: BilledCost, EffectiveCost and the reconciliation rule

FOCUS, the FinOps Foundation’s open cost specification, gives the industry’s names for the two bases. Version 1.4 is the current published release. BilledCost is the “cost of a charge as invoiced by the invoice issuer in a given billing period,” and for an issued invoice its sum must match the payable amount within a rounding tolerance. EffectiveCost is the spread basis: usage charges include the recognized share of related purchase charges, and a purchase intended to cover eligible charges is zero.

The rule that matters for reconciliation is that, when both the covering and covered charges are in the dataset, the sum of EffectiveCost across them must equal the sum of BilledCost. FOCUS notes the sums can differ when charges span billing periods or accounts, or when only one side is present. ListCost and ContractedCost add the price side, separating public prices from your negotiated ones.

How CloudQuell handles cost basis

Here is how this maps onto CloudQuell, so you can place its numbers in the bridge above.

• ◦Detailed AWS data comes from CUR 2.0 Data Exports. Cost Explorer is used only to backfill history from before CUR data exists.
• ◦The default view is billed, cash-basis cost. Credits, discounts and refunds are off by default, taxes are on, and amortization is off.
• ◦CloudQuell supports amortized/effective cost views for AWS and Azure where the underlying provider data supports them. Google Cloud has no separate amortized view in CloudQuell.
• ◦These settings change which number you see, so note them next to any figure you reconcile.

CloudQuell’s views are analytical views. Reconcile them to the provider invoice rather than treating them as a replacement for it.

What is the difference between billed cost and amortized cost?

Billed cost records a charge when it appears on the bill, so an upfront commitment fee lands in full on the purchase date. Amortized cost spreads that fee over the commitment term and attributes it to the usage it covers. For the same eligible commitment, the two represent the same underlying spend over the term; they differ in when and where it is recognized.

Why does AWS Cost Explorer not match my invoice?

Common causes are the accounting basis (the invoice is cash-basis, while Cost Explorer can show amortized costs), refunds (the Bills page excludes them in charges by service, while Cost Explorer includes them), refresh timing, service grouping and rounding. When they differ, AWS says the invoice is the final amount you owe.

What is amortized cost in AWS?

It is a Cost Explorer and CUR view that spreads upfront and recurring fees for Reserved Instances and Savings Plans over the term, so a purchase does not appear as a one-day spike. Since November 6, 2026, AWS Cost Explorer and CUR 2.0 also support amortized treatment of the upfront fee for EC2 Capacity Blocks for ML.

What is unblended cost?

Unblended cost is the cost of the usage: the unblended rate multiplied by the usage amount, with discounts separable into their own line items and commitment fees on the day they are charged. It is not the invoice total, which also reflects tax, credits and refunds.

Should FinOps use billed or amortized cost?

Neither is universally correct; it depends on the question. Use billed cost for invoice reconciliation, close and cash forecasting, amortized cost for trends and unit economics, and a policy decision for chargeback. For commitment analysis, look at both.

What is BilledCost vs EffectiveCost in FOCUS?

BilledCost is the cost of a charge as invoiced, and for an issued invoice it sums to the payable amount within a rounding tolerance. EffectiveCost spreads covering purchase charges onto the usage they cover. When both the covering and covered charges are in the dataset, the two sum to the same total, though FOCUS notes they can differ across billing periods or accounts.

Does Azure support amortized cost?

Yes. Azure Cost Management has an Amortized Cost dataset alongside Actual Cost, in cost analysis and exports, covering reservations and, for compute, savings plans. It includes unused reservation hours and has no purchase records. Support depends on agreement type and export scope.

Does GCP have amortized cost?

Not as a named view in the billing export documentation we reviewed. Google bills commitments as a monthly fee and offsets them with credits, so the practical choice is cost before or after credits. Google’s FOCUS export is labelled Preview.