Royal Mail Lost Parcel Compensation Claim Automation: Xero & Linnworks Case Study

Case Study Highlights

• Systems: Xero for purchase orders, Linnworks for orders, products and Royal Mail tracking, with an AI document-parsing layer across both

• Problem: Royal Mail pays compensation on actual loss, not retail price, so every claim needs the original purchase order for every item in the parcel. Finding one meant opening purchase orders in Xero and reading them, one at a time. Twenty minutes a claim, sixteen lost parcels a week

• Solution: Every purchase order parsed and indexed, so support enters an order ID and gets a claim-ready bundle of evidence back

• Result: Twenty minutes a claim down to around two, roughly 240 hours a year handed back to the support team, and hundreds of pounds a month recovered in Royal Mail compensation that used to go unclaimed

Filing a reimbursement claim with Royal Mail shouldn’t take 20 minutes. But for one of our clients, that’s exactly how long it took every single time a package went missing.

The 20 minutes turned out to be the smaller problem.

The support team knew the drill. A customer reports a lost parcel. To file a Royal Mail compensation claim, you need evidence of value: a purchase invoice showing what the item actually cost you to buy or manufacture. Royal Mail pays out on “actual loss”, not the retail price.

So every claim is really an insurance claim, and like any insurance claim it dies without the receipt. That means digging up the original purchase order for every item in the shipment.

Sounds simple enough until you actually try it.

The manual Royal Mail lost parcel compensation claim nightmare

Here’s what the process looked like:

1. Find the tracking number for the lost package
2. Look up the order in Linnworks to see what products were in it
3. Figure out the SKU or barcode for each product
4. Go into Xero and start hunting through purchase orders
5. Open each PO and pray it’s not a scanned photocopy

Step four was where things fell apart. Xero’s search is not built for this. You can’t search inside PDF attachments, and the metadata on purchase orders rarely had the detail the team needed.

So they’d scroll through lists of POs, open them one by one, and visually scan the contents looking for a matching SKU or product name. It’s the same kind of pain we saw with a client whose sales team had to leave Tradegecko to manually check warehouse stock before placing every order.

Most POs were proper digital documents. A decent number were scans and photocopies that suppliers had uploaded as PDFs, and a scanned PO is just a picture of words.

Xero can see the picture. It cannot read the words. So the only way to check one was to open it and read it yourself.

Multiply that by sixteen lost packages a week and you’ve got a team spending a serious chunk of their time on work that feels like the computer should already be doing it. Nobody enjoys being the computer.

They brought the problem to us at SaaS Glue.

How we built the AI-powered Royal Mail compensation claim automation system

We broke the problem into two parts: making the data searchable, and making the search instant.

The stack, for anyone holding this up against their own setup:

• Xero, for purchase orders. Pulled by API, and the source of every cost figure in a claim.
• Linnworks, for orders, products and Royal Mail tracking statuses.
• An AI parsing layer that turns scanned and photographed POs into structured line items.
• A lookup tool for the support team. Order ID in, zip of evidence out.
• Grafana and Rollbar, for match rates and errors.

The PO processing pipeline pulls every purchase order PDF out of Xero and runs it through an AI parsing layer. Blurry scan of a photocopied invoice? Crooked image of a supplier receipt? Doesn’t matter. The system reads the document, extracts line items, quantities, and prices, then builds a searchable index of every product the client has ever purchased. Watching it pull clean line items off a crooked photo of a photocopy does not get old!

If your purchase orders are already clean digital documents with a barcode on every line, you don’t need any of this. A text search would find them. The AI layer exists because enough of this client’s POs were photographs of a piece of paper to make a text search useless.

The parsing was never the hard part. The matching was.

Each item gets cross-matched against the Linnworks catalog. When a PO has a barcode or SKU that matches, the link is straightforward.

But plenty of POs don’t include barcodes at all, and suppliers often use their own SKUs that have nothing to do with the client’s. For those cases, the system falls back to AI-powered name matching, comparing product descriptions from the PO against the Linnworks catalog to find the right item. The end result is the same: a clean link between “this product in an order” and “this is what we paid for it, and here’s the PO to prove it.”

It didn’t work on everything. One supplier the client had stopped using years ago left behind POs with no barcodes and product names that matched nothing in Linnworks. No amount of parsing fixed those, so we skipped them.

The AI parsing works because the integration does the unglamorous part first. That’s the readiness pattern that decides whether AI projects deliver or stall.

The front end is dead simple. Support enters an order ID, the system pulls every relevant purchase order, bundles them into a zip file, and hands it over. What used to take 20 minutes of tab-hopping now takes about ten seconds.

Ten seconds because we index every PO up front rather than parsing on demand. Running a stack of PDFs through an AI parser takes real time, and a support agent with a customer on the line does not have real time. Doing the expensive work in advance is the whole reason the lookup feels instant.

Automatically finding unclaimed Royal Mail lost parcels

Once the system was running, it showed us something nobody had gone looking for. A lot of lost packages were never being claimed at all. Not rejected. Never filed.

