Technical
The make-or-break technical question in any peer-to-peer routing evaluation: how does it actually integrate with the ERP? Three patterns work in practice across the major systems, none requiring custom development. A reference for IT directors and controllers.
Vertaling volgt. We tonen de Engelse versie.
For most fashion retailers evaluating peer-to-peer return forwarding, the operational case is straightforward: returns route directly between consumers, the warehouse round-trip disappears, and per-return costs drop. The financial case, the consumer experience, the regulatory upside: each of these has answers that pencil out reasonably quickly.
The question that takes longer to resolve is the technical one: how does this actually integrate with the ERP system that runs the business? A peer-to-peer return does not fit cleanly into the assumptions most ERPs make about inventory movement. The item never enters the retailer's warehouse, never appears on the inventory ledger, and yet it generates a sale, a refund, and a financial event that needs to be reported correctly.
This article covers the three integration patterns that work in practice across the major ERP systems used by fashion retailers (Microsoft Dynamics 365 in both Business Central and Finance & Operations, SAP S/4HANA and Business One, NetSuite, Acumatica, and others). None of these patterns require ERP modifications or custom development. They all use functionality that exists in standard ERP installations. The right choice depends on your accounting team's preferences, the rest of your inventory handling, and the volume of peer-to-peer returns you expect.
We will cover what is happening operationally, how each pattern handles the accounting, the practical trade-offs, and ERP-specific notes for the major systems. The goal is to give an IT director or controller enough material to evaluate the options against their own setup before scheduling a scoping call.
The default ERP model for a return assumes a physical movement: the customer ships the item back, it arrives at the warehouse, it is received into inventory, eventually it is picked, packed, and shipped to a new buyer. Each step generates an event the ERP recognises (receipt of goods, inventory update, warehouse movement, eventual shipment, COGS calculation, refund).
Peer-to-peer return forwarding skips most of this physical movement. The item ships directly from the original buyer to the next buyer. There is no warehouse receipt, no inspection event, no inventory accumulation. From the ERP's perspective, this is a problem: a sale has been generated and a refund has been issued, but the inventory journey does not match what the ERP expects.
This is not a fundamentally new challenge. Drop-shipping presents the same accounting problem: a sale to a customer, fulfilment by a supplier, no physical receipt by the retailer. The accounting profession has developed standard patterns for handling drop-ship over the past two decades, and those patterns translate cleanly to peer-to-peer returns.
The core principle, as Len Green wrote in a much-cited 2017 Proformative discussion on drop-ship accounting: "Why not regard it as in + out inventory from a warehouse location that never has a balance?" That single insight underlies most workable peer-to-peer integration patterns.
There are three patterns that handle peer-to-peer return forwarding cleanly in mainstream ERPs:
Each pattern is workable. They differ in the trade-off between integration complexity and operational visibility. The right choice depends on factors covered in section 6.
The patterns below describe the accounting flow in general terms. Specific ERP implementations vary in syntax and module names, but the underlying mechanism is consistent.
This is the most elegant pattern and the closest to how the ERP "wants" to see the transaction. It treats peer-to-peer returns the same way the ERP treats drop-shipping.
The setup. Create a new logical warehouse in the ERP, naming it something like P2P-PASSTHROUGH or FORWARDING-VIRTUAL. This warehouse exists only in the ERP. There is no physical location associated with it. The warehouse's balance is always zero: items receive in and ship out as a single atomic transaction.
The flow when a peer-to-peer return is matched to a new buyer:
Accounting effect. The accounting entries are identical to a normal warehouse fulfilment, just with the item passing through a logical location rather than a physical one:
Because the virtual warehouse is set up with the same chart-of-accounts mapping as physical warehouses, the journal entries are automatic.
Practical trade-offs:
Best fit for: Microsoft Dynamics 365 (BC and F&O), SAP S/4HANA, NetSuite, Acumatica, Infor CloudSuite. Any ERP that supports multiple warehouses and clean drop-ship handling.
This pattern treats peer-to-peer returns as transactions involving a non-inventory item, then reconciles the inventory effect at month-end.
The setup. Create a non-inventory item in the ERP, called something like P2P-RETURN or FWD-NONSTOCK. Non-inventory items do not appear on the inventory ledger. They are recognised as expense at point of purchase and revenue at point of sale, with no stock tracking.
The flow when a peer-to-peer return is matched:
Monthly correction booking. At month-end (or whatever cadence works for the controller), a single journal entry reconciles the inventory effect:
The peer-to-peer system provides a monthly summary export listing all Forwards, original SKU, and fulfilment reference. This export becomes the source data for the correction booking.
Accounting effect. In real-time, the ERP sees:
At month-end, the correction booking aligns the actual inventory state with the recorded transactions.
Practical trade-offs:
Best fit for: SAP Business One, smaller installations of Microsoft Dynamics 365 BC, retailers with strong existing month-end close processes who do not want real-time complexity.
This is the simplest pattern and the one most suitable for retailers piloting peer-to-peer returns or running them at low volume.
The setup. The peer-to-peer system runs entirely outside the ERP in real-time. The ERP does not see individual peer-to-peer transactions. It sees the original sale and the refund as normal events.
The flow:
Monthly adjustment journal entry. At month-end, the controller records:
The peer-to-peer system provides a structured monthly statement with all transactions, fees, and inventory movements. This statement is the source document for the adjustment.
Practical trade-offs:
Best fit for: retailers piloting peer-to-peer routing for the first time; small retailers using simple accounting systems; any retailer who wants to evaluate the model before committing to deeper integration.
This pattern often makes sense as the starting point even for retailers who eventually move to Pattern 1 or 2. The simplicity lets the operations and finance teams build confidence in the model before deciding whether tighter integration is worth the setup work.
Three factors typically drive the choice.
Volume and visibility needs. At low volume (pilot phase, under 100 Forwards per month), Pattern 3 is usually fine. The operational simplicity outweighs the real-time visibility loss. As volume grows past a few hundred per month, the controller's office typically wants more granular tracking. Pattern 1 or 2 becomes appropriate.
ERP capability. Pattern 1 (virtual warehouse) requires the ERP to support multiple warehouses and clean drop-ship handling. Most enterprise-grade ERPs do this well. Smaller systems sometimes do not, in which case Pattern 2 or 3 is the practical choice.
Internal preference. Some controllers prefer real-time visibility (Pattern 1). Some prefer operational simplicity with month-end reconciliation (Patterns 2 and 3). This is partly an organisational culture question. Neither preference is wrong.
A practical recommendation for most fashion retailers evaluating peer-to-peer returns: start with Pattern 3 during a 90-day pilot. If the pilot works and volume justifies tighter integration, migrate to Pattern 1 or 2 as part of the production rollout. This staged approach minimises upfront integration cost while preserving the option for tighter integration when the business case is proven.
This sequencing also matches the way most retailers evaluate any operational change: start with low-risk validation, deepen the integration once the model has earned trust internally. Trying to commit to Pattern 1 before the operational evidence has accumulated tends to cost more than it should.
Microsoft Dynamics 365 Business Central. Pattern 1 is well-supported. Create a non-stock-keeping location for the virtual warehouse. Use a Sales Credit Memo with an Item Charge for the per-Forward fee, or set up a dedicated G/L account. The TRIMIT Fashion extension handles peer-to-peer flows cleanly with appropriate location setup. Several deployments run this configuration in production.
Microsoft Dynamics 365 Finance & Operations. Same as BC for the warehouse setup. F&O's more sophisticated cost accounting makes Pattern 1 the obvious choice for retailers at this scale. Webhook integration is standard via the Common Data Service / Dataverse.
SAP S/4HANA. Pattern 1 works through SAP's plant and storage location concept. Create a virtual storage location within an existing plant, or a dedicated plant for peer-to-peer if cross-functional reporting is desired. SAP's drop-ship functionality handles the receipt-and-ship-in-one-transaction flow natively.
SAP Business One. Pattern 1 requires SBO's drop-ship setup, which works but has more constraints than enterprise SAP. Pattern 2 (non-inventory item) is often simpler in SBO. SBO handles non-inventory items cleanly with appropriate G/L account mapping.
NetSuite. Pattern 1 maps to NetSuite's drop-ship workflow exceptionally cleanly. NetSuite's native handling of "items shipped from supplier" translates directly to "items shipped from previous buyer." Custom records can extend the standard workflow if needed.
Acumatica. Pattern 1 works through Acumatica's multi-location inventory functionality. Acumatica's flexibility with custom workflows makes Pattern 1 setup straightforward.
Infor CloudSuite Retail. Pattern 1 is supported through Infor's location framework. The matrix inventory functionality (size, colour, style) works cleanly with peer-to-peer flows because the SKU identity remains constant through the Forward.
K3 Pebblestone (fashion-specific BC extension). Inherits BC's strong handling. Pebblestone's matrix item management works directly with peer-to-peer flows.
TRIMIT Fashion (BC extension). Handles the BC scenario as documented above. Most relevant to mid-market European fashion retailers.
For ERPs not listed here, the underlying patterns still apply. It is a matter of mapping the patterns to the specific ERP's terminology and workflow.
Regardless of which integration pattern you choose, the data flow between the peer-to-peer system and the ERP follows a consistent shape.
Inbound to ERP (events from the peer-to-peer system):
These events arrive via webhooks (recommended) or scheduled API polling. Webhook integration is preferred. It is real-time, more efficient, and better suited to event-driven ERP workflows.
Outbound from ERP (data the peer-to-peer system needs):
The peer-to-peer system typically reads this data via the retailer's e-commerce platform or PIM system rather than directly from the ERP. If the e-commerce platform is the source of truth for catalogue and orders, the peer-to-peer system integrates there, and the ERP receives the resulting events.
Practical integration tooling:
A peer-to-peer system without these basics is not really enterprise-ready. When evaluating providers, the API documentation is a good proxy for engineering maturity.
Whatever the technical approach, the integration question is solvable. The harder questions are operational and strategic: how will your team handle the workflow, what is the right consumer presentation, what does the financial case actually look like for your specific volume. The technical integration is, in practice, the most tractable part of evaluating peer-to-peer returns.
For more on the operational side of peer-to-peer return forwarding and where it fits, see our explainer of peer-to-peer returns as a category. For the financial case underlying the integration decision, see our guide to calculating the true cost of a return. For the broader operational context, see our guide to preparing your operations team for the new returns reality.
An emerging return model routes returns directly from one customer to the next without warehouse processing. This article explains the mechanism, where it fits, where it does not, and how to evaluate it as one option among several.
Laatst bijgewerkt:
Most retailers undercount what a return actually costs. Once depreciation, opportunity cost, write-off, and customer-service overhead are properly attributed, returns are typically 2 to 3 times more expensive than spreadsheet defaults suggest.
Laatst bijgewerkt:
Operations teams that have run returns the same way for years now face higher volumes, regulatory pressure, capacity constraints, and environmental accountability simultaneously. The teams that adapt fastest gain real advantage.
Laatst bijgewerkt:
