How allocations and backorders work

An allocation is the record that commits a quantity of one product, at one warehouse, to a demand document — a sales order line, a warehouse transfer, a manufacturing component, or a vendor-credit restock. It's the single mechanism behind the numbers you read elsewhere in the Inventory area: the Allocated column on a product's stock view is the sum of its allocated commitments, and a backorder is simply an allocation that has no on-hand stock behind it yet.

When you approve a sales order, for example, SKU.io decides line by line whether the line can ship from stock already on hand or has to wait for stock still on the way, and it records that decision as allocations. 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: the states an allocation moves through, how priority decides which backorder gets incoming stock first, how a purchase order covers a backorder and produces a resolved ETA, the settings that let SKU.io release and cover backorders automatically, and — in From a sales order — how the same model shows up on an order. It's the conceptual companion to two how-to guides: Work the backorder queue / allocation pipeline and Browse allocations & pin stock to bins.

New to a term?

Words like allocation, backorder, FIFO, and fulfillment order are defined in the glossary.

Looking for exact status and field names?

This page explains the model. For the lookup table of every allocation, hold, and backorder status and field, see the allocation, hold & backorder reference.

What an allocation is

An allocation is a link. Each row ties a product, a warehouse, and a quantity to a demand document. The demand document can be any of:

Linked document	What it commits stock for
Sales Order Line	Units a customer ordered.
Warehouse Transfer Line / Transfer Shipment Line	Units moving to another of your warehouses. See How warehouse transfers work.
Manufacturing Component Line	Components consumed by a build.
Vendor Credit Line	Units set aside to return to a supplier.

Every allocation also carries an allocation type — a free-form tag such as Sales Order, Warehouse Transfer, or Manufacturing. It's intentionally a plain label, not a fixed list, so new demand sources can be added without a rework. Don't confuse it with the allocation's status, which is a fixed set of five values and drives the whole lifecycle below.

A commitment, not a 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 demand, and is that stock on hand or incoming?	When demand is committed (for a sales order, at approve or reserve), and whenever coverage changes
Inventory movements	What stock has physically left the warehouse?	Only when the demand ships or is consumed

Creating or releasing an allocation never moves physical stock and never realizes cost. Those happen only when the demand document ships or is consumed, which writes to the movement ledger. An allocation records intent to consume; the movement records the consumption. There is no "reserved" stock status in SKU.io — commitment is expressed entirely through the allocation statuses below.

The five statuses

Every allocation is in exactly one of five statuses. Two mean "backordered", one means "committed from on-hand stock", and two are terminal.

Status	Meaning	Counts as backordered?	Claims on-hand stock?
Planned	Demand with no stock behind it and no purchase order linked yet — an uncovered shortage.	Yes	No
Awaiting Receipt	Backordered demand linked to an incoming purchase order line that will supply it.	Yes	No
Allocated	On-hand stock committed to the demand. The only status that reduces Available.	No	Yes
Fulfilled	The committed stock has shipped or been consumed. Terminal.	No	No (already consumed)
Cancelled	The commitment was released. A terminal audit row, holding nothing.	No	No

Three rules follow 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 a product has Available.
• Planned and Awaiting Receipt together are the active backorder. A demand line is backordered while it carries either; it's resolved once every allocation on it has been released, fulfilled, or cancelled.
• Cancelled allocations are history, never live. They stay visible as an audit trail of what was once committed, but they hold nothing. When you re-approve a sales order line, SKU.io allocates it afresh precisely because its old allocations are all Cancelled.

The allocation lifecycle

An allocation is born when demand is committed, moves between states as coverage and stock change, and ends either fulfilled or cancelled.

Where allocations start

When demand is committed, SKU.io claims what on-hand stock it can as Allocated and records any remainder it can't cover as Planned — the backordered portion. A single line can split across both: some units Allocated, the rest Planned.

For a sales order, approving the order commits every unallocated product line in one pass, each against its own warehouse. 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 are covered in Approve, reserve, and allocate stock.

