Inventory allocation and backorders
When you approve a sales order, SKU.io decides — for every line — whether it can ship from stock already on hand or must wait for stock still on the way. It records that decision as an allocation: a claim that ties a specific quantity of a product, at a specific warehouse, to that order line. A line whose demand can't be met from stock becomes a backorder — a sale you've taken but can't ship yet.
This page explains the allocation model behind that decision, the five states an allocation moves through, what a backorder is (a derived state, not a separate record), and how stock that frees up later flows back to waiting orders on its own.
Words like allocation, backorder, FIFO, and fulfillment order are defined in the glossary.
Allocation, not movement
A common misconception is that reserving stock for an order moves inventory. It doesn't. SKU.io keeps two separate ledgers, and they answer different questions:
| Ledger | Question it answers | When it's written |
|---|---|---|
| Allocations | What's committed to this line, and is that stock on hand or incoming? | At approve / reserve time, and whenever coverage changes |
| Inventory movements | What stock has physically left the warehouse? | Only at fulfillment, when the shipment ships |
Everything committed to a line lives in the allocation ledger, linked directly to the sales order line. Approving an order never writes a stock movement and never realizes cost — those happen only when you ship. To see the allocations on an order, open its Allocations tab on the order detail page; each row shows the product, warehouse, quantity, and its allocation status. How the second ledger works is covered in How fulfilling moves inventory and realizes COGS.
The five allocation states
Every allocation carries one of five statuses. Two of them mean "backordered", one means "reserved from stock", and two are terminal:
| Status | What it means | Counts against on-hand stock? | Backorder? |
|---|---|---|---|
| Planned | Demand that has no stock behind it and no incoming purchase order linked yet — a true shortage. | No | Yes (uncovered) |
| Awaiting Receipt | Backordered demand that a specific incoming purchase order line has been linked to cover. Waiting on that receipt. | No | Yes (covered) |
| Allocated | On-hand stock claimed from a warehouse for this line. This is the only status that reduces available inventory. | Yes | No |
| Fulfilled | The claimed stock has shipped. Terminal. | No (already consumed) | No |
| Cancelled | The claim was released. A terminal audit row, not a live claim. | No | No |
Two rules follow from this table and are worth holding onto:
- Only Allocated stock is real, on-hand stock. Planned and Awaiting Receipt are promises about future supply — they never reduce what's available to sell.
- Cancelled allocations are history, never live. They stay on the Allocations tab as an audit trail of what was once committed, but they hold nothing. When you re-approve a line, SKU.io re-allocates it precisely because its old allocations are all Cancelled.
How an allocation moves through its life
An allocation is born when you approve or reserve an order, moves between states as coverage and stock change, and ends either shipped or released:
Where allocations come from
Approving a sales order creates allocations for every unallocated product line in one pass. For each line, SKU.io claims what stock it can from the line's warehouse as Allocated, and records any remainder it can't cover as Planned — the backordered portion. A single line can end up split across both: some units Allocated, the rest Planned.
Reserving an order (rather than approving it to Open) does the same allocation work — the difference is the order status, not the stock claim. Both approve and reserve are covered in Approve, reserve, and allocate stock.
A Planned allocation is pure demand — it doesn't create a fulfillment order line, because there's nothing to ship. The line only gains a shippable plan once its stock is Allocated. This is why backordered lines don't appear as fulfillable work until they're released. See Two-tier fulfillment: intent vs execution.
Coverage: Linking a backorder to an incoming PO
A Planned (uncovered) allocation becomes Awaiting Receipt (covered) when SKU.io links it to an incoming purchase order line that will supply the product. Coverage runs automatically after approval and again whenever supply changes; you can also pin coverage to a specific PO line by hand. If that coverage is later lost — the PO is cancelled, or its stock is claimed by a higher-priority order — the allocation drops back to Planned.
Both Planned and Awaiting Receipt count as active backorders. The difference is only whether an incoming PO is on the hook to fill it.
Backorders: A derived state, not a record
There is no "backorder" table in SKU.io. A backorder is simply the presence of a Planned or Awaiting Receipt allocation on a line. That's why a line has no backorder status column of its own — its state is read from its allocations:
| Line signal | Means |
|---|---|
| has active backorder | The line has a Planned allocation with no PO coverage — a real, uncovered shortage. |
| active backordered quantity | The units in Planned plus Awaiting Receipt — everything still waiting on supply. |
| backordered quantity | The units in Planned only — the uncovered shortage portion. |
Because the state is derived, it updates itself the moment allocations change — you never set it manually. Line-level fulfillment state generally works this way; see How sales order status works.
Where backorders show up
Backordered demand surfaces in several places, all reading the same allocation ledger:
- On the order line. A backordered line shows a red Backordered chip. Expanding its coverage detail reveals one of: Backorder Coverage (linked to a PO, with an Available ETA from that PO), Backorder — No PO Coverage (uncovered, with quick actions to create a draft PO or open demand planning to Fill backorders), Covered — Awaiting Receipt, or Backorder Released once stock has arrived.
- The Backorder Queue. Go to Inventory → Backorder Queue for the tenant-wide, priority-ordered list of every backordered line across all orders, with its covering PO and ETA.
- The order's backorder summary. An order exposes its earliest and latest covered ship-by dates, drawn from the ETAs of the POs covering its backordered lines.
- The list filter. The sales orders list offers a Backorder Status advanced filter whose options span active backorders (Any Active Backorder, plus covered-vs-uncovered and scheduled-vs-unscheduled sub-options), Was Backordered (resolved), and Never Backordered. Matching on a PO number is handled by two separate advanced-filter columns — Backorder Released by PO# and Covered by PO# — not by the Backorder Status dropdown. See List columns and filters.
Active versus resolved backorders
A backorder is active while at least one Planned or Awaiting Receipt allocation remains on the line. Once every allocation on the line has been released (to Allocated), fulfilled, or cancelled — with none still active — the line counts as resolved ("was backordered"): it carries the history of a past shortage but nothing outstanding. An order can sit Open with active backorders indefinitely; the shortage doesn't stall the order, it just marks what can't ship yet.
How freed stock releases automatically
The point of tracking backorders precisely is that SKU.io can fill them the instant stock appears — you don't chase them by hand. Stock frees up two ways, and both trigger a release:
- A purchase order is received. New on-hand stock is handed to the backorders it can now cover. (See How a PO becomes inventory.)
- On-hand stock is freed by a cancellation. When you unreserve a line, cancel an order, or otherwise release an Allocated claim, the stock returns to its warehouse pool — and any Planned or Awaiting Receipt backorders on that same product and warehouse are released against it.
Release runs in queue order: the oldest backorder (the first one queued) is served first, so a released batch fills waiting orders fairly, first-come-first-served. A released allocation transitions from Planned or Awaiting Receipt to Allocated, and the line's shipment plan is built so it becomes fulfillable.
When freeing stock by hand — for example, reversing a reservation — SKU.io shows an Eligible Backorders — Release Now? prompt listing the waiting orders that the freed stock could fill, so you decide whether to release immediately or hold the stock.
When an allocation loses its stock
Because an Allocated claim doesn't lock a physical FIFO layer at reservation time, another event can consume the stock behind it before it ships — a negative inventory adjustment, an assembly, or a sibling order shipping first. When the stock behind an Allocated allocation is gone, SKU.io detects the shortfall and demotes the now-unbacked allocation from Allocated back to Planned, returning the line to the backorder queue so it re-fills when stock arrives again.
This demotion is careful about what it touches:
- Already-shipped units are never re-backordered. A line whose quantity is fully accounted for by shipped, externally fulfilled, and cancelled units is left alone — SKU.io won't strand a phantom backorder for stock that has already left the building.
- In-flight shipments are protected. A line with a live shipment already out to a carrier or 3PL keeps its allocation, so tracking can still land against it.
The same FIFO consumption that drives this demotion is explained from the shipping side in How fulfilling moves inventory and realizes COGS.
Backorders and the end of an order's life
Allocations and backorders shape what you can do with an order:
- Active backorders block closing. SKU.io refuses to close an order while any line still has a Planned or Awaiting Receipt allocation — there's outstanding demand it can't yet satisfy. Release or cancel the backordered quantity first. See Close, cancel, archive, and delete orders.
- Cancelling releases everything. Cancelling an order cancels all of its active allocations (Planned, Awaiting Receipt, and Allocated alike), frees their stock, and re-runs coverage so other backorders can pick it up.
- Reverting to draft releases everything. Marking an order back to draft cancels its allocations the same way, so re-approving it later allocates the line fresh.
- Clearing a line's warehouse releases its allocations. Removing the warehouse from a line auto-cancels that line's active allocations, since a claim can't exist without a location to claim from. Warehouse handling is covered in Warehouse routing and the warehouse lock.