How Business Central Handles Return Centers on Purchase Return Orders and Why It Might Surprise You
Returns have quietly become one of the biggest cost centers in modern operations. Retail and manufacturing were already struggling with growing return volumes. But over the last few years something major has changed. Companies are no longer bringing returns back into their traditional warehouses. They are sending them to dedicated return centers, specialized reverse logistics hubs, or outside processing partners.
Industry studies have been tracking this shift. The National Retail Federation reports that U S retailers processed well over $743 billion in returns in 2023.1 Other research suggests return activity now makes up around 16 percent of total retail sales, nearly double what it was before the surge in ecommerce.2 Much of that volume no longer goes back to the vendor that sold the goods. It goes to a branded return center, a third party service provider, or what some call a reverse distribution partner.
All of this works from an operations perspective. The problem is that our ERPs were built in a time when the vendor and the return destination were usually the same company.
This is exactly where my Microsoft Dynamics 365 Business Central story begins.
What We Needed
We have a vendor we buy from and pay. That is the vendor we have a contract with. That is the vendor we report on. That is the vendor we process AP against.
We also have a return center. A completely different legal entity that receives the physical goods. They never send an invoice. They are not the pay-to vendor. They simply handle returned product on behalf of the real vendor.
The goal was simple. Create a Purchase Return Order. Select the correct vendor. Then choose the return center as the Vendor Order Address so the shipment goes to the right place.
In our minds this was straightforward. Vendor equals the legal transaction. Order Address equals where the box goes. We expected the PRO to keep that separation clear.
What We Found in Business Central
As soon as we selected the Vendor Order Address, something unexpected happened.
The Vendor Name on the General FastTab changed.
The address changed too.
The General Tab on PRO no longer displayed the real vendor. It displayed the return center as if that were the entity we were transacting with.
The system still posted financially to the correct vendor. All AP reporting, pay-to vendor logic, and ledger entries were tied to the right place. Nothing in the background logic was wrong.
But the document itself now looked like it was created for the return center, not the vendor.
And the surprise did not stop there. When the Purchase Return Order was posted, the Posted Purchase Credit Memo carried forward the same information. The posted document also showed the return center as the vendor name and vendor address. Even the final financial document that auditors and AP teams rely on can look like it belongs to a third party rather than the actual vendor.
This is when things clicked. Business Central is not trying to model the financial relationship on the document header. It is trying to model the physical flow. In BC’s mind a return is a shipment. And shipments show the destination name and address. So, if you choose a return center, BC assumes the return center is the name that should appear on the document.
That makes sense for someone sending a package. It makes far less sense for someone reviewing posted credit memos, reconciling vendor accounts, or answering questions during audit season.
We had the right financial vendor behind the scenes. We had the right return address. What we did not have was a single place where all identities were visible in a clear and logical way.
Sidebar: This Behavior Goes All the Way Back to NAV 2009
If you are wondering whether this quirk is new to Business Central, the answer is no. The way Purchase Return Orders handle vendor information is a direct carryover from Microsoft Dynamics NAV. In NAV 2009, selecting a Vendor Order Address on a Purchase Return Order also updated the Buy from Name and Buy from Address fields on the document.
The reasoning made sense at the time. NAV treated a return as an outbound shipment and assumed the Buy from block should show the destination for that shipment. Twenty years ago return centers were rare and third party reverse logistics partners were not nearly as common. The vendor was almost always the same company that handled the return.
Because of that, the system simply reused the Buy from fields to display the “ship to” information on the return. Financial logic, such as the Pay to Vendor, remained correct in the background. Only the visible vendor name and address changed.
Business Central still behaves the same way today because the purchasing and return architecture has stayed consistent. The challenge is that the world around it has changed. Vendors now rely on outside return centers, repair hubs, and reverse logistics partners, which means the original assumption no longer fits many real world scenarios.
This makes the behavior feel outdated even though it is technically working as designed. Understanding the NAV roots helps explain why BC overwrites the vendor information and why extending the documents to show all three identities can create a more accurate picture for modern businesses.
Why It Does Not Completely Work Out of the Box
Business Central overwrites the Buy from Name and Buy from Address with the values from the Vendor Order Address. It does not expose the Pay to Vendor fields on the standard Purchase Return Order or Posted Purchase Credit Memo reports. And the dataset for most return documents does not include the Pay to information at all.
That means:
- The user interface shows the return center as the vendor.
- The printed and posted documents also show the return center as the vendor.
- The financial posting still goes to the true vendor.
- And there is no built in way to show the Buy from, Pay to, and Return To identities together.
Business Central is not broken. It is simply optimized for a world where the place you send the return and the vendor you buy from are the same. The industry has moved. The product behavior has not.
Our Options Moving Forward
Here are the real options available if you want to support modern return scenarios without misleading users or partners.
Option 1: Accept BC’s behavior and train users to look at Pay to Vendor
This requires no development but relies on user knowledge.
The PRO and posted documents will show the return center, but AP and vendor reporting stay correct in the background.
Option 2: Add Pay to Vendor fields to the PRO and Posted Credit Memo pages
A simple page extension can surface the Pay to Vendor information where users expect to see it.
This brings clarity without altering system behavior.
Option 3: Extend the return document reports to show all three identities
This is the cleanest and most accurate model.
Add the Pay to fields to the report dataset.
Update the layout to show three clear blocks:
- Buy from (operational vendor)
- Pay to (financial vendor)
- Return to (order address)
Auditors love it. Vendors love it. Users love it.
It finally matches modern reverse logistics patterns.
Option 4: Create a dedicated Return Cover Letter
A separate report can present all identities without replacing the standard PRO or posted credit memo printouts.
This is useful for vendors that require detailed RMA documentation.
The Closing Thought
Business Central is doing exactly what it was designed to do. It treats a return as a shipment and makes the recipient of that shipment visible on the document. The challenge is that business models have changed. Returns no longer flow back to the vendor that sold the product. They flow through a network of specialized centers and reverse logistics providers that did not exist when this pattern was first created.
The good news is that with small changes you can bring clarity back to the process. The system already holds all three identities. You simply need to surface them.
Sharing the Righter WayTM
Created as part of Sharing the Righter Way, this article blends my hands-on Business Central experience with research and analysis supported by AI. I use AI as a thinking partner to explore angles, validate patterns, and accelerate the writing process, while all conclusions, explanations, and recommendations reflect my own professional judgment. The result is clearer guidance, deeper insight, and a more practical path forward for Business Central users and teams.
References
- National Retail Federation and Appriss Retail. “NRF and Appriss Retail report seven hundred forty three billion dollars in merchandise returned in 2023.”
- Grand View Research. “Reverse Logistics Market Size, Share and Trends Analysis Report.”
