Why carriers regret writing their own billing

You already have Asterisk. You have a few scripts that rate CDRs overnight. Prepaid works for the customers you have today. A commercial softswitch looks expensive next to “we already built it.”

That is how many small carriers start. The regret arrives later: not on the first invoice, but when the person who wrote the scripts leaves, when a rate deck changes twice a week, when least-cost routing fails over in a way nobody wrote down, or when the tenth edge case lands in production on a Friday night.

This piece is for founders running a growing operator on homegrown Asterisk and scripts. Building is sometimes right. The question is whether you are building a temporary tool or a second company you never meant to start.

Why building looks cheaper at first

Homegrown billing wins the whiteboard math.

• Asterisk (or FreeSWITCH) already handles the calls.
• A CSV import and a cron job appear to cover rating.
• No monthly licence shows on the P&L.
• You can ship the one prepaid rule your first big customer asked for this weekend.

Open-source charging engines sit in the same story. CGRateS is powerful and engine-agnostic, but it is a charging engine you wire yourself, not a finished admin panel with invoices and day-to-day ops. That gap shows once finance, not only engineering, lives inside the system.

Buying looks like cost. Building looks like control. For the first year of a thin operation, that framing is often true.

Ten regrets of owning the billing stack

These are not three war stories. They stack. Most DIY shops hit several before they admit the whiteboard math was wrong.

1. You never finish the software

Release is not the end of the cost. Libraries go out of date. Security holes appear in code that worked last year. PHP, MySQL, and the OS under Asterisk move on whether you touch the rating script or not. Teams that skip that work watch a system that “works” get harder to change until a small fix becomes a rewrite.

Industry guidance often budgets on the order of 15–25% of the original build cost every year just to keep custom software alive. That line rarely sits on the whiteboard next to “we already built it.”

2. Everything rests on one developer

The founder who can read dialplan and SQL becomes the only person who can change a balance rule, fix a hung import, or explain why last month’s invoice is wrong.

That is fine at five customers. It is a business risk at fifty. Miss that engineer for two weeks and nobody else can change a balance rule. Research on turnover technical debt names the same failure: the component that only one person understood becomes expensive the day they leave. A commercial softswitch does not remove the need for a technical founder. It stops the billing engine from being one person’s private codebase.

3. Edge cases you never designed for keep appearing

This is the regret operators underestimate most. The first version rates answered calls by prefix. Then production teaches you the rest:

• Late CDRs after the invoice closed.
• Duplicate rows from a retried export.
• A rate that must be the version valid at call start, not at import time.
• Ported numbers that wrong-rate if you only trust the dialled digits.
• Increments, grace seconds, and origin-based prices that disagree with a partner’s file.

Routing adds its own pile. One example from how MOR orders providers and fails over: dial 921…, Provider A offers prefix 92 at 0.1, Provider B offers 92 at 0.05 and 921 at 0.2. Longest matching prefix decides which rate applies; LCR order can put A ahead of B on the shorter match. Failover: if the first leg is answered, busy, or no-answer, the call ends. The next provider is used only on congestion.

None of that is exotic once you have lived it. Each one was invisible on day one. On a DIY stack every new edge case is a custom patch. On a product platform it is someone else’s already-shipped rule. When cheapest is not good enough, quality-based routing is another layer; see Quality based routing.

4. Your best people work on plumbing, not the product

Every week spent debugging a rating bug or a broken import is a week not spent on routes, partners, or the service customers pay for. Build-from-scratch advocates outside telecom say the same thing: the initial build is the small cost; the long tail of maintenance is where engineers stop shipping the product. For a carrier, billing is plumbing. Selling minutes and quality is the product.

5. Security patches never pause

Homegrown PHP and AGI stacks sit on the public internet next to SIP. A dependency you pinned two years ago can grow a known hole. Vendor software ships security updates as part of the product. DIY means you are the security team for the system that holds balances and card or payment integrations. Skipping patches is not thrift. It is deferred incident cost.

6. Switches, providers, and formats change under you

Provider rate decks arrive in a new spreadsheet layout. A switch upgrade changes CDR columns. A partner adds a timezone offset. Neon’s build-vs-buy write-up lists the same pain: rate cards weekly, tax rules by jurisdiction, switch CDR formats that move. Each change is a support ticket against software only your team understands. Automatic tariff import on a softswitch exists because that work never ends (process overview).

7. Money errors stay silent until the dispute

