Prepaid Drawdown and True-Up Contract Support as a Vendor Evaluation Criterion

Prepaid drawdown and true-up support is now a hard evaluation gate for billing platforms serving AI and enterprise SaaS contracts. A platform must show that it can track credit commitments, reconcile consumption, and keep billing and revenue records in step. Feature claims are insufficient. Buyers need to see these mechanics run before signing, because gaps in tracking, reconciliation, and revenue records otherwise become visible at live contracts’ first reporting close.

Why hybrid prepaid-plus-usage contracts became the default structure for AI and enterprise SaaS deals

Classical SaaS assumed a near-zero marginal cost for each added user, which made per-seat pricing easy and meant there was no need for consumption metering. AI inference breaks that assumption. Every model call has a non-zero compute cost, while usage varies by orders of magnitude across customers. A uniform seat price therefore becomes untenable for vendors, while pure pay-as-you-go leaves buyers exposed to unpredictable spending.

Pratik Gupta’s 2026 paper, From Tokens to Credits to Outcomes, finds that subscription-with-usage-quota is the most common pricing primitive among AI-native companies, though some companies in the cohort also use prepaid credits and hybrid seat-plus-usage structures. The paper records credit-based entries at Adobe in 2023, HubSpot in 2024, Salesforce in 2025, and Notion in 2026. The pattern extends beyond AI-native sellers. Prepaid balances give enterprise buyers a committed budget and keep the published price list separate from changing model costs, so a price migration is not needed every time a new model ships.

What prepaid drawdown and true-up actually require a billing system to do

Prepaid drawdown requires a ledger. Each credit lot needs a record of its source, amount, expiration, and drawdown order. Debits must be atomic and idempotent so that concurrent consumption or retries cannot spend the same balance twice. Expiry and refunds also depend on lot-level records. Without them, a total balance cannot explain which credits remain available or what an unused balance represents.

Gupta specifies atomic, idempotent debits, threshold-triggered automatic recharge, configurable balance limits, low-balance alerts, and defined exhaustion behavior for the observed prepaid mechanics at OpenAI and Anthropic. Formance’s 2026 account describes a double-entry ledger in which each burn recognizes its own revenue atomically. The customer wallet and finance’s revenue record must derive from the same log to keep consumption and recognition aligned.

True-up adds reconciliation after the bill is first calculated. Late meter data, corrected records, and contractual reconciliation periods require the original reading, correction, approval, and accounting entry to remain traceable. Otherwise, billing and revenue can diverge across reporting periods. Underneath both mechanics, metering must validate, buffer, and durably store events through traffic spikes, with idempotency protecting against duplicate charges and an explicit late-event policy governing period treatment.

How fast pricing is actually changing, and why that velocity compounds the problem

A working contract model is only a starting point. Salesforce’s May 2025 introduction of Agentforce Flex Credits illustrates how established software companies are extending credit denominations to AI workloads. With these changes, billing systems must handle new commercial terms as well as repeat an existing subscription schedule. Buyers must establish whether that change can be made without turning pricing configuration into an engineering project.

Gupta documents Cursor repricing in June 2025 and publicly clarifying the change within two weeks. The paper classifies the case as “boundary ambiguity” for seat plus usage add-on pricing. Invoice presentation is part of the pricing design. If customers cannot distinguish included allowance from paid overage, the platform has not made the contract understandable even if it can calculate the charge.

That velocity changes what a credible demonstration must establish. Buyers must test whether finance or product can change pricing, rather than only whether the vendor can configure today’s contract. Requiring an engineering sprint for each iteration introduces weeks of delay and diverts engineers from product development to pricing logic. A functioning credit wallet that requires an API call to reprice it therefore fails the velocity criterion.

Where standard billing platforms fail when contracts include credit drawdown and commitment tracking

Credit support can take the form of either a configuration layered onto a subscription engine or a native ledger capability. The distinction becomes visible under operating conditions. A characteristic failure occurs when a large upfront commitment is recorded as revenue on receipt. Finance discovers the ASC 606 error at the first reporting close, after the contract is live and the correction requires manual rework.

Separate billing paths for prepaid drawdown and usage overage can produce two invoices or a confusing combined document. Neither gives a unified account of commitment consumed versus remaining. When the allowance boundary disappears from the presentation, customers cannot readily connect the amount charged to the agreement they signed.

Late-event reconciliation exposes another failure. If a platform has no native way to correct the original period, finance has to change the invoice, revenue schedule, and accounts receivable record one by one. Kong Konnect’s 2026 prepaid credit metering release describes a lack of visibility into the costs of LLM calls, agent invocations, and API requests. The shortfall affects how well customers can see their spending and how well the vendor can control its margin, as well as how invoices are produced.

What the finance team's workload looks like when the billing system can't handle it

When these connections are absent, finance becomes the reconciliation layer. Consider the first reporting close for a large prepaid enterprise contract. Finance must connect the contract terms to metered consumption, credit drawdown, overages, and any modifications to determine the amount expected to be collected. A subscription billing schedule alone cannot make those links. The team then has to reconcile that collection view with the amount eligible for revenue recognition.

