Scaling SaaS Billing: How To Plan For The Insanity

~ 18 min read | October 14

A billing system is at the heart of the subscription wheel. It holds the spokes of invoicing, accounting, and reporting together so your business can operate in the way that you intend it to. The problem is that billing can get complex overnight and throw a wrench in the works. This guide disrupts the complexity of billing so you can make better plans, whether you’re building your own system or buying one.

When Synergy signed their first two customers in December 2016, they opened that bottle of whiskey they’d been saving. Amidst rueful conversations, memories tinged with nostalgia, and clinking ice, the three founders began to feel the road they were on curve towards solvency. It felt like validation. And validation felt good.

Synergy hadn’t given much thought to the infrastructure around their SaaS product. That quickly changed as 2017 began to usher new customers and revenue in.

All of a sudden, the engineer-founders went from thinking about efficient code to thinking about customer lifecycle management, customer support, subscription management, marketing campaigns, and sales decks. They were determined but it was overwhelming—the blinders were off—they weren’t just building a product anymore, they were responsible for a business.

Of all the things they were juggling, billing seemed to be the simplest. Synergy used Stripe and Stripe subscriptions. It let them accept payments and generate receipts in a matter of minutes. It also allowed them all-essential mental space – there were so many other things to think about.

One crisp August morning one of their customers asked if Synergy supported payment by cheque. Of course, the founders said yes. “Pay us however you want,” they told him, “we’ll figure the details out”.

The details proved to be more complex than they expected, though. Stripe didn’t support receipts for payments via cheque. That meant manually entering the payment into Quickbooks, their accounting software, and manually generating a receipt for the customer.


But, it didn’t end there. The customer had to be manually created in Stripe, and his payment manually recorded so it didn’t throw off their MRR or revenue recognition.

They were suddenly looking at code that had to be written on top of Stripe so they wouldn’t have to put this kind of manual work in every month. Mildly annoying, but nothing that they couldn’t handle. The leak was successfully plugged.

Until two months later, when they had a customer request a custom price. And another ask for a one-time add-on service.

The leaks began to pop up faster than they could plug them, towards the end of 2017—marketing asking for coupons, investors asking for metrics, sales asking for pricing experiments and, most importantly, customers asking for credits, prorated payment plans, and an endless list of subscription management intricacies—all innocuously tied to what they initially suspected to be the simplest component of their business—their billing system.

This guide is a deep dive into the complexity of the billing system. What makes billing systems so complex? Why? How can smart businesses plan for the complexity? Can the complexity be avoided altogether?

We’ve been helping subscription businesses with their billing since 2012, and this is how we’ve learned to think about it along the way.

When billing goes from simple to complex

I absolutely hated billing because we had our own self-built billing system that was always super buggy because of our actual product being priority #1 for our development team.
Jeroen Bos, co-founder and Chief Product Officer,

With a payment gateway whirring away at your checkout page, it comes down to a few lines of code to set up the most basic subscription model there is (if you payment gateway doesn’t support it already): the monthly recurring credit card payment.

The simplicity of it is mind-boggling—not much more than a CRON job (because a gateway stores the crucial credit card information and integrates directly into your checkout page, all you need to build is code that schedules the card to be charged every month, for the uninitiated).

It’s 100% true that recurring billing can be as simple as a few lines of code.


A simple billing system will break when it runs into a recurring model outside of the simple subscription structure it has been constructed to handle.

A billing system goes from simple to complex when small changes add up to make complex subscription models like this:

Jill has three subscriptions that all need to be billed on the 1st of every month (she signed up for all three at different points during the previous year). She has a six month Christmas deal from last year that she’s still seeing through—which means she’s got 25% off two of the three subscriptions.

She’s also based in Australia and that means 1) the amount she is charged ought to be inclusive of tax and 2) her invoice ought to lay out the details of the breakup of the final amount she is charged as clearly as possible.

A use case like this makes you wonder how many times the ‘monthly recurring card payment’ code might have had to be rewritten to suit this kind of flexibility with taxes, promotions, and irregular charges.

