Building a billing engine in-house: A User’s Guide

Imagine diving into building an in-house billing system for your SaaS startup. It seems like a reasonable decision at first—after all, how hard can it be to tailor a billing solution to your specific needs? What starts as a seemingly straightforward project can quickly evolve into a labyrinth of technical and operational hurdles, consuming valuable resources and diverting focus from your core product.

Building a robust billing system for a fast-growing B2B company is complex, time consuming and requires several iterations to get right. In this user’s guide we’re sharing what you need to keep in mind should you decide to build an in-house billing system.

Dealing with dates and timezones

Dates and timestamps are crucial in a billing system. You have to deal with billing and service periods, and identify when billable events took place. Unless all of your team and customers live in a single territory with no daylight saving, your system needs to have an intimate understanding of timestamps, time zones and date periods.

For example, you could be US East Coast based, with clients in Europe and operators in California. What timezone do you use to display and for processing? There are visible implications to that decision, especially if you invoice clients based on their usage during a time window. There’s a good chance you will need to keep track of the timezones of each user of your system, so that anyone from your company can see the same view regardless of where they are, and you might even end up maintaining an operational timezone for each client, so you can meter and charge for their usage based on when their day ends, not where your servers are located.

Another source of headaches is day counting. Napoleon didn’t get his way by reforming calendars, and now we have a variable number of days each month. Some have 30 days, some 31, and February can be 28 or 29. This manifests in many weird and wonderful ways, including but not limited to:

• Proration (and it gets extra spicy if prorating across multiple months)
• Selection of invoice-generation date of month
• Revenue recognition

There is a reason day-count conventions exist, but there’s a catch: there’s multiple of them, and different countries have different preferences. 

Custom pricing and evolving pricing models 

B2B sales involves price negotiations and incentives. Contracts tend to be bespoke and specific to each customer. Growth teams expect to have the freedom to structure deals and employ commercial levers to win deals (beyond just free trial periods). 

These commercial levers need to be modelled into the billing system, otherwise operators would need to manually amend bills to match them. For instance, the sales team may apply a 3 month price ramp to a contract, or waive an implementation fee. Your system will need to natively model pricing ramps, including the price step up and the date on which it applies, in order to accurately produce invoices. This will include having to deal with prorated values if those dates do not align with the overall billing period.

You may initially decide not to model waived fees or discounts, given they might not contribute to an invoice. But sales teams want to ensure their customers are reminded of concessions they’ve received – you also need to account for discounts when recognising revenue. During implementation, you will need to figure out your stance on a number of issues (or risk them being undefined), including but not limited to:

• If a discount expires mid way through a billing period, should it apply in full, apply as a prorated value, or apply in full to the date period in which it is applicable
• What does it mean to have a one-month discount over a one-off implementation fee, do you discount the entire fee, or divide it by month and only discount the first

You may also have to support a variety of billing cadence combinations. Imagine a scenario where you charge customers upfront for access to a service, and in-arrears for using that service. This is quite common in order to guarantee minimum income, while fairly charging customers based on their needs. This requires several layers of modelling in your system:

• In-advance vs. in-arrears: you will need to build scheduling logic that understands for the same billing period, you may create an invoice either at the beginning or after the end of said period
• Billing Frequency: you will need to alter how often you schedule invoices to be created. While you might be able to get away with only monthly billing to begin with, you’ll soon need to support quarterly and annual billing. You may also need to consider how multiple frequencies should work in tandem, such as a monthly rolling charge alongside a quarterly upfront fee. 

Now imagine combining these dimensions. You have a contract with some products being billed in advance, with others being billed in arrears, and each product is billing at a different frequency. More painful still, imagine these contracts starting on a random day of the month, say the 17th of September. 

Lastly it’s important you maintain a source of truth for products and prices. Sales might want to live in Salesforce, but multiple stakeholders in the company must have visibility to products and their prices. Your product, finance and executive team are interested in those. So in addition to building billing, you will likely want to create a Product Catalogue that gives all operators a view of products and prices sold in the business with the ability to organise, delete or archive prices no longer in use. 

Usage based pricing

Your pricing may include a usage based component. Operationalising usage-based billing is hard: it requires data to flow from the product stack into the billing and financial systems, describing accurately who is using what, how and where. That data has to be aggregated and transformed according to each customer’s agreed pricing terms, to produce a bill for each customer. The bill, and the details of the calculation behind it, has to be conveyed transparently to both financial operators and customers, and be synced with other systems of record such as your CRM and ERP. 

Your usage infrastructure will also need to accurately model the metric your business is using to charge customers. If your company is working with enterprise customers, the specific usage aggregation may vary across customers and your system may need to handle new aggregation methods.

The product usage pipeline cuts across multiple functions and technologies – from the product backend, through to data infrastructure, sales records, invoicing and accounting systems, which makes it inherently hard to build and maintain. All of a sudden, making changes to the pricing model requires multiple engineering cycles, seemingly innocuous code refactors are breaking billing, and signing a large customer is delaying entire billing cycles.

