5 SaaS Billing Mistakes That Cost Money

1. Not Retrying Failed Payments Correctly

The single most expensive billing mistake is botching payment retry logic. When a credit card fails, most founders either retry too aggressively (annoying customers and triggering fraud alerts) or not at all (losing revenue immediately).

Stripe's default Smart Retries are good but not perfect. They work well for involuntary churn like expired cards, but you still need to handle edge cases yourself.

What goes wrong:

• Canceling subscriptions immediately on first failure instead of giving cards time to work
• Not sending dunning emails that actually explain what's happening
• Retrying at the same time every day when the card might have daily limits
• Not distinguishing between hard declines (stolen card) and soft declines (insufficient funds)
• Failing to update payment methods when Stripe's card updater service provides new details

The right approach: Use Stripe's Smart Retries, but layer your own dunning email sequence on top. Send a friendly heads-up on first failure, a clear action-required email after 3 days, and a final warning before cancellation. Studies show that proper dunning emails recover 10-15% of failed payments.

2. Poor Proration Handling on Plan Changes

Proration sounds simple until you actually implement it. When customers upgrade or downgrade, you need to calculate exactly what they owe or what credit they deserve. Get this wrong and you either undercharge (losing money) or overcharge (losing customers).

The complexity multiplies when you mix annual and monthly plans, add-ons, usage-based components, and mid-cycle changes.

Common mistakes:

• Not prorating at all, just charging full price for the new plan immediately
• Using Stripe's automatic proration without understanding what it actually does in your specific setup
• Forgetting to prorate annual plans correctly when someone switches to monthly
• Not handling timezone differences, causing off-by-one-day calculation errors
• Showing customers a preview of charges that doesn't match what they actually get billed

The damage: If customers see unexpected charges, they contact support. That burns your time and theirs. Worse, some will dispute the charge with their bank, which costs you $15-25 per dispute regardless of outcome. And if your dispute rate gets too high, payment processors start threatening to drop you.

The fix: Always show customers exactly what they'll be charged before they confirm a plan change. Use Stripe's upcoming invoice preview, but test it thoroughly with every combination of plans you offer. Build your upgrade flow to be transparent about timing, credits, and charges.

3. Breaking Webhook Handling

Webhooks are how Stripe tells your app what happened. Payment succeeded, subscription canceled, invoice paid, dispute created. If your webhook handler breaks or gets overloaded, your database falls out of sync with reality.

This is where AI-generated code especially falls apart. An LLM will give you a basic webhook handler that works in testing but fails under production load or edge cases.

What breaks:

• Not verifying webhook signatures, allowing anyone to send fake events to your endpoint
• Processing webhooks synchronously, causing timeouts when Stripe expects a fast response
• Not handling duplicate events, which Stripe explicitly warns will happen
• Failing silently when your database is down, losing critical billing events forever
• Not logging webhook payloads, making debugging impossible when something goes wrong

Real example: A founder came to us after discovering their webhook handler had been failing for two weeks. Stripe kept trying to deliver events, got timeouts, and eventually gave up. Result: 47 customers had canceled subscriptions that were still showing as active in the app. Those customers kept using the product for free, and some were furious when they finally got cut off.

The solution: Webhook handlers must be fast, idempotent, and resilient. Return a 200 response immediately, queue the actual work, verify signatures, handle duplicates, and log everything. Use a dead letter queue for failures so you can replay events manually if needed.

4. Not Handling Subscriptions and Seats Correctly

Per-seat billing seems straightforward until you deal with real usage patterns. Customers add users mid-cycle, remove them, forget to remove them, add ten at once, then remove nine the next day.

Each scenario requires different handling to avoid either losing money or creating billing surprises that kill trust.

The problems:

• Letting customers add unlimited seats without charging until next billing cycle (giving away free usage)
• Charging immediately for new seats but not crediting removed seats, which feels unfair
• Not setting a maximum seat count, then getting hit with a $10,000 Stripe bill when someone adds 1,000 seats as a test
• Allowing seat removal that drops below your plan minimum, breaking your pricing model
• Not handling the case where payment fails for additional seats but base subscription succeeds

