ASN, inbound delivery, goods receipt: what SAP is actually tracking
The three are used interchangeably in conversation and mean different things in SAP. What each one is, which table it lives in, and why the gap between them is where delays hide.
In most procurement meetings "ASN", "inbound delivery" and "GR" get used as if they were three words for the same event. In SAP they are three different objects created at three different moments, and the distance between them is exactly where a delay becomes invisible.
Three objects, three moments
| Object | Created when | Means |
|---|---|---|
| Order acknowledgement | Supplier accepts the order | They intend to deliver, at some date and quantity |
| ASN / inbound delivery | Goods dispatched | It has physically left. Created in SAP as an inbound delivery document |
| Goods receipt | Goods arrive and are booked | It is in your stock, and the PO history reflects it |
The acknowledgement is a promise. The ASN is a fact about the supplier's warehouse. The goods receipt is a fact about yours. Treating any of them as a substitute for the others is what produces surprises.
Where they live
Confirmations of both kinds are rows in EKES, separated by confirmation category — which is why a single "has it been confirmed" check is ambiguous unless you say which category you mean. The inbound delivery itself is a delivery document, created through VL31N and visible in the PO history alongside the goods receipt.
The expensive gap
Consider a line with a delivery date on Friday. On Tuesday there is an acknowledgement and no ASN. Nothing in a standard open-PO report is red. The line is confirmed, the date has not passed, no rule has been broken.
On Friday the material does not arrive. Now it is late, production planning is already affected, and the cost is fixed. The information that would have prevented it existed on Tuesday: goods that are going to arrive Friday have usually shipped by Tuesday, so an empty ASN field was the signal.
That is the entire argument for tracking ASN separately. It is the only check in the sequence that fires while you can still do something.
The three rules worth running
ASN present inbound delivery exists against the PO line
ASN missing delivery date is within N days
AND no inbound delivery exists
-> this is the one that saves money
delivery late delivery date < today
AND goods receipt not complete
-> the audit of the two aboveThe third rule is not for acting on, it is for measuring. A line that reaches "delivery late" is one the first two rules failed to catch in time, and the count of those is how you know whether the process is actually working.
Partial deliveries break naive checks
An ASN for 100 of an ordered 500 satisfies "an ASN exists". A goods receipt for 100 satisfies "a goods receipt exists". Both are true and the line is still 400 short. Any check that asks whether a document exists, rather than comparing quantities, will pass a line that should be flagged.
- Compare confirmed quantity to ordered quantity, not document counts
- Compare received quantity to ordered quantity, per schedule line where you use them
- Treat over-delivery tolerance explicitly, or short lines and tolerated lines look the same
What to check this week
Take your open PO set and count the lines where the delivery date falls inside the next five working days and no inbound delivery exists. That single number is the most useful thing a procurement team can look at on a Monday morning, and almost nobody has it on a dashboard.
What we build
ASN tracking
Everything above, running on a schedule against your own SAP data — with the exception list, the alerts and the follow-up drafts that come out of it.