How long does a business take to get from monthly credit card payments to this level of complexity?

There’s no definite answer to that question.

But we’ve managed to isolate the variable that’s responsible, and I think it’ll help put the trouble with scaling a SaaS billing solution in perspective.

Subscriptions maketh bills

Billing is a simple process. It’s always been.

There are only three elements to it—collecting a payment, recording the payment for your customer (raising an invoice), and recording the payment for yourself (so you can pay your taxes, or return the money if you have to).

So, where does the complexity come from?

It comes from building on top of those fundamentals to accommodate subscriptions.

Questions of how bills should recur and when aren’t billing related at all, they’re subscription questions and product questions, closely tied to the growth of your company.

Billing gets complex when your subscriptions do. So the line between recurring billing and subscription management gets very hazy once your company is firmly off the ground, with subscriptions flying off the shelves and revenue flying into the bank.

As you start attracting new user personas, expanding into new geographies, and experimenting with your pricing, your subscriptions will evolve into hubs of complexity, affecting your billing.

With user personas come additional payment methods, backup payment gateways, advanced invoicing options, unconventional billing periods, credits and refunds, promotion support, and payment recovery or dunning.

With new geographies come new tax laws, new invoice rules, and support for different languages (what developers call localization).

With new prices come grandfathering existing subscriptions, cloning subscription models, creating new ones, and support for one-time payments (pricing experiments can cost you a fortune without them).

Your billing system will have to support charging every use case, in any permutation or combination. A failure costs you a subscription.

Billing might be black and white, but subscriptions are a whole mess of grey.

Here’s the crux of the problem: failing to acknowledge how billing is influenced by subscriptions will inevitably mean you are stuck with a recurring billing system that cannot scale with your company and a customer experience that is restrained by an inflexible billing system.

Good SaaS billing is damn hard planning

We’re just six developers, and we know that if we try to do it all, we’re going to fail. The best code is the code you don’t have to write. I’d rather spend five days integrating with [an external billing system] than two months building one and going back to it every time we need to make changes.
João Caxaria, Codacy, on why a team of developers chose to go with an external solution.

The key to good billing, then, is to anticipate your subscription needs in the best way you can.

This is easier said than done, though, and here’s why.

1. You don’t know what demands your customers are going to make until they make them

We’ve been in subscription billing for over six years this September, and our customers still surprise us with new ways to mix and match features so they can be creative with their subscription. Over the years, we’ve discovered details within details, microcosms within concepts.

At best, what we can give you is a list of non-negotiables you’ll need when you’re starting out. Over and above those, the way your subscriptions evolve highly depends on what kind of business you are running, how much you want to grow, and how flexible you want your customer experience to be. Good billing is damn hard planning.

Here’s the breakdown of what you’ll need for the first year of operation (if you’re not starting out with complex subscription models).

These features will support most of the subscription management demands that early SaaS companies can expect, from plans that are flexible enough to suit different personas within the market, frictionless transitions from trial periods to paid plans, payment information organized as invoices or receipts for accounting and taxes, easy recovery of payments that have failed because of a technicality with the card or the gateway, and basic reporting so you can use your sales to keep track of the health of your business.

Non-negotiable billing features for B2B subscriptions or B2C subscriptions selling digital services:

  • Plans map out the base price, billing frequency, set up fee, and taxability of your offering. Your plans will define your subscriptions.
  • A Gateway integration – A payment gateway allows you to accept payments from your customers. Here’s a handy guide/post to figure out which one is right for your business.
  • PCI compliant checkout pages
  • Trial periods – Essential, if your plans are competitively priced. Here’s something to help you decide where the line between a free trial and the freemium model is.
  • Support for upgrades to paid plans – This ensures there’s as little friction as possible when your customer decides to make the switch from your trial to one of your paid plans.
  • Support for flexible billing periods – Your pricing will change depending on how your business grows. Make sure your billing system will be able to support any changes.
  • Support for invoices – Fully customizable, an invoice usually contains an itemized list of charges, including details of the customer’s plan and applicable taxes.
  • Communication support – Sending out emails of charges, invoices, and other communication is an essential if you want to keep your customers up to date on changes to their subscriptions. They’re also a good opportunity to build a relationship with your customers.
  • Basic Dunning – 6% of online payments fail. A failure means friction for your customers and revenue that hasn’t reached you as yet. Dunning is the automatic process of retrying a failed payment.
  • Basic Metrics – Your billing system can keep you up to date on the health of your business, with insights on your revenue, your churn, and your renewals.

