Recovering 4.1% of freight spend by auditing every invoice

The situation#

Two problems that turned out to share a cause.

Freight invoices arrived from forty-odd carriers and agents in every format from a structured EDI feed to a scanned PDF attached to an email. Auditing one properly meant checking it against the contracted rate card, the accessorials actually incurred and the service actually delivered. Doing that by hand took twenty minutes, so the team sampled about one invoice in twenty and accepted the rest.

Separately, shipment exceptions were discovered when the customer called. Milestone data existed across carrier systems, but nobody was watching it against plan, because watching it meant a person logging into six portals.

Both problems were downstream of the same gap: no normalised view of what was supposed to happen versus what did.

What we did#

Weeks 1–2 — the normalisation layer. One canonical shipment and invoice model, with per-partner adapters feeding it. Structured feeds went through deterministic parsing because it is cheaper and more reliable where the format holds. The emailed spreadsheets and scanned PDFs went to extraction, which is where the model earns its place — the column order changes every month and a rigid parser cannot cope.

Weeks 3–5 — invoice audit. Every line checked against the contracted rate card, accessorial entitlement and the actual service milestones. Discrepancies above a threshold assembled into a dispute pack with the evidence attached, for a person to review and submit.

Weeks 6–7 — exception detection. Milestones monitored against plan, deviations flagged as they occurred, and the customer notification drafted with the case assembled.

Weeks 8–9 — track-and-trace deflection and handover. Status enquiries answered automatically from the normalised layer, with anything carrying a decision escalated to operations.

Why the recovery number is what it is#

The 4.1% is not one large error. It is the accumulation of small systematic ones that sampling was structurally unable to find — an accessorial applied where it was not entitled, a fuel surcharge computed on a superseded rate, a service level billed as express and delivered as standard.

Each individual discrepancy was small enough that finding it by hand would have cost more than recovering it. That is precisely why they persisted, and precisely why automating the check changes the economics rather than just the effort.

What we would do differently#

We built a portal scraper we did not need.

One carrier had no API on their standard tier, so we scoped and built browser-driven extraction against their portal in week four. It worked, it was brittle, and it broke twice in the first month when the portal changed.

In week seven the client's account manager asked the carrier directly and had API access enabled within three weeks, at no cost, because it was available on the tier they were already paying for. Nobody had asked.

We now make the commercial check a required step before scoping any portal integration — who owns this relationship, and have they asked. It costs one email and it has saved that work twice since. The general rule we took from it is in our logistics guidance: if a partner has an API and simply has not switched it on, that is a conversation, not an engineering problem.

Where it went next#

Customs documentation extraction went live the following quarter, reusing the extraction and review scaffolding. The dispute packs are now submitted by a single coordinator rather than the three people who previously assembled them.

The portal integration that remains — for one agent with genuinely no alternative — is monitored on a per-cycle basis so a break is detected within hours rather than at month end, and its maintenance cost is quoted in the retainer rather than absorbed silently.