Close a transfer, add costs & post accounting

Once a transfer is created and moving, there are a handful of ways to finish it, cost it, and tidy it up. You can close a draft you never processed, revert an open transfer back to an editable draft, attach a landed-cost bill so freight and duty land in COGS, generate the accounting transactions that sync to your books, and archive or delete transfers you're done with. This guide covers all of them, plus the rules that stop you from unwinding a transfer whose goods have already left for Amazon or Walmart.

For how a transfer moves through draft → open → shipped → received in the first place, see How warehouse transfers work. To build and open one, see Create a transfer.

Which action do I need?

These actions look similar but do very different things. Pick by intent.

You want to…	Use	Effect on inventory	Reversible?
Abandon a draft you never shipped or received	Close Order (Never Processed)	None — the draft never moved stock	Yes — Delete it, or leave it closed
Send an open transfer back to an editable draft	Revert to Draft	Reverses shipment movements, cancels allocations	Yes — re-open it
Add freight, duty, or handling to a transfer's cost	Add Landed Cost Invoice (bill)	Prorates onto destination FIFO layer cost	Yes — edit or delete the bill
Push in-transit and inventory entries to your books	Generate (Accounting tab)	None — builds accounting transactions	Yes — regenerate
Hide a transfer from the working list	Archive	None	Yes — Unarchive
Permanently remove a transfer	Delete	Reverses every movement, receipt, and FIFO layer	No — permanent for non-Amazon transfers

Before you begin

• Open the transfer from Inventory → Warehouse Transfers, or select rows on that list for the bulk actions.
• On the transfer detail page, the finishing actions live in the Actions menu (top right); the landed-cost and accounting actions live on their own tabs. On the list, archive and delete appear on the bulk-actions bar once you check one or more rows.
• What you can do depends on the transfer's status and your permissions. Transfers use granular, per-action permissions — see Permission gates for the full list.

Action	Permission enforced	Available when the transfer is…
Close Order (Never Processed)	Update warehouse transfers	Draft
Revert to Draft	Update warehouse transfers	Open and unreceived (non-channel-managed only)
Add / edit a landed-cost bill	Update warehouse transfers	Any status
Generate accounting	(available on the detail page)	Shipped or received
Archive / Unarchive	Update warehouse transfers	Any status
Delete	Delete warehouse transfers	Any status (usage-checked)

Close a never-processed draft

Use this when you built a draft transfer that you're never going to act on — a plan that changed, a duplicate, or an abandoned idea — and you want to take it out of circulation without deleting the record. Because a draft has never allocated or moved stock, closing it changes nothing about inventory. It sets transfer_status to Closed and nothing else.

1. Open the draft transfer.
2. Click Actions, then Close Order (Never Processed).
3. In the confirmation dialog, click Close Order.

What you'll see: the transfer's status changes to Closed. It stops appearing in your open work and can't be edited, but the record — lines, notes, custom fields — is preserved.

Only a draft can be closed this way

Close Order (Never Processed) appears only while the transfer is a Draft. An open transfer that's mid-flight can't be closed here — either finish receiving it, close it with a receiving discrepancy, or revert it to draft first.

Revert an open transfer to draft

Reverting takes an open transfer all the way back to an editable Draft — use it to cancel a transfer mid-flight, before anything has been received, so you can restructure or scrap it. This is heavier than closing a draft: SKU.io has to unwind whatever the open transfer already did.

1. Open the transfer.
2. Click Revert to Draft in the action bar.

What you'll see: the transfer returns to Draft, with its shipment status reset to Unshipped and receipt status to Unreceived, and the Fully shipped and Fully received timestamps cleared. Behind the scenes SKU.io:

• deletes any shipments, which reverses their inventory movements (and restores the source FIFO layers they consumed);
• cancels the line-level allocations created when the transfer was opened, handing the reserved stock back at the source;
• resets all three statuses and clears the timestamps.

For an Amazon FBA transfer, there are no SKU-side shipments to delete — instead SKU.io unreserves the reservation movements on each line, returning the reserved units to available at the source.

Revert is blocked once goods have physically left

You can't revert a transfer whose stock is already out the door. See When revert is blocked below for the exact rules — an FBA transfer with shipments or a pending inbound, a shipped Walmart WFS transfer, and any transfer whose FIFO layer has already been consumed downstream all refuse the revert.

