Telecom Expense Management Software Problems: The 5 That Cost You Real Money, and How to Avoid Them

Why does the inventory get scoped as last month's invoice so often?

Because an invoice export is the only telecom dataset most enterprises can produce on request, so it becomes the starting point by default. It is also the wrong object, and the whole system inherits the error.

An inventory says: this circuit, this identifier, 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. A billed charge says almost none of that, and the identifier on it is the carrier's rather than yours. The moment you have more than one carrier the same physical service carries three identifiers: yours if you assigned one, your carrier's circuit identifier, and the underlying facility provider's, which frequently belongs to a completely different carrier who owns the last mile.

Reconciling those is not a one time cleanup. It is a permanent matching problem, and it is the actual product. Everything else in this category is reporting on top of an inventory, so if the inventory is wrong every dashboard above it is decoration. The tell in a proposal is what the developer does with a billed identifier 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 and an owner, because that queue is where recovered money actually comes from.

What goes wrong when you assemble the inventory from carrier records and site lists?

Three sources have to be joined and none of them was maintained for this purpose.

Customer Service Records from the incumbent local carrier list what is provisioned against each billing account, down to the service order codes, and they are the best starting point available. They are also written in carrier language, they describe services that were disconnected years ago and still appear, and they use address formats that will not match your property system. Request them early, because the request itself can take weeks and it sits directly on the critical path.

Your site list comes from property or facilities and reflects leases rather than operations, so it carries sites that closed, sites under a legal entity name rather than a trading name, and addresses formatted for a landlord. Your cost centre hierarchy comes from finance and gets restructured on a different cycle from everything else, so last year's allocation is already stale.

Expect a meaningful share of records not to join on the first pass. That is not a defect, it is the finding, and the plan has to include a human review queue rather than treating unmatched rows as bad data. The second trap is history. Twelve months of invoices in whatever format they arrive is enough to build and test ingestion, and it is also the evidence base for any retrospective claim, so check your carrier agreements for how far back a credit claim may reach before scoping a historical audit. That window is contractual and usually shorter than people assume.

Why do carrier invoice feeds and HR (Human Resources) feeds break after launch?

Both fail without an error, which is why they survive to cause damage.

Carrier invoices arrive in every shape there is. Some carriers send a structured electronic invoice such as an EDI 811 consolidated service invoice, which is the good case. Some send a comma separated file that is stable until the quarter they add a column. Some send a summary page and forty pages of detail as a PDF, and regional or international carriers still send paper or an emailed image. The failure after launch is a format that shifts slightly, so a column moves and your parser produces plausible detail lines that are wrong, or drops a whole surcharge category without complaining.

The guardrail is arithmetic rather than trust. Parse every detail line, then reconcile the sum of parsed detail back to the invoice control total, and route any invoice where those two figures disagree to a human before anything posts. This is also where document extraction genuinely earns its place for PDF only carriers, under exactly that supervision. Never let a model quietly decide a charge looks correct, because a plausible wrong number is worse than a missing one when the whole point of the system is that you can defend every figure in a dispute.

The HR or identity feed for mobile fails differently. It works, then somebody changes the leaver process or a contractor population arrives that does not exist in the HR system at all, and suspend recommendations quietly stop generating for a whole category of people. Monitor the recommendation count against expected leaver volume rather than assuming the feed is healthy, and decide explicitly how contractors are represented before go live rather than after.

What happens when disconnects, credits and term liability are not covered?

These three are unglamorous, they are usually cut from a first release, and together they are where most of the money is.

A disconnect is not done when the order is placed. It has to carry through to a carrier order number and then be verified against the next invoice, and verified again on the one after, 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 cannot tell those two apart, which is why single cycle verification produces both false alarms and missed leakage.

Credit matching is the second. When you dispute a charge you get a carrier ticket number, and eventually a credit appears on a later invoice, often described in a way that never mentions your claim. Matching credits received back to disputes raised is how you discover which promised credits never arrived, and nobody does that by hand for long, which is precisely why it belongs in the build rather than in someone's spreadsheet.

Term liability is the third and it changes decisions rather than just reporting them. The answer to should we disconnect this is not always yes, because a circuit still inside its committed term can carry early termination liability that exceeds the cost of running it out. If in service date, term length and termination terms are not in the data model, the system cannot answer the only question that matters before an order goes out, and finance finds out afterwards.

Should you build custom or configure what you already own?

If you have never audited telecom spend and have no internal owner, buy. Tangoe, Calero and Sakon are sold as platform plus people, and that managed service model is genuinely the right first move, 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 one relationship. Asignet is worth a look if your problem is narrowly invoice capture at volume. MobilSense and brightfin specialise in the mobile side, and brightfin running on ServiceNow is a strong argument if you already own ServiceNow and an awkward one if you do not. These are real products doing real work and there is no honour in rebuilding them.

The build case 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 mapping your structure into their system has already been quoted to you as a change request. Build when you want 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 covers poorly and that is where your spend is growing. And build when a recovery share fee has started to look expensive against what a system you own would cost to run.

One honest warning that applies either way. A system does not replace the person. Somebody has to raise disputes, chase carrier tickets and make disconnect decisions. Build this with no owner and you will have an accurate, well designed record of money you are still losing.

How do hidden costs get into the quote?

Invoice format count is the first and it is almost always written as one line reading carrier ingestion. Each additional format is real work, PDF only carriers cost materially more than structured feeds, and the long tail of small regional carriers is where the awkward formats live. Price by carrier, and accept a manual path for the tail in release one.

International operations are the second. Multiple currencies, local tax treatment on the same spend line, and local carrier document conventions are three separate pieces of scope that a domestic quote does not contain.

Third, the finance posting. General ledger coding means agreeing an allocation model with your finance team, which is a business negotiation before it is code and frequently the slowest item on the plan. Fourth, the HR or identity integration for mobile, which is straightforward until you meet contractors who hold lines and do not appear in the HR system.

Fifth, and never in a developer's number, the assembly of your own source data. Customer Service Records have to be requested, the site list has to be reconciled with property, and the cost centre hierarchy has to be agreed with finance. If those three have never been put side by side, expect two to four weeks of assembling and arguing about them before the join means anything, and that work sets the schedule.

What separates a build that works from one that fails here?

Start with the carriers holding most of your spend rather than trying to cover everything. Two carriers well ingested with detail reconciled to control totals will surface more money in a quarter than eleven carriers half parsed, and the long tail can stay manual without anyone noticing.

Design the unmatched queue as a first class part of the product, not an error log. Every billed identifier that will not join to a site and a cost centre is a work item with an owner and a status, and the throughput of that queue is the closest thing this system has to a success metric in year one.

Name an owner before you name a budget. The disputes, the carrier ticket chasing and the disconnect decisions are human work that software organises rather than replaces, and a project with an executive sponsor and no operational owner produces a clean dataset and no recovery.

Then 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, which matters here because the system holds your contract terms, carrier account structure and dispute history, and losing access means rebuilding an inventory that took months to reconcile. One thing you can do this week without buying anything: take the last invoice from your two largest carriers, list every billed circuit identifier, and try to write the site and cost centre next to each one. The count you cannot fill in is your business case.