Does any of this describe your operation?
- Multiple purchase orders have been raised to the same supplier for the same SKU in the same purchasing cycle
- Purchasing decisions are triggered by individual backorders rather than total demand across all outstanding orders
- The team consolidates purchase orders manually after raising them, correcting quantities and combining lines
- The same product has been delivered in multiple separate shipments from the same supplier in the same week
- Demand visibility at the time of purchasing is per-customer rather than per-SKU across all outstanding demand
- Purchasing is permanently reactive — always catching up with the last backorder rather than working from the complete demand picture
If any of the above are true of your business, the purchasing function is working harder than it needs to because demand is not consolidated before purchasing decisions are made.
“That might happen 20 times and then I have 20 individual purchase orders for a single SKU which I then have to consolidate.”
Purchasing manager, B2B wholesale distributor
Root cause: Purchasing is triggered by individual demand events — a single backorder — rather than by consolidated demand signals — all backorders for a SKU across all customers, combined with reorder point requirements and existing open POs. Without a system that aggregates all demand before generating purchasing recommendations, each backorder is treated as an independent purchasing need. The consolidation that should happen before the PO is raised happens after it, manually, by the operations team.
Stok.ly consolidates all backordered demand for a SKU across all customers and orders before generating a purchasing recommendation. The purchasing team sees one demand signal per SKU — the total outstanding quantity across all backorders plus any reorder point demand, minus stock already inbound on an existing PO. One PO. One delivery. One goods-in. When stock arrives, it is automatically allocated to backorders in priority order.
Trust your stock. Transfer with confidence. Control orders. Fulfill every day like clockwork.
Demand consolidation — the total before the purchase order, not after
The sequence that produces 20 POs for the same SKU is predictable. Customer A backordered item X on Monday. A PO was raised for Customer A’s quantity. Customer B backordered item X on Tuesday. Another PO was raised. By Friday, eight customers have backordered item X and eight POs have been raised — all to the same supplier, all for the same product, none of them communicating that the others exist.  Stok.ly reverses this sequence.
All eight backorders for item X are visible as a single demand signal in the purchasing view. The total consolidated quantity — all eight customers combined — generates one purchasing recommendation.
The purchasing team raises one PO at the click of a button.
The supplier receives one clear order. One delivery arrives. One goods-in event processes it.
The 20-PO problem never occurs because the consolidation happens before the PO, not after.
Per-SKU purchasing view — all demand visible before committing to a supplier
Effective demand consolidation requires a purchasing view that shows total outstanding demand per SKU rather than per customer or per backorder event. In most systems, the purchasing view is organised around individual orders or individual customers — which makes consolidation a manual exercise in aggregation.
In Stok.ly, the purchasing view is organised around SKUs.
For each product that requires replenishment, the view shows: total backordered demand across all customers, total reorder point requirement, stock already inbound on existing open POs, and the net quantity to order.
The purchasing decision is made from this complete picture.
There is nothing to manually consolidate because the consolidation already happened.
“Our replenishment process was manual, error-prone and time-consuming. Between the three of us, we’ve gained 70 to 80% of our time back.”
Purchasing team, multi-channel fashion retail business
One consolidated PO — one delivery, one goods-in
The operational cost of PO proliferation is not just the time spent consolidating.
It is the multiple deliveries that result from multiple POs.
The same product arrives on three different days in three different cartons.
The warehouse team processes three separate goods-in events for the same SKU in the same week.
Each goods-in takes time. Each creates its own receipt record.
Each needs to be matched to an open PO for the quantity to close correctly.
A single consolidated PO produces a single delivery.
One goods-in event. One receipt record. The warehouse team processes it once. The PO closes once.
The available-to-sell updates once.
See also: We Can’t See What Can Ship, What’s Committed and What’s Backordered.
How Stok.ly controls backorder demand consolidation
| Capability | What it controls | Why it matters |
|---|---|---|
| Demand consolidation | All backordered demand for a SKU across all customers aggregated into one purchasing signal | One PO per SKU per supplier per cycle; no manual post-hoc consolidation |
| Per-SKU purchasing view | Total outstanding demand for each SKU visible before any PO is raised | Purchasing decision made on complete demand picture, not individual backorder events |
| Purchase order accuracy | PO quantity based on total consolidated demand plus reorder point, minus existing inbound POs | Right quantity ordered; not under-ordered or over-ordered by missing part of the demand picture |
| Consolidated goods-in | One delivery to receive against one PO rather than multiple partial deliveries in the same cycle | Warehouse receives once per SKU per cycle; goods-in effort proportional to actual delivery volume |
| Backorder allocation on receipt | Stock arriving against consolidated PO allocated to backorders in priority order | Oldest or highest-priority backorders fulfilled first; allocation is automatic, not manual |
| Live demand signal | Consolidated demand signal updates in real time as new backorders are placed and POs change | Purchasing team always works from the current total demand before making a supplier commitment |
Current approach versus Stok.ly
| Current approach | What tends to break | Stok.ly |
|---|---|---|
| Each backorder triggers its own purchasing action | 20 POs for the same SKU; hours of manual consolidation; multiple deliveries | Demand consolidated before PO generation; one PO per SKU per cycle; no manual consolidation |
| Demand visibility per-customer at time of purchasing | Purchasing misses demand from other customers with the same backorder in the same cycle | Per-SKU view shows all customers with outstanding demand before any PO is raised |
| Multiple POs to same supplier for same SKU in same cycle | Supplier receives fragmented orders; may fulfil at different times and prices | Single consolidated PO; supplier receives one complete order for the replenishment cycle |
| Consolidation done manually after POs are raised | Hours of work per week; consolidation errors create wrong quantities; team time consumed | Consolidation is automatic before PO generation; manual work eliminated |
| Same SKU received in multiple partial deliveries in same week | Multiple goods-in events for the same product; warehouse effort fragmented | One consolidated delivery per SKU per cycle; one goods-in event per SKU |
| Purchasing triggered reactively by each backorder event | Permanently behind demand; always catching up; purchasing decisions made with partial information | Demand-signal purchasing: complete consolidated demand visible before any supplier commitment |
“We have gone from a pen and paper warehouse to a completely digital system that has streamlined our business immensely.”
Verified G2 review, 5 stars — Read on G2
Who this is for
- B2B wholesale and distribution businesses whose purchasing is triggered by individual backorder events rather than consolidated demand
- Operations managers spending hours each week manually consolidating purchase orders for the same SKU
- Purchasing functions that are permanently reactive — always responding to the last backorder rather than the complete outstanding demand
- Growing wholesale businesses where order volume has reached the point where individual backorder-driven purchasing creates unmanageable PO proliferation
- Businesses where goods-in for the same product occurs multiple times per week because multiple POs arrived separately
Who this is not for
Businesses with simple, predictable replenishment needs and low backorder frequency where individual PO generation per event is manageable. Businesses with a single customer or very few SKUs where demand consolidation adds no material operational value. The benefit of demand consolidation increases with SKU count, customer count and the frequency of backorder events per replenishment cycle.
G2 Customer Reviews
What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“we have been a user for the last 4 years and we cannot think of life without it for our retail business. it makes listing to shopify and other marketplaces easy, keeps inventory accurate online and the POS is easy to use. accurate inventory across all sales channels is the big win for us.”
Order management and inventory ERP software for growing retail, wholesale and distribution businesses.
Frequently asked questions
Why do businesses end up with 20 purchase orders for the same SKU?
Multiple POs for the same SKU accumulate when purchasing is triggered by individual backorder events rather than consolidated demand across all outstanding orders. Ten customers backordering the same SKU in the same week generates ten purchasing actions and, in the absence of a consolidation step, ten separate purchase orders to the same supplier. The team consolidates them manually after the fact — a task that recurs every week.
What is demand consolidation and how does it work in Stok.ly?
Demand consolidation is the aggregation of all outstanding demand for a SKU — from all backorders, all customers and all demand signals — into a single purchasing quantity before any supplier PO is generated. In Stok.ly, the purchasing view shows total consolidated demand per SKU: all backordered quantities across all customers, plus reorder point demand, minus stock already inbound on existing open POs. One PO is raised for the consolidated quantity. Manual post-hoc consolidation is eliminated.
How does Stok.ly generate purchasing recommendations from consolidated demand?
Stok.ly generates purchasing recommendations from the live operational record. The demand signal for each SKU is the total of all outstanding backorders plus reorder point requirements, minus any quantity already expected on open purchase orders. The recommendation is a single quantity per SKU per supplier. The purchasing team reviews the recommendation, adjusts if required, and raises one PO. The complete demand picture is visible before the purchasing decision is made.
How does Stok.ly allocate stock to backorders when a consolidated PO arrives?
When goods-in is confirmed for the consolidated purchase order, Stok.ly allocates the received stock to outstanding backorders in priority order. The default is oldest backorders first. Customer priority tiers can be configured to ensure high-value accounts are fulfilled first. The allocation is automatic — no manual distribution of received stock across backorders is required.
What is the difference between backorder-driven purchasing and consolidated purchasing?
Backorder-driven purchasing generates a purchasing action for each individual backorder event. Ten customers backordering the same product generates ten purchasing actions and potentially ten POs. Consolidated purchasing aggregates all demand before generating any purchasing action. The same ten customers generate one demand signal and one PO for the total consolidated quantity. One supplier order. One delivery. One goods-in event.
How does Stok.ly calculate the right quantity for a consolidated purchase order?
The consolidated PO quantity is the total of all backordered demand for the SKU across all customers, plus any reorder point quantity required to return to minimum stock levels, minus the quantity already inbound on any existing open purchase order for the same SKU. The calculation is live — it updates as new backorders are placed and as open POs are confirmed, changed or closed.
Does Stok.ly support automatic purchase order generation from consolidated demand signals?
Stok.ly generates purchasing recommendations from consolidated demand signals. The purchasing team reviews and approves PO generation, or the system can be configured to generate POs automatically when demand meets defined thresholds. The exact automation level is configured per business and supplier. Demand consolidation happens automatically regardless of whether PO generation is manual or automated.
How does Stok.ly compare to Orderwise for backorder and purchasing management?
Orderwise’s purchasing and backorder management is built on a Windows-based platform with SQL-driven reporting. Many customers describe the backorder management process as manual and the purchasing workflow as disconnected from real-time demand signals. The system generates reports rather than live demand views, and consolidation of backorder-driven purchasing typically happens manually through report exports. Stok.ly connects live consolidated demand to purchasing recommendations from the same operational record as orders and inventory.
Related pages
Contact Information
All our sales, support and development team are located in Hereford and Cheltenham in the U.K. Please submit the contact form and we will contact you within the same business day.