Under ASC 606, prepaid credit revenue is deferred on receipt until consumption. Expected breakage on unused credits is recognized proportionally to consumption. If deferral and recognition schedules are not automated, finance has to rebuild them from raw usage data each reporting period. A late true-up adds external records of the original reading, correction, approval, and accounting entry for the audit trail.

This work recurs as hybrid contract volume grows. Its scale follows the number of contracts. A fast-growing enterprise segment can therefore saturate finance’s reconciliation capacity before revenue growth justifies additional headcount. The organizational cost is an ongoing close workload.

Why buyers discover the gap after contracts are signed, not during evaluation

Standard evaluations tend to test the billing flow for the pricing model at signing. They rarely exercise the deviations that occur later. Questions about support for usage billing, prepaid credits, and hybrid contracts can all receive affirmative answers because the platform has some implementation of each. Those answers do not establish how deeply the mechanics are integrated.

The omitted questions concern operations over time. Late meter data after period close, deferred revenue for a large commitment, and a partial refund of an unused balance each test something that a clean initial billing demonstration can conceal. Discovery typically occurs in the first or second reporting period after a major enterprise contract goes live. That is when finance needs a deferral schedule or a true-up record that the demonstration never required.

Gupta describes the relationship between pricing and infrastructure as bidirectional. Pricing designs determine what metering, entitlement, and settlement systems must do, while system capabilities bound which designs are practical to operate. A shallow evaluation can leave the commercial team unaware of those limits. Buyers should run contract scenarios through their exceptions.

Specific evaluation tests that expose whether a billing platform genuinely supports drawdown and true-up

Buyers should ask the vendor to show an account that has multiple credit lots with different amounts, expiration dates, and drawdown orders. A partial burn should span two lots. The resulting ledger must show depletion at the lot level. This establishes whether the system preserves the records required to explain consumption.

Next, the vendor should receive a sizeable prepaid commitment and generate its ASC 606 deferral and recognition schedule across a 12-month contract as credits are consumed. The schedule must come from the system. Requiring finance to construct it externally reveals that credit billing and revenue recognition remain separate operational tasks.

The late-event test should send in usage with a timestamp that falls within a billing period that has already closed. The vendor must demonstrate the correction against that original period, the updated revenue record, and the audit trail without manual intervention. Each part needs to remain connected. An adjusted invoice alone does not demonstrate true-up reconciliation.

To test pricing velocity, a finance or product team member should change the credit burn rate for a specific usage type. The new rate should apply to new contracts while existing contracts retain the old rate. Engineering involvement fails this test.

Invoice presentation needs its own scenario. Buyers should request a sample covering a prepaid commitment, a usage allowance, and overage within the same period. It should show commitment consumed, allowance remaining, and overage charged in one coherent document. Separate line items originating from separate billing paths reveal integration.

Finally, the vendor should use up a balance mid-period. A hard cap, automatic recharge, or accumulating overage can each be valid, but the system must execute the contract’s specified behavior. The demonstration should also cover configurable balance limits, low-balance alerts, threshold-triggered recharge, and atomic, idempotent debits. A zero-balance display is not sufficient evidence of enforcement.

The build-vs-buy calculus when in-house metering teams push back on purchased billing infrastructure

In-house metering is a credible architectural choice. Gupta finds that, where the choice had been made, the metering layers were built in-house in a large majority of cases, while 74% of companies bought their billing platforms. The two decisions are independent. A team’s ownership of event ingestion alone does not show that it should also own credit accounting, reconciliation, and revenue recognition.

Building billing can be justified when the pricing model is genuinely unusual and no vendor supports it. Building can also make sense when managed platforms cannot meet billing data residency requirements, or when usage is so high that per-event platform fees cost more than the engineering work. Outside those conditions, buying is the default. On-premises requirements in health-tech and fintech narrow the vendor field, but do not by themselves require an internal build.

The cost calculation must include continuing ownership. A production-grade system for hybrid pricing, credit wallets, and basic revenue recognition needs substantial engineering investment, followed by upgrades, maintenance, and debugging. The team that builds the ledger can become the dependency for every pricing change, true-up adjustment, and ASC 606 schedule.

What purpose-built billing infrastructure that natively handles drawdown and true-up looks like in practice

Infrastructure built for this purpose has credit lots, commitments, and reconciliation as first-class objects. Formance’s ledger pattern provides a concrete architectural target. Each burn recognizes revenue atomically, and the customer wallet and finance reporting draw from the same log. Each lot retains its source, amount, expiration, and drawdown order as a permanent record rather than losing that detail in an aggregate balance.

Real-time metering at millisecond latency supports enforcement when a balance reaches zero, ahead of the next batch reconciliation. Prepaid commitments and postpaid overages belong on the same engine. Otherwise, the buyer inherits an integration project to reconnect mechanics that coexist within a single enterprise contract.

Finance and product need to change burn rates, add usage dimensions, and launch tiers for new contracts without engineering tickets. Buyers with strict residency requirements need an on-premises option, while customers need direct, real-time visibility into their balance, drawdown rate, and projected exhaustion date.

The evaluation posture follows from these requirements. A platform with this architecture should demonstrate the scenarios through ledger records, schedules, invoices, and enforced contract behavior. Buyers should make that performance the acceptance gate before signing.