The errors that never happened
A fee-validation agent at a cross-border payments company saved around a thousand hours a year. The hours were the least interesting part of the result.
A payments company bills its merchants according to a signed contract: tiers, transaction fees, installment surcharges, payout fees, refunds and chargebacks. The contract is the source of truth. The live configuration in the billing system is what actually charges money. Nobody had a systematic way to check that the two still agreed.1They agreed at signature. That's the easy part. The question is whether they still agree after a renegotiation, a rushed setup, or eighteen months of nobody looking.
Configuration was verified manually, without a consistent trigger, and usually only after somebody had already felt the problem.
What we built
An agent that takes a merchant identifier and their contract, pulls the live configuration and fee data from the billing systems, normalizes both into a common structure, compares them field by field, and outputs a discrepancy report a human reviews.
It doesn't fix anything. It reads two things that are supposed to match and says where they don't.
We wired it into the three moments a fee configuration can be created or altered: at the completion of a new integration, after any change to an existing merchant's fees, and on a schedule across the highest-value accounts. Those three cover every event that can introduce an error. Everything else is drift, and the scheduled runs catch that.
The hours
Full manual coverage at scale would take roughly a thousand hours a year across four teams. The figure is built the boring way: time per review, times reviews per month, times twelve, summed by team. The people doing the work recognized their own numbers in it.
Running the agent costs a few thousand dollars a year, and less in practice, because validating several merchant IDs under one contract in a single run costs less than doing them one at a time.2Our planning figures assumed no batching. Estimates that assume the optimistic case get audited later by someone in a worse mood.
That's the number that goes in the business case, and it's the weakest true thing I can say about the project.
Why the hours are the wrong headline
A fee-configuration error has two failure modes, and neither shows up in a timesheet.
Under-charging is a silent, compounding revenue loss. The company collects less than the contract entitles it to, on every affected transaction, for as long as nobody notices. Nothing breaks. The merchant does not write in to report being charged too little.
Over-charging bills a merchant more than they agreed to pay. That's a trust problem the moment it's discovered, a dispute-and-refund problem shortly after, and a billing-accuracy problem for any regulated payments company.
Same mistake, one digit in one field, landing in completely different parts of the business. One erodes margin, the other erodes the relationship and the compliance posture at once. Hours saved captures neither.
The part that can't be counted
When an agent like this runs against live configurations, it does what you'd expect: it turns up real discrepancies, waiting to be corrected before they compound. What it can't tell you is what they would have cost, because once a discrepancy is caught, the counterfactual disappears. Prevention always has this problem: success looks like an absence.3Which is why "errors prevented" is a claim about the future and "hours saved" is a claim about the past. I'll put the past one in the proposal and say the rest out loud.
Three things changed that don't fit in a spreadsheet.
The check happens whether or not anyone remembers. Before, validation depended on somebody deciding an account was worth reviewing, and that decision was the real bottleneck. Nobody logs the reviews they didn't think to do.
There's a record. Each run leaves an artifact: this configuration was compared against this contract on this date, and here is what matched. Worth something to an auditor and quite a lot to whoever inherits the account.
A clean run is a result. Most runs find nothing. Manually, "nothing" costs twenty minutes and feels like waste, so it doesn't get done. At a few dollars a run, "nothing" is a fine thing to buy repeatedly.
What's still missing
There's no established baseline error rate for this kind of configuration drift across the industry. Without one, "reduces configuration errors" is a direction rather than a magnitude — a claim that gets sharper as more runs accumulate.
The output is only as good as the source-of-truth contract it validates against. If that record isn't reliably current, the agent compares a reliable thing to an unreliable one and reports with false confidence. That's a filing problem, not an engineering one, and it's the real dependency.
The automation has its own upkeep. Small, not zero, and a fair number subtracts it.
The shape of the result
The summary isn't "we saved a thousand hours." It's that a recurring blind spot became a monitored control, and the hours are how we know someone was spending effort on it before.
The next step is the obvious one and the one to be careful about: an agent that proposes the configuration from the contract, with the validator checking its work, looping until there's nothing left to flag. That's a different risk conversation, because it means write access to a revenue system. Read-only for the checker, scoped and staged writes for the proposer, human approval before anything lands.
Reading is cheap to get wrong. Writing isn't.