Start a Project
Oops! Something went wrong while submitting the form.
September 24, 2025
The subscription economy is having its next inflection point. Flat-rate SaaS pricing worked when software was simple and usage patterns were predictable. That era is ending. AI platforms charge per token, cloud services charge per compute second, and data platforms bill per query executed. The companies that win this decade will be the ones whose billing infrastructure can keep up, and Zuora Billing was purpose-built for exactly this.
This guide covers how consumption-based billing works inside Zuora, how token-based pricing is architected using the Prepaid with Drawdown (PPDD) framework, and the implementation steps that separate clean deployments from costly rework.
For most of the 2010s, the SaaS industry treated seat-based recurring revenue as the platonic ideal of business model design. Predictable ARR. Smooth renewal cycles. Recognizable under ASC 606. Then the hyperscalers rewrote the rules.
Snowflake went public with 100% usage-based revenue and reached a $70B valuation. Twilio built a $15B business on per-message pricing. AWS, Azure, and GCP collectively generate hundreds of billions in consumption revenue. Now the AI wave has accelerated this further: Anthropic, OpenAI, Google, Cohere, and Mistral all price their APIs on token consumption, not seats.
According to OpenView's 2024 SaaS Benchmarks report, 61% of B2B software companies now offer some form of usage-based pricing, up from 27% in 2018. Among AI-first companies, that figure exceeds 90%.
The business logic is simple: customers pay in proportion to the value they receive. During expansion, they spend more automatically. During contraction, churn pressure is lower because costs scale down. The challenge is entirely on the vendor's side: building billing infrastructure that can ingest millions of usage events, rate them accurately, and produce invoices customers trust.
Token-based billing is a specific sub-type of consumption billing that has become the de facto standard for large language model (LLM) APIs. Understanding it is now non-negotiable for any finance systems team supporting an AI technology company.
A token roughly corresponds to four characters of text in English, about three-quarters of a word. When a user sends a prompt to an LLM and receives a response, both the input (prompt tokens) and output (completion tokens) are metered separately. Most providers charge different rates for each because output generation is computationally more expensive.
EXAMPLE: REAL-WORLD TOKEN PRICING A typical enterprise LLM API prices at $3.00 per million input tokens and $15.00 per million output tokens for a flagship model, with cheaper rates for smaller/cached variants. A single enterprise customer processing 500M tokens per month generates wildly different invoices depending on input/output ratio; this variance must be handled in the billing layer, not in a spreadsheet.
At enterprise scale, token billing becomes a layered commercial arrangement:
Building this in a spreadsheet or a homegrown billing system creates reconciliation debt that compounds every month. Zuora's data model handles all of these dimensions natively.
The billing systems most companies already have, whether an ERP module, a custom-built invoicing tool, or the Salesforce order object, were designed for a world of fixed charges and predictable periods. They fail on consumption billing for structural reasons, not configuration reasons.
THE REAL COST OF MANUAL CONSUMPTION BILLING Finance teams managing usage billing manually spend an average of 3–5 days per billing cycle on reconciliation. For a company with 200+ customers on consumption plans, this translates to 40–60 person-days per month, roughly one full-time analyst, every month, just keeping invoices accurate. Zuora eliminates this entirely.
Zuora's approach to consumption billing is built around five interconnected layers. Each layer must be designed correctly for the system to function reliably at scale.
1. Product catalog design: charge models and units of measure Every consumption billing design starts in the product catalog. A Rate Plan Charge of type Usage is the core object. You select a charge model (Flat Fee, Per Unit, Volume, Tiered, Tiered with Overage, or Pre-Rated) and associate it with a Unit of Measure (UoM). For token billing, you typically create two UoMs: Input-Tokens and Output-Tokens, each with a separate usage charge on the rate plan. Product catalog design is the highest-leverage design decision; changes here cascade downstream into invoicing, revenue recognition, and reporting.
2. Usage data ingestion: the /v1/usage API Usage events are submitted to Zuora via the REST POST /v1/usage endpoint. Each record requires: subscription Number, chargeNumber, quantity, start date time, end date time, and unit ff Measure. Zuora processes these asynchronously; submission returns an import ID, and you poll GET /v1/usage/{id}/status for completion. For high-volume scenarios (millions of events), use the bulk import endpoint. A common mistake is submitting usage after the billing run has already executed; always validate that usage is ingested before the billing schedule triggers.
3. Rating engine: tiered, volume, overage, and PPDD Zuora's rating engine applies the charge model to submitted usage quantities at invoice time. For Tiered pricing, each tier is rated independently. For Volume pricing, the total quantity determines which tier applies to the entire period. For Tiered with Overage, usage above a committed level is rated at the overage price. The most sophisticated model is Prepaid with Drawdown (PPDD), described in detail in the next section, which handles pre-purchased credit buckets, real-time balance visibility, and automatic overage detection.
4. Invoice generation: consolidation and presentation Zuora generates invoices that consolidate recurring charges and usage charges into a single customer-facing document. Usage line items display the quantity consumed, the applicable rate, and the resulting amount. For multi-model token billing, each model tier appears as a separate invoice item. Invoice templates can be configured to show a usage summary table, drawdown balance consumed, and credit remaining, which is critical for enterprise customer transparency and reducing billing disputes.
5. Revenue recognition: variable revenue under ASC 606 / IFRS 15 This is where most implementations fall short. Under ASC 606, recognizing prepaid token credits at the point of sale is incorrect; revenue must be recognized as the credits are consumed (usage-based recognition). Zuora Revenue handles this via a variable consideration pattern: the prepaid amount is deferred, and revenue is recognized pro-rata as usage data flows from Zuora Billing. The PPDD balance serves as the recognition event trigger. For companies with a mix of base + usage charges, each performance obligation (POB) must be separated in the revenue layer.
The Prepaid with Drawdown model is Zuora's most powerful, and most underused, consumption billing architecture. It was designed precisely for the token bundle model that dominates AI API pricing today.
When a customer purchases a token bundle (e.g., 1 million input tokens for $30), Zuora creates a Prepaid Balance object that holds the purchased quantity. As the customer submits usage via API calls, each event draws down that balance. Zuora tracks the remaining balance in real time, exposing it via the GET /v1/prepaid-balance endpoint so customers can monitor their consumption in a self-service dashboard.
PPDD ARCHITECTURE SNAPSHOT Prepaid Purchase → Drawdown Balance Created → Usage Events Submitted → Balance Decremented → Balance Hits Zero → Overage Charge Activated → Overage Rated at Higher Unit Price → End of Period Invoice Generated
RATE PLAN CHARGE SETUP - ZUORA PRODUCT CATALOG
json
{
"name": "AI Tokens — Prepaid Bundle",
"chargeType": "OneTime", // or Recurring for auto-renew bundles
"chargeModel": "FlatFee", // fixed price for the bundle
"productRatePlanChargeId": "...",
"prepaidOperationType": "Drawdown",
"prepaidQuantity": 1000000, // tokens in the bundle
"validityPeriodType": "Annual",
"overageUnused": "CreditBack", // or Rollover for rollover contracts
// Overage charge on same rate plan:
"overageChargeModel": "PerUnit",
"overagePrice": 0.000018, // $0.018 per 1K tokens = $0.000018/token
"unitOfMeasure": "Input-Tokens"
}
POST /v1/usage — USAGE EVENT PAYLOAD
json
{
"accountNumber": "A-00012345",
"subscriptionNumber": "S-00067891",
"chargeNumber": "C-00143200",
"unitOfMeasure": "Input-Tokens",
"quantity": 45000,
"startDateTime": "2026-06-01T00:00:00Z",
"endDateTime": "2026-06-01T23:59:59Z",
"uniqueKey": "evt_20260601_session_7742" // idempotency key
}
CRITICAL IMPLEMENTATION NOTE Always include a uniqueKey on every usage submission. Without idempotency keys, retry logic in your integration layer will double-count events, resulting in overbilling that is extremely difficult to reverse once invoices are generated. This is the #1 source of billing disputes in consumption implementations.
Enterprise contracts often include unused credit rollover or credit-back clauses. Zuora handles both natively via the overageUnused field on the PPDD charge:
AI & LLM platforms Token-based PPDD bundles with multi-model rate plans. Separate input/output UoMs, tiered volume discounts for enterprise committed use.
Cloud infrastructure Compute-hour and storage-GB usage charges, tiered with overage. Hybrid base + consumption with monthly billing cycles and real-time usage dashboards.
IoT & telematics Device-event-based billing at scale. Millions of usage records per day ingested via bulk import API. Volume pricing applied across the entire device fleet.
Healthcare API platforms Per-query pricing on clinical data APIs. PPDD credit bundles for health system customers, with usage-based rev rec aligned to HIPAA billing cycles.
"Companies that nail consumption billing see 2.5x higher net revenue retention than those on flat-rate subscriptions, because expansion revenue is automatic and churn pressure is lower."
❌ Ignoring UoM taxonomy upfront Defining UoMs ad-hoc as products launch creates catalog sprawl. Design the full UoM hierarchy before the first product goes live; it cannot be changed on active subscriptions.
❌ Submitting usage after billing run Usage submitted after a billing run is not retroactively applied. It accrues to the next period, causing undercharging in the current cycle and a billing spike customers weren't expecting.
❌ Missing idempotency keys Without a uniqueKey on usage submissions, any retry logic in your integration will double-count events and overbill customers, a trust-destroying error that's hard to reverse.
❌ Recognizing prepaid revenue at sale Booking token bundle revenue at invoice date violates ASC 606. Prepaid credits must be deferred and recognized as consumption is reported. This requires proper Zuora Revenue POB setup.
❌ Single charge for multi-model pricing Using one Usage charge for all AI model tiers makes rate plan changes impossible without subscription amendments. Each model tier should have its own charge within the rate plan.
❌ No grace period on drawdown exhaustion When PPDD balance hits zero, service interruption or sudden overage charges without customer notification destroys relationships. Build a low-balance notification workflow using Zuora Workflow + callout to your notification system.
Consumption billing is no longer a niche requirement for infrastructure companies. It is the pricing model of this era, and every company building on LLM APIs, cloud services, or metered data products is already operating in this paradigm, whether their billing system is ready or not.
Zuora Billing provides the complete infrastructure stack for this: a flexible product catalog with native usage charge types, a REST API designed for high-volume event ingestion, a rating engine that handles every commercial model from simple per-unit to complex prepaid drawdown with rollover, and a revenue recognition pipeline that handles the variable consideration complexity of ASC 606.
The companies that invest in this foundation now, designing UoM taxonomies carefully, implementing PPDD correctly, and connecting the billing layer to RevRec from day one, will compound that advantage every time they add a new consumption product. The ones who defer it will pay a steep price in reconciliation debt, billing disputes, and analyst headcount.
What Zuora edition supports PPDD (Prepaid with Drawdown)?
PPDD is available in Zuora Billing with the Prepaid & Drawdown add-on, which is part of the Growth and Enterprise editions. Confirm with your Zuora account team whether your current license includes PPDD or whether it requires an add-on SKU. It is not available in the base Starter tier.
Can Zuora handle real-time balance visibility for token billing?
Yes. The GET /v1/prepaid-balance endpoint returns the current drawdown balance for a given subscription and charge in near-real-time. You can expose this through a customer portal or internal dashboard to give customers visibility into their remaining token credits before they hit overage.
How does Zuora handle revenue recognition for consumption billing?
Zuora Billing passes transaction data to Zuora Revenue (RevPro) via the automated data pipeline. For prepaid credits, revenue is deferred and recognized as usage events trigger drawdown. For pure usage billing in arrears, revenue is typically recognized in the period the service was delivered. Your Zuora Revenue configuration must define performance obligations at the charge level to handle the variable consideration correctly under ASC 606 / IFRS 15.
What is the maximum volume of usage events Zuora can process?
For standard REST submissions, Zuora recommends batching usage records into files of up to 50,000 records per import. The bulk import endpoint supports larger volumes. For very high-frequency workloads (billions of events per month), consider aggregating usage at the application layer before submission, for example, aggregating per-session token counts into hourly or daily summaries per subscription, rather than submitting individual API call events.
Can different AI models have different pricing on the same subscription?
Yes. The recommended architecture is to create separate Usage charges within a single rate plan, one charge per model tier (e.g., Standard, Premium, Cached). Each charge has its own UoM, pricing, and optionally its own PPDD drawdown pool. Usage submissions reference the specific chargeNumber, ensuring the rating engine applies the correct price per model. This avoids the need for separate subscriptions per model variant.
Salesforce
Let La Confianza Tech be your trusted partner in building a smarter, more connected business.
.png)
