Carrier data is the missing half of most reconciliation setups. Pulling LRs and PODs automatically is unglamorous work that closes a surprising number of disputes.
Most brands have decent visibility of two things: what they ordered and what the channel eventually received. The bit in between — the part where goods are on a truck — is usually a black box held in someone else's portal.
That gap is where a lot of unwinnable disputes come from. Not because the brand was wrong, but because it could not prove it was right.
Three documents matter, and none of them are in your ERP by default.
The manifest lists what was handed over: carton count, weight, destination. It is the moment custody transfers, and it is the strongest evidence you have that goods left complete.
The lorry receipt (LR) is the carrier's acknowledgement. It carries the reference number that everything downstream will be tracked against.
The proof of delivery (POD) confirms arrival: date, time, receiving signature, and any remark about damage or short delivery noted at the gate.
Pull those three in and the dispatch-to-GRN window stops being a black box. A short receipt now has a location.
Carrier data is genuinely awkward to collect, and it is worth being clear about why rather than pretending it is a solved problem.
Every carrier exposes data differently. Some have clean APIs. Some have a portal and a CSV export. Some send a daily email with an attachment. Aggregators like ClickPost help by normalising several carriers behind one interface, but most brands still have at least one partner sitting outside whatever standard they have chosen.
There is also a matching problem. The carrier knows an LR number. Your ERP knows a PO and an SO. Nothing in the carrier's system references your purchase order, so the link has to be reconstructed — usually via the invoice number or the dispatch reference, and occasionally via a fuzzy match on destination and date when the reference is missing.
This is exactly the sort of work that is tedious for a person and trivial for a workflow, which is why it tends to get skipped until someone loses a large dispute.
A delivery reconciliation workflow runs in four steps.
Step four is where the value actually lands. The point of assembling the evidence is not the report; it is that somebody can raise a claim the same week rather than reconstructing history a month later.
Two things are worth watching, and they are not the same.
Delays are predictions. A consignment that has not scanned in 48 hours on a lane where the observed P90 is 3 days is not yet late, but it is drifting. Flagging it early gives you a chance to inform the channel before the SLA breaks.
Shortfalls are facts. A POD carton count below the manifest is a dispute you can open immediately, with documentation, while the carrier's own records are still fresh.
Most teams only build the second and then wonder why they are always reacting. Fastrack cut their response time on operational exceptions by 75% by moving detection out of manual checking and into automated monitoring — the same pattern applies here, where the cost of noticing late is usually a closed dispute window.
Carrier data is not a standalone project. It is the fourth document in material-flow matching, and it is what makes short-supply diagnosis possible at all.
It also feeds dispatch decisions. Once you are collecting dispatch-to-POD timestamps per lane, you have observed turnaround times — which is the input for choosing carriers on evidence rather than on habit.
That is the argument for doing this even if disputes are not your biggest pain today. The data has more than one use, and it only accumulates if you start collecting it.
Carrier systems reference an LR number, not your PO. The link is reconstructed using the dispatch or invoice reference passed at manifest creation, with a fallback match on destination, date window and carton count where the reference is missing.
Portal exports and emailed reports can be ingested through an RPA step or email parsing, and aggregators such as ClickPost normalise several carriers behind a single interface. A REST or GraphQL step covers anything else.
A delay alert is predictive — a consignment drifting past its expected scan pattern, flagged before the SLA breaks. A shortfall alert is factual — a POD quantity below the manifest, which is an immediately actionable dispute.
Delhivery, Blue Dart, DTDC, ClickPost and Aramex — pre-built connectors that pull manifests, LRs and PODs into your reconciliation.
Book a demo →Scoring couriers on observed P90 delivery time and landed cost, so dispatch stops running on habit.
What changes operationally when you cross into the GCC — documentation, VAT, Aramex, and reconciling in more than one currency.
A finance view: why the close is too late to find problems, and what a live outstanding position actually requires.