Subscription Billing Systems: What to Consider Before Building

Charging a customer the same amount every month looks like a simple problem.

A scheduled job, a call to a payment provider and an email receipt, and you are done. That impression is why so many teams decide to build their own subscription billing system, and why so many of them later describe it as one of the most expensive projects they underestimated.

The difficulty is not the first charge. It is everything that happens around it: customers upgrading halfway through a month, cards expiring, payments failing for reasons you cannot see, tax rules that differ by country and state, invoices that finance teams need to reconcile, revenue that accountants must recognise over time, and consumer laws that dictate how people can cancel. Each of these is manageable on its own. Together, they turn billing into a core financial system where small mistakes cost real money and customer trust.

So should you build? For most SaaS businesses, the honest answer is that you should buy a billing platform and build around it. Building from scratch makes sense only in a narrower set of situations: when your pricing model is genuinely unusual, when billing is part of the product you sell, or when your scale makes platform fees larger than the cost of a dedicated team. This guide explains what a billing system needs to do, where the hidden complexity lies, and how to decide between building, buying and the hybrid approach many growing companies end up with.

What a subscription billing system actually does

It helps to separate billing into its parts, because each one carries its own complexity and its own risk.

The product catalogue defines what you sell: plans, prices, currencies, billing intervals, add-ons, discounts and trial periods. It needs versioning, because prices change and existing customers often keep their old price for a time.

The subscription engine tracks each customer's plan, status and billing cycle. It handles trials, upgrades, downgrades, pauses, cancellations and renewals, and works out what each change means financially.

Usage metering, if you charge by consumption, collects and aggregates usage events such as API calls, messages sent or storage used, then prices them at the end of the period.

Invoicing turns all of that into a legally valid invoice or receipt, with the right tax, numbering, currency and wording for each jurisdiction.

Payments collect money through a payment service provider, store payment methods securely, retry failed charges and handle refunds and disputes.

Dunning and collections manage what happens when payment fails: retry schedules, reminder emails, grace periods and eventually suspension or cancellation.

Tax calculation determines whether to charge VAT, GST or sales tax, and how much, based on where the customer is and what you sell.

Revenue reporting and recognition feed finance with recurring revenue figures, deferred revenue and the records needed to recognise revenue under accounting standards.

Entitlements connect billing to the product, so that a customer's plan determines what features and limits they can use.

Finally, a customer self-service portal lets customers update cards, download invoices, change plans and cancel without contacting support.

When teams estimate a build, they usually picture the subscription engine and payments. The rest is where timelines slip.

When building your own billing system makes sense

The billing platform market is mature. Stripe Billing, Chargebee, Recurly, Zuora and Maxio cover most subscription models. Merchant of record providers such as Paddle take on tax collection and compliance as the legal seller. Usage-based specialists such as Orb, Metronome and the open-source Lago focus on metered and hybrid pricing. With that range available, the reasons to build from scratch have narrowed. They still exist, though.

Your pricing model genuinely does not fit. Most platforms handle flat, per-seat, tiered and usage-based pricing well. Some businesses have pricing that does not map cleanly onto any of them: complex contract terms negotiated per customer, pricing tied to real-world outcomes, multi-party revenue splits or rules driven by industry regulation. Before concluding that yours is one of them, test it against two or three platforms with real examples. Many "unique" pricing models turn out to be configurable.

Billing is part of your product. If you run a platform where your customers bill their own customers, or billing logic is something you sell, you may need full control over how it works.

Scale changes the economics. Platform fees are commonly charged as a percentage of billing volume, often under one percent but sometimes with minimums or tiered contracts. At small volumes this is far cheaper than any team. At very large volumes, those percentages can add up to the cost of several engineers, and building or deeply customising starts to look reasonable.

Specific data or regulatory constraints. Some sectors have requirements about where financial data is stored, how records are retained or how pricing is calculated that off-the-shelf platforms do not meet.

If none of these applies, buying is almost always faster, cheaper and safer. The remaining sections are useful either way: they describe what a bought platform must handle well, and what you will own if you decide to build.

