Dunning, Prepayment, and Spend Caps: How to Stop Unpaid AI Bills

For many SaaS applications, if a user doesn't pay, it's not a big deal.

Sure, that implies that they are churning, which translates to lost revenue, but the cost of the service was likely minimal. However, with AI, this isn't exactly the case. AI is expensive. If a user racks up a massive AI bill and doesn't pay, then the entire customer account may be unprofitable to the business.

Thankfully, there are a few pricing models,plus budget and usage alerts that put hard limits on runaway AI spend, that mitigate this risk.

1. Prepayment

The obvious solution to a customer not paying is to request prepayment. If users pre-purchased tokens (or whatever unit) in advance, there is no risk of a lack of payment. The credits are just consumed over time. This creates a new challenge, however. Customer accounts cannot just grind to a halt if credits are exhausted. That would be punishing the best users.

Rather, companies need to automatically top-up credits whenever they run dry or tolerate some level of negative balances.

2. Threshold charging (dunning by another name)

The other solution is to bill customers whenever usage crosses a reasonable threshold. For instance, if a company can tolerate a $5,000 loss, then they can bill the client whenever they reach $2,500 in costs. If they reach another $2,500 tranche without paying the last invoice, then service can be cut-off.

This is particularly reasonable if the payment method is set to auto-pay.

While this does introduce some risk, it may be preferred over prepayment if there are concerns that prepayment will negatively impact sales. It also transparently provides the customer with a reminder of their spending rate.

⚠ There is a complication with this strategy, however. Some customers may reach the billing threshold really slowly. Hypothetically, some might never reach it. To address this, customers should still be billed at a monthly (or yearly) cadence. That way, their balance is wiped out, restarting the cycle.

A past-due balance that never resolves is exactly what this cadence prevents — it forces a monthly reset instead of letting an account drift indefinitely.

3. Spending minimums

Sometimes, metered pricing may also have spending minimums.

This is independent of a subscription tier—the minimum is applied to units (e.g. tokens) used. For example, if the minimum is 5M tokens / month, and the user only used 3M tokens last month, then they'll still be charged for the full 5M. Spending minimums might often equal one base unit. For instance, if the rate is $5.00 / 1M tokens, and 1M tokens was the minimum, then any value below a single base unit (e.g. 800K tokens) would round up.

4. Enterprise contracts

AI companies often offer enterprise contracts with negotiated prices. This rises the need to tailor prices, thresholds, and packages for each individual enterprise customer. This personalization can sometimes be expensive; maintaining unique pricing for each contract naturally leads to a bigger administrative overhead. It also mandates for a more flexible billing system to account for the variations.

Spend caps close the loop

None of the four models above eliminate risk on their own — they cap it. That's what budget and usage alerts are for: lifetime spend caps for free trials, current-cycle thresholds that notify finance at 80% of a customer's credits, and metric-based alerts tied to dollars or usage volume. Each threshold can be soft (notify and keep serving) or hard (pause automatically). Combined with prepayment, threshold charging, and spending minimums, this is the layer that turns "we hope they pay" into a system that never lets the exposure get large enough to matter.

It's also worth knowing this problem doesn't disappear at scale — see revenue leakage in SaaS billing for the broader pattern of money that quietly slips through billing systems, and usage-based billing models for how these mechanics fit into a full pricing structure.