The whole claims process had one trigger, and it was a customer getting annoyed enough to email. Call it complaint-driven recovery: you only ever get back what somebody else notices you lost.

But packages go missing whether the customer notices or not, and Royal Mail will pay out either way, as long as you file in time.

So we built a lost package tracking pipeline. It monitors Royal Mail tracking statuses across all outbound shipments and flags anything showing signs of being lost: parcels stuck in transit past expected delivery windows, packages with no scan activity for days. When it spots one, it automatically pulls the matching purchase orders from the index.

Every two weeks the system compiles a report of unclaimed lost parcels with the PO evidence already attached. The support team reviews the list and submits the Royal Mail reimbursement claims in bulk.

Fortnightly, not instant, and that was deliberate. Claims are not an emergency as long as you file inside Royal Mail’s window, and a report that lands every morning becomes a report nobody opens. Batching them means the team does claims once, in one sitting, instead of being interrupted sixteen times a week.

What used to slip through the cracks now gets caught automatically.

Where the automation stops

Royal Mail has no API for filing a claim. The form on their website is the only way in, and somebody has to sit in front of it and fill it.

So we drew the line there on purpose. The system does everything up to the form: spots the parcel, finds the POs, bundles the evidence, hands it over. The last two minutes are a human.

That is not the version anyone draws on a whiteboard. But automating a form you don’t own is a different kind of promise. It works fine right up until the vendor moves a button, and then it stops working quietly, which is the worst way for an integration to fail. We would rather hand a support agent a finished bundle and let them click submit than build something that silently stops claiming money while everyone assumes it is still running.

After this shipped we talked about closing that last gap with a browser bot, filling the Royal Mail form straight from the evidence bundle. It is a real option and it may still get built. It also needs monitoring of its own, and a person whose job is to look at what it failed on.

Ensuring long-term stability

A system like this is only useful if you can trust the data. Suppliers change their invoice formats, product names drift, new items get added.

Monitoring it is like keeping a smoke alarm working. All the value is in the one day it goes off, which is exactly why nobody notices the battery died eight months ago.

If a PO suddenly starts failing to parse or match, we need to know about it before the support team does.

We set up a Grafana dashboard that tracks PO processing in real time: how many are being parsed, how many line items match successfully, and the rate of unmatched lines. We agreed with the client on a 2% failure rate as the acceptable threshold. (Every integration has a number like this. On most of them it lives in somebody’s head rather than on a dashboard.)

If the unmatched rate climbs above that, it usually means a supplier changed their invoice layout or started using different product descriptions, and we can catch it early.

Errors and exceptions get logged to Rollbar, so if something breaks we get alerted straight away rather than waiting for someone to notice missing data.

Results: 240 hours saved + recovered revenue

Here’s the math. About 16 lost packages a week, each one taking 20 minutes to process. With the new system the lookup takes about 10 seconds and the whole claim, forms included, takes around 2 minutes. That’s roughly 240 hours a year given back to the support team.

That figure is arithmetic, not a stopwatch study. We measured the lookup. The 20 minutes is the team’s own number from before we started, so if they were rounding up, so are we.

On top of that, the client started recovering hundreds of pounds every month in Royal Mail compensation that previously went unclaimed, simply because nobody had the time to file. That money had been sitting there the whole time, waiting for somebody to complain. And the person who used to spend half their afternoon hunting through Xero for purchase orders? They now spend that time on work that actually matters.

The Linnworks and Xero integration runs quietly in the background. New purchase orders get indexed as they come in, so the data is always current. The support team doesn’t think about the pipeline at all, they just use it.

Frequently Asked Questions – Royal Mail Claims Automation

Could this work with accounting software other than Xero?

Yes. The PO parsing doesn't care where the PDF comes from. We just need API access to pull the documents.

Could this work with an order management system other than Linnworks?

Yes. The system just needs a product catalog to match against. Whether that's Shopify, Sellercloud, Veeqo, Brightpearl, or anything else with an API, the approach is the same.

Did you run into problems with the PO data?

The only issue was a batch of very old POs from a supplier the client no longer works with. Those had missing barcodes and inconsistent product names that the system couldn't map to anything in Linnworks, so we skipped them. Every recent PO from active suppliers parsed and matched without trouble.

Why doesn't the system file the claim with Royal Mail automatically?

Royal Mail has no API for filing claims, so the form on their site is the only route and a person has to fill it in. The system does everything up to that point and hands over a finished evidence bundle. Automating the form itself with a browser bot is possible and we have discussed it, but it needs monitoring of its own, because a form automation breaks silently the moment the page changes.

How long did this take to build?

The core system (PO parsing, indexing, and the lookup UI) was up and running in a month.

What does it cost?

It depends on the data. Document parsing can be straightforward or it can get messy, and we won't know which until we see what you're working with. We start with a short discovery phase to evaluate the complexity, then quote either a fixed fee or an hourly rate depending on the job.

If parcels are going missing and nobody has the time to claim for them, that money is gone and nothing in your stack will tell you. Drop us a message and we’ll work out whether this is worth building for you.

You can also see more of our work or read our manifesto to understand how we approach these problems.