When revert is blocked

Revert-to-draft only makes sense while the goods are still recoverable at the source. Three cases stop it:

Situation	What happens	How to proceed
Amazon FBA transfer with shipments or a pending inbound	Rejected — the goods are already handed to Amazon. Error: "Cannot make FBA warehouse transfer draft while shipments or pending inbound records exist. Please delete shipments first." (FbaWarehouseTransferHasShipmentsException)	Delete the shipments / pending inbound first, if they haven't already been actioned by Amazon.
Shipped Walmart WFS transfer	Rejected with the same exception — a WFS shipment posts a source -active movement, so the units have left for good. An unshipped WFS transfer can still revert (it only cancels the open-time allocations).	The stock is with Walmart; reconcile through the WFS inbound rather than reverting.
A source FIFO layer has already been used	Rejected — reversing would corrupt a layer that a later sale or transfer has already drawn from. Error names the SKU (UsedFifoLayerException).	The transfer's cost is already realized downstream; delete or close instead of reverting.

The Revert to Draft button is hidden entirely for channel-managed destinations (Amazon FBA/AWD, Walmart WFS) in the standard action bar, so you'll usually only meet these errors on edge-case or API-driven flows.

Attach a landed-cost bill

A transfer's own movements carry the product cost from source to destination, but freight, duty, insurance, and handling aren't part of that. To fold those into the destination inventory value, attach a landed-cost invoice (a bill) to the transfer. SKU.io prorates the bill across the transfer's shipment lines and rolls it into the destination FIFO layer cost, so the receiving warehouse's COGS reflects the fully landed cost.

1. Open the transfer and go to the Landed Costs tab.
2. Click Add Landed Cost Invoice. (You can also use the OCR upload button to pull an invoice from a PDF or photo.)
3. Fill in the invoice details:
   • Supplier (for example, the freight forwarder or customs broker)
   • Invoice number and invoice date
   • Currency and, if it differs from your base currency, the exchange rate
   • The invoice lines (each cost and its amount)
   • The proration method — how the total is spread across the transferred products (for example, by value or by quantity)
4. Save the invoice.

What you'll see: the bill appears in the Landed Costs table with its supplier, invoice number, date, allocated percentage, and proration method. The prorated cost is added to the destination FIFO layers, raising the landed cost of the received units.

A bill belongs to one transfer

Each landed-cost bill is linked to the transfer you created it on. Fetching or editing a bill under a different transfer returns 404 Bill not found for this warehouse transfer — the bill and the transfer must match.

Landed costs, not financial lines

Third-party costs on a transfer go on a landed-cost invoice, not on transfer "financial lines" (that older mechanism is disabled for transfers). Bills are the supported way to get freight and duty into transfer COGS. To review or correct the resulting cost, see Revalue COGS and FIFO layers & how COGS is realized.

Generate accounting transactions

Shipping and receiving a transfer create the inventory movements; generating accounting transactions turns those into the journal entries your accounting integration syncs. A transfer has two kinds: the shipment (in-transit) transaction that moves value into an in-transit account, and the receipt (inventory) transaction that lands it at the destination.

1. Open the transfer and go to the Accounting tab.
2. For any shipment or receipt that shows No accounting transaction generated, click Generate.

What you'll see: SKU.io builds the missing transactions and reports how many it generated (for example, "2 accounting transaction(s) generated successfully."). Entries that already exist are left untouched, so you can run this repeatedly to fill in only what's missing — it never duplicates.

Only missing transactions are built

Generating skips any shipment or receipt that already has an accounting transaction. If you've changed a landed cost and want the numbers refreshed, review the existing transaction from the Accounting tab rather than expecting Generate to overwrite it.

Archive & unarchive transfers

Archiving tucks a finished or abandoned transfer out of your default list without deleting it. It's a soft flag (archived_at) — the record and all its history stay intact, and you can bring it back at any time.

Archive a single transfer

1. Open the transfer, click Actions, then Archive. (Where surfaced, archive/unarchive is also available from the list row.)

Archive in bulk

1. On Inventory → Warehouse Transfers, check the transfers you want to archive.
2. On the bulk-actions bar, choose Archive (or Unarchive to restore).
3. To act on every transfer matching your current filters — not just the checked rows — switch the scope toggle to All. SKU.io resolves the full filtered set and archives all of it.

