Skip to main content
Prepaid usage drawdown invoices a committed usage pool up front, then recognizes revenue as you record consumption against that remaining balance. After you finish this page, the usage obligation bills as Prepaid drawdown, a funding invoice sits in deferred revenue, and later usage draws that pool down instead of creating a pay-as-you-go invoice. For the accounting model, see How Usage Drawdown Works.

Prerequisites

Before you configure usage drawdown, confirm the following:
  • Revenue recognition is enabled for your organization.
  • The item on the obligation uses the Usage recognition strategy and has a deferral account.
  • You know the committed prepaid quantity and rate, or the flat or tiered usage pricing that DualEntry should apply before it draws the pool.
  • You are creating or editing a contract that does not already require a change order or auto-renewal on the drawdown obligation. Those actions are unavailable after prepaid drawdown is in use.

Configure prepaid drawdown on an obligation

Set billing mode to Prepaid drawdown on the usage obligation so DualEntry invoices the committed pool instead of billing each usage row.
  1. Open Accounting > Revenue Recognition > Contracts and create a contract, or open an existing draft contract.
  2. Add a performance obligation and select an item that uses the Usage recognition strategy.
  3. On the Terms tab, enter the committed quantity and contract rate when the obligation uses a flat rate.
  4. When the obligation uses graduated, volume, or block pricing, configure the usage pricing model and tier scope on the Terms tab instead of a single contract rate. See Usage Pricing: Flat and Tiered Models.
  5. On the Invoicing tab, set Billing mode to Prepaid drawdown.
  6. Set the prepaid invoice timing: Frequency, Interval, and First Invoice Date / Last Invoice Date. For a one-time funding invoice, set Invoice Date instead of a date range.
  7. Leave Sync with recognition off. DualEntry rejects billing that stays in sync with recognition on a pool-backed usage obligation.
  8. Save the obligation, then activate the contract when the terms are complete.
DualEntry creates the funding invoice for the committed quantity as soon as the drawdown obligation is saved, using the invoice dates you set. That invoice credits the deferral account and does not recognize revenue. After the invoice exists, DualEntry locks quantity, rate, and discount on the obligation. Add more funds with a top-up instead of editing those fields. DualEntry also blocks switching billing mode away from drawdown while invoice lines remain against the obligation.
A contract with any prepaid drawdown usage obligation cannot receive a change order, and drawdown obligations do not auto-renew. Confirm the committed quantity, rate, and term before you activate the contract.
You can set the same billing mode through the contracts API by sending billing_mode as drawdown on the usage obligation. The obligation response then includes prepaid_invoiced, prepaid_recognized, and prepaid_remaining.

Record usage against the prepaid pool

Record usage the same way you do on other usage obligations. DualEntry prices the row, then draws the priced amount from prepaid remaining. Choose one intake path:
  • On the contract: open the active contract and choose Update Usage.
  • From a file: import usage from CSV, or use Import Multi-Contract Usage when you are loading many contracts at once.
  • Through the API: post usage to /public/v2/contracts/{contract_id}/usage/bulk-upsert/.
Then complete these steps for every row, regardless of intake path:
  1. Enter the usage date and quantity. DualEntry maps the row to the usage obligation.
  2. Save the usage. DualEntry applies the obligation’s pricing model, reduces prepaid remaining, and creates the recognition for the priced amount.
Each usage row needs a date and quantity. Do not expect a second invoice for consumption that fits in the remaining pool. The customer already paid when the pool was funded. If DualEntry rejects the write, the priced amount is greater than prepaid remaining. DualEntry does not keep a partial row or invoice the excess. Top up the pool so remaining funds cover the usage, then record the same date and quantity again. Editing, adding, or archiving a usage row can leave later tiered rows with stale amounts. Use the usage reconcile flow to preview and apply corrected rates. After reconciliation, DualEntry redraws the corrected amounts from the remaining pool. The same insufficient-funds check applies to imported rows and API writes that land on a drawdown obligation.

Top up the prepaid pool

A top-up adds prepaid funds to the same usage obligation when remaining credits are too low for the next usage, or when the customer buys more capacity.
  1. Open the contract that already has a prepaid drawdown usage obligation.
  2. Add a top-up for the additional prepaid amount.
  3. Save the top-up. DualEntry creates another funding invoice, credits the same deferral account, and increases prepaid invoiced and prepaid remaining.
A top-up is a funding event, not a new performance obligation and not a change order. It does not unlock quantity, rate, or discount on the original obligation, and it does not switch billing mode. Later top-ups increase the available balance going forward. They do not rewrite a usage write that DualEntry already rejected. After the top-up invoice exists, retry the usage that previously failed the funds check. If the priced amount now fits in prepaid remaining, DualEntry records the usage and recognizes that amount from the pool.

Track prepaid invoiced, recognized, and remaining

The contract overview keeps prepaid invoiced, prepaid recognized, and prepaid remaining tied together so you can see how much of the pool is still deferred. After each funding invoice, usage row, top-up, refund, or termination, confirm this identity:
  • Prepaid invoiced equals prepaid recognized plus prepaid remaining.
  • Prepaid recognized is never greater than prepaid invoiced.
  • Prepaid remaining is never negative.
Those amounts also appear on the obligation in the contracts API as prepaid_invoiced, prepaid_recognized, and prepaid_remaining. Use them when you reconcile the deferral account to the contract. The prepaid remaining balance rolls into the standard revenue reports as deferred revenue until usage draws it down. For the deferred revenue rollforward, invoice waterfall, and contract-level schedules, see Reporting. If the term ends and prepaid remaining is still greater than zero, DualEntry does not recognize that unused balance as breakage on its own. Record additional usage if the customer still consumes against the package, or terminate the contract and choose accelerated recognition or cancel remaining schedules.

Troubleshooting

These are the usual blockers when a prepaid drawdown obligation will not fund, consume, or close the way you expect.
  • Usage is rejected for insufficient funds. The priced usage amount is greater than prepaid remaining. Add a top-up that covers the shortfall, then record the usage again. DualEntry does not invoice the excess automatically.
  • Quantity, rate, or discount will not save. A funding invoice already exists. Add capacity with a top-up instead of editing the original obligation amounts.
  • Billing mode will not leave Prepaid drawdown. Invoice lines still exist against the obligation. DualEntry keeps the obligation on drawdown while those lines remain.
  • Add Change Order is missing. That action is unavailable on any contract that has a prepaid drawdown usage obligation. Top up the pool, or terminate and replace the contract.
  • Unused prepaid funds are still in deferred revenue after the end date. DualEntry does not auto-recognize breakage. Consume the remainder or terminate the contract so the remaining prepaid balance is accelerated or reversed.
  • The obligation header shows a larger amount than the prepaid invoice. Usage form totals can still show a pricing estimate such as quantity times rate times invoice periods. Actual recognition follows recorded usage against the prepaid pool, not that header estimate.

Next steps

Last modified on October 7, 2026