How to automate returns processing in a 3PL warehouse

Automating returns processing in a 3PL means the worker photographs the return label, an AI model reads it, and the system finds the open return or order the parcel belongs to. The worker scans each item out of the box, marks anything damaged, and the system books the result in the WMS and says where the goods go. Anything that cannot be matched with certainty goes to an exceptions shelf instead of a guess.

In the system I built for a Dutch 3PL fulfilment company, this runs on a handheld or phone at the returns bench, connected to ChannelDock. Below is how it works, and every edge case that showed up on the live bench.

What slows down returns processing in a 3PL?

A returned parcel rarely tells you whose it is. The label on the box is usually the return label, not the outbound one. A fulfilment warehouse with more than 300 sellers cannot rely on a packing slip being inside.

Before automation, a worker had to:

• read the name or order number off a creased label
• search the WMS portal by hand, often by customer name
• work out which seller the product belongs to
• decide which order line to receive, when several lines look the same
• type a note so the seller knows what came back

The tracking code is the most reliably printed thing on a label, and ChannelDock offers no tracking filter on orders. So the most readable field was useless for lookup. That one fact shaped the whole design.

How does an automated returns workflow work?

This is the flow the bench runs for every parcel:

1. Photograph the label. The worker takes one photo. If the model cannot read it, the screen asks for a retake with framing tips before anything else happens.
2. Read the label with AI. The model returns tracking code, order number, customer name, postal code and any product barcode as fixed JSON.
3. Repair what the camera misread. Barcodes are checked against their check digit. Only safe fixes are applied.
4. Look for a waiting return. Most returns were already announced on Bol or Amazon and sit as pending in ChannelDock.
5. Fall back to the order. If there is no return, find the order by order number or exact customer name.
6. Scan each item. Each scan ticks off one open line. Anything not scanned stays pending.
7. Mark damage with a photo. A rejected item needs a photo before the booking is accepted.
8. Book and verify. The system writes the result and reads it back to confirm it landed.
9. Say where the goods go. Accepted items go to their stock location. Rejected items go to the seller's own pallet or the general rejects shelf.
10. Leave a note for the seller. Customer name, tracking code and counts go into the return comment, one fact per line.

How does AI label reading work?

I use Gemini on Vertex AI with a fixed JSON schema. Every field is nullable, and the prompt tells the model to leave a field empty rather than guess. A wrong tracking code costs more than a missing one, because it resolves to somebody else's order.

On live tests the model read an angled, dimmed, blurred label correctly. It collapsed a spaced-out code like "3S R E T 8 8 4 2..." into one string without being asked. A photo of something that was not a label came back with confidence 0 and every field empty.

Speed matters at a bench. The service asks one model first. If it has not answered by its normal worst case, a second model is asked as well and the first answer wins. A rate-limit error starts the next model at once. A rejected photo ends the race, because no other model will do better with the same image.

Which misreads can be repaired safely?

Cameras confuse 0 and O, 1 and I, 5 and S, 8 and B. A product barcode is digits only, so a letter inside one is certainly a misread and can be swapped back. EAN-13 has a check digit, so a candidate fix can be verified with arithmetic.

What the system refuses to do matters more. It never repairs a digit read as another digit. On a real code with one wrong digit, that search found four valid barcodes: four different real products. It never corrects a carrier tracking code either, because there is no check digit to verify against.

It does know two carrier quirks. DHL eCommerce return codes add an R after the prefix, so the system also searches without it. Some labels print a check character the stored return does not have, so a match without the last character is tried as well.

Why should you match to the existing return first?

On marketplaces, the customer requests the return, the channel syncs it as pending, and the parcel arrives later. When I checked live data, every return in the account came from a channel, and the newest page held 50 unhandled pending returns created that same day.

So the normal action is to receive an existing return, not create one. Creating on scan puts a duplicate next to the channel's own record.

The return label's tracking code is the key, and the API cannot search by it. The service keeps its own index of open returns by carrier code: the newest pages refresh every five minutes, the last twelve days every few hours, and a background mirror holds every return ever read. Before the mirror existed, two parcels whose customers announced returns in July and August were booked a second time in September.

Which edge cases break a returns automation?

These all came from the live bench, not from planning.

Unreadable label or no order number

The worker retakes the photo first. If only a tracking code is left, the parcel goes to the exceptions shelf.

No matching order

The parcel can still be booked by scanning the products, which identifies the seller. A return is then created against the seller. These manual bookings are audited daily.

Several orders or returns for one customer

One customer can have two orders for the same goods. The system prefers the order it found from the label itself, then checks name, billing name, email, postal code and house number.

The same product sold to many customers

One seller sold the same four-product set to many people. The bench once offered another customer's return because the products matched. Now a name on the label that contradicts the order stops the booking. Silence does not: a label with no name is not treated as a mismatch.

Repeated barcodes

One return had eight lines with one barcode repeated four times. Each scan ticks the next open line, not the first one again. A scan beyond the expected count is called out, not ignored.

Bundles and packs

A three-month pack can be stored as one line for the pack plus a line of three boxes. The WMS counts the return against the pack. The rule is whole packs only, one condition per pack. Two boxes of three, or a pack with one damaged box, goes to a person.

Barcode in the wrong field

Some sellers keep their own code in the EAN field and the printed barcode in SKU. The lookup checks EAN, SKU and product reference, and always books using the code the WMS knows.

Duplicate returns

When a parcel booked manually shares a carrier code with a return that is still open, the seller now has two returns. The WMS has no delete, so the system lists these pairs for a person to reconcile.

Damaged items

The box is open on the bench exactly once. A rejection is refused on the server until a damage photo exists, so a seller who disputes it has evidence.

Seller-specific instructions

Admins attach instructions to product barcodes, for example "check the seal, see the SOP". The bench shows them the moment the product is scanned and records that the worker acknowledged it. Changes reach the bench within a minute.

No stock location

About 8% of returned barcodes had no location. The bench asks once, stores the answer, and never asks again for that product.

What belongs on the exceptions shelf?

Two things only: parcels the worker gave up on, and parcels the WMS refused. In one audit, 40 of the 50 parcels on the shelf had already been booked, because a record was filed the moment the screen said "no order found". Three more were the same box photographed twice. Shelf entries are now merged by carrier code or order number. Never by customer name: two boxes from one customer are two parcels.

What should you measure?

The service counts events in memory and writes one document per day, so the dashboard costs almost nothing to run. I track:

• parcels scanned per day and per hour
• seconds per label read, in buckets
• minutes from label photo to booked
• share matched automatically versus manual or exception
• bookings later found on the wrong order
• rejections per seller

The mistake audit is the one I would not skip. It found a few dozen wrong bookings in the first two weeks. Each finding became a rule that now stops the bench.

Should you build or buy a returns automation?

Buy if your WMS has a returns module that searches by return tracking code and handles your marketplaces. Build if it does not, or if your sellers' data is messy in the ways above. Most of my work was not the AI. It was making the system refuse to guess.

Returns automation checklist

• Read labels into fixed fields, empty instead of guessed
• Verify barcodes with check digits before lookup
• Match to the announced marketplace return before creating one
• Index open returns by carrier code, including old ones
• Handle repeated barcodes, packs and split lines
• Leave unscanned items pending
• Require a photo for every rejection
• Show seller instructions on scan
• Audit bookings daily for wrong customer or duplicates

This is part of the logistics automation services I offer to 3PLs. See the full AI returns scanner case study and the wider 3PL fulfilment operations platform it runs inside. If returns are only half your problem, read how I automate carrier claims and parcel investigations.

Want this on your returns bench? Get in touch and tell me what your current process looks like.