Agentic Bank Fee Audit: Catching Account-Analysis Overbilling Before Treasury Pays It
written by Cooter:Labs
published on September 19, 2026
Introduction
Every commercial bank account under a treasury management services agreement (TMSA) generates a monthly account-analysis statement: a line-item bill for every service the bank provided against that account — wire transfers, ACH originations, lockbox items processed, positive-pay exception review, stop payments, sweep transactions — priced against a fee schedule the company negotiated, and offset by an earnings credit calculated on the account's average collected balance. In a company with a handful of entities and a handful of banks, that's dozens of statements a month, each one a mix of a bank-generated summary and, in the better cases, a structured EDI 822 account-analysis file underneath it. Almost nobody recomputes those statements line by line against the negotiated contract. Treasury reconciles the total debit against cash, not the arithmetic that produced it — which means a mispriced line item, a miscounted transaction volume, or an earnings-credit calculation that quietly drifted from the negotiated rate can bill the same error every month for years before anyone notices.
An account-analysis statement is the bank grading its own homework — it states what it charged and what earnings credit it applied, but it doesn't show its work against the specific unit prices, volume tiers, and earnings credit rate the company actually negotiated, so an error only gets caught if someone independently recomputes every line.
The agent ingests each bank's monthly account-analysis statement — the structured EDI 822 file where the bank provides one, a CSV or PDF extraction where it doesn't — and maps every billed service code to the corresponding line item in that account's TMSA fee schedule. This step alone catches a category of error that has nothing to do with pricing: a bank billing a service code that isn't in the negotiated schedule at all, or applying a newer bank-wide price list instead of the company-specific negotiated rates after a relationship renewal.
For every billed line item, the agent independently counts how many of that transaction type actually ran through the account that month — wires sent, ACH items originated, lockbox checks processed, positive-pay exceptions reviewed — from the account's own transaction-level activity feed, rather than trusting the count the bank prints next to its own unit price. A bank overcounting outgoing wires by including same-day repairs or a batch that was reversed and resubmitted is a volume error, not a pricing error, and it only shows up if something recounts independently of the bank's own tally.
Once the agent has its own volume count, it prices that volume against the negotiated fee schedule — including any tiered discount the schedule specifies once a monthly volume threshold is crossed (the 401st wire that month priced lower than the first 400, for instance) — and compares that computed charge to what the bank actually billed for that line. A fee schedule negotiated at contract signing but never re-applied after a subsequent relationship repricing is the most common source of drift here: the bank's system still has an old price list active for one service code while everything else on the same statement reflects the current one.
Separately, the agent recomputes the earnings credit allowance — the account's average collected balance for the period, multiplied by the negotiated earnings credit rate, net of the reserve requirement adjustment the bank applies before crediting it against fees — and compares that to the credit the statement actually applied. It then nets every discrepancy, on both the fee side and the credit side, ranks them by dollar impact, and routes each one: a unit-price mismatch goes to the banking relationship owner with the specific TMSA clause it should match, a volume miscount goes back to treasury operations to reconcile against the account's own transaction log, and an earnings-credit calculation error goes to a treasury analyst, since a wrong ECR often means the bank is using a stale average-balance figure or an outdated reserve percentage rather than a simple typo.
Looking Ahead: Challenges and Innovations
The fee schedule is a negotiated contract, not a structured dataset, and the agent is only as accurate as its translation
A TMSA fee schedule is a PDF or Word exhibit with tiered pricing, bundled 'relationship pricing' discounts across accounts, and minimums that don't always map one-to-one onto a billed service code. Someone still has to translate that contract language into a structured rules table the agent can price against, and a schedule with ambiguous bundling language (does the volume discount apply per account or across the whole relationship?) will produce a false discrepancy flag until a human resolves which reading is correct — the agent surfaces the mismatch, it doesn't adjudicate an ambiguous contract term.
Multi-bank, multi-entity companies don't have one format problem, they have five
A company with accounts at five banks across a handful of legal entities is reconciling five different statement formats, five different definitions of what counts as a billable 'wire' (domestic versus international, outgoing versus incoming, repair versus original), and five separate negotiated schedules that were renewed at different times by different people. The agent has to hold each bank's own definitions and schedule version separately rather than assuming a service code means the same thing everywhere, and getting that account-to-schedule mapping wrong at onboarding produces confident-looking discrepancies that aren't real.
A flagged discrepancy is a case to bring to the bank, not a refund
Finding that a bank overbilled a line item doesn't get the money back — someone on the banking relationship team still has to raise it with the bank's service team, and most banks only credit disputes raised within a lookback window (often 60 to 90 days), so a discrepancy that's been quietly compounding for a year is mostly unrecoverable by the time it's found, even once it's proven. The agent's real value shifts from recovering old overbilling to shortening how long a new one runs before someone catches it and disputes it while it's still inside the window.
The metaverse
Bank fee auditing has stayed a manual, after-the-fact exercise mostly because the account-analysis statement itself has been the only structured artifact available — the underlying transaction-level data the bank used to build that statement wasn't something a corporate treasury team could see or independently recompute against. As more banks expose account-analysis and transaction data through open-banking APIs rather than a monthly EDI file or PDF, the same recomputation an agent runs today as a once-a-month batch check becomes something that can run continuously against live data — catching a mispriced service code on the transaction that triggers it instead of on the statement that bills for a month's worth of them.
Conclusion
A bank account-analysis statement is designed to be paid, not audited — it states a total and expects treasury to reconcile it against cash, not against the contract that was supposed to price it. Recomputing every billed line from the account's own transaction volume and the negotiated fee schedule, and recomputing the earnings credit offset the same way, doesn't require any new banking relationship or renegotiation to start paying for itself — it just means someone is finally doing the arithmetic the bank's own statement never shows, before the dispute window on any given month's error closes.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.