Automatically Capture RTS Returns in Xentral | Guide

What Is Return-to-Sender (RTS)? The Short Answer

Return-to-Sender (RTS) = packages that come back to the sender because they could not be delivered. Not a customer return, but a delivery failure (wrong address, recipient unknown, delivery refused).

The problem: RTS shipments are not automatically detected in Xentral. The return has to be recorded manually – often only after the customer complains.

The solution: Webhook-based tracking monitoring that automatically detects RTS events and creates returns in Xentral.

---

It's Monday morning. You open Xentral and see 15 open orders that supposedly have been delivered. But yesterday a message came in from customer service: "Customer XY never received their package." You check the tracking – "Undeliverable, return to sender." The package has been on its way back to you for four days already, but your system still shows "shipped."

Sound familiar? You're not alone. Return-to-Sender shipments – RTS for short – are one of the hidden problems in e-commerce that a surprisingly large number of merchants handle manually. In this article, I'll explain why that is costly, what an automated solution looks like, and when the investment pays off.

The Hidden Problem: RTS Shipments

Return-to-Sender sounds like a fringe issue. But the numbers tell a different story.

Depending on industry, target audience, and shipping region, the RTS rate is between two and five percent of all shipments. With 1,000 packages a month, that's 20 to 50 shipments coming back undeliverable. With 10,000 packages, we're talking about 200 to 500 units.

The problem isn't just the sheer volume. The problem is that these shipments usually only come to light when it's too late – when the customer complains, when the package turns up again at the warehouse two weeks later, or when discrepancies appear during the monthly inventory count.

The consequences are wide-ranging: customer service spends time investigating. Inventory levels are off because returns weren't recorded. Items get sold as available even though they're actually still on their way back. And accounting has open items that never get closed. You can find more on returns processing in Xentral at the Xentral Help Center.

What Exactly Is Return-to-Sender?

Before we continue, an important distinction: RTS shipments are not regular customer returns.

With a customer return, the customer actively decides to send the goods back. They request a return label, pack the package, and ship it back. That is a planned, documented process.

With an RTS shipment, on the other hand, the package comes back without the customer ever having received it. The most common reasons are an incorrect or incomplete address, the recipient has moved and is unknown at the address, delivery was refused, repeated delivery attempts failed, or the package could not be picked up at a service point and was returned after the storage period expired.

The critical difference: with a customer return, you know about it. With an RTS shipment, you often only find out when the package shows up at your warehouse again – or when the customer gets in touch.

Why Manual Tracking Doesn't Scale

The obvious solution is: go through all open shipments every day and check the tracking status. Some merchants actually do this. But this approach has fundamental problems.

First, the time investment. With 100 open shipments and an average check time of 30 seconds per shipment, you're spending 50 minutes a day on tracking alone. With 500 open shipments, that's over four hours. Every single day.

Then there's the error rate. Manual checking is monotonous. People make mistakes, overlook entries, get distracted. An RTS status reported by the carrier at 6 a.m. is easy to miss if you're checking at 10 a.m. and the tracking has since switched to "In transit back to sender."

Finally, the delay. Even if you check conscientiously – you check at most once a day. But the RTS status gets set at some point during the day or night. On average, 12 to 24 hours pass before you find out. By that time, customer service may have already received an inquiry.

The truth is: manual RTS tracking is a stopgap for small volumes. As soon as you have more than a few hundred shipments a month, it becomes a bottleneck.

Expert insight: "With 1,000 packages a month and an RTS rate of 3%, that's 30 returns that need to be tracked manually. With automatic detection, you save 5–10 hours per month – and customer service is informed straight away." — Fabian, XentralExperte.at

How Does Automatic RTS Detection Work?

The good news: most major shipping carriers now offer webhooks or push notifications. This means the carrier contacts you when a status changes – not the other way around.

A webhook works roughly like this: you register a URL with the carrier. Every time the tracking status of one of your shipments changes, the carrier sends a message to that URL. The message contains the tracking number, the new status, and often additional details such as the reason for non-delivery.

With that, you have all the building blocks for automatic RTS detection. A system that receives and processes these webhooks, stores all shipment information in a database, recognizes RTS-relevant status codes (each carrier uses different codes), and automatically creates a return in Xentral.

The result: seconds after the carrier reports the RTS status, you know about it. Automatically, reliably, 24 hours a day, seven days a week.

How Automatic Return Creation Works

Let me describe the process concretely, as I implement it for my clients.

Everything starts when a package leaves the warehouse. The shipment is posted in Xentral and the tracking number is recorded – this already happens anyway. What's new is that this tracking number is additionally transmitted to the RTS detection system.

From that moment on, the system monitors the shipping status. Every status change reported by the carrier is received and evaluated. Most updates are uninteresting – "In Transit," "Out for Delivery," "Delivered." These are logged, but trigger no action.

Things get interesting when an RTS-relevant status arrives. This can look different depending on the carrier. With DHL, for example, these are codes such as "Undeliverable" or "Return to Sender." DPD uses different labels. The system must know all these variants and interpret them correctly.

When such a status is detected, the system automatically creates a return in Xentral. Several things are configured in the process: the return status, for example "RTS – expected"; the return reason, automatically populated based on the carrier code; and an internal note with the tracking details for later follow-up.

Optionally, an email notification can be sent simultaneously to the warehouse or customer service team. That way the team knows straight away and can proactively reach out to the customer if needed.

