SaaS Billing Made Simple: Subscriptions, Metered Usage, and Dunning

SaaS billing breaks in three predictable places. The first is when you add metered or usage-based pricing on top of flat-rate seats. The second is when customers start changing plans mid-cycle and you have to figure out proration. The third — and the one that actually loses you money — is when payments start failing at scale and your dunning process is held together with three Stripe webhooks and a Slack channel.

Most teams over-engineer the first two and under-engineer the third. They will spend a quarter perfecting their usage aggregation pipeline and then lose 4% of MRR every month to involuntary churn because their failed-payment retry logic is `retry once, then email the customer, then forget about it`.

This guide walks through what actually matters in each of the three hard parts of SaaS billing, with specific numbers, the standard industry patterns, and the gotchas that catch teams the first time they ship paid plans.

Flat-rate seat-based billing is easy. A customer signs up for the $49/seat plan, has 8 seats, and you charge $392 on the first of every month. Stripe handles the renewal, you book the revenue, and nobody thinks about billing for 30 days.

The trouble starts when one of these three things happens:

1. You introduce usage-based pricing. Maybe your product charges per API call, per AI token, per active user, or per workflow execution. Suddenly you need to aggregate usage data, decide on a billing cadence (in arrears? in advance with overage?), handle proration on plan changes, and reconcile your internal usage logs with what you actually invoiced.

2. Customers change plans mid-cycle. Upgrades, downgrades, seat additions, seat removals, plan switches with different feature tiers. Each one creates a proration calculation, an invoice line item that may or may not be the right amount, and an emotional reaction from a customer who does not want to do the math themselves.

3. Payments start failing. At any meaningful scale, somewhere between 5% and 10% of recurring charges fail on the first attempt. Cards expire, banks decline, fraud filters trigger. If you do nothing, this becomes pure churn. If you do something — but the wrong thing — you annoy customers, get cards blocked, or worse, suspend service on a customer whose card just had a temporary issue.

The rest of this post takes each of these in turn.

The simplest SaaS billing model is flat-rate per seat. You define a price per user per period (monthly or annual), the customer tells you how many seats they want, and you multiply.

`monthly_charge = seats * price_per_seat`

For a $19/seat plan with 12 seats, that is $228/month. Stripe (or your billing provider) handles the recurring renewal. Annual billing is the same math with a 12x multiplier and usually a discount, often 15-20% off the monthly equivalent.

The second most common model is tier-based pricing: Free, Starter ($19), Business ($39), Enterprise ($69). Each tier unlocks features and/or higher usage limits. The seat math is the same — you just charge a different price per seat depending on which tier the customer picked.

Where this gets non-trivial:

If you are using Stripe Billing, most of this is configuration rather than code. The trap is assuming Stripe handles things it does not — for example, Stripe will not automatically email your customer about a failed payment unless you turn on Smart Retries plus customer emails, and even then the email content is generic and Stripe-branded.

Usage-based billing is the part everyone wants to add and the part most teams ship in a way they regret six months later. The three common flavors:

1. Pure usage / per-event pricing. $0.001 per API call, $0.05 per AI message, $0.10 per workflow run. Customer pays in arrears for whatever they used. Examples: Twilio, OpenAI, AWS.

2. Included quota plus overage. The plan includes 10,000 API calls. If you exceed that, you pay $0.001 per additional call. Examples: most AI tools, most observability platforms.

3. Tier-based with usage caps. Starter includes 1,000 messages/month, Business includes 10,000, Enterprise is custom. No overage — you upgrade when you hit the cap. Examples: most B2B SaaS in 2026.

For most SaaS teams, option 3 is the right starting point. It avoids the operational complexity of metering and overage billing, gives you a clean upgrade signal, and matches how most B2B buyers actually want to pay (they want predictable, not literal-usage). Option 2 is what you graduate to once you have customers who genuinely need to flex. Option 1 is for true infrastructure plays.

Here is the gotcha that catches almost every team the first time they ship metered billing.

Say your plan includes 10,000 API calls per month for $99. A customer is on day 15 of their billing cycle, has used 6,000 calls, and decides to upgrade to a plan that includes 50,000 calls for $299. What do you do with their existing usage?

The wrong answer: reset their usage to 0 and start fresh on the new plan. The customer thinks `I just lost the 6,000 calls I already paid for`.

The right answer: keep usage running. The customer used 6,000 calls under the $99 plan, then continues from 6,000 toward the $299 plan's 50,000 cap. The proration math happens on the plan price, not on the usage counter.

This seems obvious in hindsight but it is genuinely easy to get wrong if your usage tracking is keyed on `subscription_id` and a plan change creates a new subscription record. The fix is to track usage on the team or customer, not the subscription, and roll it forward across plan changes within a billing period.

The other proration trap: only report overage to your billing provider, never the full usage amount. If your plan includes 10,000 calls and the customer used 12,500, you report 2,500 to Stripe, not 12,500. Reporting the full amount and trusting Stripe to subtract the included quota is how teams accidentally double-bill.

Dunning is the process of recovering revenue from failed payments. It is the highest-ROI engineering investment in your billing system and the part most teams treat as an afterthought.

The baseline numbers most SaaS finance teams quote:

Industry standard for SaaS dunning is 4 retry attempts spread across roughly 14 days, with the most common cadence being:

- Day 1: First attempt fails. Retry immediately or within a few hours. - Day 3: Second retry. Most temporary declines (insufficient funds, banking glitches) clear by now. - Day 7: Third retry. Customer has been notified by email by this point. Many will have updated their card. - Day 14: Fourth and final retry. After this, you suspend the account or downgrade to free.

