Case Study
Remittance Stub Parsing
multi-format extraction · arithmetic validation · reconciled ledger
The deduction was invalid. The dispute window closed before anyone read the stub it was buried in. That is how most recoverable money at a specialty food brand quietly becomes unrecoverable — not lost to a bad argument, lost to an unopened PDF.
Every retailer and distributor payment arrives with deductions already subtracted, described on a remittance advice in that partner’s own format and its own reason-code vocabulary. A finance team keys them into a spreadsheet by hand, if there is time, which there usually is not. The consequence is direct: a deduction that is not identified and classified before the retailer’s dispute deadline is unrecoverable regardless of whether it was ever owed.
The worked example is Cinderhaven Provisions — a fictional $25M specialty food brand that logged 3,357 chargebacks — 2,873 from retailers and 484 from distributors — over a rolling 36-month window. The ledger is synthetic, but the shape is the one every brand at this scale lives with: four major formats — Walmart, Costco, UNFI, and KeHE — each describing the same events with a different layout and a different code.
The arithmetic decides what a human reads
Extraction is the easy half and the wrong thing to optimize. The question is which extracted stub a scarce human should actually look at, and the answer is not a model confidence score. It is a balance check: net cash received, plus the sum of the deductions, must equal the gross invoice. If it balances, the stub is fully accounted for and no one needs to read it. If it does not balance, something was missed or miscoded, and it routes to a human review queue with the discrepancy already surfaced.
No probabilities, no judgment call about whether the model was sure enough. A stub reconciles to the penny or it does not, and only the ones that do not consume attention. Reason codes classify against a per-retailer map, and any code the map does not recognize is flagged rather than guessed — because an unmapped code is precisely the kind of thing a person should see. The trust does not come from the model. It comes from the arithmetic, which is checkable and the same for every retailer.
Attention is the scarce input, not extraction
The bottleneck at a lean brand was never the ability to read a single remittance. It was the impossibility of reading all of them before their windows closed. Automate the extraction and validate it with arithmetic, and the review queue holds only the stubs that failed to balance, while the window is still open, ranked so the largest exposures surface first.
That is the difference between finding an invalid deduction and finding it in time. Recovery win rates collapse as a claim ages, from 75 to 80% inside the first week to under 5% past ninety days. A parser that clears the balanced stubs automatically buys back the days that decide whether the invalid ones are worth disputing at all.
What you get
Your remittances from every partner turned into a single reconciled ledger, penny-exact, with the stubs that do not balance flagged and ranked by dollars and days. A remittance is not paperwork. It is a countdown, and the only thing standing between a brand and its own recoverable money is whether someone classified the stub before the clock ran out.
The ledger feeds everything downstream
The unified ledger is the raw material for the rest of the deduction work: the Trade Spend & Deduction Recovery → that disputes the invalid claims worth recovering now, and the Chargeback Prevention roadmap → that finds which single wrong field is generating the same deduction every shipment.
Start in writing.
A few minutes by form — no call. Send me one month of remittance advices from your top four partners, in whatever formats they arrive. I’ll return them as a single reconciled ledger, show you which stubs do not balance, and tell you how many dollars are already past the dispute window. No deck, no obligation.