White-label hosted PBX: one invoice for many resellers

You sell hosted PBX or UCaaS through partners. Each partner wants their logo, their rates, and their own customers. If every customer sits on a separate PBX box, month-end billing turns into CDR exports and spreadsheets. The cost that hurts is not another server. It is the hours your team spends building invoices by hand, and the credit risk you cannot see until a reseller’s balance hits zero.

This article is for the owner or CTO of a hosted PBX provider who already sells through resellers, often in markets like the UK, US, or Ireland. You get a checklist for a multi-tenant VoIP billing platform: one system, many resellers, one invoice run.

The cost of many separate PBXs

A single-tenant PBX works for one organisation. To host many business customers, some providers stand up one install per customer, or per reseller. That model scales in a straight line: more customers means more boxes to patch, more dashboards to watch, and no shared billing view.

PortaOne’s Cloud PBX product page names the same pattern: every enterprise customer becomes another box, and resellers add another set of prices and settlements to keep straight. ICTPBX’s 2026 comparison of open-source single-org PBX GUIs says the same: many instances, more servers to patch, and no shared billing view. Both pages describe why providers look for multi-tenant platforms.

The money problem shows up later. Call records live in different systems. You export CDRs, map columns, apply each reseller’s rates, and build invoices in a spreadsheet or a second accounting tool. One missed export becomes a wrong invoice. One wrong rate becomes a margin fight. Partner invoice disputes already eat finance time when two CDRs disagree; multiplying PBX islands multiplies that work.

What multi-tenant actually requires

Multi-tenant is not “many extensions on one Asterisk.” For a reseller channel it needs commercial layers, not only dialplan isolation.

Reseller layers. You (the operator) sell to a reseller. The reseller sells to end users. Some platforms add a Partner layer above resellers so larger partners manage their own sub-resellers. Each layer needs its own tariffs, credit rules, and reporting.

Branding. Resellers expect their logo, their domain or homepage, and invoices under their details. White-labeling at the operator GUI (logo, domain, header, footer, favicon) is separate from letting each reseller brand the portal their users see.

Separate rates and balances. The reseller’s buy rate from you is not the user’s retail rate. Balances move on both sides when a call completes. Inbound DID through a reseller channel needs the same two-tier idea: wholesale to you, retail to them.

Feature control per group. Not every reseller should get calling cards, SMS, autodialer, payment gateways, or full PBX functions. Groups that turn those modules on or off stop you from giving every partner the whole catalogue.

Tenant spaces for PBX. When several companies share one Class 5 system, extension namespaces and PBX pools keep one customer’s dialplan from colliding with another’s.

If the platform cannot do those jobs in one place, you are still stitching exports. Class 5 softswitches with reseller billing are built for that retail channel; Class 4 wholesale switches are a different job.

How billing should flow: call to reseller to invoice

A clean path looks like this:

1. The end user’s device places or receives a call on the shared platform.
2. The switch rates the call against the user’s tariff and the reseller’s tariff in the same CDR.
3. The user’s balance (or postpaid credit) moves. The reseller’s balance moves for their share.
4. At period end, invoices generate from those rated CDRs: user invoices under the reseller’s brand where that is configured, and your wholesale settlement with the reseller from the same call history.

Concrete numbers help. Suppose you pay a provider 0.30 per minute. The reseller pays you 1.20. The reseller’s client pays 2.00. Your margin is 0.90. The reseller’s margin is 0.80. That split only holds if both rates live in the rating engine, not in a spreadsheet after the fact.

Outbound is the usual path. Inbound DID through resellers used to leak margin when only the end user was billed and the reseller was not. Two-tier DID billing for MOR resellers writes Owner Rate for the user and Reseller Rate for you on the same answered receive call.

When a supplier’s invoice PDF and your CDRs still disagree, settle from paired call rows, not from a destination total. That is a separate fight from reseller retail invoices. The rated CDR is still the source of truth.