What you'll see: archived transfers drop out of the default view. Use the Archived filter on the list (exclude / only / all) to hide, isolate, or include them.

Archiving an already-archived transfer

If a transfer is already archived, archiving it again returns a warning rather than an error — nothing changes and the transfer stays archived. The same applies to unarchiving one that isn't archived.

Delete a transfer

Deleting removes a transfer and reverses everything it did to inventory. Use it for transfers entered by mistake. Unlike archiving, this is destructive.

1. Open the transfer, click Actions, then Delete (or select rows on the list and choose Delete on the bulk-actions bar).
2. Confirm in the dialog.

What you'll see: the transfer is removed. As it goes, SKU.io cascades the cleanup:

• deletes the Amazon pending inbound (and its items, shortage, and related accounting);
• deletes the shipments, which reverses their movements and FIFO layers, and removes their receipts and shipment lines;
• deletes the transfer lines and any attached landed-cost bills;
• unlinks any Amazon inbound shipments (old FBA, new FBA, and AWD) that referenced the transfer, without deleting those shipments.

Non-Amazon deletes are permanent

A regular transfer is force-deleted — hard-removed with no soft-delete recovery. Only Amazon FBA-inbound placeholder transfers are soft-deleted (they can be restored). Be sure before you delete a non-Amazon transfer; there's no undo.

Check whether a transfer can be deleted

A received transfer may be "used" — a later sale, assembly, or onward transfer may have already consumed the stock it brought in, in which case reversing it would corrupt those downstream records. The list's delete flow pre-checks this for you before committing.

• SKU.io runs a per-line deletable probe on each selected transfer. Unreceived transfers are always deletable (they've moved nothing yet).
• If a transfer's received stock has been used, the check returns a reason naming the transfer number and the SKU that blocks it, and that transfer is held back from deletion.

If a delete does hit used stock server-side, it's rejected with a message identifying the SKU (a transfer FIFO used error) rather than partially unwinding.

Permission gates

Warehouse transfers use granular, per-action permissions, so you can let a role ship without letting it delete, or import without letting it receive. Buttons you don't have permission for are hidden in the UI, and the API enforces the same gates.

Capability	Permission
Create / duplicate a transfer	warehouse_transfers.create
Edit, open, revert to draft, close draft, archive/unarchive	warehouse_transfers.update
Ship / mark as shipped / delete a shipment	warehouse_transfers.ship
Receive / update or delete a receipt / record a discrepancy	warehouse_transfers.receive
Delete a transfer	warehouse_transfers.delete
Import transfer lines	warehouse_transfers.import
Export the transfer list	warehouse_transfers.export

Ship and receive are separate permissions — a warehouse clerk can be allowed to receive incoming transfers without being able to create outbound shipments, and vice versa.

Moving stock between bins within a warehouse is a different feature with its own gate: location transfers require the inventory inventory.transfer permission, not any warehouse_transfers.* permission.

Walmart WFS transfers are channel-managed

A transfer whose destination is a Walmart WFS warehouse is driven by Walmart's inbound lifecycle, not by manual actions in SKU.io. Two things follow:

• You can't manually ship it. Shipping is posted by the WFS inbound (a source-only -active movement — the WFS warehouse holds no SKU-side on-hand), so a manual Ship is rejected. The Ship button is hidden for WFS destinations.
• You can't manually receive it. Receipt is reported by Walmart. A manual Receive is rejected with "This transfer's destination is managed by Walmart WFS; its receipt is recorded automatically from the channel, not received manually." (HTTP 422). The Receive button is hidden too.

The same holds for Amazon FBA and AWD destinations — receipt flows in from the channel's pending-inbound and ledger reconciliation, never through the manual receive endpoint. See Receive a transfer for how channel-managed receipts settle.

Next steps

• How warehouse transfers work — the full draft → open → shipped → received model
• Transfer statuses, fields & list — every status value and column
• Ship a transfer and Receive a transfer
• FIFO layers & how COGS is realized and Revalue COGS — how landed costs reach inventory value
• View the movement ledger — the audit trail a revert or delete writes
• Move stock between bins (location transfers) — the intra-warehouse alternative