To avoid over-stating what's committed, a new allocation for a demand line that already has an active row for the same product, warehouse, and status merges into that row — the quantities sum rather than creating a duplicate. (For a merged Planned row, the priority number reserved for the new row is dropped; the resulting sequence gap is tidied up by a background reshuffle — see Priority below.)

Releasing to Allocated

A release is the key transition: a Planned or Awaiting Receipt backorder becomes Allocated once stock exists to back it. Release can be:

• Partial — when only some of the backordered quantity can be covered. SKU.io reduces the Planned (or Awaiting Receipt) remainder and creates a new Allocated row for the released portion, carrying a reference to the FIFO layer the stock came from.
• Full — when the whole quantity is covered. The existing row transitions in place to Allocated, and any purchase order link it held is cleared, because the stock has now landed and the row no longer represents units still on order.

An invariant worth knowing

Once an allocation has been released against received stock, it can never also point at a purchase order line — the two are mutually exclusive. A background safeguard enforces this on every save, so a row that says "already received" can never also say "still on order."

When an allocation loses its stock

An Allocated claim doesn't physically lock the stock behind it, so another event can consume that stock before the demand ships — a negative inventory adjustment, an assembly, or another order shipping first. When the stock behind an Allocated allocation is gone, SKU.io detects the shortfall and demotes the allocation from Allocated back to Planned, returning the line to the backorder queue so it fills again when stock arrives.

The 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, so you never see 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 stock consumption behind this is explained from the shipping side in How fulfilling moves inventory and realizes COGS.

Terminal states

• Fulfilled — the demand shipped or was consumed. From the sales-order side, this is covered in How fulfilling moves inventory and realizes COGS.
• Cancelled — the commitment was released without shipping: the stock was unreserved, or the demand was cancelled, reverted to draft, or had its warehouse cleared. Cancelled rows remain as an audit trail but hold no stock.

Priority decides who gets stock first

When several backorders compete for the same product, priority decides the order in which they're filled. Priority is a per-product integer sequence carried only on Planned and Awaiting Receipt rows (it's null on Allocated and terminal rows). Lower number = filled first. Every release pass — automatic or manual — walks a product's backorders in priority order.

You manage priority on the Product Analysis panel of the allocation pipeline, under Release Order (drag to reorder). You can drag a backorder up or down, or move it to the top or bottom; SKU.io rebalances the surrounding rows so the sequence stays contiguous. See Work the backorder queue for the task steps.

Two tenant-wide maintenance actions keep the sequence healthy:

Action	What it does
Reset priorities	Renumbers every product's backorders from scratch, seeded either by sales order date (oldest order first — FIFO) or by allocation creation order, depending on the Backorder Priority Method setting.
Compact priorities	Removes gaps left behind when higher-priority rows were released or cancelled, preserving the existing order.

A few subtleties follow from priority being a live sequence:

• Cancelling a backorder closes the gap. When a priority row is cancelled, every later row for that product shifts up by one, so the sequence stays contiguous with no hole where the cancelled row was.
• Reordering a row with no priority does nothing. Allocated and terminal rows have no priority, so a reorder request against them is a no-op.

Purchase orders cover a backorder

A Planned backorder becomes Awaiting Receipt when SKU.io links it to an incoming purchase order line for that product — this is coverage. Coverage doesn't release stock (nothing has arrived yet); it records which incoming PO is on the hook to fill the backorder, and it lets SKU.io show a projected arrival date.

Coverage runs automatically after a sales order is approved and again whenever supply changes. If a backorder loses its coverage — the PO is cancelled, or its incoming stock goes to a higher-priority backorder — the allocation drops back to Planned. Either way, Planned and Awaiting Receipt both count as active backorders; the only difference is whether an incoming PO is on the hook to fill it.

Automatic versus tight (manual) coverage

Coverage comes in two flavors, distinguished by how it was created:

• Automatic coverage is created and maintained by SKU.io. It's torn down and rebuilt whenever supply changes, so the earliest-arriving PO always covers the highest-priority backorder.
• Tight coverage is a manual link you pin by hand — for example, from the PO Builder's Fill Backorders action or by reassigning coverage on a single allocation. Tight coverage is sticky: automatic re-syncs and rebalances leave it untouched, so a deliberate pairing survives.