When the package then physically arrives at the warehouse, the return is already in the system. The warehouse checks the goods, processes the return, and the inventory is increased again. Everything documented, everything traceable.

Practical Example: Before and After

One of my clients runs an online shop for home textiles and ships around 3,000 packages a month, primarily via DHL and DPD. The RTS rate was around three percent – roughly 90 shipments per month.

Before automation, the process looked like this: every morning, a team member went through all shipments from the last 14 days whose tracking status was not "delivered." With around 200 to 300 open shipments, this took a good hour. RTS shipments were noted by hand and then manually entered as returns in Xentral. The average time from the carrier notification to the entry in Xentral: about two to three days.

The problem with this: during that time, customers whose packages were being returned as "undeliverable" would regularly get in touch. Customer service then had to research what had happened to the shipment – even though the information had theoretically been available at the carrier for days.

After automation, the process runs fully automatically. The time from the carrier notification to the return being created in Xentral: under one minute. The team member who previously spent an hour a day on tracking can now use that time for value-adding activities.

When RTS cases arise, customer service can immediately see that the package is coming back and proactively contact the customer: "We noticed that your package could not be delivered. Would you like us to reship it or cancel the order?" Customers respond well to that.

An additional bonus: the collected RTS data now enables analysis. Which regions have high RTS rates? Which products are affected more often? Which reasons are cited most frequently? These insights help reduce the RTS rate over the long term.

Which Carriers Are Supported

The good news is that all major carriers in the DACH region now offer webhook-based tracking.

DHL offers a comprehensive tracking API and webhook functionality. The integration is well documented and reliable. RTS statuses are clearly communicated, including the reason for non-delivery.

DPD also has a solid API with push notifications. The status codes differ from DHL, but all relevant RTS scenarios are covered.

GLS offers tracking updates via webhook. The granularity of information is sometimes slightly lower than with DHL or DPD, but it is sufficient for RTS detection.

Hermes has significantly improved its API in recent years. Webhook support is available and works reliably.

Austrian Post also offers tracking APIs for business customers. The integration requires a bit more effort, but it is feasible.

For special shipments such as freight or international carriers, it is necessary to check on a case-by-case basis what is possible. Most offer at least a tracking query, even if active push notifications are not always available.

When Automation Pays Off

The honest answer: not for everyone. Here is my assessment of when the investment makes sense.

With fewer than 500 shipments per month, the manual solution is often still manageable. The time investment is reasonable, and the error rate at small volumes is lower. The investment in an automated system may not pay off here.

With 500 to 2,000 shipments per month, it gets interesting. The daily tracking effort adds up to several hours per week. The RTS rate becomes noticeable – at three percent, that's 15 to 60 shipments per month. Here it is worth taking a closer look at the cost-benefit calculation.

With more than 2,000 shipments per month, automation is almost always economically sensible. The manual effort is significant, the error rate increases with volume, and the time savings quickly justify the investment.

Beyond sheer volume, other factors also play a role. A high RTS rate makes automation more attractive because the benefit is greater. If customer service frequently handles RTS-related inquiries, the indirect benefit from faster information availability is substantial. And if inventory accuracy is critical – for example with tight margins or just-in-time reordering – the timely recording of RTS returns is particularly valuable.

Common Concerns and How I Address Them

When I raise this topic with clients, I regularly hear similar concerns.

"That sounds complicated." – Understandable. Webhooks, APIs, carrier codes – it sounds technical. But you don't have to implement this yourself. You need someone who does it for you. In your day-to-day operations, little changes – except that RTS shipments suddenly appear automatically as returns.

"What about false positives?" – A fair question. No system is perfect. But the detection rate with a properly configured system is well above 99 percent. And false detections in both directions are possible: sometimes an RTS isn't detected, sometimes one is incorrectly detected. The latter is less problematic – you simply cancel the unnecessary return if the package was delivered after all.

"We use multiple carriers." – That's the norm, not the exception. The system is designed to support different carriers in parallel. Each carrier has its own status codes, but the system normalises these into a consistent format.

"We also ship internationally." – International shipments are more complex because multiple carriers are often involved. The handover points between carriers can delay or complicate RTS detection. Here it is necessary to check on a case-by-case basis what is feasible.

Conclusion and Next Steps

Return-to-Sender shipments are a hidden but costly problem in e-commerce. Manual tracking is time-consuming, error-prone, and doesn't scale. Automatic detection via carrier webhooks solves these problems.

The technology is mature. The carriers support it. The integration with Xentral is feasible. The question is not whether but when the investment pays off for you.

My recommendation: if you ship more than 500 packages a month and regularly spend time on RTS tracking, it's worth taking a closer look. Set aside an hour and note down how much effort currently goes into manual tracking. Then you'll know whether it makes sense to have a conversation.

---

Further Resources

• Xentral Help Center – Returns – Official documentation
• DHL Developer Portal – DHL API documentation
• DPD Interfaces – DPD API documentation

Related Articles

• Xentral Flows Automation Guide – Automating workflows
• Xentral Shopify Integration – Shop connection with tracking
• Xentral Costs & Pricing 2026 – Planning your investment

Next Steps

• Return-to-Sender Detection as an Add-On – Full details about the tool
• Automation with Xentral Flows – Further automation options
• Get in touch – Schedule a free initial consultation