Telecom Expense Management Software: How Do You Stop Paying for Circuits at Sites You Shut Three Years Ago?

The circuit at a site you closed three years ago

A retail chain shuts eleven stores in a restructuring. Leases are surrendered, the fixtures go to auction, the point of sale (POS) hardware comes back to head office. Two years later somebody in IT finance is looking at a Verizon invoice with 340 line items on it and notices a DS1 billed against an address that no longer trades under your name. It has been billing every month since the store closed. Nobody placed the disconnect because the store closure checklist covered the lease, the utilities and the alarm contract, and the circuit was ordered four years earlier by a project manager who has since left.

That is the war story version. The ordinary version costs more. A circuit was disconnected properly on request, the carrier acknowledged the order, and the charge kept appearing for another seven billing cycles because the disconnect completed in the provisioning system and never reached the billing system. Nobody checked, because checking means opening a 340 line invoice and comparing it to a request that lives in an email thread. The money leaves quietly, monthly, and the only person who would notice already has three hundred other invoices to approve this week.

Problem one: you do not have an inventory, you have a pile of invoices

Ask most enterprises for their telecom inventory and you get an export of what was billed last month. That is not an inventory. An inventory says: this circuit, this ID, at this address, serving this cost centre, ordered on this date, in term until this date, at this monthly recurring charge, under this contract, with this disconnect status. What you have instead is a billed charge with a carrier's circuit ID on it, and the ID format is the carrier's, not yours.

This gets worse the moment you have more than one carrier, because the same physical service is known by three different identifiers: yours, if you assigned one, your carrier's circuit ID, and the underlying facility provider's ID, which is frequently a completely different carrier who owns the last mile. Reconciling those is not a data cleanup exercise you do once. It is a permanent matching problem, and it is the actual product. Everything else in telecom expense management is reporting on top of an inventory, so if the inventory is wrong every number downstream is decoration.

The starting data usually exists and nobody has assembled it. Customer Service Records from the incumbent local carrier list what is provisioned against each billing account, down to the USOC codes. Your site list sits in property or facilities, your cost centre hierarchy in finance. The build is the join, plus a review path for records that will not join, because there will always be a few hundred of those and pretending otherwise is how these projects fail.

Problem two: every carrier invoice is a different document and it changes without telling you

Some carriers send an EDI 811, the consolidated service invoice transaction set, and that is the good case. Some send a CSV that is stable until the quarter they add a column. Some send a PDF with a summary page and forty pages of detail. Regional and international carriers still send paper or an emailed image, and across countries you are also handling multiple currencies and tax treatments on the same spend line.

This is where general accounts payable automation gives up. AP tooling is built to capture a header, a total and a few line items so an invoice can be coded and approved. Telecom invoices need every detail line parsed, because the leakage is in the detail lines: a feature charge on a line that no longer exists, a surcharge that survived a rate change, a circuit at a closed address. Approving the invoice total tells you nothing. You have to reconcile the sum of the parsed details back to the invoice control total, and every invoice where those two numbers disagree goes to a human before anything is posted.

Document extraction is the one place AI genuinely earns its keep here, and it earns it under supervision. A model reads the PDF layouts you cannot get a structured feed for and produces draft detail lines. The reconciliation to control total is the guardrail. Never let a model decide silently that a charge looks correct, because a plausible wrong number is worse than a missing one, and the whole point of this system is that you can defend every figure in a dispute.

Problem three: the disconnect is not done when the order is placed

The single highest value loop in the whole system is the boring one. A disconnect request has to carry through to a carrier order number, then be verified against the next invoice, and then verified again on the one after that, because carriers commonly issue a final bill with partial month proration that looks like the charge is still running when it is not, and equally commonly leave a charge running when it should have stopped. One cycle of checking is not enough to tell those two apart.

The same object has to know your contract position, because the answer to should we disconnect this is not always yes. A circuit still inside its term commitment may carry early termination liability, and disconnecting it can cost more than running it to term. So the inventory has to hold the in service date, term length and termination terms, and tell the requester what a disconnect will cost before the order goes out rather than after finance sees the charge.