On the physical goods side, these features will support tracking packages so your customers know that a package has been dispatched after a payment is complete, frictionless checkout so you’re collecting shipping information along with card information (and not on two separate occasions), real-time updates so you can keep track of your inventory, order fulfilment so you don’t accidentally send the wrong package to the wrong customer, refund support in case a customer wants to return something (avoid those chargebacks!), and again, basic metrics so you can keep a finger on the pulse of your business.

Non-negotiable billing features for B2C subscriptions selling physical goods:

  • Plans map out the base price, billing frequency, set up fee, and taxability of your offering. Your plans will define your subscriptions.
  • A Gateway integration – A payment gateway allows you to accept payments from your customers. Here’s a handy guide/post to figure out which one is right for your business.
  • Support for shipping addresses – If you’re selling physical goods, you’ll need to collect and store shipping addresses. When shipping comes around, you’ll have to align the addresses with your plans so you’re sending the right packages to the right customers. This can be a time-consuming process and it’s worth investing in automating as much of it as you can.
  • Shipping operations integration – If you do intend to automate elements of the shipping process, either building or buying a shipping module, your billing system will have to integrate with it.
  • Support for webhooks – Make sure your PO numbers, invoice numbers, and customer information match for each order you’re sending out with webhooks that help your billing system communicate with your website and vice versa.
  • Order fulfillment integration – Part of subscription management, in a physical goods business, is making sure that items that are out of stock don’t appear in the online store (or are marked ‘out of stock’). Your billing system would need to integrate with the tool that you build or buy to achieve this.
  • ERP (Enterprise Resource Planning) integration – You would also have to integrate your billing system with your ERP so that you can mark products as delivered, invoices as paid, or transactions as complete.
  • Support for refunds
  • Basic Metrics – Your billing system can keep you up to date on the health of your business, with insights on your revenue, your churn, and your renewals.

When this basic setup starts to strain under the weight of your subscription complexity, there’s no other way forward than to revisit your billing system and decide how it ought to change in relation to your company. If you’re selling to bigger clients you might want to begin supporting upfront payments for subscriptions and that means advance invoices, you might want to invoice all your customers on the same date every month and this will mean calendar billing, you might want to group subscription together on a single invoice and that means consolidated billing, the options are endless and the right combination of features is unique to your business.

2. Billing systems have a host of moving pieces, and making changes to them can be challenging

Even if you believe you know how your subscriptions are going to change and you can figure out what features you’ll need from a billing system, pouring the resources into building them all upfront is risky. You might build features you don’t need or features that you do but are just a few centimeters off the exact use case you were expecting.

It’s a catch-22. You can build for complexity now and run the risks of over-engineering or you could address complexity as it comes up, which comes with risks of its own.

The risks of addressing subscription complexity as it comes up

If you choose to accommodate complexities as your subscription needs changes, it’s safe to distinguish between two kinds of changes that you will need to make.

  • Small upgrades or ‘tweaks’ to improve performance and accommodate existing subscriptions better and
  • Big upgrades or ‘alterations’ that will fundamentally change the way your billing system operates so you can address new subscription use cases (like Jill’s).

Why Tweaks are difficult to pull off

Every tweak you make is a change to the system, a domino that can set off a series of issues that make the next tweak harder, if it isn’t planned for. The only way to work around the domino effect is to document how you’re building your billing system.

