Case study
A third party logistics firm in Ohio settles carrier invoices for about 300 shippers. Three people were keying several hundred a week and the backlog grew each quarter. We built an agent that runs the sequence and stops when something does not match.
Named only with client approval Figures marked are illustrative Reply within one business day
Agent running - queue empty
Flow 04
01
Trigger
Webhook
02
Enrich
Normalise
03
Decide
Policy
04
Act
Resolve
Run log
> Matched 42 records
> Routed 7 exceptions to a human
> Closed 35 tickets automatically
35
Auto-resolved today
6h
Engineer time saved daily
OlDevs built an agent that settles carrier invoices end to end for a third party logistics firm in Ohio that handles about 300 shippers.It reads the invoice, pulls the load and rate confirmation through the TMS API, compares accessorial charges line by line, requests missing paperwork from the carrier, and posts the approved entry to accounting. Anything outside tolerance stops and goes to a human queue with the discrepancy shown. Every step, tool call and document version is written to an append only log in PostgreSQL, so an auditor can replay exactly how a given invoice reached its outcome.
Key facts
The challenge
Settling a single carrier invoice meant opening the invoice PDF, finding the matching load in the transport management system, checking the rate confirmation, chasing a missing bill of lading and then keying the result into accounting. Three people did this several hundred times a week and the backlog grew every quarter. Auditors also needed to see why any given invoice was approved, which nobody could reconstruct from email.
Every settlement meant opening the invoice PDF, locating the load in the transport management system, checking the rate confirmation and then keying the result into accounting. The work was mechanical, and the cost of it was a person's full attention each time.
Three people worked several hundred invoices a week, which was never quite enough. The queue lengthened each quarter, so the team spent its capacity on the routine invoices rather than the ones that needed judgement.
A settlement often stalled on a bill of lading that had not arrived, and chasing it meant an email thread that lived in one person's mailbox. Nobody else could see what had been asked for, when, or whether a carrier had already replied.
Auditors asked why a given invoice was approved, and the answer sat in scattered email and in someone's memory of a rate confirmation. There was no record tying the invoice, the load, the documents and the decision together in one place.
What we built
OlDevs built an agent that runs the whole sequence: it reads the invoice, pulls the load and rate confirmation through the TMS API, compares accessorial charges line by line, requests missing paperwork from the carrier, and posts the approved entry to accounting. Anything outside tolerance stops and goes to a human queue with the discrepancy shown. Every step, tool call and document version is written to an append only log in PostgreSQL, so an auditor can replay exactly how a given invoice reached its outcome.
The agent extracts line items, references and totals from the invoice document, then pulls the matching load and rate confirmation through the TMS API. Matching is on identifiers in the systems of record rather than on a person recognising a number.
Each accessorial charge is compared against what the rate confirmation allows, with tolerances the billing team sets themselves. Agreement moves the invoice forward, and disagreement stops it with the specific line and the difference shown.
When a bill of lading or other paperwork is missing, the agent requests it from the carrier and tracks the state of that request. What has been asked for and what has come back is visible to the whole team rather than sitting in one mailbox.
Every step, tool call and document version is written to an append only log in PostgreSQL. Given an invoice, an auditor can walk the exact sequence that led to its outcome, including which document version each check was made against.
Process
Settlement walkthrough with the billing team
We sat with the three people doing the work and wrote down the real sequence, including the judgement calls and the shortcuts that never appeared in any written procedure.
Extraction and matching prototype
Invoice reading and TMS matching were built first and measured against invoices already settled by hand, so accuracy was compared with a known answer rather than estimated.
Tolerances and the exception queue
The billing team set the tolerances themselves, and we built the queue that receives anything outside them with the offending line and the difference shown in context.
Accounting posting and audit logging
Approved entries were wired through to accounting, with each step, tool call and document version recorded in the append only log as it happened rather than afterwards.
Ongoing tuning since 2025
The engagement continues: exception patterns are reviewed, tolerances adjusted and new carrier document formats added as the shipper base and its paperwork change.
Stack
Agent runtime
Document handling
Integrations
Data and audit
Delivery and operations
4
Systems joined end to end
−72%
Manual handling per invoice
+29%
Invoices cleared same day
Outcomes
Invoice intake, the transport management system, the carrier document channel and accounting were joined, recorded as 4 Systems joined end to end, so no one moves data between them by hand.
Manual handling per invoice dropped, recorded as −72% Manual handling per invoice, because the routine sequence runs without a person and only exceptions reach one.
Same day clearance improved, recorded as +29% Invoices cleared same day, and the backlog stopped being a function of how many hours the team could give it.
When an auditor asks why an invoice was approved, the team can replay the whole trail, including which version of each document the checks were run against.
In their words
Our billing team now looks at the exceptions instead of every invoice, and when an auditor asks how one was approved we can show them the whole trail.
Controller, third party logistics provider
Logistics and transportation
FAQ
It stops. Anything outside the tolerances the billing team set is held and sent to a human queue with the specific line and the difference shown, rather than being approved on a best guess. The agent never resolves a disagreement about money on its own.
Yes. Every step, tool call and document version is written to an append only log in PostgreSQL, so a given invoice can be replayed from receipt to posting. That includes which version of the rate confirmation and bill of lading each check was made against.
The agent reads loads and rate confirmations through the TMS API and posts approved entries to accounting, so what matters is that both expose an API or a supported integration path. We assess that in discovery and build the connectors as part of the engagement.
Extraction is validated against a schema, so a document that does not yield the fields required is routed to a person rather than guessed at. New carrier formats are added as they appear, which is part of why this engagement has continued rather than ending at launch.
We begin with a walkthrough of how your team settles invoices today, including the judgement calls that are not written down anywhere, then prototype extraction and matching against invoices you have already settled so accuracy is measurable. Request a quote to start that conversation.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.