The Modern Billing Stack Explained for Engineers (2026)

Billing tells you what happened, but a modern billing stack decides what's allowed to happen, and coordinates that decision across catalog, entitlements, metering, invoicing, and reconciliation before the next request runs.

This guide maps the 2026 architecture, explains what each component owns, and shows where request-time decisions belong.

What is a modern billing stack?

A modern billing stack is a set of connected services that defines commercial terms, controls product access, records usage, calculates charges, issues invoices, processes payments, and reconciles financial data.

The architecture separates work by execution path. Product access and usage controls run with the application. Invoice, payment, tax, and accounting work runs through the financial path.

That separation gives each system a clear source of truth. It also keeps a payment-provider migration from rewriting feature access logic across the product.

The systems behind pricing connect these paths. A product catalog defines the offer, entitlements express the purchased rights, metering records consumption, and billing converts settled usage into money.

The 4 layers of a modern billing stack

Modern billing stack architecture has 4 layers covering configuration, runtime control, financial execution, and data operations.

The boundaries matter more than the vendor count. One service may own several components, and a large implementation may split each component into its own service.

How data moves through the modern billing stack

Data moves through the modern billing stack in 8 stages, starting with catalog configuration and ending with reconciliation.

1. Publish the commercial model. The product catalog stores a versioned plan, its features, usage limits, prices, add-ons, and credit grants.
2. Create the customer state. Checkout or an executed contract creates the subscription and provisions the matching commercial rights.
3. Resolve the runtime decision. The application checks the customer, resource, feature, current usage, available credits, and applicable limits before an action runs.
4. Execute the allowed action. The product serves the feature, model call, agent task, or API request after the runtime returns an allow or block result.
5. Record consumption. The metering path accepts an idempotent usage event and attributes it to the correct account, user, agent, feature, and billing period.
6. Apply pricing. The rating layer converts the accepted quantity into a charge, credit deduction, overage, or included usage record.
7. Settle the financial record. The billing engine creates invoice lines. Payment, tax, dunning, and revenue systems process their parts of the transaction.
8. Reconcile the stack. Ledgers and data pipelines compare usage, grants, invoice lines, refunds, and journal entries across system boundaries.

The request path can end after stage 5 accepts the usage record. The remaining work can use asynchronous processing once the runtime has made the access decision.

The 10 core components of a modern billing stack

Each component answers a different production question. Clean ownership reduces duplicate logic and makes failures easier to trace.

1. Product catalog

The product catalog is the commercial source of truth for products, plans, add-ons, features, prices, credit grants, and usage limits.

Catalog versions preserve grandfathered offers and contract terms. A customer remains tied to the version they purchased until a defined migration moves them to another version.

Configuration should cover packaging changes that leave the product model intact. Structural changes, such as introducing a new billable unit, still need engineering work across events, data contracts, and downstream reporting.

Webflow’s billing migration shows the value of this boundary. Product managers can update plans and entitlements through configuration, which reduces engineering involvement.

2. Subscription and contract state

Subscription and contract state records what the customer bought and when each term takes effect. It covers start dates, renewals, amendments, upgrades, downgrades, cancellations, trials, and custom enterprise terms.

The state model needs effective dates and version references. Those fields tell the runtime which catalog definition applies during a mid-cycle change.

Contract systems and self-serve checkout may create the same downstream subscription shape. A shared provisioning contract keeps both purchase paths aligned.

3. Entitlements and provisioning

Entitlements are commercial allowances that define which features a customer can access and how much they can consume. They can be Boolean, configured, metered, or credit-backed.

RBAC identifies a user’s organizational role. Entitlements resolve the product rights created by a plan or contract. An admin role can coexist with a plan that excludes a paid feature.

Effective entitlement state can combine several sources:

• Active plan with the base feature set and limits
• Parent plan inheritance shared across related plans
• Add-ons that extend or override a value
• Active trials that grant temporary access
• Promotional grants applied to one customer

Conflicts need a documented resolution rule. A generous-value rule can grant access if any active source allows it and selects the highest applicable limit.

Provisioning writes the resulting state when a purchase, amendment, or cancellation occurs.

The runtime response should return access status, current usage, limit, an unlimited flag, and a machine-readable access-denied reason, so paywall and upsell copy can explain what unlocks the gate without touching gating logic.

Soft-limit checks add a soft-limit flag alongside access-granted, so application code can distinguish 'blocked' from 'in overage, allow and track it' without inferring from balance.

4. Usage runtime and request-time enforcement

The usage runtime makes a synchronous decision before the product consumes a costly resource. It evaluates entitlements, available credits, usage limits, and spend policies in the request path.

This component gives the product an actionable result:

Request-time enforcement is central to AI billing infrastructure because post-usage records cannot control compute that has already run.

Stigg is the usage runtime for AI products. Entitlements, credits, usage limits, and spend governance are enforced synchronously in the request path.

5. Metering and event ingestion

Metering records how much product value each customer consumes. A useful event carries an immutable event ID, customer ID, resource ID, feature or meter ID, quantity, timestamp, and pricing version.

