Billing anomaly and dispute agents: finding the problem before the customer does
High-volume billing produces errors at a rate that hand-tuned thresholds either drown in or miss. Anomaly agents that learn what normal looks like per account, paired with dispute agents that triage consistently, turn billing from a complaint channel into a control.
In most of the operators and financial institutions we work with, billing errors are found by customers. That is the most expensive possible detection mechanism: it costs trust, it costs call-centre time, and it arrives weeks after the error occurred. The work described here inverts that, so the operator finds the anomaly first and resolves the dispute consistently when one does arrive.
Why thresholds fail
A static threshold on bill size or usage change is either noisy for the customers with volatile usage or blind for the ones with steady usage. Hand-tuning per segment does not scale, and the people who did the tuning move on.
Anomaly detection has to be relative to each account's own history and its peer group. That is a modelling problem, but a well-understood one: seasonal baselines, peer cohorts, and change-point detection, with the model refreshed as behaviour drifts.
The anomaly agent
The agent scores every bill run before it is issued, ranks anomalies by expected customer impact and revenue at risk, and assembles the evidence: the account's history, the tariff change, the usage records, the last few interactions. It hands a human a case that can be decided in minutes rather than a number that has to be investigated.
Low-risk corrections that match a pre-approved pattern (a known tariff misconfiguration, a duplicated charge) can be applied automatically under policy. Everything else is a human decision.
The dispute agent
Disputes that do arrive need consistent triage: classify, gather the evidence, apply the policy, propose a resolution, and draft the customer response. An agent doing this from the operator's own policy documents and billing records produces a consistency that a rotating call-centre team cannot.
The policy is retrieved with citations, not memorised. When the policy changes, the behaviour changes on the next case, and the audit trail shows which version applied.
Measuring it
Three numbers matter: the proportion of anomalies detected before issue, the mean time to resolve a dispute, and the consistency of outcomes for similar cases. The second and third move within weeks. The first depends on the quality of the baselines and improves as the model sees more billing cycles.
A secondary effect is that finance and engineering start fixing root causes, because the anomaly agent surfaces the same tariff misconfiguration fifty times and someone finally owns it.
Where this lives in the architecture
This is not a chatbot bolted onto the billing system. It is a set of services on the billing event stream with their own data model, a case-management console for the human decisions, and an audit store. The LLM components are narrow: evidence summarisation, policy retrieval, and response drafting.
The solution architecture matters more than the model. Getting the event stream, the case model, and the policy corpus right is most of the work.
Where we apply this in practice
Working on this in your own organisation?
If any of this maps to a programme you are running, we would be glad to compare notes.