By Sharon R. Watkins, Founder and CEO of RadiusPoint. Sharon founded the company in 1992 after a career in bank internal audit, and has spent more than three decades building the ExpenseLogic platform and reconciling carrier invoices against the accounts that generate them.
A billing account number, or BAN, is not a reference code you type into a carrier portal. It is the account identity a carrier bills under, and in telecom expense management the BAN is the one key that has to reconcile to three separate records at once: the invoice header, the customer service record from the carrier, and the inventory of services you actually run. When the BAN agrees across all three, your payables are auditable. When it does not, you get ghost payables, which is real money leaving the building against accounts nobody can tie back to a service.
Most finance and telecom teams never look at the BAN directly. They approve an invoice total, code it to a cost center, and pay it. The BAN sits quietly on the invoice header doing the one job nobody audits: deciding which account, and therefore which inventory, a charge belongs to. That works until a carrier migration, a merger, or an acquisition changes the BAN underneath a stream of charges that keeps arriving on the old schedule. Deciding whether to reconcile that yourself or hand it to a provider is a large part of knowing when you need a TEM program.
Key Takeaways
- The BAN is the account identity a carrier bills under. It sits above service IDs and should reconcile to the invoice header, the customer service record, and the inventory of record.
- A BAN is not a phone number, a circuit ID, an invoice number, or a remittance ID. Confusing the BAN with any of these is the root of most reconciliation errors.
- Ghost payables appear when a BAN is truncated on import, remapped after a merger, split across accounts payable vendors, inherited in an acquisition, or paid under a remittance ID that does not match the BAN.
- One location can hold several active BANs after adds, migrations, and acquisitions, so the inventory has to list every one.
- Loading each BAN as a controlled key, so every invoice, dispute, and general ledger file points to one account identity, is what keeps payables audit-ready.
How BANs relate to CSRs, invoices, and inventory
The BAN sits at the top of a hierarchy, and every other telecom identifier hangs beneath it. On the customer service record, the CSR the carrier maintains for your account, the BAN is the parent. Under it sit the service IDs: circuit IDs, billing telephone numbers, and mobile numbers, each one a service the carrier has provisioned. Undder each service ID sit the charge lines: the monthly recurring charge, usage, features, taxes, and surcharges. That chain, BAN to service ID to charge line, is the structure a real reconciliation follows.
The invoice header carries the BAN. The inventory of record carries the service IDs. Reconciling the header to the CSR and to the inventory, line by line rather than by sampling, is the core of invoice auditing services, and it is where the account identity has to hold. If the BAN on the invoice does not match a BAN in your inventory, the charge has nowhere to land and the audit stops before it starts.
BAN, service ID, invoice number, remittance ID: four identifiers people conflate
Four numbers travel together on a telecom account, and treating any two of them as interchangeable is how reconciliations break. Each names a different thing and changes on a different schedule.
| Identifier | What it names | Where it appears | How often it changes |
|---|---|---|---|
| Billing account number (BAN) | The account a carrier bills under | Invoice header, customer service record, contract | Rarely, until a migration, merger, or acquisition |
| Service ID (circuit ID, billing telephone number, mobile number) | One provisioned service under a BAN | Charge lines, inventory of record, CSR detail | Whenever a service is added, moved, or disconnected |
| Invoice number | One monthly bill document for a BAN | Invoice header only | Every billing cycle |
| Remittance ID | The payee identity accounts payable pays to | Vendor master, check or ACH file | Rarely, and set separately from the BAN |
One BAN groups multiple service IDs, so counting BANs tells you how many accounts you have, not how many services. The invoice number is disposable, new every cycle, and useless as a reconciliation key. The remittance ID is the one most likely to drift away from the BAN, because accounts payable sets it up for payment routing without reference to the carrier’s account structure. That gap is where the next section lives.
Common BAN failures that create ghost payables
A ghost payable is a charge that clears every month against an account you can no longer connect to a service. The money is real and the payment posts cleanly, which is exactly why nobody catches it: nothing bounces, nothing errors, the general ledger balances. The BAN is what failed, quietly, upstream. Five failure modes account for most of them, and a line-item telecom audit is built to surface all five.
| Failure mode | How it happens | Why it creates a ghost payable |
|---|---|---|
| BAN truncation | Leading zeros are dropped or account segments are cut when a BAN is keyed or imported into accounts payable or a spreadsheet | Charges post to a malformed account that reconciles to nothing in inventory |
| Post-merger remapping | A carrier merger or platform migration reissues BANs, and for a period both the retired and the new BAN bill | The old BAN keeps billing while inventory points only at the new one, so the old stream goes unwatched |
| Split across accounts payable vendors | The same carrier account is set up under two or more vendor records in accounts payable | One BAN pays through two remittance identities, so no single view ever reconciles the whole account |
| Acquisition split | BANs inherited through an acquisition are never folded into the inventory of record | Inherited accounts bill against an owner nobody tracks, often for years |
| Remittance versus BAN mismatch | The remittance ID accounts payable pays to is set separately from the BAN on the customer service record | Payment clears but never ties back to a service, so the charge cannot be audited or disputed |
The last two are the most expensive because they hide the longest. After an acquisition, the inherited estate arrives without a clean inventory, and the BANs that came with it bill against no clear owner until someone reconciles them deliberately. A remittance versus BAN mismatch is worse still: the payment side looks healthy, so the mismatch never raises an exception. Both need the same fix, which is a single inventory owner who holds the authoritative list of active BANs and reconciles every remittance back to it.
A ghost payable never bounces. It clears, it balances, and it bills again next month. That is why it survives.
How RadiusPoint and ExpenseLogic keep BANs audit-ready
RadiusPoint loads every BAN into ExpenseLogic as a controlled key, so each invoice, each dispute, and each general ledger file points to one account identity rather than to whatever string happened to be typed that month. Once the BAN is controlled, the hierarchy underneath it becomes testable: every service ID maps to a BAN, every charge line maps to a service ID, and every payment maps back to the BAN it settled. When a carrier reissues a BAN in a migration, the old and new identities are linked in the platform rather than left to drift, so the retired account cannot keep billing unnoticed.
This is where the software-plus-people model matters. The platform holds the controlled keys and the rate table; RadiusPoint analysts do the reconciling work that keeps them true, validating every invoice line item against the inventory of record each billing cycle instead of sampling a few. RadiusPoint captures and validates every BAN, alias, and account number during onboarding and data collection, which is the step that decides whether the rest of the program reconciles or guesses. In one client estate, correcting the inventory of record recovered $174,000 in re-credits that had been sitting behind mismatched accounts.
Every month a BAN stays uncontrolled is another cycle of the same charges posting against an account nobody can audit. Ask RadiusPoint to reconcile one carrier’s BANs against your inventory of record, and you will see how many of your payables point at a service and how many point at a ghost.
Frequently Asked Questions
Is a BAN the same as a phone number or circuit ID?
No. A phone number, a billing telephone number, and a circuit ID are service identifiers that sit under a BAN, and one BAN can hold multiple of them. The BAN names the account; the service IDs name the individual services the carrier has provisioned on that account.
Who owns BAN accuracy, accounts payable or telecom?
Both, on different sides of the same number. Telecom owns inventory truth, meaning which services exist under which BAN. Accounts payable owns payment posting, meaning which BAN a payment settles against. They need the same BAN to agree, which is why a single inventory owner and a shared account list matter more than which department holds them.
What if a carrier uses an account number instead of a BAN?
Treat the account number as the BAN equivalent. Some carriers, particularly wireless and utility providers, label the field differently. Document the alias against the account in ExpenseLogic so the account number, the BAN, and any legacy identifier all resolve to one controlled key rather than three that look unrelated.
Can one location have multiple BANs?
Yes, and it is common. Adds, carrier migrations, and acquisitions all create new BANs for a site that already had one, so a single location can carry several active BANs at once. The inventory of record has to list every active BAN for the location, or charges under the unlisted ones become ghost payables.
Does wireless use BANs too?
Yes. Wireless bills roll up to a master account number that functions as the BAN, with individual mobile numbers as the service IDs beneath it. Map wireless the same way you map wireline: master account number as the controlled key, mobile numbers reconciled against an employee or cost center directory underneath it.