There are two advantages to documentation:

  • It will serve as a frame of reference in case new developers come aboard for maintenance and
  • It will be a lucid record of how features work with each other. It’s worth knowing what changes in one might cripple another.

The problem is that maintaining documentation is an upward trajectory of difficulty because it is an ongoing, time-consuming process.

Why Alterations are difficult to pull off

With documentation, tweaks (like making a small change to your checkout page so that you’re collecting a shipping address in addition to billing information) are more than manageable.

Making an alteration, though (like changing pricing models) is a slow, research-intensive process.

An integration is the perfect illustration of an alteration, in case you’re wondering what I mean. Which brings me to my third point.

3. Your developers need a knowledge base to integrate with tools in your product ecosystem

If you have a product manager or you are one, you know what tools you’ll need to manage your customers and their ecosystems from the get-go. Integrating these tools with your billing system will make sure that all the information you need from your billing system shows up in the right place at the right time. And vice versa, that information shows up in your billing system when you need it.

Some integrations are easier to get off the ground than others—your helpdesk, for example. If you’re working with tools that need to exchange information, setting up a line of communication between them is easy (and there are a host of tools that can help you do it—from Zapier to Cloud Elements to Stitch Labs).

It’s a little harder to integrate with applications that call for more, though, and tools like Zapier and Stitch Labs won’t do a perfect job opening clear lines of communication and working around their limitations.

Think of your accounting software that requires statements to be imported from your gateway so you can reconcile payments from your customers with money in the bank, invoices to be synced (not just the information but the document itself) with its record of your customers, and separate accounts to be managed for each of the products you’re selling.

If you’re building an accounting integration without the aid of an online tool, you would need a dedicated developer who has an advanced understanding of your subscription use cases and how they will expand, and a grasp of basic accounting and taxes to work with your accounting team (whether that’s one person or six) and address their needs. It will take time and effort to learn and understand both sides of the integration before every limitation (there are lots of ifs and buts to account for when two APIs are involved) in each system can be sidestepped to meet the needs of your business.

At some point you’ll ask if it’s fair to expect your developers to be subscription, product, and tax experts from the get-go.

It could take anywhere from a few weeks to a few months, depending on how complex your subscription use cases are—it’s an iterative process of simulating needs, running the simulation by all the teams involved, and then coding it.

The same goes for a customer management integration, a tax integration, a reporting integration, and a referral marketing integration. Each requires a solid knowledge base and multiple teams. Time intensive is saying the least.

Does this mean you need to buy a billing system?

It doesn’t.

Good billing is difficult but it’s far from impossible, especially if you have the resources and your subscription needs are simple.

When building your billing system, what’s important is to plan for subscription complexity right in the very beginning. It’s the only way to make sure your billing system doesn’t stall when you want to meet customer expectations later.

The pros, if you can put in the time, effort, and planning, are—you’ll know exactly what you built, exactly what the limitations of your system are, and there’ll be no external dependencies if something breaks or goes wrong.

Buying an external billing system makes sense only if you want to sidestep the complexity all together and focus on other aspects of your product or business.

Jeroen Bos, co-founder and CPO at puts it better than I can, “If I would have to start this all again, the first project I would take on after a successful MVP for the product would be the implementation of an automated billing system. This instantly gives you the functionality and circumstances to grow as a startup, without all the distractions of having to figure out how European VAT rules work or how to build an MRR calculation script, which is expertise in and of itself.”

If you’re thinking of buying one, you could consider evaluating Chargebee.

Any questions I haven’t addressed?

There are a few.

If a billing system really holds the spokes of the subscription wheel together, can it help optimise them for growth? If a billing system handles all my customer payment information, can it be used for more, revenue recognition and my revenue recovery, for example? Does a billing system help productivity? How?

I’ve saved them for part two: Unhacking SaaS Growth and rethinking recurring billing’s role in it.

Get the scoop on what's new

Yohann Kunders

Former product marketer and staff writer. With a background as a researcher and teacher, he lives to build understanding by disrupting complexity in any way that he can (in SaaS, these days, for Chargebee’s SaaS Dispatch)