The nuance: Different businesses need different approaches. B2C SaaS might not prorate seat removals at all (use it or lose it). B2B SaaS with annual contracts needs careful proration and often manual approval for large changes. Usage-based SaaS might not have seats at all, just metered billing.

What works: Decide your seat policy upfront and be explicit about it. Will you prorate additions? Removals? Both? Neither? Set hard limits on how many seats can be added without manual approval. Show customers exactly what they'll be charged before they confirm changes. Test the hell out of edge cases like adding then immediately removing seats.

5. Ignoring Tax Compliance and Invoicing Requirements

Tax compliance is boring until it costs you six figures in back taxes, penalties, and legal fees. Different states, countries, and regions have different rules about sales tax, VAT, GST, and what information must appear on invoices.

Many founders ignore this entirely in the MVP phase, which is fine for a few months. But once you hit certain revenue thresholds or start selling in Europe, you have legal obligations that AI-generated code definitely doesn't handle.

Common gaps:

• Not collecting tax at all, leaving you liable for paying it out of pocket later
• Collecting tax in some jurisdictions but not others, creating audit nightmares
• Not showing legally required information on invoices (VAT numbers, business addresses, tax breakdowns)
• Not storing invoices in a way that meets record-keeping requirements
• Not handling reverse charge VAT for B2B sales in the EU

The stakes: In the US, economic nexus laws mean you might owe sales tax in states where you have no physical presence, just based on revenue thresholds. In the EU, you need to register for VAT in each country once you hit their threshold, unless you use special schemes. Get it wrong and you're on the hook for back taxes plus penalties.

The practical approach: Use Stripe Tax from day one if you're selling internationally. It costs 0.5% of transaction volume but handles calculation and most compliance automatically. For the US only, you might calculate tax yourself, but you still need to register, file, and remit in each state where you have nexus. Budget for a tax professional once you hit $10k+ monthly revenue.

Why These Mistakes Persist

Billing code looks simple in tutorials. Create a customer, create a subscription, handle a webhook. Ship it.

The complexity only reveals itself in production. When real customers hit edge cases. When Stripe sends duplicate webhooks. When someone in Germany with an expired corporate card tries to upgrade to an annual plan on the last day of the month.

AI tools make this worse, not better. They generate billing code that passes basic tests but fails under real-world conditions. They don't know about dunning best practices, proration edge cases, or webhook idempotency. They certainly don't understand tax compliance.

The result: Founders ship billing systems that lose money from day one. Sometimes it's obvious. Usually it's not. You just have a higher churn rate than expected, or a lower average revenue per user, or mysterious support tickets about charges that don't make sense.

How FinishLine AI Handles This

Billing systems are exactly the kind of thing that needs to be built right the first time. The edge cases aren't optional. The compliance requirements aren't suggestions. The reliability standards are higher than almost any other part of your application.

When founders come to us with broken billing implementations, it's usually part of a larger AI-built project that looked good in demos but falls apart in production. We see the same patterns: missing webhook signature verification, no retry logic, broken proration, no tax handling, and zero monitoring.

Our $100 Quick Audit includes a specific billing review if that's your concern. We'll look at your Stripe integration, webhook handlers, plan change logic, and tax setup. You'll get a written breakdown of what's actually broken, what's at risk, and what it would take to fix.

Most billing fixes fall into our Fix & Finish tier ($5k-$15k), depending on how much needs rebuilding. We don't patch over AI-generated code. We replace the broken parts with production-grade implementations that handle edge cases, verify signatures, retry correctly, and stay compliant.

If you're building from scratch, billing is a core part of any SaaS MVP. Our Small Builds ($500-$5k) and Custom Builds ($8k-$25k) both include proper Stripe integration as a standard component. You get webhook handling that actually works, plan management that doesn't lose money, and tax setup that won't create legal problems later.

Book a $100 Quick Audit if you're not sure whether your billing system is costing you money. Most founders are surprised by what we find.