When the PBX was built for one organisation

Open-source PBX GUIs that manage one organisation per install are strong for a single office. They are a weak foundation for a reseller-channel hosted PBX business. ICTPBX’s comparison states it plainly: FreePBX has no built-in way to package and bill service; you add a separate billing system, or you buy a commercial multi-tenant product, or you run many instances.

You can still trunk a third-party PBX into a Class 5 softswitch and keep phones where staff already know them. That pattern (PBX for features, softswitch for money) is a migration path when billing is the pain. It is not the same as running one multi-tenant platform with reseller layers, white-label portals, and one invoice run. If your plan is one FreePBX per customer forever, stop and count the invoice hours before you add the next ten customers.

Reseller credit risk: one empty balance blocks a tree

In a proper reseller model, the reseller’s prepaid balance (or postpaid credit limit) sits above their users. When that reseller is out of money, or has hit the credit limit, their users cannot place calls even if those users still show credit on their own accounts.

That design protects your float. Without it, you fund the reseller’s customers while the reseller owes you. With it, one empty reseller wallet becomes a support queue: every user under that partner fails at once. Set credit limits you can live with. Watch low-balance warnings for resellers the same way you watch end users. Decide in advance whether a reseller may sell below their buy rate; loss calls at the reseller or partner layer are a commercial choice, not an accident.

If you run a Partner → Reseller → User hierarchy, the same idea stacks: each layer can block the tree below it. Caps on devices per reseller help stop a partner from provisioning beyond what you agreed.

Checklist: choosing a white-label hosted PBX billing platform

Use this when you shortlist vendors or decide whether to keep stitching PBXs together.

If most answers are “export and fix it later,” you do not have a reseller platform yet. You have a stack of PBXs and a finance problem.

How MOR covers this checklist

Kolmisoft’s MOR is a Class 5 softswitch with billing and routing in the same product. The Reseller Addon lets a reseller create tariffs and users, view their traffic, add a logo, customise invoices, and track profit. White-labeling covers domain, header, footer, logo, and favicon on the GUI you run. The Multi-Level Resellers Addon adds Partner users who create and manage their own resellers, with billing User → Reseller → Partner → Admin.

Reseller groups can enable or disable calling cards, call shop, SMS, autodialer, payment gateways, and PBX functions per group. Multi-tenant PBX on MOR (PBX Functions) includes PBX Pools, IVR, queues, voicemail, and related features, with reseller permissions for the advanced set. DID billing for MOR resellers writes Owner Rate and Reseller Rate on the same inbound receive.

MOR is the retail and reseller product. High-volume carrier interconnect belongs on M4. If you need both businesses, you run both products; you do not upgrade MOR into M4.

FAQ

What is multi-tenant VoIP billing?

One platform rates and invoices many customers (and often many resellers) from shared call detail records, with separate tariffs and balances, instead of exporting CDRs from separate PBXs.

Can I keep a third-party PBX and only move billing?

Yes, for some migrations: register or trunk the PBX into the softswitch and bill by CallerID or trunk. That solves money and routing. It does not by itself give every reseller a branded multi-tenant portal on the old PBX GUI.

Why do all of a reseller’s users fail when the reseller has no credit?

The reseller’s balance sits above their users. When the reseller is prepaid and empty, or postpaid at the credit limit, the platform blocks that tree so you are not carrying their customers’ spend.

Is white-label the same as multi-tenant?

No. White-label is branding. Multi-tenant is isolation plus commercial layers. You usually need both for a reseller-channel hosted PBX.

Pilot the invoice run, not another spreadsheet

Open the MOR online demo to click through reseller and billing screens (web interface only; no live calls). If you want a live month with trunks, rates, and training, start the Pilot Project. Bring one reseller’s tariff and a sample of how you invoice them today. The test that matters is whether the next invoice run comes from the switch, not from a CDR export.