Stripe's Smart Retries does something similar by default, using ML to pick retry timing based on what worked for similar declines historically. If you are running on raw Stripe API without Smart Retries, the 1/3/7/14 cadence is the safe default.

What happens in parallel with the retries is the part most teams skip:

Dunning emails fail when they sound like a collections agency. They also fail when they sound like nothing happened.

The rule of thumb: first email is helpful, last email is direct, nothing in between is hostile.

First email (day 1) should read like you are doing them a favor — `we tried to charge your card and it did not go through, here is the easy fix`. Mention the specific reason if you have it (`your card on file expired in April`) because that turns it from a vague problem into a specific action.

The last email (day 14, suspension) should be direct without being aggressive. State clearly what happened, what is suspended, and what one click will restore service. Most customers at this stage are not ignoring you on purpose — they are dealing with an issue that requires their finance team's attention.

The in-between emails are reminders, not escalations. Do not threaten suspension at day 3. Do not bold-and-red-text day 7. Save that energy for the actual suspension notice.

When all retries fail, what do you actually do? The most common patterns:

Hard suspension — block all access to the product except a billing-update screen. This works for high-touch B2B where the customer relationship is deep enough that suspension is annoying but not relationship-ending. It does not work for low-touch products where the customer can just leave and use a competitor.

Graceful degradation — limit features but keep core access. The customer can still log in, see their data, maybe even do basic operations, but advanced features (integrations, exports, automations) are blocked until billing is current. This is friendlier and tends to recover more accounts.

Read-only mode — customer can view but not write. Common in data-heavy products where the customer's pain is `I cannot make changes` rather than `I cannot see anything`.

Auto-downgrade to free tier — for products that have a free tier, this is the cleanest option. The customer keeps using the product on the free plan and the upgrade prompt becomes a daily reminder.

Whichever you pick, make the recovery path one click. The customer should land on a page that updates payment method, runs the failed charge, and reactivates the account in a single flow. Every additional click between failed payment and full recovery is dollars left on the table.

Sales tax on SaaS is a topic that deserves its own post and probably a CPA. The short version, current as of 2026:

US sales tax is now collected on SaaS in roughly half of US states, with the specific rules varying by state. Tax nexus is triggered both by physical presence and economic thresholds (typically $100K in sales or 200 transactions in a state per year). Once you cross nexus in a state, you have to collect and remit sales tax there.

EU VAT applies to all B2C SaaS sales into the EU regardless of your location. B2B sales use the reverse charge mechanism if the customer provides a valid VAT number. The OSS (One-Stop Shop) registration consolidates filings.

UK VAT is similar to EU VAT but a separate registration since Brexit.

Canada GST/HST, Australia GST, and a long list of other jurisdictions have their own rules.

The practical answer for most SaaS startups under ~$5M ARR: use Stripe Tax, Anrok, or a similar automated solution, and consult a SaaS-specialist tax accountant before you cross any major threshold. Do not try to build this in-house. The complexity is real and the penalties for getting it wrong are not theoretical.

There are roughly three options for SaaS billing infrastructure in 2026:

1. Stripe Billing alone. Use Stripe's hosted checkout, Stripe's invoice generator, Stripe Smart Retries for dunning, and Stripe Tax for sales tax. This is the path of least resistance for most B2B SaaS up to roughly $10M ARR. Pricing is roughly 0.5% on top of Stripe's normal payment processing fees, give or take depending on your plan.

2. Stripe + custom. Use Stripe for payment processing and the subscription primitives, but build your own invoicing UI, your own dunning flows, your own customer billing portal. This is the right choice when you have specific requirements that Stripe Billing does not handle well — complex usage aggregation, custom invoice formats for enterprise customers, multi-currency setups with specific FX rules, or industries with unusual compliance needs.

3. All-in-one billing platform. Tools that sit between you and Stripe (or other payment processors) and handle subscriptions, metering, dunning, taxes, and revenue recognition in one product. These are typically priced as a percentage of revenue or a flat platform fee. Right answer for teams that want to ship billing in a quarter rather than a year.

For most B2B SaaS startups under $5M ARR with relatively simple pricing, Stripe Billing is the right choice. The fancy platforms become worth it once you have multiple pricing axes (seats + usage + add-ons), enterprise customers asking for custom invoice terms, or revenue recognition requirements driven by an external auditor.

Deelo's Invoicing app is built for the layer of billing your finance team owns directly — invoices to clients, recurring billing for services and retainers, payment tracking, and accounts receivable. It is not a Stripe Billing replacement for your SaaS subscription product, but it is the right tool for the operational billing your team does outside that subscription.

Where it fits naturally:

- Service-layer SaaS billing. If your product has a self-serve SaaS subscription (handled by Stripe) plus implementation services, training, or custom add-ons billed manually, Deelo Invoicing handles the manual side cleanly while Stripe handles the recurring side. - Recurring invoicing for services-led businesses. Agencies, consultancies, and managed-service businesses that bill monthly retainers can use Deelo Invoicing as the primary recurring billing engine, with built-in payment links and automated reminders. - Accounts receivable for B2B SaaS. Enterprise customers who insist on net-30 or net-60 terms and pay by ACH or wire need invoicing software, not just a Stripe checkout. Deelo Invoicing handles the invoice issuance, payment tracking, and aging report side.

Under the hood, Deelo Invoicing integrates with Stripe for payment collection, supports automated payment reminders (which is a form of dunning for invoices, not subscriptions), and connects to the rest of the Deelo platform — so a deal won in CRM can flow into a contract signed in ESign and an invoice issued in Invoicing without re-entering data.