The cloud billing stack: 25 layers from product catalog to general ledger
AI-assisted / research-based
This field note was drafted with AI assistance and synthesizes publicly documented cloud billing concepts and general industry practice. It is not based on confidential Microsoft systems or data, describes a generalized reference architecture rather than any single provider's implementation, and is not accounting, tax, or legal advice. Public documentation is linked so you can verify each concept yourself.
A customer sees one number at the end of the month. Behind it sits a long chain of systems, each owning a narrow decision: what can be sold, what was consumed, what it costs this customer, who owns the charge, what tax applies, and how the result lands in the books.
Most billing incidents are not failures of a single layer. They happen at the seams, where one layer's assumptions quietly differ from the next one's. A useful way to reason about commerce billing is to lay the whole chain out end to end and be explicit about what the company must define at every step.
The pipeline in five phases
The 25 layers below group naturally into five phases. Each phase consumes the output of the one before it.
- Define (layers 1–3): the catalog, the commercial offer, and the meter. Nothing can be billed that is not first described here.
- Measure (layers 4–6): services emit usage, the platform ingests it, and heterogeneous events are normalized into one canonical record.
- Price (layers 7–13): rating, pricing, tiers, commitments, discounts, account ownership, and eligibility combine to turn quantity into money.
- Bill (layers 14–17): tax, credits, aggregation, and the invoice document itself.
- Account and operate (layers 18–25): allocation, reconciliation, disputes, revenue recognition, ledger posting, audit, downstream APIs, and FinOps analytics.
From catalog to ledger in five phases
The full reference map
Scroll the table sideways on smaller screens. The first column stays pinned.
| Architecture Layer | What It Does | Typical Cloud Billing Provider Example | What the Company Defines | Typical Policy / Schema Examples |
|---|---|---|---|---|
| 1. Product / Service Catalog | Defines what can be sold and billed | Azure VM, Storage, Cosmos DB, OpenAI tokens | Products, SKUs, editions, regions, units | ProductId, SkuId, MeterId, Region, UnitOfMeasure |
| 2. Offer / Commercial Model | Defines how a customer buys the service | PAYG, Enterprise Agreement, MCA, CSP | Contract type, eligibility, term, commitment | Customer eligible for negotiated pricing only under a specific agreement |
| 3. Meter Definition | Defines the measurable consumption unit | VM hours, GB-month, API calls, tokens | Meter name, unit, aggregation method | ComputeHours, StorageGBMonth, InputTokens |
| 4. Usage / Telemetry Generation | Service produces billable usage records | A VM reports running hours | Event format, timestamps, resource IDs | {subscriptionId, resourceId, meterId, quantity, timestamp} |
| 5. Usage Ingestion | Collects usage from Azure services | Usage pipeline receiving events from compute/storage | Validation, deduplication, late-event handling | Reject missing MeterId; dedupe identical event IDs |
| 6. Usage Normalization | Converts different service events into a common billing format | Different services mapped into standardized usage records | Canonical billing schema | Convert seconds → hours; bytes → GB |
| 7. Rating Engine | Converts usage into monetary charges | 10 VM hours × $0.12/hour | Pricing rules, tiers, discounts | Charge = Quantity × EffectiveUnitPrice |
| 8. Pricing Engine | Determines applicable price | Retail price vs EA negotiated rate | Price lists, negotiated prices, currency | US East VM = $X/hour; customer discount = 12% |
| 9. Tier / Threshold Logic | Supports volume pricing | First 100 TB vs next 400 TB | Tier boundaries and rates | 0–100TB=$x, 100–500TB=$y |
| 10. Commitment / Reservation Logic | Applies prepaid commitments | Azure Reservations, Savings Plan | Coverage, eligibility, allocation | Apply reservation before PAYG pricing |
| 11. Discount / Benefit Engine | Applies contractual benefits | Azure Hybrid Benefit, dev/test rates | Precedence and stacking rules | Reservation → negotiated discount → promotional credit |
| 12. Account Hierarchy | Determines who owns the charges | Billing Account → Billing Profile → Invoice Section → Subscription | Organizational relationships | Subscription belongs to department/cost center |
| 13. Entitlement / Eligibility Engine | Determines what pricing or benefits a customer can use | Dev/Test subscription eligibility | Customer/tenant/product eligibility | Only Visual Studio subscribers qualify |
| 14. Tax Engine | Calculates tax treatment | VAT, sales tax, GST | Jurisdiction and tax rules | WA sales tax based on customer billing location |
| 15. Credits / Adjustments | Handles credits and corrections | SLA credit, support credit, billing correction | Adjustment reason and authorization | Credit $500 against invoice |
| 16. Invoice Aggregation | Groups rated charges | Monthly Azure invoice | Billing period, grouping, invoice ownership | Aggregate by billing profile + currency |
| 17. Invoice Generation | Produces invoice documents | Azure monthly invoice PDF | Invoice schema and legal fields | Invoice ID, billing period, tax, subtotal, total |
| 18. Cost Allocation | Maps spend to business units | Cost Management tags | Tag policies, cost centers, departments | CostCenter=Finance, Environment=Prod |
| 19. Reconciliation | Verifies usage → charge → invoice integrity | Compare source usage against billed records | Tolerance and reconciliation rules | Usage quantity must equal rated quantity |
| 20. Dispute / Support Workflow | Handles customer billing disputes | Customer challenges unexpected Azure charge | Investigation and approval policy | Usage validation → pricing validation → adjustment |
| 21. Revenue Recognition | Converts billing into accounting events | Monthly service consumption revenue | Accounting rules | Deferred vs recognized revenue |
| 22. Financial Ledger Integration | Posts transactions into finance systems | Revenue, AR, tax ledger | GL mappings | VM revenue → Cloud Compute Revenue GL |
| 23. Audit / Compliance | Maintains traceability | Who changed price or issued credit | Audit requirements | Every pricing change has version + approver |
| 24. Billing APIs / Exports | Exposes billing data downstream | Azure Cost Management exports/APIs | API schema, access policy | UsageDetail API, invoice API |
| 25. FinOps / Analytics | Helps customers optimize spending | Azure Cost Management | Allocation, budgets, anomaly rules | Alert if spend > 110% of monthly budget |
Where the hard problems live
Identity has to survive every hop
The MeterId defined in layer 3 is the thread that ties a telemetry event to a price, a tax treatment, and eventually a GL account. If normalization rewrites it, or a service emits a meter the catalog does not know, the charge either drops silently or lands on the wrong line. Ingestion should reject unknown meters loudly rather than guess.
Ingestion must be idempotent and tolerant of lateness
Usage arrives out of order and sometimes twice. Deduplicating on a stable event ID and defining a cut-off for late events per billing period are what separate a correct invoice from one that needs a correction later.
Precedence is a contract, not an implementation detail
Reservations, savings plans, negotiated discounts, hybrid benefits, and promotional credits can all touch the same usage. The order they apply in changes the final amount, so the stacking rule belongs in versioned policy, not scattered across engine code. A typical order is commitment coverage first, then contractual discounts, then credits.
Ownership decides the invoice
The account hierarchy in layer 12 determines which invoice a charge lands on and which currency and tax jurisdiction apply. Moving a subscription between invoice sections mid-period is a common source of split or duplicated charges.
Reconciliation closes the loop
Layer 19 is the control that proves the pipeline is honest: usage quantity in equals rated quantity out, and rated charges sum to the invoice. Without it, errors surface as customer disputes in layer 20 instead of internal alerts.
A billing system earns trust when every number on the invoice can be traced back to a meter, a price version, and an approval.
Design principles that hold across layers
- Version every price, rule, and discount, and record who approved each change.
- Keep one canonical usage schema; translate at the edge, not in the middle.
- Treat tax, revenue recognition, and ledger mapping as first-class consumers of the rated record, not afterthoughts.
- Expose the same rated data customers are billed on through exports and APIs, so FinOps teams reconcile against the source of truth.
- Build reconciliation as a continuous check, not a month-end task.
Public references
- Azure billing accounts and scopes ↗ describes the Billing Account → Billing Profile → Invoice Section hierarchy.
- Microsoft Customer Agreement overview ↗ covers the MCA commercial model.
- Organize costs with invoice sections ↗ shows how invoice ownership is structured.
- Azure Retail Prices API ↗ exposes meters, SKUs, units of measure, and tiered prices.
- Usage details fields ↗ documents the rated usage record exposed downstream.
- Azure Reservations ↗ and Azure savings plan for compute ↗ explain commitment-based pricing.
- Azure Hybrid Benefit ↗ is an example of a contractual licensing benefit.
- Cost Management best practices ↗ and budgets ↗ cover allocation and budget alerts.
- FinOps Framework ↗ and the FOCUS specification ↗ define a common language and schema for cloud cost data.
- IFRS 15, Revenue from Contracts with Customers ↗ is the international standard behind revenue recognition.