Prepaid with overages: How it works and how to bill it

Prepaid with overages isn't a new pricing model. It's existed in telco and energy industries long before SaaS and AI companies came along.

Today, it's one of the most popular pricing models for companies offering usage-based pricing.

Because if you ask a prospect how they’d like to pay for usage and you’ll hear the same answer: They want to know the number. They don’t want a cap. (And they’d rather not have a conversation about their bill every month.)

It’s the pricing model behind “1,000,000 API calls a year for $9,000, then $0.012 a call,” and it’s the one that appears in most contracts that come through Alguna.

This post covers what it is, why it's both a customer and finance favorite, and where billing usually goes wrong. Most importantly, we walk you through how you can set up prepaid with overages out of the box in Alguna.

Prepaid with overages: What it is and how it works

How it works

Take a customer who commits to 1,000,000 API requests a year at $0.009 a request, with overage at $0.012.

1. The customer commits to a block. They choose a volume of whatever you meter, such as requests, tokens, gigabytes, or checks, for a set period, usually a year.
2. The block is invoiced up front. At the start of the period, they pay for the whole block at the block rate: 1,000,000 × $0.009 = $9,000.
3. Usage draws the block down. Every unit counts against a running total for the whole period, not month by month. A busy month only creates overage if it pushes the year's total past the block.
4. Usage past the block is billed as overage. Once the running total crosses 1,000,000, each extra request is billed at $0.012, in arrears. Overage usually invoices monthly, and each invoice bills only the units that crossed the block since the last one.
5. The block resets. When the next period starts, the count goes back to zero. Unused units don't roll over.

Why buyers ask for it

Buyers ask for prepaid with overages because it fixes the two things they dislike about the alternatives.

Pure pay-as-you-go makes budgeting impossible. Finance can’t approve a number nobody can predict, so the buyer either pads the estimate or blocks the deal. A block gives them a number to approve.

Pure subscriptions with hard caps create a cliff. The customer hits the limit mid-month and the product stops working, or they get a call from sales at the worst possible moment. An overage rate removes the cliff. Growth costs money, but it never costs access.

A block with an overage rate makes the customer feel in control. They chose the block and they know the rate, sof they go over, it was their decision, and they know what it costs.

3 benefits for finance teams

For the seller, prepaid with overages does three things a plain usage model doesn’t.

1. It brings cash forward. The block is invoiced on day one. On an annual commitment, that’s a year of committed revenue collected before the customer has used anything.
2. It gives finance a floor. Committed revenue is easier to forecast, easier to recognize, and easier to explain to a board than a usage curve.
3. It builds expansion into the contract. Every customer who goes over the block has just told you the block is too small. Overage is revenue this period and an upsell conversation for renewal.

How prepaid with overages compares to other pricing models

How the industry does it: 5 examples

Prepaid with overages is everywhere once you know the shape to look for.

• The block is usually called "included usage," "committed use," or "capacity"
• The overage is “additional usage,” “on-demand,” or “pay-per-task”

Here are examples from public pricing pages (as of September 2026), grouped by what each one teaches.

1. Developer infrastructure: A small block as the on-ramp

A cheap block serving as the on-ramp across several dimensions at once, each with its own overage meter.

2. Messaging: The block is the product, the premium is the lever

Postmark’s modest premium lets a customer run over for a month without much pain.

SendGrid’s steep premium makes the next plan up the obvious move the first time it happens.

3. Workflow and go-to-market software: Overage as a bridge to the next tier

Three answers to “what happens when a customer is over every month.”

• Zapier adds a ceiling so a runaway workflow can’t produce a runaway bill.
• Auth0 charges no premium at all and instead converts persistent overage into a bigger block.
• HubSpot sells the overage itself in blocks.

All three are doing automatically what a sales-led renewal does by hand: resizing the commitment to match reality.

4. Enterprise data and observability: Annual commit, on-demand overage

This is the enterprise version of the model, and the closest to how most B2B contracts are written: A yearly commitment for the discount, on-demand rates for whatever exceeds it, no rollover.

Snowflake’s own guidance to customers is to commit to roughly 80 to 90% of expected usage, which is the block-sizing advice below, from the buyer’s side of the table.

5. AI and developer tools: Blocks denominated in dollars or minutes

When the unit is hard for a customer to reason about, like tokens across a dozen models, the block gets denominated in dollars instead.

What to take from the examples

