Blog
Learn how SAP EWM receiving handles document mismatches between ASNs, packing slips, and delivery notes—and how automated reconciliation prevents dock delays, invoice blocks, and inventory errors.
At 2:14 in the morning, a packaging supplier's system sends a DESADV message to a distribution center running embedded EWM on S/4HANA. The ASN lists 22 handling units against two purchase orders. EWM creates the inbound delivery, builds the HU hierarchy, and records the expected SSCC numbers. On paper, the warehouse is ready.
The truck backs into door 7 at 9:30. The driver hands over a delivery note that lists 24 pallets, not 22. Two pallets carry a batch number that appears nowhere in the ASN. The packing slips taped to each pallet count cartons in cases of 12, while the purchase order line is maintained in eaches. When the RF operator starts scanning, the first 20 SSCC labels match. The next two return an error because those handling units do not exist in the inbound delivery. The last two match, but with the wrong batch.
Now the dock has a decision to make. Somebody can adjust the inbound delivery in /SCWM/PRDI, call the supplier, park the pallets in a staging bay, or push everything through and let inventory control sort it out next week. Each choice costs something. The one most warehouses pick under pressure, posting what the ASN said and fixing it later, costs the most.
This article looks at receiving specifically in SAP Extended Warehouse Management. Classic WM and Logistics Execution handle inbound deliveries in a simpler way, and a lot of general goods receipt advice assumes that simpler model. EWM raises the stakes. Its inbound delivery drives handling units, packaging specifications, process-oriented storage control, stock types, and putaway strategy. A document mismatch that WM might absorb can stall an entire EWM inbound process.
In classic WM, the inbound delivery lives in the ERP layer. You create it with VL31N or from an ASN, post goods receipt, and a transfer requirement or transfer order moves the stock to its bin. The delivery is mostly a quantity container. If the quantity is close enough, the process moves forward.
EWM treats the inbound delivery as a warehouse document with a life of its own. In a decentralized setup, the ERP delivery replicates to EWM as an inbound delivery notification, which EWM then activates into a warehouse inbound delivery. In embedded EWM on S/4HANA, the handoff happens inside one system, but the warehouse still maintains its own delivery object with separate statuses for unloading, goods receipt, and putaway.
That delivery carries far more than a quantity. It holds the handling unit structure, often nested from pallet to carton. It holds batch data, shelf life dates, country of origin, and serial number requirements set at the warehouse level. It determines the warehouse process type, which decides whether the stock goes through unloading, counting, deconsolidation, and quality inspection steps under process-oriented storage control. It also decides whether stock lands as F1, unrestricted in putaway, or Q1, quality inspection in putaway, before it becomes F2 or Q2 in its final bin.
So when the ASN says one thing and the pallet says another, EWM does not quietly average out the difference. A wrong HU hierarchy sends cartons to the wrong deconsolidation station. A wrong batch breaks FEFO picking weeks later. A wrong unit of measure turns a putaway task for 12 eaches into a task for 12 cases, and the bin capacity check fails in the middle of the aisle.
Decentralized EWM adds one more layer. Stock posted in EWM reports back to ERP through the received-on-dock and available-for-sale storage locations. If the inbound delivery is wrong at receipt, the error flows back to ERP inventory, to MRP, and eventually to invoice verification.
Most EWM receiving teams work with three supplier documents for every inbound shipment. The trouble starts because three different systems produce them at three different moments.
The advance shipping notice is the electronic one. It arrives as an EDIFACT DESADV or an ANSI X12 856 and lands in SAP as a DELVRY IDoc. The E1EDL20 segment carries the delivery header, E1EDL24 carries the items, and when the supplier sends packing detail, E1EDL37 and E1EDL44 describe the handling units and their contents. A good ASN gives EWM everything it needs to build a packed inbound delivery before the truck leaves the supplier's yard.
The catch is timing. Many suppliers generate the ASN when the shipment is planned or when picking starts, not when the trailer is sealed. Anything that changes after that point never reaches the ASN. A short pick, a substituted batch, or an extra pallet added to fill the truck all stay invisible to EWM.
The packing slip is the physical one. The supplier's warehouse system prints it at the end of packing, so it tends to reflect what actually went onto the pallet. It lists cartons, quantities per carton, and sometimes batch and lot numbers. It also uses the supplier's own item numbers and units, which rarely line up with your material master. A packing slip that reads "8 CS item 44-1180-B" means nothing to EWM until someone converts the supplier part to your material and cases to your base unit.
The delivery note is the commercial and legal one. In Europe it is often the primary receiving document, and the driver expects a signature on it. It references the supplier's order confirmation, frequently prints the supplier's sales order number more prominently than your PO number, and may consolidate several purchase orders onto one sheet. It sometimes shows backordered lines that are not on the truck at all, which clerks misread as shortages.
Each document is right about something. The ASN is right about the HU structure the supplier intended. The packing slip is right about what physically went on the pallet. The delivery note is right about what the supplier will invoice. Receiving works only when someone reconciles all three against the PO and the material master before the inbound delivery hardens into a goods receipt.
SAP does a lot out of the box. A PO item with confirmation control key 0004 expects an inbound delivery with confirmation category LA, so an ASN creates a delivery against the right PO item. The system checks that the PO item exists and that the delivery quantity respects the over-delivery tolerance on the PO line. In EWM, RF receiving validates scanned HUs against the delivery, and exception codes let an operator report a difference, trigger a quantity adjustment, or start a follow-up workflow.
What SAP does not do is read paper. Nothing in standard EWM compares the packing slip taped to pallet 14 with the E1EDL44 segment that described pallet 14 six hours earlier. Nothing flags that the delivery note lists a batch the ASN never mentioned. Nothing converts "8 CS" into 96 eaches using the alternative units in MARM and then checks that result against the ASN quantity.
That comparison happens in a receiving clerk's head, usually with a pen, while a driver waits. Clerks get good at it. They also get tired, get interrupted, and default to trusting the ASN because the ASN is already in the system and the RF gun wants a scan.
Non-EDI suppliers make the gap wider. For the long tail of vendors who email a PDF packing list or show up with only a delivery note, there is no ASN at all. Someone creates the inbound delivery by hand, often at the dock, and often from the PO rather than from what arrived. EWM then has no HU structure to validate, so the operator packs HUs manually or receives unpacked, and the downstream process takes its slowest path.
The cost shows up later and somewhere else. A quantity posted from a stale ASN produces a quantity variance in MIRO, and with GR-based invoice verification on the PO item, the invoice blocks. A missing batch means FEFO picks the wrong stock. A shelf life date that fell below the minimum remaining shelf life on the material master gets discovered when a customer rejects the shipment. None of these problems land on the receiving team's scorecard, which is exactly why they persist.
The fix is not to ask receiving clerks to compare harder. The fix is to move the comparison upstream of the physical receipt, so EWM starts the unloading step with an inbound delivery that already reflects all three documents.
Artificio uses AI agents to do that reconciliation. The agents read the ASN as structured data straight from the IDoc or the EDI feed. They read packing slips and delivery notes in whatever form they arrive, whether that is a PDF attached to an email, a scan from the dock office, or a phone photo of a crumpled sheet taped to shrink wrap. Template-based OCR needs a fixed layout for every supplier. The agents do not. They find the PO number even when a supplier prints it in a footer, recognize a sales order reference for what it is, and pull line data from tables that change format between shipments.
Every extracted field then goes through five matching layers against SAP data. The output is more than extracted text. It is a validated set of changes for the EWM inbound delivery, with a confidence score and an evidence trail for each line, plus a recommended action whenever something does not reconcile.
The header match answers a simple question. Does this shipment belong to the purchase orders EWM thinks it does? The agent pulls PO numbers, supplier identity, delivery note number, ship date, and carrier reference from every document and compares them to the PO header and the inbound delivery. When a delivery note prints the supplier's own sales order number as the main reference, the agent traces it through the order confirmation back to your PO instead of failing the match. When one delivery note covers three POs, the agent splits the lines accordingly, because every inbound delivery item has to reference a single PO item.
The header layer also catches the quiet problems. A delivery note number that already appears on a posted inbound delivery points to a duplicate. A ship date weeks before the ASN transmission date suggests the ASN belongs to a different shipment.
Suppliers describe goods in their own language. The agent maps supplier part numbers to your materials using the purchasing info record and the supplier material number on the PO item. When those fields are empty, which happens more often than anyone admits, it falls back to GTINs in the material master and then to description similarity. It records which path produced each match, so a reviewer knows whether a line matched on a hard key or on a best guess.
Substitutions surface here. A supplier ships a newer revision of a part, or a different pack variant, and prints it on the delivery note without updating the ASN. The agent sees that the delivered material does not match the PO line and routes it for a purchasing decision before an operator scans it into the warehouse as the ordered item.
This is where most receiving errors live. The packing slip says cases, the ASN says pieces, the PO says eaches, and the delivery note says pallets. The agent converts every quantity to the base unit using the alternative units of measure in MARM and the packaging specification maintained in /SCWM/PACKSPEC, then compares the results line by line.
Once the units agree, tolerance logic takes over. The agent checks the delivered quantity against the open PO quantity and the over-delivery and under-delivery tolerances on the PO item. It also compares the ASN against the packing slip, because a two-case gap between them usually means the ASN went out before final picking. Small variances inside tolerance become a proposed quantity adjustment with a reason code. Larger ones go to a review queue with the evidence attached.
For batch-managed materials, a wrong batch does more damage than a wrong quantity, because it survives putaway undetected. The agent extracts vendor batch numbers, production dates, and expiry dates from pallet labels, packing slips, and delivery notes, then compares them to the batches in the ASN. When a pallet carries a batch the ASN never mentioned, the agent proposes an update to the inbound delivery item before goods receipt, rather than waiting for an inventory count to find it.
Expiry gets checked against the minimum remaining shelf life and total shelf life on the material master. If the delivered shelf life date falls below the minimum, the agent recommends posting to blocked stock and flags the line for supplier follow-up. Country of origin gets the same treatment for materials where trade compliance depends on it.
EWM cares about handling units in a way classic WM never did. The agent compares three views of the HU structure. It checks the SSCC numbers and nesting in the ASN's HU segments, the carton and pallet counts on the packing slip, and the SSCC labels photographed or scanned at the door. Mixed pallets, missing labels, and extra pallets all show up as structural differences before an operator starts scanning.
This layer protects the process-oriented storage control steps that follow unloading. If EWM expects a homogeneous pallet and receives a mixed one, the deconsolidation step never triggers and the pallet heads straight for a bin it does not fit. Fixing the HU tree before receipt keeps POSC routing honest.
The five layers matter most for suppliers who never send an ASN. For them, Artificio works from whatever they do send. A PDF packing list emailed the evening before becomes a proposed inbound delivery, created through SAP's standard inbound delivery APIs or a DELVRY IDoc, complete with HUs, batches, and quantities in the right units. The receiving team sees the expected arrival in the warehouse monitor, the yard team can plan a door, and RF operators scan labels instead of keying lines.
When a supplier sends nothing ahead of time, the same logic runs at the door. A clerk photographs the delivery note and packing slips on a mobile device, and the agents build or correct the inbound delivery while the trailer unloads. The clerk reviews flagged lines instead of retyping every one.
This turns the long tail of small suppliers from the slowest receiving path into something much closer to an EDI supplier. It also produces a record most warehouses lack, a structured history of what those suppliers actually shipped against what they promised.
Reconciliation without a decision just moves the pile of exceptions to a different desk. Each discrepancy type needs a defined path into EWM, agreed with the warehouse, purchasing, and quality teams before go-live.
Clean matches release the inbound delivery for unloading, and goods receipt posts when operators scan the HUs. Unit conversions and small quantity variances inside the PO tolerance post as automatic adjustments with reason codes, so the audit trail explains every change. A material substitution waits in a purchasing review queue, because accepting it is a commercial decision. A batch that appears on the label but not in the ASN gets written to the delivery item and checked against shelf life before goods receipt. An expiry date below the minimum remaining shelf life goes to blocked stock. An SSCC that exists on the pallet but not in the inbound delivery triggers an EWM exception code and holds that HU in staging while the rest of the trailer keeps moving.
The principle behind this matrix is simple. People should make the judgment calls, and software should do the arithmetic. A receiving lead should not spend the morning converting cases to eaches or checking a batch number character by character. That lead should spend the time deciding whether to accept a substitute part.
The matching logic stays the same in both deployment models. The integration point shifts.
In embedded EWM on S/4HANA, the agents read the PO, the material master, info records, and the EWM inbound delivery from one system. Proposed changes go straight to the delivery, and the warehouse and purchasing views stay in sync without replication delays.
In decentralized EWM, the ERP system still owns purchasing and material data, while the EWM system owns the warehouse delivery. Reconciliation works best at the ERP inbound delivery stage, before replication, so the inbound delivery notification that reaches EWM already reflects reality. When a discrepancy only becomes visible at the door, the correction happens in EWM and flows back through the normal delivery update. Either way, the goal stays the same. The received-on-dock and available-for-sale postings in ERP should match what actually sits in the warehouse.
Teams moving from classic WM to EWM as part of an S/4HANA migration have a particular reason to care. The migration is the moment receiving gets redesigned around HUs, packaging specifications, and POSC. Building document reconciliation into that design costs far less than retrofitting it after the first quarter of stuck deliveries.
The receiving dock rarely gets credit for the problems it prevents, so it helps to trace where accurate inbound deliveries show up.
Accounts payable feels it first. When goods receipt quantities reflect what arrived and the delivery note number is captured on the receipt, three-way matching in MIRO has far fewer quantity variances to block. Invoices post against receipts that already explain the difference.
Inventory accuracy follows. Correct batches and shelf life dates mean FEFO picking selects the right stock, and quality teams stop running recovery counts to find batches received under the wrong number. MRP stops planning around phantom stock from ASNs that overstated a shipment.
Warehouse productivity improves in ways that are easy to measure. RF operators scan instead of keying. Deconsolidation triggers when it should. Putaway tasks carry correct units and fit the bins EWM chose for them. Labor planning works from expected inbound volumes that match what really arrives.
Supplier management gains a dataset it never had. Every reconciled shipment records whether the ASN matched the physical goods. Over a few months, that becomes an ASN accuracy score by supplier, which purchasing can use in scorecards and, where contracts allow it, in chargebacks for non-compliant shipments. Suppliers who know their ASNs get checked tend to send better ASNs.
Regulated industries get an audit trail. Food, pharmaceutical, chemical, and aerospace warehouses need to show which batch arrived on which truck with which paperwork. Linking the source documents, the extracted values, and every adjustment to the EWM inbound delivery answers that question in one place.
Trying to reconcile every supplier on day one is a mistake. Start with the data you already have. Pull the last three months of inbound deliveries from one warehouse number and look at quantity adjustments, exception codes raised during receiving, and invoices blocked for quantity variance. A handful of suppliers usually account for most of the pain, and they tend to fall into two groups. EDI suppliers send ASNs too early. Non-EDI suppliers send paper nobody wants to key.
Pick five to ten of them. Agree on the decision matrix with warehouse, purchasing, and quality leads, including tolerances and which discrepancies block stock. Run reconciliation in parallel with the current process for a few weeks, so the team can compare the agent's proposed changes with what clerks actually did. Then switch on automatic adjustments for the categories where the agent and the clerks agree, and keep review queues for everything else.
The truck at door 7 still arrives with 24 pallets instead of 22. The difference is that by the time it backs in, the inbound delivery already shows 24, the unplanned batch has a proposed update waiting for goods receipt, and the RF operator scans every label without an error. The driver leaves on time. Nobody in accounts payable ever hears about it.
Artificio helps warehouse teams running SAP EWM turn ASNs, packing slips, and delivery notes into inbound deliveries they can trust. If your receiving team still reconciles paper by hand at the dock, talk to us about a pilot with your highest-exception suppliers.
Lal Singh, SAP AI Automation Expert
CEO & Founder of Artificio
See it in your SAP environment
Bring us a document, a process, or a bottleneck. We'll show how Artificio captures, validates, and posts into SAP — then scale from there.
Security & compliance
ISO 27001:2013 certified, SOC 2 Type 2 compliant, GDPR and HIPAA ready. Every agent action is logged, auditable, and runs in isolated environments.
