Allocations & backorders

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.

This page explains the allocation model from the inventory side: 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, and the settings that let SKU.io release and cover backorders automatically. It's the conceptual companion to two how-to guides: Work the backorder queue / allocation pipeline and Browse allocations & pin stock to bins.

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 polymorphic link. Each row ties a product, a warehouse, and a quantity to a demand document through a link_type / link_id pair. 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 schema change. Don't confuse it with the allocation's status, which is a fixed set of five values and drives the whole lifecycle below.

Allocation is a commitment, not a movement

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

Two 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.

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.

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."

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 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.

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 — 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.

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.

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 exposes its own backorder chips and coverage detail — covered from the order side in Inventory allocation and backorders.

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
• Inventory overview