• The overage premium is a choice, not a law. Postmark and Datadog run about 20% above the block rate, Zapier 25%, Auth0 zero, SendGrid several times over. Pick the premium that produces the behavior you want: a nudge toward a bigger block, or a hard push to the next plan.
• Add a safety valve. Zapier’s cap at three times the allowance exists so a bug can’t generate an unpayable invoice. An alert at 80% and a notification at 100% do the same job more gently.
• Decide what repeated overage means. Auth0 and HubSpot move the customer up automatically. In a sales-led motion the same rule is “resize the block at renewal,” and the overage invoices are your evidence.
• Nobody rolls over. None of these companies carries unused units into the next period. The moment you do, the block stops being a block and becomes a balance with an expiry, which is a different product with different accounting.

Where billing goes wrong

Prepaid with overages is easy to agree to in a sales conversation and hard to bill.

The tricky parts usually comes down to:

• Carrying an allowance across twelve months
• Billing overages monthly without double-charging
• Applying graduated rates to a window that straddles two bands
• Handling a mid-year upgrade

These are the parts that break in legacy billing systems and spreadsheets.

Alguna handles all of it from the pricing you configure once, so the invoice your customer receives matches the contract they signed.

We’ve migrated a lot of prepaid contracts into Alguna, and the same mistakes show up in the spreadsheets they came from.

Overage counted per month instead of per period. The customer commits annually, the billing tool counts monthly, and a seasonal spike in March gets billed as overage even though the year’s total never came close to the block. The customer notices. Trust goes with it.

Surprise overage. The first the customer hears of overage is the invoice. A usage alert at 80% of the block turns the same event into a courtesy and an upsell.

A hard cap sold as prepaid. Some teams sell a block and then switch the product off at the limit because the billing tool can’t rate overage. The customer bought room to grow and got a cliff.

Revenue recognized on the invoice date. The block is invoiced in advance, so it’s deferred revenue released over the period. Recognizing $9,000 in January and nothing for the next eleven months is a restatement waiting to happen.

Manual true-ups. Someone exports usage, compares it to the block in a spreadsheet, and raises an invoice by hand. It works until it doesn’t, usually at quarter end.

Overview: How prepaid with overages works in Alguna

Prepaid with overages is the classic enterprise usage deal: Your customer commits to a volume up front, pays for it in advance at a discounted rate, and only pays extra if they go beyond what they committed to.

In Alguna, this popular pricing model works out of the box:

• One price holds the block, the block price, and the overage rate. Add several tiers to offer several block sizes on the same product; the block the customer buys selects the tier, and the tier sets both rates.
• Two cadences. The commitment bills on its own interval and the overage on another, so an annual block with monthly overage is a setting, not a project.
• Usage counts across the commitment period. Each overage invoice bills only the units that crossed the block since the previous one. Unused units reset at renewal.
• Alerts are automations. Trigger on prepaid usage at 80% to email the customer, at 100% to notify the account owner, once per period per price.
• Mid-term changes prorate the commitment, never the overage, and keep counting usage from the cycle start.
• Revenue recognition is automatic. The commitment is deferred over the period; overage is recognized as delivered.
• Sales can quote it. The prepaid product goes on a quote template, the rep sets the block and rates per deal, and the signed quote becomes the live subscription.

Prepaid with overages in Alguna: A step-by-step guide

Step 1: Agree the commitment

The commitment is a number of units for the term: 100,000 API calls, 2 TB of storage, whatever your product meters.

In Alguna you set this up as a tiered price list, where each tier is a commitment level:

You then enter the number your customer actually committed to, say 100,000, and Alguna picks the matching tier automatically. Bigger commitment, better rate, which is exactly the incentive you want in the room during a negotiation.

You can price each tier:

• Per unit (committed units × price per unit)
• Flat fee for the tier

Use per-unit when the contract quotes a rate, flat fee when it quotes a number.

Step 2: Set the overage rate

Overages are what your customer pays for usage beyond their commitment. You have two options.

1. One flat rate. Simplest: every unit over the commitment costs the same, for example $0.14 per call.
2. Graduated overage tiers. The further over they go, the cheaper each additional unit gets:

Graduated overage tiers are how you keep a heavy-usage quarter from turning into an angry email. The customer's effective rate drifts back down toward their committed rate the more they use, instead of punishing them for growing.

Step 3: Choose how often overages are billed

The commitment and the overages don't have to be billed on the same schedule, and usually shouldn't be.

A typical enterprise setup: The commitment is billed annually, the overages monthly. Your customer pays $10,000 on day one for the year, and any overage shows up on a monthly invoice shortly after they incur it.

This is so you're not sitting on a year of unbilled consumption, and they're not hit with one enormous surprise at renewal.

The only rule is that overages can't be billed less often than the commitment. Monthly overages on an annual commitment: fine. Annual overages on a monthly commitment: Alguna will reject it.

