How Usage Drawdown Works

Usage drawdown funds a prepaid pool of credits on a usage-based performance obligation, then recognizes revenue only as recorded consumption draws that pool down. The prepaid invoice creates deferred revenue. Each usage row is priced first, then DualEntry reduces the remaining prepaid balance and posts the matching recognition. This page explains when the model fits, how the pool moves, and what happens when usage exceeds remaining funds or prepaid credits go unused. For the setup steps, see How to Configure Usage Drawdown.

​

When to use usage drawdown

Use usage drawdown when the customer pays for a committed pool of usage up front and then consumes against that balance over the term. The commercial form is a prepaid package, a block of credits, or a funded usage commitment, not a bill-as-you-go meter. Typical arrangements include:

• Prepaid API or infrastructure credits, where the customer buys $100 of usage and later consumption reduces that balance.
• Committed cloud or storage packages, where a prepaid quantity is invoiced at the start and later usage draws the funded amount.
• Usage retainers, where finance invoices the commitment first and recognizes revenue as work or consumption is delivered.

Do not use drawdown when every usage event should create its own invoice. That is ordinary usage billing: DualEntry prices each usage row and invoices it in the next billing cycle. Drawdown inverts that timing. Billing happens when the pool is funded. Recognition happens when usage is recorded. Usage drawdown is a billing mode on a usage obligation, not a separate recognition strategy. The obligation still uses the Usage strategy and still prices consumption with flat or tiered usage pricing. DualEntry calculates the usage amount from the pricing model first, then allocates that priced amount against the prepaid pool.

​

The pool of funds

The pool of funds is the prepaid balance DualEntry tracks on a drawdown usage obligation. Funding invoices increase the pool. Usage consumption decreases it. DualEntry does not recognize revenue when the pool is funded. When you save a usage obligation with billing mode Prepaid drawdown, DualEntry invoices the committed quantity according to that obligation’s invoicing schedule. The funding invoice posts accounts receivable and credits the obligation’s deferral account. Payment status does not change deferred revenue. The pool exists as soon as the funding invoice is created. DualEntry stores three prepaid amounts on the obligation:

• Prepaid invoiced: the funded amount billed so far, including the opening invoice and later top-ups.
• Prepaid recognized: the funded amount already drawn into revenue by usage.
• Prepaid remaining: the unused funded balance still sitting in deferred revenue.

Those three amounts stay tied after every funding or consumption event: invoiced equals recognized plus remaining. Recognized never exceeds invoiced. Remaining never goes below zero. A later top-up is another funding event on the same obligation. It creates an additional prepaid invoice, increases prepaid invoiced and prepaid remaining, and does not create a new performance obligation. Top-ups add capacity going forward. They do not rewrite usage that DualEntry already rejected for insufficient funds. After a funding invoice exists, DualEntry locks the obligation’s quantity, rate, and discount against ordinary edits. Add more funds with a top-up. DualEntry also blocks switching the billing mode away from drawdown while invoice lines remain against the obligation.

​

How consumption recognizes revenue

Consumption recognizes revenue by drawing the priced usage amount out of the remaining prepaid pool. DualEntry prices the usage row first, then posts recognition for that amount and reduces prepaid remaining. Consider a customer who prepays $100 of credits on 03/01/2026. The funding invoice books the pool:

• Debit Accounts Receivable $100
• Credit Deferred Software Revenue $100

No revenue is recognized on 03/01/2026. The $100 sits in deferred revenue as prepaid remaining. On 03/31/2026 you record usage that prices to $36 under the obligation’s flat or tiered schedule. DualEntry draws $36 from the pool:

• Debit Deferred Software Revenue $36
• Credit Software Revenue $36

After that consumption, prepaid invoiced is still $100, prepaid recognized is $36, and prepaid remaining is $64. The customer is not invoiced again for the $36. The invoice already happened when the pool was funded. Pricing and pool allocation are separate steps. If the obligation uses graduated, volume, or block tiers, DualEntry applies that schedule to the usage quantity first. The pool then absorbs the resulting dollar amount. Changing a usage row can change later tier amounts, so use the same usage reconcile flow you use on other usage obligations. After reconciliation, DualEntry redraws the corrected amounts from the remaining pool. Recognition still follows the contract’s recognition mode. Individual mode posts the usage recognition through the obligation’s income and deferral accounts. Subledger mode accumulates the line until you post a recognition batch. The pool math is the same in both modes.

​

Overage when usage exceeds remaining funds

Overage is usage whose priced amount is greater than prepaid remaining. DualEntry rejects that usage write instead of invoicing the excess or letting remaining go negative. If prepaid remaining is $64 and you submit usage that prices to $80, DualEntry blocks the entire usage record. Nothing is recognized from that write, and the pool stays at $64. The check applies to usage you enter on the contract, import from CSV, or send through the contracts usage API. To accept the usage, add funds with a top-up first, then record the consumption. A $50 top-up on 03/31/2026 books another funding invoice:

• Debit Accounts Receivable $50
• Credit Deferred Software Revenue $50

Prepaid invoiced becomes $150 and prepaid remaining becomes $114. The $80 usage can then draw down the pool:

• Debit Deferred Software Revenue $80
• Credit Software Revenue $80

After that sequence, prepaid invoiced is $150, prepaid recognized is $116 (the earlier $36 plus $80), and prepaid remaining is $34. DualEntry does not split a single usage row across remaining funds and an overage invoice. It also does not keep the usage and bill the shortfall later. If the priced amount does not fit in the remaining pool, add a top-up that covers the shortfall before you retry the usage.

​

Unused prepaid balance at expiry

Unused prepaid balance is remaining funded amount that the customer never consumed. DualEntry does not automatically recognize that remainder as breakage, or use-it-or-lose-it revenue, when a date passes. If a contract or obligation end date arrives and prepaid remaining is still $34, those $34 stay in deferred revenue. DualEntry does not debit the deferral account and credit a breakage income account on its own. The pool continues to satisfy the invoiced equals recognized plus remaining identity until you consume the remainder or close the contract. Handle leftover funds through the actions the contract already supports:

• Record additional usage if the customer still consumes against the prepaid package. Recognition then draws the remaining pool in the ordinary way.
• Terminate the contract when the arrangement ends and unused funds must leave deferred revenue. Choose accelerated recognition to recognize the remaining prepaid balance, or cancel remaining schedules when the unused amount should not become revenue. Termination amounts for drawdown usage follow the remaining prepaid balance on each invoice and recognition schedule.

Change orders and auto-renewal are not available on a contract that has a prepaid drawdown usage obligation. If the commercial terms change, top up the existing pool or terminate and replace the contract. See How to Configure Usage Drawdown for those operational limits.

​

Next steps

• Configure billing mode, record usage, and top up a pool in How to Configure Usage Drawdown.
• Set the pricing model that calculates each usage amount in Usage Pricing: Flat and Tiered Models.
• Close leftover prepaid balances in Change Orders, Terminations, and Renewals.
• Review prepaid movement on the deferred revenue rollforward.