Returns are not deliveries in reverse: what breaks when you automate them

The credit note goes out before anyone opens the box

Most companies automate the way out and improvise the way back. Orders, delivery notes, invoices and carrier bookings run on interfaces. Returns run on a shared mailbox, a corner of the warehouse everyone calls "the pile", and one person who remembers which pallet belongs to which customer.

A lab and practice supplier we worked with had built the return path as a mirror image of the outbound one. Customer fills in a form, warehouse scans the paperwork at goods-in, the automation issues the credit note and books the quantity back into stock. Two steps, both technically clean.

In March a hospital sent back fourteen cartons of reagents. The form said "ordered by mistake". The automation issued a credit note for 4,180 euros and put 336 units back into available stock. Three days later, 90 of them shipped to a different customer.

The cartons had spent two weeks on a ward next to a window. The label said two to eight degrees. Nobody opened them before the money went out, and nobody blocked the stock before it was sold again. It surfaced when the receiving lab asked why the batch number on their delivery note belonged to a shipment three weeks older than the delivery date.

Eleven days of recovery work followed, plus a conversation with the hospital's quality team and a note in their supplier record. The goods were the cheap part.

A return is its own object with its own clock

The mistake sits in the data model. Returns get built as a negative order or a reversed delivery. Quantity times minus one, same article, same customer, done.

A delivery has two states worth tracking: in transit and arrived. A return has five, and each one can take days. Announced, or not. Arrived. Inspected, physically, by someone who opens the carton. Decided, meaning somebody rules on what happens to the goods and what the customer gets. Booked, in stock and in accounting.

Collapse those five into one step and they do not disappear. They move out of the system and into people's heads, where they work surprisingly well until someone is off sick or a hospital asks where its money is.

There is a second difference that matters more than it sounds. On the way out, your system knows everything: what is in the box, what it cost, when it left. On the way back, the information arrives from outside, incomplete, often wrong, sometimes not at all. A pallet at the gate is just a pallet.

Nobody announces a B2B return

The clean version starts with an announcement. Customer registers the return, gets a number, sticks it on the carton, goods-in scans it.

That works in consumer retail because without a label there is no return. In B2B it works far less often, for reasons that have nothing to do with software. The driver is already in the yard, so he takes the pallet with him. In hospitals, the ward sending goods back is not the department that ordered them. The ward has no order number and no delivery note. It has a carton.

So a meaningful share of returns is never announced, and at some customers that share is the majority. An automation that requires a return number handles half the volume and reports no errors on the rest, because the rest never reaches it.

We build the opposite assumption. The process expects goods to arrive without paperwork and opens a return case in the warehouse: photo, article, quantity, customer if identifiable. A case with gaps beats no case at all, because it has a number, a date, and a place on a list.

Matching, which is where the manual work starts

Linking a return to the original delivery sounds trivial. It is the single biggest source of clarification work we see.

Customers quote the number they can see. Sometimes that is the invoice, sometimes the delivery note, often their own purchase order, and in hospitals frequently an internal requisition number that does not exist anywhere in your system. An automation that searches only for order numbers finds nothing and parks the case.

Then there is the same article across several deliveries. The hospital ordered size M gloves four times this quarter, at three different prices, from two batches. Eighty units come back. Which delivery is that? Without a batch number on the outer packaging, the answer is commercial, not technical, and it needs to be a rule in the system rather than a habit in someone's head.

Add discontinued articles, where the carton carries a part number your item master retired in spring, and partial deliveries, where the customer quotes the first shipment because that is the one on the invoice. None of these are edge cases. Together they are most of your exceptions.

Quarantine stock, or you sell it twice

Booking returned goods straight into available stock is the most expensive single mistake in this whole process, and it is in nearly every self built automation.

The reason is convenience. The ERP interface offers a goods receipt, and a goods receipt writes to the main warehouse. Blocked stock usually exists in the system but is harder to reach over the API, and in testing the difference never shows, because nobody resells test goods two days later.

In production they do. The pallet sits unchecked in the aisle, the system considers it available, the next order picks it. Now you have two problems instead of one: possibly defective goods on their way to a customer, and no way to tell which units came from the return.

Returned goods belong in a separate location that does not count towards availability, and they move to the main warehouse only after inspection. If your ERP will not expose blocked stock over the interface, a physically separate rack with its own location number does the job. What does not work is a status flag that gets set correctly and then appears in no availability check.

With batch managed goods there is a second reason. If the returning batch is not captured on receipt, traceability breaks at exactly that point, and a recall aimed at that batch will not find the units you resold.

Timing the credit note

Whether the credit note fires on arrival or after inspection is the most consequential decision in the process. In most home grown workflows it fires on arrival, because that is when the automation happens to be running.

