OS&D — overages, shortages and damages — is the part of receiving that most warehouse software treats as an afterthought and most furniture projects live or die on.
The reason is timing. A damaged headboard found at the dock costs a photograph, a form and a vendor conversation. The same headboard found on the installation floor costs a delayed room, a return trip, and an argument nobody can win because the evidence that would have settled it was never captured.
The job of the system is to make the first outcome cheap and the second one rare. Here is what that requires.
What counts as OS&D
The acronym undersells the category. In practice you are handling six distinct exception types, and conflating them makes the data useless for the conversation you will eventually have with a vendor.
| Exception | What arrived | Typical cause |
|---|---|---|
| Overage | More than the packing list called for | Duplicate carton, double-shipped room set, someone else's freight on the container |
| Shortage | Fewer pieces than the line expected | Short-loaded container, split shipment nobody flagged |
| Damage | Right item, wrong condition | Handling in transit, poor packaging, crushed load |
| Wrong item | Right count, wrong finish, fabric or model | Vendor substitution without notice |
| Missing | Item present but incomplete | Hardware pack absent, glass absent, component only found at assembly |
| Delivery dispute | The delivery record itself is contested | Signature, count or condition disagreement at handover |
The three that hurt most on furniture programs are the three that are easiest to miss: concealed damage, wrong finish, and missing hardware. All three survive a visual dock check. All three are found by the installer.
The seven-step model
A workable OS&D process has seven steps, in this order. Skipping any of them tends to break one of the others.
1. Identify. An operator finds the discrepancy at the dock or during inspection. The critical design property here is that the operator can stop. If the only way to complete a task is to enter a number, the operator will enter a number — and an improvised number becomes a variance somebody investigates three months later. A task that can be blocked with a reason is what converts a guess into a signal.
2. Capture evidence. Photographs, notes and — where the process supports it — a damage type and a severity. This has to happen where the operator is standing, on a phone or a handheld. Evidence that requires walking to a workstation gets captured late, from memory, or not at all.
3. Create the record. A typed exception against the receipt, the customer and the warehouse. Typed matters: "damage" and "wrong item" lead to different conversations with different parties, and a free-text note cannot be counted, filtered or reported on.
4. Hold the inventory. This is the step that separates a process from a paper trail. See below.
5. Assign follow-up. The investigation belongs to a named person with a due expectation, not to a shared inbox. An unassigned exception is an exception that resolves itself by being forgotten.
6. Record the disposition. Repair, replace, accept as-is, return, reject — with the notes that justified it. The disposition is the answer to the question the client will ask, and it needs to be attached to the piece rather than living in an email thread.
7. Release deliberately. The hold is cleared by someone with authority to clear it, and that action is recorded with their identity. A hold that anyone can silently clear is not a control.
Step four is where most systems fail
Almost every WMS can record a damage note. Far fewer can stop the damaged piece from being picked.
That distinction is the whole value of the process. If a damaged credenza is flagged but still allocatable, then on a busy Thursday it will be allocated, picked, staged and loaded, and the flag will be discovered by the installer.
There are four mechanisms worth having, and they are not interchangeable:
Quarantine-status locations. A location whose status makes the system refuse ordinary inventory movements into or out of it. This is the strongest form, because it is enforced by the transaction rather than by a person noticing a flag. It works well for a whole pallet or a segregated bay.
Held quantity on the balance. Separates quantity that is physically present from quantity that is actually available. Right when you have 40 chairs on hand and 3 of them are damaged: the piece stays where it is, but availability drops to 37. This is the mechanism that keeps allocation honest without physically moving anything.
Zone-level hold. A whole staging zone — a room set, a floor's freight — marked on hold as a unit. Useful when a client review is pending on an entire scope rather than an individual piece.
Blocked operator task. The operator-side equivalent: the task stops with a reason such as damaged, short, unreadable label or wrong location, and becomes visible work for a supervisor.
A serious OS&D process uses all four, because they cover different granularities. Read more about how these fit together on the FF&E and project logistics page.
Evidence that is worth having later
Most damage photographs are useless six weeks after they are taken, for predictable reasons. A useful evidence record has five properties:
Attached to the record, not to a person. A photo in an operator's camera roll or a chat thread is not evidence, because it cannot be found by anyone who was not in that conversation.
Timestamped by the system, not by the file. File metadata is easy to dispute and easy to strip. A timestamp written by the transaction is not.
Attributed to an operator. "Someone photographed this at the dock" is weaker than "this operator recorded this at 09:41 during the receipt of container MSCU-4471".
Categorised. A damage type and a severity turn a pile of photographs into something you can count. Six "minor" scuffs from one vendor and one "total loss" from another are different problems, and only categorised data shows that.
Captured before the freight moves. Evidence recorded after the carton left the receiving area invites the question of where the damage actually happened. This is the single most common reason a carrier claim fails.
What the system should not claim to do
A warehouse system documents. It does not adjudicate.
It cannot determine who is legally liable for damage found in a sealed container. It cannot guarantee a carrier, vendor or insurer will pay. It cannot tell you whether a substitution is acceptable to the designer.
Being explicit about this is not a disclaimer — it is a design constraint that keeps the process honest. The system's job is to make sure that when the argument happens, your side of it is documented: what was found, when, by whom, with photographs, before the freight moved, with the disposition someone actually decided.
That is a much stronger position than being right without evidence.
Metrics that tell you the process is working
Four are worth tracking, and only one of them is about volume.
Exceptions per container, by vendor. The point is not the total. It is the comparison. A vendor whose containers generate four times the exceptions of another vendor is a procurement conversation, not a warehouse problem.
Percentage of exceptions caught at receiving rather than downstream. This is the health metric for the whole process. If exceptions are being raised at picking or at the site, the receiving inspection depth is wrong for that vendor.
Time from exception raised to disposition recorded. Long tails here mean follow-up assignment is not working. Exceptions that sit open for weeks are exceptions that will be resolved by the install date arriving.
Held quantity as a share of on-hand, by project. Rising held quantity on an active project is an early warning that the install window is going to be tight.
Start with the second one. If most of your exceptions are found downstream, nothing else on this list will help yet.
To see how exception records, evidence and holds connect to receiving in practice, see the receiving workflow, or book a WarePulse demo and bring a real container's worth of problems to it.