The Preserve Manual PO Links on Priority Reorder setting controls whether tight coverages survive a priority reset; automatic links are always recalculated.

Which purchase orders can cover

Only PO lines with unreceived quantity on a coverable purchase order can provide coverage. Purchase orders in a draft, closed, cancelled, or voided status are excluded. When you reassign coverage by hand, SKU.io rejects the link with a clear message if:

• the PO line is for a different product than the allocation,
• the PO line has already been fully received, or
• the PO belongs to a draft, closed, cancelled, or voided order.

Split coverage

One demand line can be covered by more than one purchase order — for example, when no single PO line has enough unreceived quantity. In that case SKU.io splits the backorder into one Awaiting Receipt row per covering PO line, and the line is flagged as having split coverage so you can see at a glance that its arrival depends on more than one receipt.

The resolved ETA

Every covered backorder shows an ETA — the projected date the covering stock arrives. SKU.io resolves it in tiers, using the first source that has a date:

1. The active inbound shipment's expected arrival. If the covering PO line is on an open inbound shipment, its expected arrival date wins (the earliest, if several).
2. The purchase order's estimated delivery date. When no inbound shipment date is available, the PO header's estimated delivery date is used.

From the resolved date, each backorder falls into one of four ETA states:

ETA state	Meaning
Has ETA	Covered, with a resolved arrival date in the future (or today).
Late ETA	Covered, but the resolved arrival date is already past (compared against today in your application timezone).
Missing — no date	Covered by a PO, but neither the inbound shipment nor the PO carries a usable date.
Missing — no PO	Not covered by any PO at all — a Planned, uncovered shortage.

The ETA column and the covering-PO column both appear on the allocations and backorder-queue tables; see Work the backorder queue for how to filter by ETA state.

Automatic release and coverage (settings-gated)

The point of tracking backorders precisely is that SKU.io can fill them the moment stock appears — you don't chase them by hand. Two settings on the allocation pipeline's Settings panel control this automation.

Setting	Default	What it does
Auto-Resolve Backorders	On	Inventory arriving from PO receipts, adjustments, and transfers automatically releases matching backorders to Allocated.
Auto-Link POs to Backorders	On	New and edited purchase order lines are automatically linked to uncovered backorders as coverage.
Backorder Priority Method	Sales Order Date (FIFO)	Seeds priority on reset — oldest order first, or backorder creation order.
Preserve Manual PO Links on Priority Reorder	On	Keeps tight (manual) coverages intact when priorities are reordered.

How auto-release works

When Auto-Resolve Backorders is on, any positive inventory event triggers a release pass over the affected product-and-warehouse pool. SKU.io walks that pool's backorders in priority order and releases each one to Allocated, clamped to the pool's real headroom — the on-hand available stock, after subtracting what existing Allocated rows and holds already claim. This clamp is what stops a backorder from being released into a pool that's already fully committed.

Freed stock releases both ways:

• Stock arrives. A PO receipt, positive adjustment, or incoming transfer hands new on-hand stock to the backorders it can now cover.
• Committed stock is freed. When an Allocated row is cancelled or shrunk — for example, a sales order is cancelled or a line is unreserved — the freed units return to the pool, and SKU.io queues a pass to re-fill any backorders that were waiting on that same product and warehouse.

A released sales order line gains its shipment plan at the same moment, so it becomes fulfillable work.

Manual releases surface for review

When you free stock by hand — for example, by unallocating a sales order line — SKU.io shows an Eligible Backorders — Release Now? prompt listing the waiting orders the freed stock could fill, so you decide whether to release them immediately or hold the stock.

Two protections during release

A release pass never touches a demand line that's already fully accounted for (shipped or cancelled), so freshly received stock is never phantom-committed to terminal demand. And when a large receipt fans the release work across parallel workers, per-row side effects are suppressed inside each chunk and reconciled once at the end, so overlapping sales orders can't deadlock.

Turning automation off