Step 4: The commitment is invoiced up front

At the start of the term, Alguna issues the commitment invoice, the full tier amount, in advance.

This charge doesn't move. It's the same whether your customer uses every unit or none of them. That's what "prepaid" means: they've bought the volume, and the invoice reflects the commitment rather than the consumption.

Step 5: Usage draws down the allowance

From there, Alguna meters usage continuously and counts it against the committed volume.

This is the part most billing systems get wrong: The allowance is a pool for the whole commitment period, not a monthly ration.

If your customer commits to 100,000 calls for the year and burns 30,000 in January, they are not in overage, they've simply used 30,000 of their 100,000. They stay out of overage until cumulative usage for the term crosses the commitment, no matter how lumpy the months in between look.

Alguna tracks usage from the start of the commitment period, not from the start of each invoice.

That's the behavior your customers expect from an annual commitment, and it's the reason a seasonal business can sign one without fear.

Step 6: Overages are invoiced in arrears, once each

Once cumulative usage passes the commitment, the next overage invoice picks up the difference.

Each overage invoice bills only the units that crossed the line since the last one. Alguna keeps a running total of what's already been charged, so nothing is billed twice, and a late-arriving usage event doesn't reopen a settled invoice.

Step 7: The commitment renews and the counter resets

At the end of the term, the commitment period starts again: a fresh allowance, a fresh invoice, and the usage counter back to zero.

Two consequences worth putting in your contract language:

• Unused units don't roll over. A customer who commits to 100,000 and uses 80,000 has bought 100,000. The 20,000 doesn't carry into next year and isn't refunded.
• Upgrading mid-term doesn't reset the counter. If a customer moves up a commitment tier in month seven, the usage they've already consumed still counts. They get the higher ceiling and the better rate, not a clean slate. This is deliberate: it's what stops an upgrade from being used to wipe out overages that were already incurred.

Example: What a full year of prepaid with overages looks like

Acme commits to 100,000 API calls at $0.10, $10,000 for the year, billed annually.

Overages are billed monthly, using graduated tiers: $0.14 for the first 25,000 over, $0.12 for the next 50,000, $0.10 beyond that.

1 January: Commitment invoice: $10,000. Acme's allowance for the year is 100,000 calls.

January to August: No overage invoices. Acme uses 92,000 calls over eight months. Some months are heavy, some are light. It doesn't matter: cumulative usage is still under 100,000, so there's nothing to bill.

September: 20,000 calls. Cumulative usage hits 112,000, crossing the commitment. The overage is 12,000 calls, all within the first band:

12,000 × $0.14 = $1,680

October: 18,000 calls. Cumulative usage reaches 130,000, so cumulative overage is now 30,000 calls. 12,000 of those were billed in September, so this invoice covers calls 12,001 through 30,000. That window spans two bands:

13,000 × $0.14 = $1,820 (finishing the first band)
5,000 × $0.12 = $600 (starting the second)
Total: $2,420

1 January the following year: Commitment invoice: $10,000. The counter resets to zero and the cycle begins again.

Acme's finance team saw one large predictable invoice and two overage invoices they could trace back to specific months. Nobody had to reconcile anything by hand.

Still billing prepaid contracts using a spreadsheet?

If your contracts live in a CRM, your usage in a database, and your true-ups in a spreadsheet, Alguna brings the quote, the invoice, and the revenue schedule into one place.

Prepaid with overages is one of eleven pricing models you can quote, bill, and recognize in Alguna without engineering work.

Frequently asked questions

Is prepaid with overages the same as committed-use pricing?
Close. Committed-use contracts usually name a dollar amount and true up against actual spend. Prepaid with overages names a volume and rates the overage per unit. If your customer negotiates in units, use prepaid with overages; if they negotiate in dollars, a minimum spend with a true-up fits better.

Should the overage rate be higher than the block rate?
Almost always, by a modest margin. The gap rewards the commitment. A large gap pushes customers to oversize the block, which creates unused units and an awkward renewal.

Can I offer a free allowance instead of a paid block?
Yes, but that’s graduated pricing with a zero-rate first tier, not prepaid with overages. The difference is that nothing is billed in advance.

How do I handle a customer who never gets close to the block?
Resize it at renewal, and consider a smaller block with a slightly higher block rate. A customer paying for units they don’t use is a churn risk, not a margin win.

What about customers who want to pay monthly for an annual block?
Bill the commitment monthly and the overage monthly. The block still resets annually if that’s what the contract says; the cadence of the invoice and the length of the commitment period are separate decisions.