Pricing models and plan changes: where complexity multiplies

Your pricing model shapes the billing system more than any other factor, and pricing tends to become more complex over time, not less. Design for the pricing you expect in two or three years, not the pricing on your website today.

Common pricing structures

Flat-rate pricing charges a fixed amount per period. Per-seat pricing multiplies a price by the number of users. Tiered and volume pricing change the unit price as quantity grows, and the difference between them matters: in graduated tiers each band is priced separately, while in volume pricing the whole quantity takes the price of the band it lands in. Usage-based pricing charges for measured consumption. Hybrid models combine a platform fee with included usage and overage charges, which has become common in SaaS, particularly for AI-powered products where the cost of serving each customer varies with usage.

Each model brings its own requirements. Per-seat billing needs reliable seat counts and rules for when added or removed seats take effect. Usage billing needs an event pipeline that does not lose or double-count data, handles late-arriving events and gives customers a running view of their usage so invoices do not come as a shock.

Proration and mid-cycle changes

Plan changes are where many homegrown billing systems break. Suppose a customer on a $100 monthly plan upgrades to a $300 plan exactly halfway through their billing period. A common approach is to credit the unused half of the old plan ($50) and charge for the remaining half of the new plan ($150), producing a net charge of $100 now and a full $300 at the next renewal. That sounds straightforward until you add annual plans, multiple add-ons, discounts that apply only to certain items, tax calculated on the net amount, changes made several times in one period and downgrades that should take effect at renewal rather than immediately.

Decide your policies in plain language before writing any code. Do upgrades take effect immediately and downgrades at renewal? Are credits refunded or held against future invoices? Do customers keep a discontinued price when they change seat count? Product, finance and support teams should all agree, because they will all deal with the consequences.

Price changes and grandfathering

Sooner or later you will raise prices. The system needs to support versioned prices, keeping existing customers on an older price for a defined period, and scheduled migrations with advance notice. Consumer protection rules in many jurisdictions also require clear notice before a price increase on an existing subscription.

Payments, failed payments and dunning

Recurring payments fail far more often than one-off purchases, simply because a card that worked at sign-up may have expired, been replaced, hit its limit or been flagged by the issuer months later. When customers leave because a payment failed, rather than because they chose to cancel, it is called involuntary churn. For many subscription businesses it is a significant share of total churn, and much of it is recoverable.

Reducing failed payments

Several techniques work together. Card network updater services, such as Visa Account Updater and Mastercard's Automatic Billing Updater, let payment providers refresh stored card details when a bank issues a new card. Network tokens, which replace the card number with a token maintained by the card network, can also keep credentials current and may improve approval rates. Most major payment providers support these, sometimes automatically.

Smart retries matter too. Retrying a declined payment immediately, or at a fixed interval, often fails again for the same reason. Better systems interpret the decline code, retry soft declines such as insufficient funds at times more likely to succeed, and stop retrying hard declines such as a closed account, which need the customer to act.

Dunning communication

Dunning is the process of contacting customers about failed payments. A good sequence starts before failure, with reminders before a card expires, then follows a failure with a clear, friendly email and in-app message linking to a secure page where the customer can update their details in one step. Further reminders follow over a set grace period. Only after that does the account move to restricted access or cancellation.

Decide what happens to service during the grace period. Cutting off access immediately is harsh for a long-standing customer whose card simply expired. Leaving full access indefinitely gives away the product. Most businesses keep access for a short period, then restrict it, then cancel.

Strong Customer Authentication and recurring payments

In the UK and the European Economic Area, Strong Customer Authentication (SCA) rules require many online card payments to be authenticated by the cardholder, usually through 3D Secure. For subscriptions, the customer typically authenticates when they first set up the payment, and later charges initiated by the merchant can then be processed as merchant-initiated transactions, which are generally outside the scope of SCA. Issuers can still request authentication, so your system needs a way to bring the customer back to complete it. A billing platform or payment provider will handle much of this. A custom system must handle it deliberately.

