Forty pallets ordered. Thirty-four on the shelf. The picker scans the bin, the count comes up short, and everything after that depends on one question: does the system become the record, or does a supervisor's memory?

Most warehouse investment optimizes the routine path — receiving, put-away, pick, pack, ship. The sequence that runs thousands of times a day and mostly works.

The cost lives in the other path. The one that runs a few dozen times a day, crosses three departments, and leaves traces in four systems but a record in none.

The evidence position

Evidence for this edition was reviewed through 20:00 UTC on November 5, 2026.

Two limits belong up front. No Körber or HighJump product documentation could be retrieved for this edition, so nothing here makes a version, module, interface or release-specific claim about that platform. And no customer outcome, benchmark or savings figure is asserted anywhere in this article.

What is offered instead is a method and a set of questions, grounded in published architecture guidance rather than a feature list.

The routine path is the easy part

A completed pick is a transaction. It has a start state, an end state, and a system that owns both.

A short pick is not a transaction. It is a discrepancy — a gap between what the order asked for and what the building could supply — and discrepancies do not naturally land anywhere.

So they land in whatever is closest. A note on a pick ticket. A radio call. A text to the inventory control lead. An email to customer service that says short six, please advise.

None of those is wrong. Each is a reasonable act by a competent person under time pressure. Together they form a record that exists only as long as the people who made it.

Four handoffs a short pick has to cross

The warehouse decision. Can the remaining quantity be sourced from another bin, another site, or a substitution? Who may decide that, and at what order value does the answer change?

The inventory adjustment. If a cycle count confirms the shortfall, someone adjusts the record. That adjustment is a financial event. It needs an owner and a reason code, not a number typed into a screen.

The customer commitment. The order will ship incomplete or late. Someone told the customer something, and that promise now has a date attached. Promises that live in an inbox are the ones broken quietly.

The commercial consequence. A partial shipment changes the invoice, may change freight, may trigger a credit, and may affect commission. Each is downstream of a decision made on a warehouse floor at 6:40 in the morning.

The failure mode is not that any single step is hard. It is that no artifact links them. When the customer disputes the credit three weeks later, the answer takes four phone calls and someone who remembers.

Where two systems meet, one of them has to translate

Warehouse execution and enterprise resource planning do not share a vocabulary. The warehouse thinks in tasks, bins and license plates. Finance thinks in orders, invoices and revenue.

Microsoft's anti-corruption layer pattern describes the structural answer: a facade that translates requests between subsystems which do not share semantics, so a dependency on an outside system does not limit the design of the one you control.

That is the boundary a warehouse needs. Not a queue that faithfully forwards a payload the receiving system will misread, but a translator that owns the mapping, enforces validation, and refuses the ambiguous case rather than guessing.

It is also where duplicate handling belongs. An exception retried because the first confirmation never returned should not create a second adjustment, and only the layer owning the mapping can tell the difference.

Operational visibility is not a dashboard

Ask a warehouse supervisor what they need and the answer is usually a screen that shows what is going on. That is the symptom, not the requirement.

What they actually need, for every open exception, is three things: its state, its owner, and its age.

State says whether it waits on a decision, a count, a customer or a carrier. Owner says who to call. Age says whether it is normal or has already cost you something.

A dashboard that shows two hundred open items without those three attributes is a nicer way to remain uninformed.

Six decision criteria

  • Exception ownership. For each exception type, is there a named role that owns resolution, or does it default to whoever notices?
  • Durable state. Does a raised exception persist through shift changes, weekends and system restarts?
  • Reason codes. Are adjustments and order changes tagged with a controlled reason, or a free-text note?
  • Boundary validation. Does the interface reject an ambiguous payload, or pass it along and let the receiving system fail later?
  • Duplicate protection. If a confirmation times out and the step is retried, is there a key that prevents a second adjustment?
  • Reconstructability. For an exception closed last quarter, can you produce what happened, who decided, and on what evidence?

