Billing Systems for ISPs: What They Are Made Of and Do

A subscriber sees one line of billing: "this much will be charged on this date". Inside, it is the carrier's most critical system: it lets people on the network, measures consumption, counts money and answers to accounting for every cent. A carrier survives a site outage, but a billing failure means thousands of subscribers either sit offline or use the network for free. Let's see what this system, known in the industry as an automated billing system, consists of.

A subscriber's path through billing

When a subscriber's router brings up a connection, the carrier's equipment asks billing whether to let it in and at what speed. The classic language of this dialogue is RADIUS, and the answer depends on the balance and the plan. The network then sends counters: how many bytes passed, how long the session lasted. Billing turns them into charges and closes the period on the charge date. A payment from the dashboard goes the other way: money credited, block lifted, speed restored, all with no human involved.

Modules of a modern billing system

Related blocks usually surround the core: technical records of cables and ports, charge notifications, coverage map integration. The larger the carrier, the more its billing resembles a kit where each module can be replaced.

Boxed, SaaS or in-house

Small networks start with boxed systems: install on your server, set up plans, go. The upside is control and a one-off price, and the downside is that updates and backups are on you. Cloud systems take over operations for a per-account fee, which for a network of a few thousand subscribers often costs less than an administrator's salary. In-house development suits carriers with a non-standard model: virtual operators, ISPs with daily rating, services where billing is the product. It is the most expensive path, with no limits from someone else's architecture.

What to look at when choosing

• Support for your equipment. Authorization and counter collection must work with your specific switch and BRAS models, and "in general" will not do.
• Blocking speed. How long it takes between a zero balance and an actual cutoff: hours of delay are gifted traffic.
• Recalculations. Backdated plan changes, refunds, promised payments: boxed systems break most often on these scenarios.
• An open API. The dashboard, site and mobile app will live longer if you can build them on an API instead of inside someone else's template.
• Load headroom. A system that feels lively with a thousand subscribers may stall at fifty thousand on a mass charge day.

Migration is a separate expense. Moving off an old system drags along balance history, open periods and promised payments. A good contractor starts by taking stock of exactly these loose ends, and a bad one starts by demoing a pretty dashboard. Plan for the two systems to run in parallel for at least one billing period: reconciling charges on live subscribers finds what no test will show.

Typical rollout mistakes

• Billing after the network. The network gets built first and billing is bolted on later. It should be the other way round: the authorization and accounting design dictates the choice of equipment.
• Plans "like the neighbors have". The system handles flexible plans, but three lines go in. Then every promotion becomes manual recalculation.
• One server for everything. A database, RADIUS and dashboard on one machine work until the first mass charge day. Move at least the database out ahead of time.
• No test environment. Updates roll straight into production, and the first rating error costs more than a test bench over its whole life.
• Backups with no restore test. Backups get made for years, and the first restore attempt happens during an outage. Run a restore drill every quarter.

The common denominator of these mistakes is treating billing as a program when it is a process. Subscribers' money flows through it nonstop, so treat it like a cash register and not like a website.

When choosing a system for a growing network, look past the feature list to two questions: how it survives charge day and how easily you can get your data out when you move. Everything else can be added, while these two properties come from the architecture. We wrote separately about the surrounding infrastructure: our overview of server types on a network helps you see where billing fits in this picture.