That means paying before knowing what for. At a three percent return rate with ten percent of returns unsellable, the loss is real and invisible, because it is spread across hundreds of small credit notes that nobody reviews as a group.

Sales will push back, and they are right to. Customers chase credit notes, and "still checking" stops being an answer after three weeks. The fix is a faster response rather than a faster payout. An acknowledgement with a case number on the day of goods receipt removes most of the pressure without booking a cent, and internal queries drop noticeably once customers can see their case exists.

Inspections that run long need a deadline and an escalation. A return with no decision after ten days belongs on a list someone reads in the morning. Without that list, the goods stay in quarantine and the blocked stock area turns into what it is in many warehouses: a rack full of items nobody can assign to anyone.

Which price ends up on the credit note

A credit note refers to an invoice, not to an article. The price has to come from the original document line, not from the item master.

Automations that pull the current sales price are more common than you would expect, and testing never catches it, because yesterday's price and today's price are the same in a test system. Production catches it when a contract expires, a price list rolls over in January, or a promotion applied. Then you refund too much or too little, and both cost you.

Volume breaks are the awkward case. A customer buys a hundred units at the hundred unit price and returns sixty. The remaining forty would never have qualified. Do you recalculate?

That is a commercial decision between sales and finance, and it has to be made before anyone configures anything, because otherwise the automation picks an answer and nobody knows which one. Most companies we work with decide not to recalculate below a certain value. That is a perfectly good rule. It just has to be written down. The same goes for freight, small order fees and packaging charges: refunded pro rata, not at all, or only when the error was yours.

Complaint, return, exchange: three things, one form

Three different situations arrive through the same mailbox and behave nothing alike.

With an actual return, goods come back and the customer wants money. With a complaint, nothing comes back at all: a line was missing, a damaged carton was disposed of on site, a device does not work. And with an exchange, a replacement ships while the old part is supposed to come back, sometimes in that order, sometimes not.

An automation waiting for a goods receipt scan will wait forever on the second one. And customers tick "return" on the form because it is the only word they know, while meaning a replacement.

Two questions at the start separate them: does anything come back, and do you want goods or money. Everything downstream can branch on those answers. Exchanges need one more rule, a deadline with a consequence. If the old part has not arrived in fourteen days, it gets invoiced. Without that, you accumulate a list of open exchanges nobody ever clears, because chasing each one costs more than the part is worth.

The supplier side, where the money actually leaks

When the fault is not yours, the process does not end with the customer's credit note. Transport damage, a quality defect or a wrong batch goes back to the manufacturer, and that second path is missing from almost every automation we review.

It runs on someone else's rules. The supplier issues their own return number and refuses delivery without it. They often want photos within a fixed window, sometimes 48 hours for transport damage. Their claim period typically runs thirty days from their invoice date, not from the day your customer complained.

The arithmetic is simple. Credit the customer, miss the supplier deadline, and you carry the goods yourself. For a company handling a few hundred supplier claims a year that adds up to a number which pays for the entire rebuild, and it never appears in any report because it posts as ordinary stock write off.

The case itself needs very little: a link to the customer return, the supplier reference, the supplier invoice date, a deadline calculated from it, and a status.

What we build instead

The return is a first class object with its own number, a link to delivery, line and batch where available, a state, a created date and a due date.

States are explicit and few: registered, arrived, inspected, decided, closed. Bookings hang off the transitions rather than off goods receipt. Into quarantine on arrival, into main stock on "sellable", credit note on "decided".

Anything ambiguous goes to a queue instead of an error log. No match found, quantity exceeds the delivery, article not in the master, product group excluded from returns. The automation clears the seventy to eighty percent that are unambiguous, and the rest sit sorted in one place instead of scattered across three mailboxes.

Return reasons get captured from a short list, never as free text. Six or seven options are enough: ordered in error, shipped in error, transport damage, quality defect, late delivery, over ordered, other with a mandatory comment. Nobody parses free text, and a list can be counted.

Those counts are the real return on the work. In one project, forty percent of returns for a specific article came back as "ordered in error". The catalogue showed the article in single units while it shipped in packs of ten, so customers ordered ten times what they needed. The fault was in the catalogue, not the warehouse, and it cost about two working days a month plus freight in both directions.

How to check yours this week

Walk into the warehouse and look at the area where returned goods sit. Take the five oldest pallets and ask how long they have been there. If the answer comes in months, you have storage rather than a process.

Then pull the last twenty credit notes and check when each was created. If the credit note date matches the goods receipt date, you are paying without inspecting. If more than three weeks separate them, you have a customer communication problem you probably already know about.

One more, if you want the real number: ask the internal sales team how many hours a week returns take. It is in no report, but somebody knows it to the half hour, and it is almost always higher than finance assumes.