Receive a transfer (full, partial & exceptions)

Receiving a transfer records that in-transit stock has arrived at the destination warehouse. It removes the received units from In Transit and adds them to On Hand at the destination, using date-preserving FIFO layers so cost carries across the move. This guide covers a full receipt, a partial receipt, quick-receiving an unshipped transfer, blemished and negative receipts, editing and deleting receipts, closing a short receipt with an accounting discrepancy, and every over/under and auto-close rule.

A few terms used on this page

• Shipment — the record created when you ship a transfer. Receiving always draws down a shipment; you can receive across several shipments of one transfer.
• Receipt — the record a receive action creates against a shipment. One receive creates one receipt per shipment involved, each with its own receipt lines.
• Receipt line — a per-product line on a receipt, carrying the received quantity and the destination FIFO layer.

For the model behind all of this, see How warehouse transfers work. For the states this page moves stock between, see Stock states.

Before you begin

Requirement	Why it's needed
Receive warehouse transfers permission (warehouse_transfers.receive)	The Receive action and the receipt-editing endpoints are gated on it.
The transfer is Open	You can't receive a Draft or Closed transfer. Receiving a draft is rejected ("Warehouse transfer must be open to receive shipments"); a closed transfer is already fully received.
A shipment exists (or the transfer qualifies for quick-receive)	Receiving draws down a shipment. If none exists and the transfer is open, unshipped, and non-Amazon, SKU.io auto-creates one — see Quick-receive an unshipped transfer.
A non-channel-managed destination	Transfers into Amazon FBA, Amazon AWD, or Walmart WFS are received automatically from the channel — a manual receipt is rejected. See Channel-managed destinations receive automatically.

Receive a shipment

Use this when goods have arrived and you're recording them against an existing shipment.