Refunds, credits and disputes

Finally, plan for money flowing back. Refunds, partial refunds, account credits and chargebacks all need to be reflected in invoices, revenue reports and customer balances. Chargebacks in particular need evidence gathering and tracking, because high dispute rates can lead to penalties from card schemes.

Tax, invoicing and revenue recognition

These are the areas where billing stops being an engineering problem and becomes a finance and legal one. They are also where homegrown systems most often fall short, because the people building them are rarely tax or accounting specialists.

Sales tax and VAT

Selling software across borders creates tax obligations in many places. In the European Union, VAT on digital services sold to consumers is generally charged at the rate of the customer's country, and the One Stop Shop scheme lets businesses report that VAT through a single registration. Business-to-business sales often fall under the reverse charge, which depends on validating the customer's VAT number. The UK has its own VAT rules for digital services. In the United States, the 2018 Supreme Court decision in South Dakota v. Wayfair allowed states to require sales tax from remote sellers that exceed economic thresholds, and states differ on whether SaaS is taxable at all. Many other countries tax digital services too.

In practice, very few businesses calculate this themselves. They use a tax engine such as Stripe Tax, Avalara or Anrok, or a merchant of record that takes on tax collection and filing as the legal seller. If you build your own billing system, plan to integrate one of these rather than maintaining tax rules in your own code, and take professional tax advice on where you are registered and liable.

Invoices that meet legal requirements

Invoices are legal documents, and their requirements vary. Many tax authorities specify sequential numbering, the seller's and buyer's details, tax registration numbers, tax amounts by rate and specific wording for reverse charge transactions. A growing number of countries are introducing mandatory electronic invoicing in prescribed formats for business-to-business transactions, so check the rules in the markets you sell to. Credit notes, rather than edited invoices, should be used to correct mistakes, because issued invoices generally should not be changed.

Revenue recognition

Cash received and revenue earned are not the same thing. If a customer pays $1,200 upfront for an annual plan, accounting standards such as ASC 606 in the US and IFRS 15 internationally generally require that revenue to be recognised over the 12 months of service, not on the day of payment. Discounts, bundles, setup fees, usage charges and mid-term changes all complicate the calculation.

A billing system should at least produce clean, detailed records that finance can use for revenue recognition, ideally feeding a dedicated revenue recognition tool or the revenue module of an ERP. Agree the approach with your finance team and auditors early. Retrofitting revenue data into a system designed only to collect payments is painful. (Internal link suggestion: a guide to integrating SaaS billing with accounting or ERP systems.)

SaaS metrics finance will ask for

Leadership and investors will expect reliable figures for monthly and annual recurring revenue (MRR and ARR), churn, expansion revenue and net revenue retention. These look simple but depend on precise definitions. For example, does a customer who pauses count as churned? Does a one-off setup fee count towards MRR? Defining these clearly and calculating them from the billing data, rather than in separate spreadsheets, prevents arguments later.

Security and regulatory compliance

Keep card data out of your systems

Any business that stores, processes or transmits cardholder data must comply with the Payment Card Industry Data Security Standard (PCI DSS). The current version, PCI DSS v4.0.1, introduced a number of requirements that became mandatory in 2025. The scope of your compliance effort depends heavily on how card data flows. If card details go directly from the customer's browser or app to your payment provider through hosted fields, a hosted checkout page or the provider's SDK, and your servers only ever see tokens, your compliance burden is much lighter.

Whatever you build, never store raw card numbers in your own database. Use your payment provider's tokens and keep the billing system's own data, such as invoices and subscription records, well protected with access controls, encryption and audit logs. Billing data reveals revenue, customer lists and pricing, so it deserves the same care as any sensitive business data.

Subscription and cancellation laws

Consumer subscription rules have tightened in many places, and they directly affect how a billing system and its customer portal must behave. The details depend on whether you sell to consumers or businesses, and on where your customers are.