Idempotency protects retries. The ingestion service should accept an event ID once, return the prior result for a replay, and keep the original event available for recovery.

Aggregation converts raw events into billing-period totals and keeps the raw records intact. The raw stream supports replay.

The aggregate supports entitlement checks, invoices, dashboards, and analytics.

High-volume ingestion also needs batching, parallel reporters, durable storage, and regional replication. Stigg documents batches of up to 1,000 events and built-in idempotency for its metering service.

6. Credits, wallets, and the ledger

A credit wallet stores a consumable balance. The ledger records every state change behind that balance, and production credit systems need more structure than a mutable number on the customer record.

Each credit block can carry its own amount, effective date, expiration date, category, cost basis, priority, and status. Paid, promotional, prepaid, recurring, and manual grants can coexist in one wallet.

Burn order makes consumption predictable. Stigg’s documented order applies configured priority first, then earlier expiration, promotional credits before paid credits, earlier effective dates, and older creation dates.

Depletion rules control what happens at zero. A hard limit blocks access, and a soft limit permits the action and tracks the deficit for later settlement.

Auto-recharge tops the balance back to a target when it drops below a threshold, under a monthly spend cap that fails closed. Once the cap is hit, recharging stops rather than continuing to bill

An append-only credit ledger records grants, top-ups, deductions, expirations, revocations, timestamps, and actors.

Starting and ending balances support disputes, reconciliation, and revenue recognition.

7. Rating and pricing engine

The rating engine converts measured usage into a financial amount. It applies the price, unit conversion, included allowance, tier, minimum, commitment, discount, and effective date tied to the event.

Rating must be deterministic. Replaying the same event set with the same catalog version should produce the same charge set.

Versioned pricing keeps historical bills reproducible after a price change. The event should reference the commercial version used when the product accepted the request.

8. Billing and invoicing engine

The billing engine turns rated charges into invoice lines and applies billing periods, proration, credits, adjustments, and invoice status transitions.

Invoice generation has its own failure surface. Period boundaries, late usage, amended contracts, retries, and backdated changes all need explicit rules.

This component also needs stable interfaces with the runtime and metering layers. Our billing software architecture guide covers the internal patterns and pitfalls inside the billing engine.

9. Payments, tax, and revenue systems

Payments, tax, and revenue systems execute the financial obligations created by the invoice. Payment processors collect funds, tax services calculate jurisdictional charges, and accounting systems post journals.

These systems need financial identifiers that remain stable across retries. An invoice, payment attempt, refund, credit memo, and journal entry should point back to the same customer and transaction chain.

Access policy should consume confirmed commercial state through a defined integration. This way, a failed card event, grace period, or contract exception can then produce the intended provisioning action.

10. Integrations, reconciliation, and observability

The final component keeps the stack coherent. Integrations move contract, customer, usage, invoice, and ledger data between CRM, CPQ, billing, accounting, and warehouse systems.

Reconciliation compares the records at each boundary. Useful checks include accepted usage versus rated usage, rated charges versus invoice lines, paid grants versus invoices, and refunds versus revoked credit balances.

Observability needs both technical and commercial signals:

• Runtime health including cache hit rate, decision latency, fallbacks, and denied checks
• Metering health including ingestion lag, duplicate events, rejected events, and replay volume
• Billing health including rating drift, invoice failures, payment retries, and sync errors
• Data health including unmatched IDs, stale versions, ledger variance, and reconciliation breaks

These signals turn a billing incident into a traceable state transition. They also give engineering a concrete reliability target for each boundary.

Why AI products need a stricter billing architecture

AI products create cost during execution, which makes request-time state part of the billing architecture.

This is the failure mode from the top of this article: a customer upgrades mid-run, checkout records the new plan, but the application keeps an old entitlement, and the next usage event lands under the previous meter.

The billing system requirements for AI products add several controls to the standard financial path.

These requirements belong beside the billing engine. They operate on live product state and feed settled results to invoicing and accounting.

Scale changes the performance profile of this boundary. Local decisions keep request latency stable, and durable ingestion absorbs usage bursts for downstream processing.

Architecture patterns that keep the stack reliable

The best patterns define system boundaries before vendor choices, and each pattern removes one class of cross-system ambiguity:

Separate the request path from the financial path

The request path must return an access decision within the product’s latency budget. The financial path can aggregate, rate, invoice, and reconcile through asynchronous jobs.

Low-latency control belongs near the application. Financial settlement belongs in durable services built for replay and audit.

Give each state one owner

The catalog owns offer definitions, the usage runtime owns live commercial access, the meter owns accepted consumption, the billing engine owns invoices, and the ledger owns credit history.

Other systems may cache or project that state. They should keep the owner’s identifier and version to support reconciliation.

Version every commercial change

Plans, prices, entitlement rules, credit formulas, and contract terms need effective dates. Versioning preserves historical bills and protects grandfathered customers.

A catalog edit should publish a new definition and leave prior records reproducible.

