Direct answer

An inbound delivery in SAP EWM is the warehouse execution document used to plan and monitor goods arriving at the site. It links expected products and quantities with receiving actions such as arrival, unloading, goods receipt and putaway. The document provides context for warehouse requests and tasks; it does not by itself prove that a physical pallet has been checked or stored correctly.

Start with what is expected to arrive

A buyer orders components and the supplier may send an advanced shipping notification (ASN). Depending on integration and configuration, that information contributes to an inbound delivery in SAP S/4HANA and to the inbound delivery used in EWM. In decentralized scenarios an inbound delivery notification may be part of the sequence; embedded EWM can use a different hand-off. The design should be described in the context of the customer's deployed architecture.

An expected delivery provides supplier, product, quantity, destination and other process data. It enables capacity planning at the receiving dock, but expected quantities are not automatically accepted quantities. That distinction is the starting point for receiving controls.

What the receiving team does when the vehicle arrives

Dock personnel identify the truck or transportation unit, find the appropriate inbound delivery, check documents and inspect the actual packages. They may record arrival and unloading activities, compare planned with received quantities, inspect visible damage and resolve missing or unexpected handling units. Warehouse labels and scan points should match how the goods are physically handled.

A useful example is an inbound delivery for 100 cartons when only 98 arrive. Staff should record the physical difference and follow the configured tolerance and exception process. Posting the planned 100 merely because it appears in the expected delivery would obscure the shortage.

Receiving clerk comparing inbound paperwork with cartons unloaded from truck
The receiving control is a comparison of expected and actual goods, not a checkbox on the document.

Goods receipt and putaway are different milestones

Goods receipt records acceptance of inbound stock and can create inventory and financial postings in the integrated system. Putaway moves material from the receiving area or intermediate location to its destination bin through warehouse tasks. The timing of goods receipt relative to task confirmation depends on the process setup: SAP Learning documents both explicit goods-receipt posting and scenarios that trigger it during task confirmation.

Do not confuse a completed goods receipt with a completed putaway. The physical stock may still be on the dock or in a staging area. The inbound delivery and related warehouse activities carry statuses that help distinguish unloading, putaway planning and final storage movement.

A practical five-checkpoint lifecycle

Think of the checkpoints below as a business review model rather than a fixed list of transaction codes. A deployment may introduce deconsolidation, quality inspection, serial-number checks, repacking or cross-docking. The key is to preserve the correspondence between document state, inventory posting and warehouse execution.

Five-stage timeline of notice, inbound delivery, unloading, goods receipt and putaway
Each checkpoint transfers responsibility and creates an opportunity to catch a mismatch.

Which records and people need to agree?

  • Procurement: supplier commitment, purchase order and expected quantity.
  • Receiving: dock arrival, packaging, actual count and damage evidence.
  • Warehouse operations: HU identification, warehouse task creation, confirmation and final bin.
  • Inventory and finance: accepted goods receipt, discrepancies, reversals and accounting consequences.

For a controlled hand-off, the receiving team must know who can correct an inbound-delivery quantity, who approves exceptions, how partial goods receipts are treated and how the record is synchronized with the enterprise system. The correct choice depends on whether the discrepancy is physical, documentary or a master-data problem.

Example: one truck, two different exceptions

Consider 20 pallets due at 10:00. Nineteen arrive on time and one is delayed. If the process supports a partial receipt, the team records what actually arrived and tracks the missing pallet without pretending the delivery was complete. Separately, suppose a pallet label is damaged although the carton count is correct: the quantity may be acceptable, but identification and traceability still require attention before putaway.

Consultants should test a correct receipt, short delivery, overdelivery, missing HU label, blocked or damaged goods, and reversal of an incorrect goods receipt. For each case, ask whether the posting, warehouse task, status and supporting evidence tell the same story.

Connected EWM foundations

Read handling units for the physical package and barcode layer, warehouse product master for location-specific settings, storage types for destination control and storage sections and bins for warehouse addresses. Return to SAP EWM.

Official SAP References