In the United States, many states have automatic renewal laws requiring clear disclosure of renewal terms, affirmative consent and an easy way to cancel, often online if the customer signed up online. California's rules are among the most detailed and were strengthened with amendments effective in 2025. The Federal Trade Commission adopted a nationwide "click to cancel" rule in 2024, but a federal appeals court vacated it in 2025, so state laws remain the main constraint, alongside the FTC's general powers against deceptive practices.

In the UK, the Digital Markets, Competition and Consumers Act 2024 includes a new regime for consumer subscription contracts, with requirements for pre-contract information, reminder notices before renewals and the end of free or discounted trials, cooling-off rights and straightforward cancellation. The government has indicated that these provisions will be phased in after the Act's other parts, so confirm the current commencement date. The EU has its own consumer rules, and several member states require online cancellation options.

For billing design, this usually means configurable renewal reminders, clear records of what customers agreed to and when, a simple online cancellation path and the ability to adapt flows by country. Retention offers at cancellation are generally allowed but must not obstruct customers who want to leave. Take legal advice for your specific markets.

Data protection

Billing records contain personal data, so data protection laws such as the UK GDPR and EU GDPR apply. Tax and accounting rules often require invoices to be kept for several years, which can override a customer's request for deletion of that data. Design for this tension from the start: retain what the law requires, minimise what you keep beyond that and be able to explain your retention periods.

Engineering details that cause the most trouble

If you do build, or build significant parts around a platform, a handful of technical decisions decide whether the system stays trustworthy. Most billing bugs are not dramatic. They are small discrepancies that accumulate until finance can no longer reconcile the numbers.

Money and rounding

Never store money as floating-point numbers, which cannot represent many decimal values exactly. Use integers in the smallest currency unit, such as cents or pence, or a proper decimal type, and store the currency alongside every amount. Remember that not all currencies have two decimal places: the Japanese yen has none, and some currencies have three. Define rounding rules explicitly, especially for tax and proration, and apply them in one place.

Time, time zones and billing dates

Billing depends heavily on dates, and dates are full of edge cases. A subscription started on 31 January needs a rule for February. Daylight saving changes can shift a billing run by an hour and push a charge into the wrong day. Leap years affect daily proration. Store timestamps in UTC, decide which time zone defines a customer's billing day, and test end-of-month and end-of-year behaviour carefully.

Idempotency

Network calls fail and get retried. Without safeguards, a retried request can charge a customer twice or create a duplicate invoice. Every operation that moves money or creates a financial record should be idempotent, meaning that repeating the same request has the same effect as making it once. Most payment providers support idempotency keys for exactly this reason. Use them, and apply the same principle to your own internal jobs.

An immutable financial record

Financial history should never be silently edited. Once an invoice is issued, corrections should be made through new records such as credit notes or adjustments. Many teams model billing data as an append-only ledger, where every change is a new entry with a reason and a timestamp. This makes audits possible and lets you answer questions like "what did this customer owe on 3 March, and why?"

Webhooks and reconciliation

Payment providers report events, such as successful charges, failures and disputes, through webhooks. These can arrive late, out of order or more than once. Handle them idempotently, verify their signatures and run regular reconciliation jobs that compare your records with the provider's, so that a missed webhook does not leave a customer marked unpaid when they have paid, or the reverse.

Testing over time

Billing bugs often appear only after weeks or months: at the first renewal, at the end of a trial or when an annual plan comes up. Build the ability to simulate the passage of time in testing environments. Some providers offer this directly, such as Stripe's test clocks. Keep a library of real-world scenarios, such as an upgrade during a trial with a coupon and a failed payment, and run them before every release.

Integrating billing with your CRM, ERP and product

A billing system rarely works alone. Its value depends on how well it connects to the systems around it, and integration work is often as large as the billing work itself.

The product: entitlements

Your application needs to know what each customer is allowed to do: which features they can access, how many seats they have and how much usage remains. Hard-coding plan names into product code is a common shortcut that becomes a problem the first time you change pricing. A cleaner approach is an entitlements layer that maps plans and add-ons to features and limits, so pricing changes do not require code changes. Decide which system is the source of truth for access, and how quickly the product should react when billing status changes, for example when a payment fails or a subscription is cancelled.