Design every write for replay

Network failures turn one logical action into several delivery attempts. Idempotency keys and immutable event IDs make retries safe across usage, rating, invoice, payment, and refund flows.

Replay tests belong in the release process. A restored event stream should rebuild the same aggregate and ledger state.

Put cache behavior in the contract

Local caching protects performance and availability. Stale state can change commercial behavior, which makes invalidation, expiry, fallback values, timeouts, and observability part of the cache contract.

Entitlement checks resolve instantly from the Sidecar's local in-memory cache on a hit. A cache miss falls back to Stigg's Edge API at around 100ms, with a configurable timeout (10 seconds by default). On timeout, the Sidecar returns configured static defaults rather than hanging the request.

The full fallback chain is Edge API → local cache → static defaults, so an upstream connectivity problem never blocks the request path. Serverless runtimes and large container fleets can opt into persistent Redis caching so cached entitlements survive restarts and stay shared across instances.

Reconcile business events across boundaries

Distributed systems can accept one side of a transaction and fail on the next. Reconciliation jobs need to find unmatched payments, grants, deductions, invoice lines, refunds, and revocations.

Corrections should create linked records that preserve the original event and the reason for the adjustment.

When to build or buy each component

A team of three to five engineers on monetization infrastructure is a permanent, seven-figure line item that produces no differentiated product value.

Webflow's engineering team reported roughly 500 engineering hours a year returned to product work after moving off their internal billing stack, with add-on rollouts dropping from months to about four hours and usage-based pricing dropping from quarters to a few weeks.

Complexity grows through new credit types, catalog versions, account hierarchies, concurrent consumption, migrations, and custom contracts. 

Buy decisions can stay component-level. A composable stack can keep the billing provider and internal services that already work, then add a dedicated runtime, ledger, meter, or catalog.

Where Stigg fits in the modern billing stack

Stigg is the runtime layer between your product and your billing stack. It evaluates entitlements, credits, limits, and spend governance synchronously in the request path, then hands settled usage to whatever billing system you already run.

Adopt it in pieces. One SDK for entitlement checks, the credits engine, metering, or a hosted catalog can each go in on their own. Node.js applications skip the Sidecar entirely and use the Node SDK in-process. Other languages run the Sidecar via a gRPC interface.

Stigg ships an MCP server, a CLI, and a set of agent skills alongside its SDKs, so pricing catalogs, credits, and entitlements can be modeled and operated from the same agentic tooling your team already uses to build.

What Stigg gives you in the request path

• Synchronous entitlement enforcement. getEntitlement returns access status, current usage, limit, and a machine-readable access-denied reason. Soft-limit checks add a soft-limit flag so code can tell 'blocked' from 'in overage.' p99 stays under 10ms.
• Auditable credit ledger. Every grant, top-up, deduction, expiration, and revocation is appended with timestamps and actors. Credit deduction returns the updated balance synchronously, so the next concurrent check sees it. Every report carries an idempotency key.
• Complex tenancy. One check evaluates the full chain (org, department, team, user, individual agent) and grants only when every budget above allows. One usage event updates every level at once. Sub-budgets can cap specific models under a broader team allowance.
• Scale and BYOC. 1M+ events/sec ingestion, 1M+ entities per hierarchy root, up to 99.99% uptime, multi-region active-passive failover. BYOC deploys inside your AWS, GCP, or Azure account via infrastructure-as-code. End-user data never leaves your boundary.
• Works alongside your billing stack. Stripe, Zuora, Chargebee, and custom in-house billing all sync bidirectionally. Stigg ships native invoicing as an option, but revenue recognition, tax, and compliance stay with your billing and ERP stack.
• Revenue stack stays aligned. Pricing, packaging, and entitlement changes propagate to your CRM, CPQ, data warehouses, and in-app portals through the same integrations.

The point is keeping runtime decisions close to the request path without rebuilding what already works. See how Stigg structures the runtime layer in the docs.

Frequently Asked Questions

1. What is a modern billing stack?

A modern billing stack is the architecture that connects product catalog, entitlements, usage metering, rating, invoicing, payments, and reconciliation. It separates request-time product controls from downstream financial processing.

2. What are the main components of a modern billing stack?

The main components of a modern billing stack are a product catalog, subscription and contract state, entitlements, a usage runtime, metering, credits, rating, invoicing, payments, tax, integrations, and observability.

3. What is the difference between a modern billing stack and billing software?

The main difference between a modern billing stack and billing software is scope. Billing software creates invoices and manages payments. The wider stack also controls product access, measures usage, applies credits, and reconciles data.

4. Where do entitlements fit in a modern billing stack?

Entitlements fit in the runtime layer of a modern billing stack. They resolve the features, limits, and usage rights created by a plan, add-on, trial, promotion, or contract before the product serves a request.

5. Does Stigg replace an existing billing system?

No. Stigg works beside an existing billing system and handles entitlements, credits, metering, usage limits, and request-time spend governance. The billing provider continues to manage invoices, tax, payments, and collections.