Cloud Cost Management: Does the Dashboard Match the Invoice?

Somebody in finance forwards last month's AWS invoice and asks why it does not match the dashboard. Not rounding. Not the usual billing lag, and not a credit landing late.

In a fair number of accounts those two numbers measure different things on purpose, and AWS documents that they will. So the position: before you touch an instance size or a commitment, find out which number your tooling is drawing. Every cloud cost management decision inherits that answer, and neither setting that decides it is in Cost Explorer.

It bites in two places. A startup buying AWS through a reseller for the rupee invoices and the thirty-day terms. And an Indian subsidiary pulled into a parent's organisation for one consolidated bill.

Why does cloud cost management stall on its first reconciliation?

Because there are three independent ways the number can be wrong and most teams know about two.

The first is allocation: which team or product the spend belongs to, the argument in our earlier post on accounts or tags. The second is which metric you picked, unblended or net amortised, which is a post of its own.

The third nobody mentions. AWS puts it in a sentence: "Pro forma data exists in a separate domain (pro forma) from your billable cost data (standard billable)." Two domains. Cost Explorer renders one of them and does not say which.

Who is actually selling you AWS?

Start here, because the rest follows from it. AWS calls the answer your seller of record, and the page that defines it says an SOR is "a local business entity established within a jurisdiction (country) to resell AWS services" which "becomes the contracting party with local customers".

For India that entity is "Amazon Web Services India Private Limited (formerly known as Amazon Internet Services Private Limited)". If you have been calling it AISPL for years: same company, newer name, still showing up under the old one in places.

Finding yours takes half a minute. In the billing console, "choose Payment preferences and under your default payment method, see the name under Service provider", or read it on the Tax settings page "under the Seller column". We have sat in kick-off calls where the CTO and the finance lead gave different answers and both were sure.

Is Cost Explorer showing the invoice or a markup?

If a partner sells you AWS, quite possibly a markup, and AWS is explicit about it rather than coy. AWS Billing Conductor is "a custom billing service for AWS Channel Partners" built to "create a second version of their costs to share with their customers", and it lets the partner "set global or specific markups or discounts".

Then the line that matters: "The primary billing view for accounts or AWS Organizations in billing groups shows only pro forma data." Only. Not alongside, not flagged. If your organisation sits in a billing group, the default in Cost Explorer, on the Bills page and in your Cost and Usage Report is the partner's configuration.

AWS even describes the gap: "Customers will observe cost differences between billable costs (matching the AWS invoice) and pro forma costs (matching the Billing Conductor configuration) throughout the month." Usage reconciles once the invoice is issued. Money does not.

Coverage is partial too: "for services and features that don't support pro forma costs, AWS accounts use costs at billable rates, matching the AWS invoice." One report, part modelled and part invoice, nothing on screen to tell them apart.

Your commitment maths does survive: those configurations "don't affect customers' existing invoices from AWS or billing configurations (for example, sharing of credits or commitment-based discounts like Reserved Instances or Savings Plans)". So the arithmetic on how much to commit holds either way.

What does the new billing context API tell you?

Until recently you asked your partner. Since 25 September 2026 there is a call for it. ListBillingViewSegments "lists the segments of a billing view over a given time period", and each segment "identifies the billing domain (PRO_FORMA or BILLABLE) and the account relationships that apply during its time range": domain, managementAccountId, billingTransferAccountId and billingGroupPrimaryAccountId.

Two details repay a careful read. Context can change under you, because "if a mid-period change occurs, the response includes multiple segments, each with its own time range". And the API admits its blind spot: "the response omits hidden segments, so the segments it returns might not cover the entire requested time period." A gap is not a clean bill of health.

Which currency is that number in?

Rupees, if your SOR is AWS India. The AWS India FAQs leave no room: "AWS India invoices are issued in Indian Rupees (INR). AWS India accept only INR as payment currency." The console you budget in may well be quoting dollars, and nobody writes down which rate got used.

The reconciliation lives in the invoicing API. ListInvoiceSummaries returns three parallel amounts per invoice, BaseCurrencyAmount, PaymentCurrencyAmount and TaxCurrencyAmount, each carrying a CurrencyExchangeDetails object with a Rate, a SourceCurrencyCode and a TargetCurrencyCode. It also names the BillingEntity and the InvoicingEntity, which answers the previous section.

