Why a Warehouse Receipt Isn't the Same as a Purchase Receipt
Say “post the receipt” to two different Business Central users and they may genuinely be describing two different documents, two different screens, and — this is the part that actually matters — two different moments at which the goods become available to sell. Neither of them is wrong. Which one applies depends entirely on how the receiving location is configured.
Four ways to receive the identical purchase order
Business Central documents exactly four methods for receiving items, distinguished by two independent location settings — Require Receive and Require Put-away, both togglable per document type (purchase, sales return, service, transfer):
Method A — post receipt and put-away straight from the order line. Neither toggle is on. There’s no separate warehouse document at all; posting the purchase order line itself records the receipt. This is “no dedicated warehouse activity” — the bottom rung of the complexity ladder described in warehouse topology, explained.
Method B — post from an inventory put-away document. Require Put-away alone is on. One inventory put-away document exists per source order, order-by-order, with no consolidation across multiple orders.
Method C — post from a warehouse receipt document. Require Receive alone is on. A warehouse receipt can now consolidate several purchase, sales-return, or transfer orders into a single receiving pass — this is the rung where receiving finally starts looking like a real, multi-order receiving dock rather than one order at a time.
Method D — post the receipt from a warehouse receipt, then post the put-away separately from a warehouse put-away document. Both toggles are on. This is the advanced configuration, and it’s the one where receiving and put-away genuinely become two separate events, not just two separate screens for the same event.
The rest of this article is about methods C and D — the two that actually introduce a distinct warehouse receipt document, as opposed to posting a purchase or transfer order’s own line directly.
What a warehouse receipt actually is
A warehouse receipt exists to gather the lines of one or more released source documents — purchase orders, sales return orders, transfer orders — into a single receiving pass, because a real receiving dock is rarely unloading exactly one purchase order’s freight at a time off one truck. It can be created two ways: push, using the Create Warehouse Receipt action directly on a source document for order-by-order work, or pull, where a source document is simply Released to signal it’s ready, and a warehouse employee later gathers one or more released documents onto a warehouse receipt using Get Source Documents (pick specific released documents from a list) or Use Filters to Get Src. Docs. (apply a saved filter — for instance, “all purchase orders for vendor X” — and pull in everything that matches at once). The filters are reusable and can be modified any time, which matters once a warehouse has a recurring pattern of grouping receipts by vendor, carrier, or dock schedule.
Quantity to receive doesn’t start at zero
Once source document lines land on a warehouse receipt, the Qty. to Receive field on each line defaults to that line’s full outstanding quantity — not zero. That default exists so a receiving clerk working a clean, exactly-as-ordered delivery doesn’t have to retype every quantity; it becomes a liability the moment a delivery is partial, over, or scanned line by line, because every line not explicitly touched is already sitting at “receive everything.” Business Central provides an explicit Delete Qty. to Receive action to zero every line out first — useful precisely for a barcode-scanning workflow that means to fill quantities in one confirmed scan at a time rather than trust the full-outstanding default — and an Autofill Qty. to Receive action to restore the outstanding quantities afterward if needed.
Receiving more than was ordered has its own accommodation: if an entered quantity exceeds what’s outstanding, and an over-receipt tolerance code is assigned to the line, the excess is captured in a dedicated Over-Receipt Quantity field rather than simply being rejected — but only within whatever tolerance that code allows. Exceed the tolerance and the over-receipt isn’t permitted at all.
Posting updates the source document — and, at the advanced rung, doesn’t finish the job
Posting a warehouse receipt updates the relevant quantity fields on the source purchase, transfer, or sales-return document and adds the received items to inventory. That much is common to methods C and D. What differs between them is what “added to inventory” actually means for whether those items can be picked.
Under method C — warehouse receipt only, no separate put-away requirement — receiving is the whole event; the goods are received and, subject to ordinary availability rules, ready to be worked with. Under method D, receiving items via a warehouse receipt is explicitly not the same as making them available to pick: Business Central’s own documentation is direct that “you can’t pick them until they’re put away.” A location running method D can perfectly correctly show a purchase order as fully received while every unit of it is still sitting, un-picked, in a receiving bin — because a separate warehouse put-away document has to be created and posted before that stock is genuinely available to a downstream pick. Business Central even offers a Post and Print action specifically for this handoff: it posts the receipt and immediately prints the resulting document as a put-away instruction showing where each item should go, precisely because the two steps are meant to happen in close sequence, not as a single combined act.
This is the honest core of the distinction this article is named for. A plain purchase-order receipt (method A) and a warehouse receipt at an advanced, put-away-required location (method D) can represent the exact same physical event — a truck getting unloaded — and still differ in a way that isn’t cosmetic: one of them makes the stock available the instant it posts; the other deliberately holds it back until a second, distinct document confirms it’s been physically stored. Confusing the two is exactly how a planner ends up promising stock that’s technically “received” but not actually reachable by anyone on the floor yet.
Zone and bin codes follow their own separate rule
If bins are mandatory at the receiving location, the bin code that lands on a warehouse receipt isn’t sourced the same way at every rung. At a location using directed put-away and pick, Business Central pulls the receiving bin from the location card’s own receipt-bin setting — and if the item’s warehouse class doesn’t match that bin’s class, the bin code is deliberately left blank rather than assigned somewhere wrong. At locations not using directed put-away and pick, the priority reverses: if no receipt bin is set on the location, Business Central falls back to whatever bin code the source document itself specifies. Two different rungs, two different tie-breaking rules for the exact same blank-bin-code problem.
Why this isn’t a maturity signal either
As with the broader complexity ladder, none of the four receiving methods is objectively better than the others — they trade consolidation and separation-of-duties for setup and process overhead, and a business that never receives more than one purchase order at a time from any given vendor has little to gain from consolidated receiving, let alone a fully separated put-away step. The question worth asking of any receiving process, including a scanning app layered on top of it, is which of the four methods the location is actually configured for right now — and whether “received” on that floor genuinely means “available to sell,” or means “arrived, awaiting put-away.” Those are different facts, and only reading the location’s own setup answers which one applies.
Where this goes next
The mirror-image document on the outbound side — and the equivalent question of when “picked” actually means “shipped” — is covered in warehouse shipments vs. sales shipments, explained. For where receiving and put-away sit on the broader complexity ladder, see warehouse topology, explained. For what actually gets written the moment any of these documents posts, see what “posting” actually means in Business Central inventory.
Key terms
New to the vocabulary? Warehouse receipt, Put-away, Bin, and Inventory pick / put-away are defined in the glossary.
Further reading — Microsoft Learn
Receive Items — the four receiving methods, over-receipt tolerances, and the zone/bin code rules described above, in full. Manage Warehouse Activities — receiving in context alongside the rest of the inbound and outbound warehouse flow.