Interconnect Settlement Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does a settlement project try to carry three settlement models at once?

The single most reliable way to overrun an interconnect build is to treat voice interconnect, access settlement and roaming as one product. They look like one product from the outside. All three are traffic exchanged with another party, rated against an agreement, reconciled and settled. Underneath they are different disciplines with different reference data, different record formats and different regulatory regimes.

Access settlement in the United States requires jurisdiction determination from the calling and called numbers using industry reference data, carries its own record formats, and has a rule history shaped by the long transition toward bill and keep following the Federal Communications Commission's intercarrier compensation reform, which means your logic has to carry historic rules by period rather than one current answer. Roaming settles through the GSMA file exchange against inter operator tariffs and is a separate discipline again. Voice interconnect is bilateral commercial agreements. An operator doing all three has three products under one roof.

The fix is a sequencing decision made before design starts. Pick the model that carries the most disputed money today and build it end to end, including the dispute workflow, before the second model gets a line of code. Share the infrastructure underneath, the record store, the rating engine shape, the reconciliation framework, but ship one settlement model properly first. Operators who sequence this way have working reconciliation in the first release. Operators who scope all three tend to have a rating engine and no dispute capability nine months in, which is the wrong half of the system to own.

What goes wrong when you migrate rate history into a new system?

Rate migration is where these projects lose credibility, and the cause is almost always the same. The old system holds a current rate table that has been updated in place for years. The new system needs effective dated rates with full history, because a call has to rate at the rules that were in force on the day it was made, and any past period has to be re-rateable identically during a dispute that may run for several quarters.

You cannot derive history from a current state. What teams do instead is import the current table with a single effective date, which produces a system that is correct going forward and useless for any dispute about traffic already carried. That gap is discovered by the wholesale team the first time a partner reopens a period, and by then the old system may already have been switched off.

The fix has two halves. First, reconstruct history from the source rather than the system: the rate sheets your partners emailed, with their stated effective dates, are the real record and they are usually sitting in a mailbox. Load them as a sequence of dated versions and accept that some historic periods will have gaps you have to mark honestly. Second, run both systems in parallel over live traffic for several full periods and investigate every difference, because each difference is either a defect in the new rating or an undocumented assumption in the old one. Do not decommission the previous system until every open dispute period is covered by the new one, and keep it readable for as long as your agreements allow a period to be reopened.

Why do partner file integrations break after launch?

Counterparty formats are the one thing in this category that changes constantly and without notice, and they are the thing most builds handle worst. A partner sends an invoice as a spreadsheet with their own column names. Another sends a fixed width file. A third sends a PDF. Then a partner changes their billing system, the file changes shape, and nobody tells you.

The break is rarely a hard failure. A column shifts, a total is read from the wrong field, or a destination code column arrives with leading zeros stripped so prefixes no longer match, and reconciliation produces a variance that looks like a commercial dispute and is actually a parsing error. Wholesale teams then spend weeks arguing about minutes when the real problem is that a file was read wrong on day one.

The fix is to put format ownership inside your own building. A new partner file type should be a mapping your operations team creates in days through an interface, not a change request in a vendor or developer queue. Add a validation layer that checks structural expectations on every load, column count, code format, totals reconciling to the stated invoice value, and rejects into an exception queue with a named owner rather than ingesting something it half understands. If adding a format takes weeks, your wholesale team will keep a parallel spreadsheet, and once that spreadsheet exists you own two versions of the truth and have paid for one of them.

What happens when dispute deadlines and evidence are not covered?

Most settlement builds model the invoice and treat the dispute as an email thread. That is the gap that costs real money, because disputes are lost on the clock far more often than on the merits.

A dispute has a partner, a period, an amount, a stated cause, an evidence set, a deadline that comes from the specific agreement rather than from a global setting, an owner and an outcome. It also has a second act nobody plans for: the counterparty comes back three weeks later accepting part of the claim, and you now need to reproduce your original position exactly, apply the partial acceptance, issue or receive a credit note, and carry the effect into the next netting statement. If the evidence was a screenshot pasted into an email, you cannot do any of that, and the partial acceptance becomes a second reconciliation problem stacked on the first.