Compare on the before-tax figure, because no rightsizing exercise ever moved a tax line. AWS's India tax page charges customers in Delhi, where AWS India is registered, "SGST (9%) and CGST (9%)", and everyone else "IGST (18%)", and you need your "GSTIN and the address to which the GSTIN is registered in the Tax Settings page" for a usable tax invoice.

What happens to an AWS India account when it joins someone else's organisation?

It can stop being an AWS India account. One sentence in the page on consolidated billing in India does it: "if your management account isn't in AWS India, you can still invite AWS India accounts to join your organization. However, their SORs automatically resolve to AWS Inc." The other direction is safe: with an AWS India management account, "the SOR of all of the linked accounts is retained".

Hold that against a structure half the fintechs we work with already have: Indian operating company, foreign holding company, one platform team, and a sensible wish for a single bill. Accept the parent's invitation and a rupee invoice from an Indian company becomes a dollar invoice from a company in Seattle. Make that call with finance in the room, before the invitation is accepted.

There is a date on it. Older accounts sit in what AWS calls the legacy model, where the seller cannot be changed by self-service, and AWS says "the migration is expected to be completed by December 2026". The restriction quietly protecting you from an accidental change of seller is going away.

Which entity is named in your outsourcing register?

Whichever one your SOR names, which is why a regulated lender cannot leave this to finance. The RBI's Outsourcing of Information Technology Services Directions, 2023 require at paragraph 15 that "REs shall ensure that their rights and obligations and those of each of their service providers are clearly defined and set out in a legally binding written agreement", and say of cross-border arrangements at paragraph 21 that "the governing law of the arrangement shall also be clearly specified".

So the register and the invoice should name the same company, and a resolved SOR quietly changes one of them. The clause-by-clause version is in our post on the RBI and a vendor contract, and a reseller holding a role in your account raises the access question we wrote about separately.

What can you run on Monday?

Three things, under an hour, and nobody has to approve anything.

Open Payment preferences and Tax settings and write down the service provider and seller names. Then ask the billing context API which domain your data is in. Both of these are global endpoints, so pass the region:

aws billing list-billing-view-segments --region us-east-1 \
  --query 'items[].{from: timeRange.beginDateInclusive,
                    domain: domain,
                    management: managementAccountId,
                    transfer: billingTransferAccountId,
                    groupPrimary: billingGroupPrimaryAccountId}'

BILLABLE means the dashboard is the invoice. PRO_FORMA means it is a configuration, and groupPrimary names whoever owns that configuration. The call needs billing:ListBillingViewSegments.

Third, pull the invoice for the last complete month:

aws invoicing list-invoice-summaries --region us-east-1 \
  --selector ResourceType=ACCOUNT_ID,Value=<management-account-id> \
  --filter '{"BillingPeriod":{"Month":9,"Year":2026}}'

Put your own reported total next to TotalAmountBeforeTax, at the Rate in the response rather than the one your spreadsheet has carried since last year. This needs invoicing:ListInvoiceSummaries. Agree to within rounding and you can go and optimise something. If not, the gap is a markup, a currency or a tax line, and all three are now visible.

When does none of this matter?

Often, and we should say so. One entity, one organisation, a direct relationship with AWS India and no partner anywhere: your dashboard is your invoice before tax, the domain comes back BILLABLE, and this is a twenty-minute confirmation.

Buying through a partner is frequently the right call too. A seed-stage fintech that cannot get its card limit raised past a few lakh, and wants a GST invoice and thirty-day terms, is better served by a reseller than by an argument with its bank. The markup buys something real.

The failure is not the markup. It is reporting a pro forma number to a board as though it were an invoice, then building a savings target on it.

The short version

Find your seller of record this week and put the entity name in the same document as your vendor contract. If a parent's organisation invited your Indian accounts in, check that the two still agree.

Call list-billing-view-segments and read domain. If it says PRO_FORMA, put that on every cost report that leaves the platform team, because the people reading it will assume otherwise.

Reconcile against list-invoice-summaries monthly, before tax, at the rate in the response. And settle what you want your seller of record to be before AWS finishes retiring the legacy model in December 2026.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.