The CRM: sales-led deals

If you sell through a sales team, deals are often negotiated in a CRM such as HubSpot or Salesforce, with custom prices, discounts, ramped pricing and multi-year terms. Those quotes need to become subscriptions without someone retyping them, which is where errors creep in. Configure-price-quote (CPQ) tools, native integrations offered by billing platforms or a custom sync can bridge the gap. Customer success teams also benefit from seeing billing status, renewal dates and payment problems inside the CRM. (Internal link suggestion: an article on CRM development or CRM and billing integration.)

The ERP or accounting system

Finance needs invoices, payments, refunds and revenue schedules to flow into the general ledger. For smaller companies, that might mean a direct integration with Xero or QuickBooks. Larger companies typically connect billing to an ERP such as NetSuite, Microsoft Dynamics 365 or SAP. Agree the level of detail with finance: some want every invoice line, others want daily summaries by account. Reconciliation between billing, payment provider and ledger should be routine, ideally automated.

The data warehouse

Analysis of revenue, churn and pricing experiments works best when billing data is available alongside product usage and CRM data. Plan to export billing events to your data warehouse in a consistent format from the start.

Build, buy or hybrid: making the decision

By now the shape of the decision should be clearer. There are three realistic options.

Buy a billing platform and configure it. This is the fastest route, often weeks rather than months, and it shifts responsibility for payments, dunning, invoicing logic and much of the compliance burden to a specialist vendor. The costs are platform fees, which typically scale with revenue, some loss of flexibility and dependence on the vendor's roadmap.

Use a merchant of record. Providers such as Paddle act as the legal seller to your customers, handling payments, tax collection and filing and some compliance obligations. This can be especially attractive for smaller SaaS businesses selling internationally to consumers or small businesses. Fees are usually higher than a payment provider alone, and you have less control over checkout and the customer relationship.

Build a hybrid. Many growing SaaS companies use a platform for the core billing engine, payments and invoicing, and build their own layers around it: an entitlements service, usage pipelines, pricing logic for complex contracts, internal admin tools and integrations with CRM and ERP. This keeps the hardest, most regulated parts with a specialist while preserving control where the business differentiates.

Build from scratch only when the reasons in the earlier section genuinely apply, and you can commit a dedicated team to it long term.

Estimating the true cost of building

There is no reliable public benchmark for what a custom billing system costs, because scope varies so widely. What is consistent is where the cost goes. The initial build covers the components described in this guide, and the integrations, testing and migration that come with them. After launch, you carry ongoing maintenance, changes in payment network rules, new payment methods, new tax and consumer regulations, pricing experiments requested by the business, finance and audit support and on-call cover for a system where errors directly affect revenue.

A useful exercise is to compare three-year costs. For a platform, take the fee schedule and apply it to your revenue forecast, then add integration and configuration work. For a build, estimate the team you would need to build and then maintain it, including a share of finance, security and compliance time. Include the cost of delay too: a long billing project can postpone pricing changes that would have increased revenue.

Questions to answer before committing

Write down your current and expected pricing models and test them against at least two platforms. Clarify who your customers are, consumers or businesses, and which countries they are in, because that drives tax and consumer law obligations. Ask finance what they need for revenue recognition, reporting and audit. Map the systems billing must connect to. Decide who will own billing internally after launch. And model how fees and team costs compare at your revenue in three years.

If the answers point towards building, start with a narrow scope, keep payments and tax with specialist providers and design the data model with finance involved from the first day. If they point towards buying, invest in a clean integration and a proper entitlements layer, so that you can change pricing, or even platforms, without rewriting your product.

For SaaS businesses already running CRM or ERP systems, billing is often the point where these systems meet. Getting the architecture right early, whether you build, buy or combine the two, avoids a costly migration later. An experienced SaaS development partner can help you map requirements, compare platforms objectively and build the integration layer around whichever option you choose. (Internal link suggestion: a SaaS development services page or a guide to SaaS architecture.)