Disabling Auto-Resolve Backorders forces all resolution to be manual — stock arrives, but backorders stay Planned or Awaiting Receipt until you release them yourself with Release Allocations or Release Selected on the backorder queue. Disabling Auto-Link POs to Backorders stops automatic coverage; only manual (tight) links from the PO Builder are created.

Manual and tracked-job actions bypass these gates by design: when you click Release Selected, SKU.io honors it even if auto-release is switched off, because you asked for it explicitly.

From a sales order

Everything earlier on this page applies to a sales order line like any other demand. This section covers what's specific to how you see and act on it from the order.

The Allocations tab

To see what's committed to an order, open the order and select its Allocations tab. Each row shows the product, warehouse, quantity, and allocation status — including Cancelled rows from earlier approvals, kept as history.

A backorder is a state, not a record

SKU.io has no separate backorder record. A line is backordered because it carries a Planned or Awaiting Receipt allocation, and its backorder state is read from those allocations. That's why you never set it by hand: it updates the moment the allocations change. Line-level fulfillment state works the same way; see How sales order status works.

A backordered line has no shipment plan yet

A Planned allocation is pure demand, so it doesn't create a fulfillment order line — there's nothing to ship. The line gains a shippable plan only once its stock is Allocated, which is why backordered lines don't appear as fulfillable work until they're released. See Two-tier fulfillment: intent vs execution.

The exception is a product and warehouse allowed to carry inventory debt: there, a backordered line on the order's Fulfillment tab also offers Ship Anyway, which ships the units now and records the shortfall as a debt claim that the next receipt repays.

Where backorders show on orders

• On the order line. A backordered line shows a red Backordered chip. Expanding its coverage detail shows 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.
• In the order's backorder summary. An order shows its earliest and latest covered ship-by dates, drawn from the ETAs of the POs covering its backordered lines.
• In the sales orders list. The Backorder Status advanced filter offers active backorders (Any Active Backorder, plus covered-versus-uncovered and scheduled-versus-unscheduled options), Was Backordered (resolved), and Never Backordered. To match on a PO number, use the two separate advanced-filter columns Backorder Released by PO# and Covered by PO# — not the Backorder Status dropdown. See List columns and filters.

Active versus resolved backorders

A line's backorder is active while at least one Planned or Awaiting Receipt allocation remains on it. Once every allocation on the line has been released, fulfilled, or cancelled, 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 marks what can't ship yet.

The backorder warning on the order line itself is narrower than the filter. It shows only while part of the line is uncovered: a Planned allocation that no purchase order is bringing in. Once an incoming purchase order covers the whole shortfall, the line shows that coverage and its ETA instead of a shortage warning, but it still counts as an active backorder in the Backorder Status filter until the stock arrives.

Backorders and the end of an order's life

• Active backorders block closing. SKU.io refuses to close an order while any line still has a Planned or Awaiting Receipt allocation. 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 each line fresh.
• Clearing a line's warehouse releases its allocations. Removing the warehouse from a line cancels that line's active allocations, since a claim can't exist without a location to claim from. See Warehouse routing and the warehouse lock.

Where allocations and backorders surface

The same allocation ledger feeds several views across the app:

• A product's stock view rolls active allocations into the Allocated column — see Stock states and View a product's stock across warehouses.
• The allocations list lets you browse every allocation, filter by status and demand document, and pin Allocated stock to specific bins — see Browse allocations & pin stock to bins.
• The backorder queue / allocation pipeline is the priority-ordered workspace for every active backorder, its coverage, and its ETA — see Work the backorder queue.
• The sales order shows its allocations on the Allocations tab, plus backorder chips and coverage detail on each line — see From a sales order.

Next steps

• Work the backorder queue / allocation pipeline
• Browse allocations & pin stock to bins
• Allocation, hold & backorder reference
• Stock states: on-hand, available, allocated, on-hold, non-sellable, incoming & in-transit
• Place & manage stock holds
• How warehouse transfers work
• Approve, reserve, and allocate stock
• How fulfilling moves inventory and realizes COGS
• What inventory debt is, and when you want it instead of a backorder
• The inventory movement ledger
• How sales order status works
• Sales order status reference
• Inventory overview