1. Open the transfer and click Receive at the top of the page. The Receive Items drawer opens listing each shipped line with its Pending quantity (still to receive).
2. Set the Received Date. It defaults to today and is required — a receipt date in the future is rejected.
3. For each line you're receiving, set its Receive Qty. Lines start selected at their full pending quantity. Use Select All to receive everything, or clear a line to leave it out.
4. Optionally set a destination Location (bin) per line — the received units land in the bin you choose (or the product's preferred bin, then default storage, if you leave it blank). See Move stock between bins.
5. Click Confirm Receipt.

What you'll see: the receipt is recorded ("Items received successfully"), the drawer closes, and the transfer refreshes. In-transit stock at the destination drops by what you received and On Hand rises by the same amount, each on a FIFO layer that preserves the source cost. If every line is now fully received, the transfer closes (see A full receipt auto-closes the transfer); otherwise it stays Open and Partially Received.

Receiving across multiple shipments

If a transfer was shipped in more than one shipment, a single receive creates one receipt per shipment it touches. Each receipt owns only its own product lines.

Quick-receive an unshipped transfer

For a local or immediate move you don't have to ship first. When a transfer is Open, Unshipped, and neither warehouse is Amazon, the sticky bar shows Receive directly. Clicking it opens the same drawer, and confirming a receipt auto-creates a shipment covering exactly the quantities you receive — so you skip the explicit Ship step. The drawer shows a notice: "A shipment will be auto-created for the items you receive here — useful for instant / local transfers."

The auto-generated shipment covers only the received quantities, so a quick-receive of part of the transfer leaves the rest unshipped and the transfer Partially Received. Quick-receive is never offered for Amazon FBA/AWD transfers.

Ship part now, receive the rest later

You don't have to receive everything at once. Receive the units that arrived and come back for the balance.

• Receive fewer units, or leave a line out. Lower a line's Receive Qty or clear it, then confirm. The transfer lands at Partially Received and stays Open.
• Receive the remainder later. Reopen the Receive Items drawer whenever more stock arrives and receive the outstanding Pending quantity. Repeat until complete.

A transfer is treated as fully received once the total received reaches the active quantity, excluding any quantity that was shipped before the transfer's start date. Anything short of that threshold keeps it Partially Received.

Receive blemished units

When part of a line arrives damaged, mark that portion Blemished during the receive instead of adding it to sellable stock.

1. In the Receive Items drawer, open a line's blemished action (Mark as Blemished). The Blemished Items dialog opens.
2. Enter the blemished Qty, a unique blemished SKU, a condition (for example Cosmetic Damage, Damaged Packaging, Water / Moisture Damage), and an optional Reference.
3. Confirm the blemished entry, then Confirm Receipt as usual.

What happens: SKU.io creates a new blemished product with the SKU you entered and posts a negative inventory adjustment against the original product's transfer line at the destination — moving that quantity out of the received-as-good stock and into the blemished SKU. The blemished SKU must be unique, and blemished units count toward the received total, so they're validated against the shipped quantity the same way received units are.

Blemished handling runs once, after all lines are added

SKU.io processes the blemished entries once per receipt, after every product line is on the receipt — so a blemished entry only ever applies to the receipt that actually contains its product (fixes Freshdesk #1896, where a shared multi-shipment receipt could dereference a line that hadn't been added yet).

Correct an over-received layer with a negative receipt

If you received too much on an earlier receipt, enter a negative quantity for that product on a new receive to pull the excess back out. SKU.io posts a negative inventory adjustment ("Negative warehouse transfer receipt.") against an existing receipt FIFO layer, reducing destination On Hand, and subtracts it from the transfer's total received.

A negative receipt needs a prior receipt to correct against

The correction targets an existing receipt FIFO layer for that product whose original quantity covers the shortfall. If no matching prior receipt exists, the receive is rejected with a clear HTTP 422 — "This negative receipt cannot be recorded because there is no matching prior receipt to correct against. Record the positive receipt first, then apply the negative adjustment." Record the positive receipt first, or reverse the specific receipt instead.

Edit a received quantity

To change the quantity on a single receipt line after the fact — up or down — use the receipt detail's line-quantity editor. It runs a preview → confirm flow so you can see the downstream effect before committing.

1. Open the receipt from the transfer's Receipts and find the line to change.
2. Enter the new quantity (a whole number; 0 removes the line's received units). SKU.io returns a preview showing the delta, the resulting in-transit quantity at the destination, and whether the edit needs extra acknowledgement.
3. Confirm. Because any change carries implications, the save requires confirmation; if you don't acknowledge it, the request is refused with HTTP 409 and the preview is returned so you can review and retry with confirmation.

The editor caps an increase at what's still available on the shipment and transfer lines — it won't let a line exceed the shipped quantity minus what other receipts already took. When the new quantity forces already-consumed downstream FIFO usages to be re-spread, the preview flags requires_redistribution; you must pass redistribute usages to proceed, or the save returns a 409 again.

Edit vs. re-receive

The line editor is the tool for adjusting an existing receipt line's number. To add or remove whole products, or change the receipt date, update the receipt instead.

Update a receipt

To change a receipt's products, quantities, or date wholesale, update it. The transfer must be Open.

• Change the receipt date. Updates the received-at date on the receipt and re-dates its inventory movements.
• Remove a product. De-listing a product from the receipt deletes its receipt line and reverses the associated inventory movements.
• Change a kept product's quantity. Updates the receipt line and its movements to the new number.

An updated quantity is validated the same way as a new receipt — it can't push a product's total received past what was shipped. After the update, SKU.io recomputes the shipment's fully received flag and the transfer's receipt status.

Delete a receipt

To undo a receipt entirely, delete it. SKU.io reverses its receipt lines and movements, clears the shipment's fully received flag if it was set, and recomputes the transfer's receipt status.

Deletion is blocked when the receipt's stock was already consumed

Before deleting, SKU.io checks whether any FIFO layer the receipt produced has been consumed downstream — by a sales fulfillment, an outbound transfer, or an adjustment. If it has, deletion is refused with HTTP 422 and a blocking_lines list naming each product and the quantity consumed: "Cannot delete this receipt — N units from it have already been consumed… Reverse the downstream consumption first, or use an inventory adjustment to correct the records." Reverse the downstream movements first, then delete.

The check deliberately excludes the receipt's own in-transit cancellations and its own blemish-out adjustments — those are reverted automatically with the receipt, so they don't count as downstream consumption.

Close a short receipt with a receiving discrepancy

When a transfer arrives short and you don't expect the balance, record a receiving discrepancy to close the shortfall in your books. This posts a RECEIVING_DISCREPANCY accounting transaction for the unreceived quantity.

1. On the transfer, choose the receiving-discrepancy action.
2. Optionally set a transaction date to control the accounting period. If you leave it blank, SKU.io uses the default date.
3. Confirm.

This requires the Receive warehouse transfers permission (warehouse_transfers.receive).

When a discrepancy can't be created

• Amazon-to-Amazon transfers are blocked — Amazon reconciles those internally ("Receiving discrepancies cannot be created for Amazon-to-Amazon transfers").
• A missing nominal-code mapping stops the post with an error telling you which mapping to add.
• A discrepancy that already exists for the transfer is rejected rather than duplicated.

Rules and exceptions

A receipt can't exceed what was shipped

Every received quantity — including blemished units — is validated against the total shipped for that product minus what's already been received. Try to receive more and the receive is rejected ("…quantity for product must not exceed total quantity shipped for product"), and the drawer surfaces an over-receive warning listing the offending lines. (The single-line quantity editor is the one place an over/under is allowed, and only behind explicit confirmation.)

A full receipt auto-closes the transfer

When the total received reaches the transfer's active quantity (excluding quantity shipped before the start date), SKU.io marks the transfer Received, closes it, and cancels any leftover non-fulfilled allocations on its lines. By the time a transfer is received and closed the goods have landed at the destination, so any remaining allocation against the source is a stale claim — clearing it prevents phantom Allocated rows that the inventory-health checks would otherwise flag. See Allocations & backorders.

Channel-managed destinations receive automatically

Transfers into Amazon FBA, Amazon AWD, or Walmart WFS are received automatically from the channel — their receipt status flows from Amazon's pending-inbound reconciliation or the WFS inbound, and the destination holds no SKU-side on-hand. The manual Receive action isn't offered for these in the app, and a manual receipt sent to the API is rejected with HTTP 422: "This transfer's destination is managed by <channel>; its receipt is recorded automatically from the channel, not received manually."

Receiving needs a shipment first

Receiving always draws down a shipment. For a non-channel-managed transfer that has no shipment and can't auto-generate one, the receive is rejected with a clear HTTP 422 telling you to ship it first — "…cannot be received because it has not been shipped yet. Ship the transfer before recording a receipt." This is an actionable state, not a server fault: ship the transfer, then record the receipt.

Next steps

• Close a transfer, add costs & post accounting — finalize the transfer's cost and books after receipt.
• Ship a transfer — the step that creates the shipment you receive against.
• View the movement ledger — see every in-transit-out and receipt-in movement the receive posted.
• Browse FIFO layers — inspect the destination layers a receipt created.
• Transfer statuses, fields & list — every receipt and shipment status value.