Billing software development

Every pricing decision your business makes eventually becomes a billing rule: the legacy plan a long-standing customer keeps, the discount sales agreed to close a deal, the usage tier that resets monthly, the currency a market is priced in. Each one is reasonable on its own. Together they are the most volatile logic in the company, and they usually end up buried in the least accessible part of the codebase.

That is the actual problem with billing. Not that it is technically hard, but that commercial policy changes far faster than software releases, and a billing system that requires a deployment to change a price has put engineering in the middle of every commercial conversation.

So we build billing so that policy is configuration with an audit trail, and only the mechanics are code. The test is simple: can the person who owns pricing see what a customer is on, change it, and know what the change will do before it takes effect?

Billing failures are quiet. Nobody pages you because a customer was under-charged, so the damage accumulates until a finance review finds it. The patterns are consistent:

• Pricing logic in the application. The moment a discount is an if-statement, changing commercial policy needs a release, and the release needs an engineer who understands a deal signed two years ago.
• Proration invented per feature. Upgrades, downgrades and pauses each get their own arithmetic, they disagree, and the disagreement shows up as a credit note.
• Usage counted twice, or not at all. Metering without deduplication and idempotency bills the customer for a retry, which is the fastest way to lose their trust in every other number you show them.
• The billing run as an ordinary job. A half-finished run that is not safe to restart either double-charges or silently skips, and both are found by customers.
• No history. Without an effective-dated model you cannot answer what a customer was on last March, which is exactly the question a dispute or an audit asks.

The three get conflated constantly, and the conflation is expensive. Billing decides what a customer owes. Invoicing turns that into a legal document and delivers it. Payments collect the money.

They change for different reasons and fail differently: billing changes when commercial policy changes, invoicing changes when a tax authority changes, payments change when a provider or a scheme changes. Building them as one module means all three forces land in the same code, and every change becomes a risk to the other two.

We build them as separate systems with clear contracts between them. That is what lets you reprice without touching the invoice format, and change acquirer without touching either.

Metered pricing looks like a billing feature and behaves like a data pipeline. The events arrive out of order, duplicated by retries, occasionally late by hours, and sometimes wrong. Bill them naively and the invoice is a guess.

The parts that matter are unglamorous: idempotent ingestion, deduplication with a defined window, a late-arrival policy that is decided rather than discovered, and a rating step that can be re-run over a period and produce the same answer.

The prize is worth it, because usage pricing only works commercially if customers trust it. That trust comes from being able to show them exactly which events produced which line, which is a requirement we design in rather than add later.

The drivers are the shape of your commercial model rather than the number of screens: how many plans and exceptions really exist, whether pricing is seat-based, usage-based or both, whether proration and mid-cycle change are in scope, whether dunning is included, and which finance system has to receive the output.

The honest one is the second question we ask: how many of your current arrangements are undocumented. In most billing engagements the discovery of what the business actually charges takes longer than building the system that charges it, and we would rather find that out with you in week one.

As reference points from our own work on financial platforms, a banking platform we built saw 150x online-lending growth in a year, and a credit platform for $lana (Monetech) reached 1M+ users with full reporting - both are products where what the customer owes had to be right at volume.