The sixth criterion has a published anchor. NIST's Secure Software Development Framework is cited here for one point it makes about itself: because it provides a common vocabulary, software purchasers and consumers can use it to foster communications with suppliers in acquisition.

The instinct transfers. A record nobody outside the warehouse team can read is a record that cannot support a procurement decision, an audit response or a customer dispute.

Three delivery options

Replace the warehouse platform. The largest lever and the largest risk. A warehouse management system controls every physical movement in the building, so a failed cutover does not degrade service — it stops it. Correct when the platform itself is the constraint, usually wrong when the constraints are the boundaries around it.

Extend alongside the platform. Build the exception layer as separate software: a supervisor workspace, a cross-system approval flow, a reconciliation view. The platform keeps doing what it does; the missing state gets a home. Microsoft's strangler fig pattern describes the migration shape: a facade routes specific functionality to the new implementation while the old path keeps running, and the old path is decommissioned once the new one has earned trust.

Govern what already exists. Write down the exception types, assign owners, add reason codes, and stop accepting we handle it as a description of a process. Cheapest, slowest to show a result, and the only option that survives a change of personnel.

Most operations need the second and the third. The first is a different decision with a different justification.

A 30-day pilot

  • Days 1 to 5. Pick one exception type — short pick, damaged in transit, bin discrepancy. One, not a category.
  • Days 6 to 12. Shadow the resolution end to end for ten real instances. Record every system touched, every person consulted, every artifact created.
  • Days 13 to 20. Write the intended state and owner for each step, and mark where no system holds it today.
  • Days 21 to 30. Implement the smallest durable record for the gap, run it against the same ten cases, and have someone who did not build it reconstruct one from the record alone.

That last test is the whole pilot. If a colleague cannot reconstruct the exception without asking a person, the record is not finished.

Four indicators worth baselining

Exception age at resolution: median hours from raise to close, split by type. Reopened exceptions: cases that came back after being marked resolved. Manual adjustments without a reason code: a number you intend to drive toward zero. Reconstruction time: how long it takes to answer what happened to order X from records alone.

Baseline all four before the pilot. None requires a vendor benchmark, and all four describe your operation rather than someone else's.

What is vendor-stated, and what is not

This article makes no claim about any specific HighJump or Körber release. No feature list, interface type, version requirement or module name is asserted, because no product documentation from the vendor could be retrieved for this edition.

The architectural patterns cited are published guidance about structuring systems. They are not measurements, and neither is presented as evidence that any organization achieved a particular result.

Nothing here establishes that any warehouse reduced exception resolution time, improved accuracy or shortened a close. The opening scenario is illustrative rather than a client story.

What remains unknown

  • What exception-handling capability exists natively in current HighJump or Körber releases.
  • Which integration interfaces a given deployment exposes, and how much of the workflow they cover.
  • Whether documented interfaces pass through the same validation the operator screens enforce.
  • Any measured effect of a separate exception layer on resolution time or accuracy.
  • Market data. None was reviewed for this edition, so no stock movements are reported.

Evidence notes and limits

The corporate relationship between HighJump and Körber Supply Chain is noted as background from third-party accounts reviewed for this edition, not from a retrieved Körber page. No version, module, interface or capability claim is made about any specific release, and vendor documentation should be treated as the authority for a given deployment.

The Microsoft pattern descriptions — anti-corruption layer and strangler fig — are architectural guidance about structuring systems and about staged migration. Neither is a measurement, and no effort, cost or outcome is attributed to implementing either.

NIST SP 800-218 is cited only for its described purpose of providing a common vocabulary that purchasers and suppliers can use in acquisition. It is guidance, not a certification, and it says nothing about warehouse management or exception handling.

The four handoffs, the three attributes of visibility, the criteria, the options, the pilot and the indicators are this publication's analysis and suggested method. They have not been validated as a protocol.

The advertisement above is separate from this analysis and is not a source for any claim in it.