E-commerce logistics software covers the operational reality of selling and shipping online: orders from several channels drawing on one stock position, shipments allocated across courier partners, tracking assembled from partners who each report differently, the two distinct flows of goods coming back, cash collected at the door, and the economics of an order once everything that came back is counted. With Pentoggle, an operation can describe how its channels and partners actually work and generate the starting application around it.
This page is about the channel and the flow. The delivery run itself is covered by Last-Mile Delivery Software, the branch network by Courier and Parcel Business Software, and picking and stock by Warehouse Management Software.
Many operations already run Tally for accounting and a channel or marketplace panel for listings and orders. Those stay where they are. What is often still managed outside them is the position across channels and partners, and what an order is worth after returns.
Key takeaways
- Two different return flows exist and they behave differently. Undelivered shipments coming back and customers sending goods back after receiving them have different causes, costs and remedies.
- An order that comes back consumes forward freight, return freight, handling at both ends and the working capital in between, while earning little or nothing depending on your policy.
- Several channels drawing on one stock position is a design problem before it is a volume problem, and it is cheaper to solve before the volume arrives.
- Courier partners report differently, and assembling a single view across them is a large part of the operational work of using more than one.
- A useful number is cost per kept order, meaning total order-related cost including returns, divided by the orders that are delivered and not returned.
The marketplace panel is often not the problem
A marketplace panel handles its own orders well. It shows what was sold, what needs shipping, and what the platform expects of you.
The trouble starts at identifiable points, and all of them involve having more than one of something.
When there is more than one channel
Two marketplaces and a storefront means three panels, three order lists and three views of stock, none of which knows about the other two.
When there is more than one courier partner
Each partner has a portal, a status vocabulary and a way of reporting. A single view of where everything is has to be assembled, and it is assembled by a person opening three tabs.
When returns arrive without context
A parcel comes back. Whether it is an undelivered shipment, a customer return, or a replacement being exchanged is not obvious from the parcel, and each needs different handling.
When the cost of a returned order is absorbed
Forward freight was paid, return freight was paid, the item was handled twice, and the order earned nothing. None of that is attributed to the order, the item or the channel that produced it.
What e-commerce logistics software holds
Orders across channels
Orders from every marketplace and storefront in one list, with the channel and its requirements attached.
Shared stock position
One stock position that all channels draw against, with what is available and what is reserved.
Courier allocation
Which partner gets which shipment, by area, service level, weight and whatever rules you apply.
Consolidated tracking
Status pulled from each partner and normalised into a view that reads the same across all of them.
Undelivered returns
Shipments that failed delivery and are coming back, with the reason and where they currently are.
Customer returns
Goods sent back after delivery, with the reason, condition on arrival and whether they re-enter stock.
Collection and remittance
Amounts collected on delivery by each partner, what has been remitted, what is outstanding and its age.
Order economics
Forward freight, return freight, handling and packaging attributed to the order, so cost per kept order is knowable.
Two return flows, not one
Most operations think about returns as a single category. Operationally they are two problems that share only the direction of travel.
Undelivered shipments never reached the customer. The causes are the ones covered on Last-Mile Delivery Software: recipient unavailable, address incomplete, refused at the door. The goods are usually in original condition and can often return to saleable stock after whatever check your process requires, and the remedies are upstream, address quality at the point of order, contact before delivery, delivery windows.
Customer returns reached the customer and came back afterwards. The causes are different: the item did not fit, did not match the listing, arrived damaged, or the customer changed their mind. The goods have been handled, opened and possibly used, so your process may require inspection before they are returned to saleable stock, and they may not return to saleable stock at all. The remedies are also different, listing accuracy, sizing information, product photography, packaging.
Holding them as one category means the aggregate return rate moves without anybody being able to say why, and the two remedies get applied to the wrong problem.
Three things worth recording separately for each flow.
The reason, from a defined list, captured where the information exists. For undelivered shipments that is the delivery partner. For customer returns it is whatever the customer said when raising it.
Condition on arrival, which matters mainly for customer returns and determines whether the item is saleable, needs repair, or is a write-off.
The cost, which differs between the flows and is discussed below.
Return terms, what a customer is entitled to and within what period, depend on your own policy, your marketplace agreements and the applicable requirements. Those are matters for your own advice, and the application holds whatever policy you set.
An order that comes back costs more than it looks
The forward journey is the visible cost. An order that returns consumes a good deal more than that, and much of the extra is not attributed anywhere.
Forward freight was paid. Return freight is paid, sometimes at a higher rate than the forward leg depending on your arrangement with the partner. The item was picked, packed and dispatched, and now has to be received, checked to whatever standard your process sets, and either restocked, repaired or written off. Packaging is frequently not reusable. Where payment was collected, it may have to be refunded, and where it was not, the working capital was tied up for the whole cycle. On a marketplace, the platform's own charges may apply regardless.
Frequently none of this appears against the order. It appears as freight cost, warehouse labour and write-offs, in three different places, at the aggregate level.
Attributing it changes what you can see, and the useful views are these.
By item. Some products return at a much higher rate than others, and where that rate is high enough the product may be loss-making at its current price despite selling well. That is a listing, pricing or discontinuation decision and it cannot be made without the number.
By channel. Channels differ in return rate, in what they charge, and in what they require of you. A channel with strong volume and a high return rate can be worth less than a smaller one.
By reason. Returns caused by listing inaccuracy are frequently among the cheaper problems to fix, and the fix tends to hold. Returns caused by customer preference are a cost of doing business in the category. Treating both as an operations problem wastes effort on the second.
By region. Concentrations sometimes indicate a delivery partner problem rather than a product problem, particularly where damage is the stated reason.
One stock position, several channels
Where several channels sell from the same stock, the gap between what is offered and what is actually available is where overselling happens.
The structural approach is a shared stock position that every channel draws against, with reservation as orders arrive. This is covered in general terms on Order Fulfilment Software; what e-commerce adds is that the channels are external and update on their own terms.
Three practical points specific to this setting.
Sync is not instantaneous, and the interval is your exposure. Between a sale on one channel and the updated availability appearing on another, the same unit can be sold twice. Whether that matters depends on volume and stock depth, and where it does the usual response is a buffer held back from channel availability.
Buffers cost sales and prevent failures, and the right size is an empirical question rather than a principle. Too large and you are declining orders you could have filled; too small and you are cancelling orders you accepted. Track both outcomes rather than only the one that is visible.
Returns re-entering stock need a rule. An item coming back and passing inspection is available again, and how quickly that availability reaches the channels affects whether it sells. Where inspection is slow, saleable stock sits invisible.
Marketplace requirements on dispatch times, cancellation rates and stock accuracy vary by platform and are set by agreements you have with them. What those require of you is a matter for your own reading of those agreements.
Where e-commerce logistics looks different by business type
- Courier and Parcel Business Software, where the operator is the delivery partner rather than the seller.
- Last-Mile Delivery Software, where the run and the attempts are the unit of work.
- Warehouse Management Software, where picking, packing and putting returns back are the physical operation.
- 3PL Software, where fulfilment is run on behalf of brands and has to be billed for.
- Cold Chain Logistics Software, where perishable goods are sold online and condition matters to the handover.
- Pharmaceutical Logistics Software, where online distribution carries requirements beyond ordinary retail.
Why operations choose Pentoggle for e-commerce logistics
Orders and stock across channels in one place
One order list and one stock position all channels draw against, with reservation and buffers you control.
Courier partners normalised
Status from each partner assembled into a view that reads the same, so nobody opens three portals.
Two return flows held apart
Undelivered and customer-initiated tracked separately with their own reasons, conditions and costs.
Cost attributed to the order
Forward freight, return freight, handling and packaging against the order, so cost per kept order is knowable.
Sits around your channels and your accounting
Your marketplace panels continue handling listings and their own order flow. Tally and comparable systems continue handling accounting and GST. Pentoggle adds the layer across channels and partners.
A useful number for e-commerce logistics
Cost per kept order, meaning the total order-related fulfilment, delivery, return and handling costs divided by orders delivered and not returned.
Cost per order shipped understates the real figure, because it spreads cost over orders that came back and earned little or nothing. Cost per kept order is what the operation actually pays to complete a sale that stays completed.
Read it by channel and by product category. Both can vary considerably, and a channel or category that looks healthy on revenue can look different on this figure.
Hold the two return rates beside it, separately. A falling cost per kept order driven by fewer undelivered shipments is an operational win. The same fall driven by fewer customer returns may be a listing improvement, or may be a change in product mix, and the two need distinguishing.
Where you also track cost per successful delivery, as a last-mile operation would, treat that as the delivery-side figure and this as the channel-side one. See Last-Mile Delivery Software.
Ready to build e-commerce logistics software?
Your channels tell you what sold.
What it cost you, after the parcels that came back, is a number assembled from three places if it exists at all.
Describe your channels, your courier partners and how returns reach you to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.