The fix is to make the dispute a first class object with reproducible evidence. Store the evidence as a saved query that re-runs against the record store, not as an exported file. Hold the dispute window per agreement and count down against it visibly. Route partial acceptances and credit notes through the settlement flow automatically so netting reflects them without a manual adjustment. And separate detection from classification: any system can show you that two numbers differ, but the useful behaviour is a statement that the gap sits in one destination group across three days and is consistent with a billing increment mismatch. That single capability turns a four week argument into a phone call.

Should you build custom or configure what you already own?

Some operators should not build this, and it is worth being direct. If you run a small number of bilateral partners on a single softswitch whose bundled wholesale billing already rates them acceptably, stay where you are. At that scale the settlement spreadsheet is annoying rather than expensive, and the money belongs in traffic acquisition. Try harder to use what the switch vendor gives you before you spend anything.

If you are a large operator, TEOCO and Subex both bring mature interconnect and settlement capability with long track records in this exact discipline, and Comarch and Hansen come at it from full business support system estates, which is an advantage if you are buying the whole stack. Configuring one of those is a legitimate answer and frequently the right one.

The friction that pushes mid sized voice carriers, transit providers and growing mobile operators toward a build is consistent: onboarding is a project before the first reconciliation runs, commercial models are scaled to operator sizes above yours, and partner format onboarding tends to route through the vendor. Test that last point during evaluation. Ask what it takes to add a new counterparty invoice format and who does it. If the answer is a support ticket with a lead time, run the numbers again, because that lead time is the thing that will produce a shadow spreadsheet.

Our threshold: build when the value of a single disputed month exceeds a month of engineering, which for most wholesale voice operators arrives somewhere past fifteen to twenty active bilateral relationships, and earlier if one partner carries a large share of your traffic.

How do hidden costs get into the quote?

• Partner format count on day one. The most commonly underestimated item in scoping. A quote for reconciliation against your top five partners is not a quote for sixty.
• Record volume. Rating a few million calls a day and rating a few hundred million are different engineering problems, and a quote written against the first will not survive the second.
• Jurisdiction determination. If you settle access in the United States this brings reference data licensing and its own update cadence, which is a recurring cost as well as a build cost.
• Currency and foreign exchange. Sounds trivial until agreements specify different rate dates and different sources, at which point it is a per agreement configuration with its own reconciliation.
• Historic rate reconstruction. The work of turning a mailbox of rate sheets into dated versions is real, and it is rarely in either party's estimate.

The fix is a scoping exercise on real material. Hand over one partner agreement with its rate sheet, one month where your number and theirs disagreed, and a list of every counterparty file format you receive. Price the build against that rather than against a feature list, and make format onboarding capacity an explicit deliverable with a stated number of days per new format.

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

The builds that hold up treat variance as a measurement with a tolerance rather than as a scandal. Increment differences, rounding conventions, treatment of calls answered by an announcement, short duration grace periods, day boundaries in different time zones and missing records at a mediation feed all produce legitimate gaps. A system with a policy threshold that reconciles every partner every period automatically and escalates only what breaches it turns settlement from an argument into an exception process.

They also put fraud detection in the same pipeline that produces the settlement. Refiling and re-origination, calling line identity manipulation that changes which rate applies, and artificial inflation of traffic toward high payout destinations all appear first as commercial shapes in the settlement data: volume the relationship does not explain, or average call duration shifting on one route. A separate fraud tool looking at separate data will always be arguing against a different number.

And they make netting visible within days of close rather than weeks. Late netting means routing and credit decisions are made on stale margin, and that loss never appears as a line item anywhere, which is exactly why it survives for years.

One test before you sign anything. Ask a prospective developer to explain how they will re-rate a call from two years ago at the rates in force on the day it was made. If the answer involves updating a current rate table, stop the conversation, because effective dated rating with full history is the foundation and retrofitting it means rebuilding everything above it. Then settle ownership in writing before kickoff: repository, cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit, which matters here because your rate history and settlement records are the evidence base for disputes that run long after the traffic was carried.