An incorrect discount, increment, or tax line early in the rating chain multiplies across every call. Duplicate or dropped CDRs under-bill or double-bill. You often learn from a partner PDF, not from your own dashboard. If you already fight invoice totals against CDRs, you know reconciliation is half of billing; see Your partner’s invoice and your CDRs disagree. DIY shops rarely build dual-run and exception queues before go-live. They build them after the first expensive month.

8. Technical debt turns every change into a risk

The “ship it this weekend” paths that got you live become the paths nobody dares touch. Documentation describes the ideal system; production runs the hacks. Adding one prepaid rule then means negotiating with every workaround already on the bus. Delayed maintenance gets more expensive the longer you wait; the eventual “rewrite” is often years of skipped upkeep paid at once.

9. Overnight scripts break when traffic and prepaid go live

Batch rating after midnight is not live balance control. Wholesale volume, concurrent prepaid cut-off, and fraud spikes need real-time debit and limits. Operators who treat charging as a nightly job then fail under load or leak margin. Scale is not only more servers. It is a different design.

10. The business moves; the homemade system becomes a brake

You add a reseller layer, a new country, a Teams trunk, or a dialer farm. The scripts that fit last year’s product become the reason you say no to next year’s deal. Software that cannot change with the business stops being an asset. It becomes the constraint. Buying a maintained core does not remove every custom need; it keeps the core changeable while you spend custom effort only on the thin slice that is truly yours.

When building is still right

Buy is not always the answer.

Build (or keep building) when:

• Your rating is the product: a wholesale or MVNO mix no platform prices the way you sell.
• You already have a solid core and only need a small rating service that posts totals into it.
• Per-subscriber or percentage-of-revenue licences would eat the margin on low-ARPU prepaid lines, and you have measured that on your own numbers.

Then treat billing as two jobs. Buy or adopt a maintained core for invoices, balances, and everyday ops where you can. Build only the thin slice no vendor will model. Rebuilding prepaid, porting, taxes, LCR, invoicing, and the admin UI from scratch is a different project from extending one honest gap.

If you are still on A2Billing and the question is open-source succession rather than greenfield DIY, start from A2Billing still runs in 2026 instead of this article.

What to check before you buy

Use this list in demos. Ask the vendor to show each item with your traffic shape, not a slide.

Kolmisoft’s softswitches put rating, routing, and VoIP billing in one platform. Automatic tariff import is the path for provider rate files that arrive by email in messy spreadsheet shapes. Invoices are a first-class output, not a weekend PHP job.

Say in the demo what is addon territory (for example local number portability) and what is core. A gap you discover after go-live costs more than a gap you plan for.

How to buy without losing flexibility

The fear behind DIY is not only price. It is “we will need a weird rule next year and the vendor will say no.”

That fear is rational. Rigid platforms strand operators who need SIP auth quirks, unusual reseller flows, or a report that matches a local interconnect. The buy that works for a technical founder is a maintained core for LCR, rating, invoices, and routing, plus a vendor who still develops to client request instead of closing the ticket with “not on the roadmap.”

Kolmisoft’s pitch to small and mid-sized operators is that combination: softswitch with billing built in, and custom work when the standard screen is not enough. You do not need to become a software company to keep the one feature that wins a partner. You do need a partner who will build that feature.

If you are choosing between another year of scripts and a supported platform, bring the LCR failover question and one real rate file to the walkthrough. Those two tests separate a billing UI from a system you can run money through.

FAQ

Is build vs buy telecom billing always “buy”?

No. Build the thin rating gap no vendor models. Buy the core that must stay correct every week: balances, invoices, imports, and LCR rules you can explain to a partner.

What VoIP billing software fits a small carrier on Asterisk?

If you keep the PBX and move money off scripts or aging AGI billers, a Class 5 softswitch with billing behind the PBX is the usual path. If your pain is wholesale transit at volume, look at Class 4 first. Match the product to the job, not to the brand slide.

How long does a DIY billing engine really take?

Vendor write-ups often cite a year or more to production-grade CDR rating and partner reconciliation. Operator stories put multi-year effort on routing and LCR alone. Your timeline depends on markets, taxes, and how many providers send decks. Plan for maintenance forever, not only the first release, and for the edge cases that only appear after real traffic.

Next step

Download The Hard Truth About Running a VoIP Business if you want the operator-side framing before a product call. If you already know the scripts are the bottleneck, ask for a walkthrough and bring one rate file plus the LCR failover behaviour you expect.