The problem

The client is a logistics and freight brokerage working with dozens of carriers, each of which invoices differently: some send structured EDI documents, some send PDFs from wildly different billing systems, and a few still fax or email scanned paper invoices. Their six-person accounts-payable team was manually keying line items from every invoice into the ERP system and cross-checking them against the rate agreement and shipment record. The work scaled roughly linearly with shipment volume, and as the company grew it was becoming the team's full-time job rather than one part of it.

The team wasn't slow because of a skills gap; the work itself was tedious and error-prone. A misread line-haul rate or an overlooked accessorial charge could mean overpaying a carrier by a few hundred dollars, small individually but adding up across thousands of invoices a month. Leadership wanted automation, but was explicit that an automatic wrong payment was a worse outcome than the current manual process, however slow.

What we actually did

We built a pipeline that ingests invoices in every format the client receives, extracts line items, validates them against the shipment record and rate agreement, and auto-processes anything that passes cleanly. Everything else goes to a human reviewer with the specific discrepancy flagged.

Weeks 1-2: cataloging the actual format variety, not assuming it

We pulled three months of historical invoices from all of the client's active carriers and found 41 distinct format variants across structured EDI, PDF, and scanned formats. That was more than the AP team had estimated, because a few carriers had quietly changed their invoice templates mid-year without anyone noticing. Building extraction against this real variety, rather than the handful of formats that came to mind first, shaped the rest of the build.

Weeks 3-4: extraction plus validation against two independent sources

Every extracted invoice is validated against two things: the shipment record (does this invoice correspond to a real, expected shipment?) and the carrier's rate agreement on file (does the billed amount match contracted rates, including accessorial charges?). An invoice only auto-processes if it passes both checks within a tight tolerance. Anything outside tolerance, or any invoice with a low-confidence line item, goes to a human reviewer automatically.

Weeks 5-6: exception routing and the reviewer interface

We spent more build time on exception routing and the reviewer interface than on extraction itself. A reviewer's job was now almost entirely the harder cases, so the interface had to show exactly what triggered each exception (which line item, which check failed, by how much). Presenting a full invoice with no guidance would only have moved the manual-review bottleneck, not shrunk it.

A design decision worth calling out
The client's finance lead initially wanted a wider validation tolerance, reasoning that it would auto-process more invoices and save more reviewer time. We pushed back with historical data: in our backtest, widening the tolerance to the requested level would have auto-approved a small but real number of invoices with billing discrepancies that the manual process had caught. We kept the tolerance conservative, so the 11% that still need review are genuinely ambiguous cases rather than errors a wider window would have let through.

Challenges and tradeoffs

Results

89% of incoming invoices now auto-process without a human touch, measured across the first two full months of production and all 41 cataloged carrier formats. A follow-up audit found that 0.4% of auto-processed invoices needed a correction afterward, all minor and none involving an overpayment of more than a few dollars. The client's controller considers that acceptable compared with the manual process's own historical error rate.

The AP team's role has shifted from keying line items to reviewing flagged exceptions and handling the carrier relationship issues they surface. The team's lead describes this as a far better use of the team's expertise than data entry, and the team has absorbed continued shipment-volume growth without adding headcount since the pipeline went live.

What we'd do differently

We'd build the format-drift detector in week one rather than reactively, after two carriers' template changes broke extraction mid-build. It became one of the most valuable pieces of the system, catching a third carrier's format change within days of production rollout, and it deserved to be part of the initial design.