The complexity of setting up these systems for the first time is a hard barrier for many companies. But the hidden dependencies are what tend to turn usage-based pricing into a growing resource drain that eventually demands a dedicated engineering team.

Calculating tax and managing parent-child relationships 

Tax rates vary by location and product type. The UK and EU have a manageable number of tax rates. In the United States, there are a broad number of variables to consider that determine tax rates, such as economic nexus, city and state.To manage sales tax calculation and filing, you’ll likely want to integrate with a tax automation software like Anrok or Avalara to ensure your billing calculations are correct in each geography. If you choose to build your own tax system, you will need to account for regular changes in tax rates, especially in the US.

In B2B, it’s common for your customer base to include businesses with multiple entities and subsidiaries. You will need to account for these ‘parent-child’ relationships in your billing system so that you can reflect the complex legal structures that need to be represented in billing. Perhaps your clients sell via third parties, want to roll up invoicing or get detailed invoicing per child entity. This is another factor to consider when building your billing system.

Making changes to customer billing: upgrades and downgrades 

Teams will inevitably experiment with different pricing models, make mistakes that need correction, or want to schedule future dated pricing changes. Consider the scenario where an operator realises that pricing was incorrect when the first invoice is produced, or a scenario where a sales rep upsells a customer a few months into their contract.

You will need to model these changes into the billing schedule. Imagine you are modelling a contract with a simple fixed price that gradually increases in 3 month increments from £100 (months 1 to 3) to £350 (months 4 to 6) up to £500 (month 6 onwards). If a price in the first phase was configured incorrectly, you may have to recalculate the correct amounts, including price increases for all future phases.

Your company may want to roll out a scheduled price increase from the 1st of the new year. This gets tricky when another change (e.g. an upsell) needs to happen beforehand, since you can’t constantly delete and recreate contracts. To deal with this complexity, you may need a form of bi-temporal price modelling and storage to produce accurate invoices and explain how invoices were created. This is a particularly difficult problem when your change is not a point in time, but rather a date period at a time. 

Your system will also need to handle regular upgrades and downgrades, pricing changes for specific contracts or across entire customer segments, etc. This requires the concept of versioned prices, grandfathering and so on.

While many of these seem like edge cases, or rare operational mistakes, the truth is they happen frequently. When they do, offloading them to an operations team drives up your ongoing operational costs, increases your risk of calculation error, and degrades your overall billing data quality.

CRM and ERP integrations

A billing and revenue system is core business infrastructure, containing essential data that needs to be synced across your sales to finance stack. 

Let’s start with Accounting & ERP systems. You will need to keep customer details and invoice activity in sync between your billing tool and accounting software, as your billing engine needs to know which customers need to be invoiced, and the accounting system needs to maintain a log of customers, issued invoices and payment history. Billing produces invoices, while accounting needs to keep a record of them. That also helps auto-generate journal entries and populate the books. You may also choose to run invoicing from your ERP.  You will need to handle scenarios where there is conflict between the billing system and ERP, and how to successfully merge customers from both.

Accounting & ERP suites often struggle to automatically recognise revenue correctly, since they lack the context on pricing to produce correct journal entries. If your business has annual upfront commitments with usage based pricing, your finance team may spend a few days to make manual journal adjustments each cycle. On their own, Accounting & ERP suites don’t know whether the invoiced amount is for services delivered (and therefore counted as earned), or for future services, and therefore counted as deferred revenue – context owned by your billing system.

Integrating billing, usage and revenue data with the CRM powers revenue teams with the data to upsell, optimise renewals and track their customer activity. You will likely want to push all of this data (in as close to real time) back to your Salesforce or Hubspot, ensuring you’re syncing with the right fields. These integrations can also be tricky to maintain. 

There is a whole range of other integrations and connections to consider, such as payment gateways, product entitlements, sales commissioning, etc. 

Building a reliable billing engine requires multiple iterations

Building a good billing system requires several product iterations, but they are not frequent and don’t come cheap. Billing is mostly an end-of-month or start-of-month activity, which means that many of the system’s features are only exercised a handful of times a year. That makes it difficult to test all logical paths and find issues that you can subsequently fix. Billing and invoicing are business critical processes related to money movement and so the tolerance for issues or incorrect calculations is low.

Consider alternative options

The allure of building an in-house billing system—complete control, customization, and the promise of perfect alignment with your business model—carries with it a hidden cost. While the intent to tailor a billing system to your company’s unique needs is understandable, the reality is that building it in-house is a complex task that can distract from your main value proposition. Before you venture down this path, consider whether the investment truly aligns with your strategic objectives or whether it’s a distraction. 

"Building a billing engine in house is undifferentiated heavy lifting and should be avoided at all costs. A long time ago we had to build one. It never worked well, cost us millions of dollars, was a thorn in our side for years, and really degraded our ability to evolve our pricing + packaging. I very much regret not moving off it sooner.” Ciaran Lee, CTO at Intercom