Receiving

Receive the shipment, not the purchase order

A purchase order is a request. A receipt is a fact. Those two numbers can differ, and the one you write down is the one every downstream calculation believes. The six SKUs below are invented so the arithmetic can be checked.

The purchase order said 2,050 units. The pallet in front of you holds 1,360. Nothing has gone wrong, exactly — one SKU is on a later container, one was short-shipped, one was cut entirely and the supplier mentioned it in an email three weeks ago. This is an ordinary Tuesday.

The question is what you type in. And the tempting answer, the one that closes the task fastest, is to receive the purchase order as written. It matches the paperwork. It clears the screen. It is also a very expensive receiving mistake, because from that moment your system believes you own 690 units that are not in the building.

Everything downstream inherits that belief. Days of supply is computed from it. The reorder list is sorted by it. The next purchase order is sized against it. A receiving error does not stay in receiving — it becomes a demand-planning error about four weeks later, wearing a different name, and by then nobody connects the two.

Receiving is the moment your records stop being a plan and start being a claim about the physical world. Make the claim true.

Step 1 — Count the delivery, line by line

Open the delivery, not the order. For each line, the only question is how many units of that SKU are physically here, in sellable condition, right now. Not how many were promised. Not how many the packing slip claims. How many you can count.

This sounds obvious, which is exactly why it is easy to shortcut. The packing slip can agree with the purchase order and the box can agree with the packing slip, and the habit of trusting the paperwork is built by every delivery where both were right. It is broken by the one where they were not, and that one is invisible until a customer order cannot be filled.

Two things are worth separating while you count. A unit that arrived damaged is not a unit that did not arrive — it is here, it cost you money, and it needs its own disposition. A unit that is missing from the box is a supply question. Recording them in the same field turns two different problems into one unreadable number. That distinction is the subject of the next post in this series.

In SKU Compass, the purchase order’s line table carries Qty Ord and Qty Recv as two separate columns, with Damaged kept in a third. The ordered quantity is not overwritten by the received one.

Why two columns beats one

A single “quantity” field forces a lie. Either it holds what you ordered, in which case your on-hand is wrong, or it holds what arrived, in which case you have lost the record of what you asked for and can no longer tell whether the supplier performed. Both readings destroy information you need later — the first for planning, the second for supplier management.

Keeping them apart costs one column and answers both questions permanently. It is also what makes the third number computable.

Step 2 — Read the outstanding balance

Outstanding is ordered minus received, per line. It is arithmetic, not judgement, and it is the number that tells you whether this purchase order is finished.

Here is the delivery from the top of this post, written out. PO 4471, six lines, one partial shipment against it:

Three lines are done. Three are not, and they are not un-done in the same way. BR-220 and TN-330 are ordinary shortfalls of 60 and 30 units. CL-044 is a different animal: 600 units, none of them here, sitting on a purchase order that a quick glance would call “delivered” because five of its six lines brought something in.

That is the failure this step exists to catch. A purchase order marked received in bulk hides its own worst line. The total says 1,360 arrived and the eye reads that as success; the per-line view says one SKU got nothing at all.

In SKU Compass, the receiving panel is laid out against the shipment rather than the order: its columns read Shipped, Already received and Arrived, and a fill control is captioned “Set every line to what is still outstanding on this shipment”.

What a bulk receipt costs you, in units

Take CL-044 alone. It sells 20 units a day, its lead time is 38 days, and there were 400 units on the shelf when the pallet arrived. Receive the purchase order as written and the system adds 600 units that do not exist: 1,000 units believed on hand, which reads as 50 days of supply. That clears the 38-day lead time with room to spare, so the SKU drops off the reorder list entirely.

Receive the delivery instead and CL-044 shows the 400 units that are actually there — 20 days of supply. Its reorder point is one lead time of demand, 38 days at 20 a day, or 760 units. At 400 units the SKU is not merely due for reorder; it crossed that point 18 days ago, and the only reason nobody noticed is that a purchase order was already open against it.

Same pallet. Same day. A 30-day swing in the answer, produced entirely by which number got typed in. This is why receiving accuracy is a forecasting input and not a warehouse chore.

Step 3 — Give the remainder a disposition

An outstanding balance is not a status. It is a question waiting for an answer, and there are only three answers:

1. Still coming. The supplier split the shipment and the balance is on a later leg. Keep it open, record the expected date, and treat those units as incoming stock — because they are.
2. Never coming. Short-shipped, cut, cancelled, or quietly dropped. Close the balance so those phantom inbound units stop suppressing the reorder need. The demand they were covering has not gone away; the supply you were counting on is what disappeared.
3. Unknown. A real answer, but it needs an owner and a follow-up date. Without those it is a decision nobody has made, and it behaves exactly like “still coming” in every calculation while being far less likely to be true.

The middle answer is the easiest one to leave unanswered, and it is the expensive one. A balance left open on units that will never arrive keeps them counted as inbound stock until someone closes it. Every reorder decision on that SKU is then made against a pipeline that does not exist — and because the phantom units suppress the reorder signal, the SKU stays quiet right up until the shelf is empty.

This connects directly to a choice covered earlier in this series. If your days-of-supply calculation counts units on open purchase orders, then a stale outstanding balance is not a tidiness problem — it is a live input feeding a wrong number into every priority sort you run. That choice, and what it does to the same SKU read two ways, is worked through in the days-of-supply post.

Closing the finished lines without closing the order

There is a practical move worth knowing. When three lines are complete and three are not, the complete ones do not have to wait. Close those lines as fully received, and leave the purchase order itself open, because three of its lines are genuinely outstanding. What stays on the open-orders view is then a smaller, explicit balance rather than a mostly-done order that looks finished from the outside, and a small explicit balance is easier to chase.

The general rule: keep open what is genuinely open, and nothing else. An open-orders list full of substantially-complete purchase orders is easy to stop reading, and a list nobody reads is the same as no list.

What good looks like

You can judge your own receiving discipline with one question, asked of a purchase order that was closed three months ago: does its received quantity match what the warehouse actually took in that day? If you cannot tell, or if the answer is “it matches the order, so probably”, then the records are describing the plan rather than the event.

Three habits get you the rest of the way:

• Receive on the day it lands, not on the day the invoice is reconciled. Those are different dates and the gap between them is invisible stock.
• Count damaged separately from missing. One is a claim against the supplier, the other is a hole in your supply.
• Review unresolved balances on a schedule, with older balances escalated rather than left indefinitely. An unresolved balance is either a supply problem or a data problem, and both are worth naming.