Insights · 13 min read
A practical guide to building a billing and invoicing system: the core modules, the data model that keeps the numbers right, tax and payment integration, and realistic costs.
By GGP Editorial
Every business that sends invoices eventually hits the same wall. The spreadsheet works for the first fifty customers, then a late payment goes unnoticed, a discount is applied wrong, and the finance team stops trusting the numbers. A billing and invoicing system is the software that makes sure money owed is tracked and money collected is recorded. It sounds simple. It is not.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects. We build financial systems and payment products for clients in Brazil, South Africa, Singapore and the US. This guide is for the people planning a build: a founder adding billing to a SaaS product, a business automating its invoicing, or an ops team replacing a manual accounts-receivable process.
A billing system has one job: turn the work you did into an amount owed, tell the customer, take the payment, and record that the payment happened. Four stages sit inside that.
Charge generation creates an invoice from a contract, an order, a subscription, or usage data. Delivery sends the invoice and gives the customer a way to pay it. Collection takes the payment and handles partial payments, credits and refunds. Reconciliation matches each payment to the right invoice so the books stay correct.
Most of the failure in these projects is not in any one stage. It is in the hand-offs between them. An invoice that is sent but never reconciled is a number you cannot trust. A payment that lands with no matching invoice is a refund you have to figure out by hand.
The first fork in a build is whether you bill once or repeatedly. The two share an invoice model but diverge quickly.
One-time invoicing is quote, invoice, payment, receipt. Agencies, professional services firms, distributors and manufacturers run on this. The hard parts are line items, discounts, tax, partial payments and credit notes.
Recurring billing is subscriptions, usage-based pricing, or a mix. It adds proration, plan changes mid-cycle, metered usage, and dunning, which is the loop that retries failed payments. A subscription that renews monthly is a billing event every month, and any one of them can fail.
Failed payments are a quiet leak. A large share of subscription churn is payment-related rather than a customer actually deciding to leave, and most of it is recoverable if something retries the charge on a schedule. The catch is that card networks cap how often you can retry a declined charge, so retry logic has to respect those rules instead of hammering the card. We wrote about the wider subscription mechanics in our guide on building a subscription SaaS platform.
Four profiles come up repeatedly.
A SaaS or product founder embeds billing in the product itself, because the product is the invoice. A business with enough invoicing volume that manual AR costs real money, like logistics, wholesale, services or property, automates it. A marketplace or platform bills on behalf of sellers and has to split or remit funds, which forces a different data model. And a finance team replaces a legacy billing tool that no longer handles multi-currency, multi-entity or local tax rules.
If you are in the first group, the billing system is part of what you sell, so off-the-shelf tools will not bend to it. That is the group that should be building. If you are in the second group, you are deciding between build and buy, and I cover that later.
A billing build accumulates scope that buyers never use. The modules that decide whether the system is trustworthy form a smaller, harder set.
| Module | What it does | What to watch |
|---|---|---|
| Invoice engine | Creates and numbers invoices | Sequential, gap-free numbering is a tax requirement in many countries |
| Line items and pricing | Items, quantities, discounts, taxes | Tax-inclusive vs tax-exclusive pricing is a day-one decision |
| Tax engine | Calculates VAT, GST or sales tax | Rules change by jurisdiction; e-invoicing mandates are spreading |
| Payment integration | Takes the money | Idempotency and reconciliation, not just a checkout button |
| AR sub-ledger | Tracks what is owed and paid | Must tie out to the general ledger |
| Dunning | Retries failed recurring payments | Card networks cap retries; the schedule matters |
| Credit notes and refunds | Reverses a billed amount | Never edit a posted invoice; reverse it |
| Reporting | Aging, revenue, collections | Cash collected and revenue recognized are different things |
| Notifications | Invoice sent, due, overdue | The touchpoints that actually get you paid |
This is the part that fails first, for the same reason it fails in a general ledger.
Money is stored as integers in minor units, or as a decimal type end to end, never as floating point. Floating point turns 0.10 plus 0.20 into 0.30000000000000004, and across a few hundred thousand line items the totals stop tying out.
Posted invoices are immutable. When a customer needs a correction, you issue a credit note. You do not edit the invoice. Editing breaks the audit trail and, in countries with sequential invoice numbering, breaks the numbering scheme.
Every payment carries an idempotency key. A webhook that fires twice, or a customer who clicks pay twice, must not result in two charges. The system treats "charge this invoice" as a request that can be safely repeated.
Line items store the tax and discount that applied at the moment of creation. Recomputing tax from current rates on an invoice issued six months ago is a bug, not a feature. You record the rate that was in force then.
Those four rules are the difference between a billing system and a checkout button. We covered the same mindset for the accounting layer in our piece on general ledger software development.
Tax is the part founders underestimate, and the requirements depend on where you sell, not on what you sell.
VAT, GST and sales tax differ by country, by product category, and sometimes by region within a country. The system needs to know where the customer is, what was sold, and which rate applied on the invoice date, and it needs to keep that history rather than recalculate it.
E-invoicing is the fast-moving part. Countries across Europe are rolling out mandatory B2B e-invoicing on staggered timelines. Belgium and Croatia started in January 2026. Poland follows during 2026, Germany in 2027 and 2028, France from late 2026, Spain from late 2027. In several of these, the invoice must be issued in a structured format, often Peppol, and reported to a government platform. What that means for a build is simple: if your customers are in those markets, the system needs a structured-invoice export path from day one, even if you only ship PDFs to start. Confirm the specifics for your own markets before you build, because these timelines move.
Invoice numbering is the quiet constraint. Many tax authorities require invoices to be numbered sequentially with no gaps. That single rule shapes the data model, because you can no longer freely delete an invoice the way you might delete a draft in other software.
Getting paid is the point, and it is where builds quietly go wrong.
Pick one gateway to start, two if you sell cross-border. Stripe, Adyen and similar handle cards well. Bank transfer, Pix, and local wallets matter for specific markets. The cross-border side has its own pitfalls, which we cover in our online payment gateway integration guide.
Reconciliation is the hard part. A gateway sends a webhook saying a payment succeeded, and your system has to match it to the right invoice, mark it paid, and never double-count it. Timeouts, retries, partial refunds and gateway fees all make this messier than it looks. The system records the gateway fee separately from the payment amount, or your revenue reporting is wrong from the first transaction.
Idempotency shows up again here. Gateways retry webhooks. Your handler has to be able to receive the same event twice and produce the same result, which means the payment record needs a unique identifier you can look up before you apply anything.
For a business that just needs to send invoices, buy. FreshBooks, QuickBooks, Xero and similar tools handle one-time invoicing well, and integrating one is far cheaper than a build. We walked through that trade-off in accounting software: build, buy, or extend.
You build when billing is inside the product you sell, when your pricing is custom in a way off-the-shelf tools will not bend to, when tax and multi-currency rules are specific, or when billing data feeds the rest of your product and the tool cannot keep up.
The test I use is simple: is billing the product, or a chore inside it? If it is a chore, buy. If it is the product, build, and treat the payment and tax correctness as the thing you are actually paying for.
As with a ledger, the band is set by how much billing logic you need, not how many screens you have.
| Scope | What it includes | Typical range | Timeline |
|---|---|---|---|
| Invoicing module | Invoice engine, line items, tax, one gateway, basic AR, PDF and email | $30,000 to $70,000 | 2 to 3 months |
| Full billing system | Adds multi-currency, multiple payment methods, credit notes, reporting, integrations | $70,000 to $150,000 | 4 to 6 months |
| Recurring subscription billing | Adds dunning, proration, plan changes, metered usage, multiple gateways | $120,000 to $250,000+ | 5 to 9 months |
These are ranges, not quotes. The number that matters is the one in a scoped proposal, and two honest vendors can be far apart on the same scope for reasons that have nothing to do with incompetence. I explain how to read those numbers in why custom software quotes vary.
The pattern to notice is that the interface is the cheap part. A basic invoice has a simple data model and a few screens. The cost climbs with the payment and tax logic, the reconciliation, and the edge cases like partial payments, refunds, proration and failed renewals.
The number of payment methods and gateways. Each one is an integration plus reconciliation logic, and each one is a place the schedule slips.
Recurring billing. Proration, dunning, plan changes and metered usage are each their own work stream, not one feature.
Tax complexity. Multiple jurisdictions, tax-inclusive pricing and e-invoicing reporting all add scope on top of the core invoice engine.
Multi-currency and multi-entity. Billing in one currency is straightforward. Billing in ten with intercompany rules is not, and we covered the currency side in our guide on building a multi-currency accounting platform.
Integrations with the rest of the business. ERP, CRM, accounting, shipping and a ledger. Each mapping is a place where the estimate quietly grows.
Data migration. Moving off an old billing tool means mapping years of invoices and open balances, and it always takes longer than the estimate. Price it as its own line.
Reporting and revenue recognition. Cash collected and revenue recognized are different things. Deferred revenue and recognition schedules add real scope once a finance team starts asking for them.
Start with one-time invoicing or a single subscription plan, not both. Get the invoice model, the tax engine and one payment method working end to end before you add anything else.
Fix the data model early. Integers for money, immutable posted invoices, idempotent payments, tax stored at invoice time. These are cheap on day one and expensive to retrofit, because the data already stored lacks the fields the features depend on.
Cap the gateways at one or two. Add methods later, once reconciliation works.
Ship the overdue and dunning path early. It is the fastest way to expose the data-model problems, and it is what actually gets you paid.
If you are still deciding how much to build before launch, our guide on defining an MVP before hiring developers applies to billing as much as to any other product.
An invoicing module runs $30,000 to $70,000. A full billing system with multi-currency and multiple payment methods runs $70,000 to $150,000. Recurring subscription billing runs $120,000 to $250,000 or more. These are ranges, not quotes.
Buy if billing is a chore inside your business. Build if billing is part of the product you sell, or if your pricing, tax or multi-currency needs are specific enough that no off-the-shelf tool fits.
Invoicing is one-off: create, send, collect. Recurring billing adds scheduled charges, proration, plan changes, dunning for failed payments and metered usage.
If you sell B2B in Europe, increasingly yes. Several countries now require structured electronic invoices, with timelines that vary by country and by turnover. Confirm the requirements for your own markets before you build.
Two to three months for a basic invoicing module, four to six months for a full billing system, and five to nine months for subscription billing. Payment, tax and reconciliation logic stretch the calendar more than the interface does.
They are adjacent but separate. The billing system tracks what is owed and paid. The general ledger records it. The two must reconcile, and we covered the accounting side in our general ledger software development guide.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa and Singapore. We build custom software, SaaS platforms, FinTech systems, ERP and CRM, mobile apps and AI products on a stack that includes Java, Spring Boot, Spring Cloud, Go, Python, React, Vue, Node, MySQL and Redis. We run overlapping hours with our clients, keep a dedicated group per project, and communicate in English and Portuguese.
A billing system is one of those builds where the first 90 percent is straightforward and the last 10 percent is careful payment and tax work. If you are planning one, talk to us about your project. Tell us what you bill, how often, in what currencies and where your customers are, and we will help you work through build-versus-buy, the data model and a realistic scope before you write a line of code.
Tell us what you are building and where you are today. We typically reply within 24 hours.