Then there is the credit side. When you dispute a charge you get a carrier ticket number, and eventually a credit appears somewhere on a later invoice, often described in a way that does not mention your claim. Matching credits received back to disputes raised is how you find out which promised credits never arrived. Nobody does that by hand for long, which is exactly why it is worth building. Check your carrier agreements for how far back a credit claim may reach before planning a retrospective audit, because that window is contractual and usually shorter than people assume.

Problem four: mobile is a different business and gets managed as if it is not

Fixed circuits are stable objects that change rarely and cost a lot each. Mobile is thousands of small objects that change constantly and cost little each, and the leakage pattern is completely different. Lines assigned to people who left months ago. Zero usage lines on tablets in a drawer. Pooled data plans where the pool is sized for a peak that happened once. Device installment plans that keep running after the device was replaced. International roaming that appears once, enormously, on a single line.

Managing that with the same screens you use for circuits does not work. The unit of work is different: mobile needs a bulk action path, an approval flow a line manager can use, and a feed from HR (Human Resources) or identity so a leaver triggers a suspend recommendation the same week rather than at the next audit. MobilSense and brightfin are both built around this side of the problem specifically, and brightfin runs on ServiceNow, which is a strong argument if you already own ServiceNow and an awkward one if you do not.

What this costs and how long it takes

A first release covering ingestion for your top carriers by spend, the circuit and line inventory joined to your sites and cost centres, invoice detail reconciliation and a dispute workflow with credit matching runs $60,000 to $140,000 and ships in 10 to 16 weeks. That is enough to find the money. The rest of the platform is about keeping it found.

A full build adding mobile line lifecycle with an HR feed, contract and term tracking with termination liability, order to disconnect verification, GL coding and posting to your finance system, and multi currency handling for international spend runs $160,000 to $400,000 phased over 6 to 12 months.

What pushes cost up is predictable. Each additional invoice format is real work, and PDF only carriers cost more than structured feeds. International operations bring currency, tax and local carrier formats. An HR or identity integration for mobile is straightforward until you meet contractors, who hold lines and do not appear in the HR system. Posting to the general ledger means agreeing an allocation model with finance, which is a business negotiation before it is code. What keeps cost down is starting with the carriers holding most of your spend and accepting a manual path for the long tail in release one.

Build versus buy, and when buying is right

Buy, and do not call us, if you have never audited your telecom spend before. Tangoe, Calero and Sakon are sold as platform plus people, and that managed service model is genuinely the right first move for an organisation that has no inventory and no internal owner, because you are buying analysts as much as software and the first pass will find things. vCom suits mid market organisations that want sourcing and management from the same relationship. Asignet is worth a look if your problem is narrowly invoice capture and processing volume. These are real products doing real work and there is no honour in rebuilding them.

The build case is different and it is about ownership rather than capability. Build when the inventory has to reconcile to your own site, cost centre and asset structures rather than a vendor's model of them, and when mapping your structure into their system has already been quoted to you as a change request. Build when you want your normalised telecom data as a live feed into your own analytics and finance systems rather than as a report you request. Build when you have carriers or countries your vendor does not cover well and the gap is where your spend is growing. And build when the managed service fee, which is often a share of what is recovered, has started to look expensive relative to what a system you own would cost to run.

One honest warning. A custom system does not replace the person. Somebody has to raise disputes, chase carrier tickets and make disconnect decisions. If you build this and nobody owns it, you will have an accurate, well designed record of money you are still losing.

How to choose a developer for telecom expense work

Ask them what they would do with a billed circuit ID that matches nothing in your site list. If the answer is flag it as an error, keep interviewing. The right answer is that it becomes a work item routed to someone who can investigate, with a status, because that queue is where the recovered money actually comes from.

Ask how they will reconcile parsed invoice detail to the invoice control total, and what happens when it does not balance. Ask whether they have handled an EDI 811 and what they do for carriers who will not provide one. Ask how a disconnect is proven complete, and listen for whether the answer involves checking more than one subsequent invoice. Ask how they would model a circuit that is in term, because if term and termination liability are not in the data model the system cannot answer the only question that matters before a disconnect.

Settle ownership in writing before kickoff: the repository, the cloud accounts and the freedom to bring in another firm. At Digital Heroes the client owns the code from the first commit. Here is a next step you can run this week without buying anything. Take the last invoice from your two largest carriers, list every billed circuit ID, and try to write the site and the cost centre next to each one. The count you cannot fill in is your business case, and in most organisations that number is large enough to end the discussion.