Return-to-Sender (RTS)
Return-to-Sender (RTS) refers to a shipment that could not be delivered to the recipient and is therefore sent back to the sender by the carrier – for example due to a wrong address, a recipient who could not be reached, a refused acceptance or an expired storage period. Unlike a classic customer return, the return is not initiated by the buyer but arises unintentionally during the delivery process.
Return-to-Sender (RTS) refers in shipping to a parcel that could not be delivered to the recipient and is therefore transported back to the sender by the carrier. Typical triggers are a wrong or incomplete delivery address, a recipient repeatedly not reached, a refused acceptance, an expired storage period at the branch or parcel locker, or insufficient customs data on cross-border shipments. The term comes from the English-speaking shipping world and literally means "back to the sender".
The decisive characteristic of an RTS shipment is that the return is not wanted by the customer but arises unintentionally from the delivery process. This is what fundamentally distinguishes Return-to-Sender from a regular return, which the buyer actively initiates, for example because they do not like the goods. For the merchant, RTS is doubly expensive: they bear both the outbound and the return transport without having completed a sale, and they have to receive, inspect and restock the returning goods – a process that a properly connected ERP system can largely automate.
At a glance
- Undeliverable shipment that the carrier sends back to the sender
- Common causes: wrong address, recipient not reached, acceptance refused, storage period expired
- Unintentional and merchant-side – in contrast to the customer-initiated return
- Causes double freight without a completed sale
- Returning goods must be recorded in goods receipt and posted back to stock
What triggers a Return-to-Sender shipment?
Return-to-Sender always occurs when delivery ultimately fails and the carrier can no longer hold the shipment or is not allowed to. By far the most common cause is faulty address data: a transposed digit in the house number, a missing address suffix, a typo in the street or town. Such errors often arise as early as the order and are hard to correct after the fact once the parcel is already moving through the network.
Other classic triggers are the recipient repeatedly not being reached – whose shipment returns after several delivery attempts and an expired storage period at the branch or parcel locker – as well as an active refusal of acceptance at the door. International shipments add another group: missing or incorrect customs documents, unpaid import duties, or goods that may not be imported into the destination country at all. In all these cases the only option left for the carrier is the way back to the sender.
RTS as a fraud and delivery indicator
A conspicuously high RTS rate for individual customers or regions is a warning sign. It can point to systematically wrong address details, to delivery problems with a particular carrier in an area, or – with cash on delivery and invoice purchase – to fraudulent orders. Those who record and evaluate RTS cases cleanly in the ERP spot such patterns early and can counteract them, for example through address validation at checkout or a change of carrier.
How the Return-to-Sender process works
If delivery fails, the carrier documents the reason with a status code in the tracking – for example "recipient not reached" or "address invalid". Once the agreed delivery and storage periods have expired, the shipment is given an RTS status and put on its way back. The sender sees this change in the tracking and then physically receives the goods back into goods receipt.
From here the actual work begins for the merchant. The returned parcel has to be identified, assigned to the original order and opened. The goods are checked for completeness and condition and then posted back into available stock. In parallel, the commercial transaction has to be resolved: if payment has already been made, a refund is usually due; with invoice purchase the receivable is cancelled. Only when goods and document are back in agreement is the RTS case closed.
Return-to-Sender (RTS) in the ERP system
In an integrated inventory management system, RTS is not a special case handled manually but a defined process. Via the interface to the carrier, the ERP receives the shipment statuses, so that an RTS status automatically becomes visible on the order. When the parcel arrives, it can be unambiguously assigned via the tracking number or the order reference – manual searching through a stack of paper is no longer needed.
The returning goods are scanned in goods receipt and posted back to stock, whereby the system can distinguish between resalable A-grade goods and goods requiring inspection. The ERP then triggers the commercial follow-up: refund or cancellation, updating the customer master data and – in repeated cases – a note flagging problematic addresses. Because the same building blocks also serve returns management, customer-initiated returns and RTS shipments often run through the same reverse process but are evaluated separately by reason.
RTS rate as a metric
The RTS rate – the share of returned shipments among all dispatched ones – is a meaningful logistics metric. It makes the cost of undeliverable parcels visible and can be broken down by carrier, region, payment method or destination country. A good ERP collects it automatically from the shipment statuses and thus makes optimisation potential measurable, for example the effect of address validation in the ordering process.
Distinction: RTS, return and undeliverable
Return-to-Sender is easily confused with the classic return, because both generate goods returns and run through similar processes in the ERP. The difference lies in the trigger: a return is initiated by the customer, who actively sends back goods they have already received – for example under the right of withdrawal. RTS, by contrast, arises unintentionally before the goods have even reached the recipient, and is triggered by the carrier.
In English shipping jargon, RTS often appears alongside the term "undeliverable". Undeliverable describes the state of the shipment, Return-to-Sender the resulting action – the transport back to the sender. Not every undeliverable shipment immediately becomes RTS: some are stored temporarily, re-addressed or redirected to a parcel locker. Only when delivery is no longer possible does the RTS mechanism take effect. To be distinguished from both is the lost or damaged shipment, which does not return but is settled through a claim with the carrier.
DACH specifics and costs
In the DACH region, the terms and conditions of the major parcel services – DHL, DPD, GLS, Hermes, UPS as well as the Austrian and Swiss postal services – govern how many delivery attempts are made, how long a shipment stays at the branch or parcel locker, and when it returns as RTS. The return is usually chargeable: the sender pays not only for the outbound shipment but also for the return freight, sometimes plus a handling fee. For merchants with high shipment volumes, this adds up to a noticeable block of costs.
A special case is cross-border shipping to Switzerland, which is not part of the EU customs territory. Missing or incorrect customs documents lead to Return-to-Sender particularly often here, and the return is more complex and expensive than within the EU because of the renewed customs clearance. The most effective countermeasure lies before dispatch: an address and completeness check at checkout, well-maintained customer master data and – in international business – complete customs data. Every avoided RTS case saves double freight and manual rework, which is why clean data quality in the ERP pays off directly here.
Example
Example: fashion retailer with a high RTS rate at parcel lockers
An online clothing retailer found that around three percent of its shipments came back as Return-to-Sender – an above-average number of them on deliveries to parcel lockers. Because the returns until then only showed up as "parcel back" in the warehouse, with no link to the order, staff spent a lot of time on assignment and manual refunds. The true scale of the problem was not even visible in the figures.
After connecting the carrier to the ERP, the retailer now receives the shipment statuses automatically. RTS cases are flagged on the order, returning parcels are instantly assigned in goods receipt via the tracking number, the goods are posted back to stock and the refund is triggered. An analysis of the RTS rate by delivery type revealed that many customers had stored an outdated post number when selecting the parcel locker. An additional validation at checkout reduced the rate significantly within a few months – and with it the double-freight costs.
Frequently asked questions
Related services
Questions about Return-to-Sender (RTS) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.