Bottom line up front: the last digit of every location code should be a check digit. I've seen this exact failure three times, and all three ended the same way: nothing was stolen, but the system couldn't find it. One extra digit costs almost nothing and catches the vast majority of these "missing inventory" cases.

The most recent one wrapped up a few months ago. An auto-parts client in eastern China, a new DC of about 20,000 square meters, three months after go-live. First full wall-to-wall count: over 2 million yuan in inventory that wouldn't reconcile. Nothing stolen, nothing mis-shipped — 40-plus pallets had been put away in the wrong locations. Location B-12-03-4 was read as B-12-08-4: the forklift driver's scan failed on a dirty label, he keyed it in by hand, and 3 became 8. In the WMS those 40 pallets were "in" B-12-03-4; in reality they sat in B-12-08-4. For two full weeks, sales saw stock on screen, pickers couldn't find it on the floor, customer service took the heat from customers, and the warehouse took the heat from sales. In the end it took two people five days of opening every location to find them. Two million yuan "missing" for two weeks — because of one misread digit.

The second project stung even more. Early 2024, a 3PL warehouse in southern China switched to a cheaper label vendor. The new template's margins were off, and the print got clipped 2 millimeters on the right — exactly where the check digit sat. Half the labels scanned as truncated codes, the floor fell back to manual entry with no check digit to catch errors, and misplacement rates took off. What they saved on labels didn't cover the labor of hunting down a single lost pallet. Two projects, one misread by a human, one misprinted by a vendor — same root cause: the code design gave errors no chance to be caught.

How a check digit stops this

The whole idea in one sentence: append a digit that carries its own answer, so the system can verify every entry.

Take location B12034 (digits only, separators stripped). In the WMS we compute one check digit using the Luhn algorithm — the same one behind credit card numbers — and the location becomes B12034-7. From then on, every scan or keyed entry gets verified first: can the system recompute that final 7 from the preceding digits? If not, hard stop, red error, the pallet never goes to the wrong slot.

It's not magic. Let me walk the math, every step reproducible. Say the location digits are 417203:

  1. Pad a zero at the end as a placeholder: 4172030.
  2. From the right, double every 2nd, 4th, and 6th digit: 3 becomes 6, 2 becomes 4, 1 becomes 2. (If doubling gives 10 or more, add the two digits — 8 times 2 is 16, so take 1 plus 6 to get 7.)
  3. Add everything up: 0 plus 6 plus 0 plus 4 plus 7 plus 2 plus 4 equals 23.
  4. The check digit is 10 minus the remainder of 23 divided by 10 — 10 minus 3, which is 7.

Full location code: 4172037. Now the driver keys 417208 instead of 417203. The system verifies 4172087, the math doesn't resolve to 7, and the screen flashes an error before the pallet leaves the dock. That's the entire trick: one digit that makes "wrong" detectable.

Warehouse associate holding a PDA scanner in front of pallet racking

Which algorithm? Don't invent your own — here's the comparison:

| Algorithm | How it works | Catches | Weakness | | Luhn | Double alternate digits, sum, mod 10 | Single-digit errors, most adjacent transpositions | Needs WMS support for verification logic | | Weighted sum | Multiply each digit by a fixed weight, mod 10 | Single-digit errors | Wrong weights mean no protection at all | | GS1 check digit | Odd/even positions times 3 and 1 | Single-digit errors | Built for product barcodes; borrowing it for locations needs site-wide consistency |

My verdict: use Luhn for location codes, full stop. "Homegrown check rules" is a failure I've seen three times — every time, the next consultant couldn't reverse-engineer the old rule, and the site ended up re-labeling the entire warehouse.

Setting it up in your WMS: four steps, none optional

  1. Lock the code rule before printing a single label. Three sentences: location code equals zone-aisle-level-bay plus one check digit; separators are display-only and excluded from the math; the check digit is always last. Print labels first and define the rule later, and you will reprint — I've seen it three times.
  2. Add two fields to location master data in the WMS: check digit and algorithm name. Don't leave the check digit only on the printed label; the system needs somewhere to store it and configure it, or the day you switch label vendors becomes disaster day.
  3. Enforce verification at three touchpoints: putaway, moves, and cycle-count adjustments. Every scan or keyed location gets verified; failures are blocked and logged. Enforcing it only at putaway is the same as not enforcing it — in my projects, most misplacements happened during moves and count adjustments.
  4. Backfill history with a script: compute check digits for all existing locations at once and reprint in one batch. Don't make the floor hand-calculate them. For a 30,000-location greenfield site, I run the batch job the night before go-live.

One trade-off to think through: hard block versus warning-only. A hard block slows the operation — every error stops a driver for a confirmation. Warning-only gets ignored, which is the same as having nothing. My split: hard block on putaway and moves (one error there means a whole pallet goes missing), warning plus same-day review on count adjustments (counting is time-sensitive, and errors surface the same day). Either extreme is wrong.

Go-live night checklist: fail any one of these five, don't go live

  1. Are labels getting clipped? The check digit sits at the very end — narrow stock or a mis-set template margin cuts half of it off and it won't scan. Scan 10 labels one by one; don't sample.
  2. Is the PDA input locked down? Some Android PDAs default to a Chinese input method, and full-width versus half-width digits are different characters to the system — every check fails. Lock every device to half-width English input before go-live, and check them one by one.
  3. Did you design against misreads? 0 versus O, 1 versus I, 5 versus S — at height, under bad light, human eyes mix these up constantly. My rule: digits only in location codes, a monospace font with a slashed zero, and 0 and O never appear on the same label.
  4. Is anyone reading the block log? Blocking errors nobody reviews is theater. Export the block log daily in week one — figure out whether they're real errors or a misconfigured rule — then relax in week two.
  5. Are legacy locations backfilled? Mixed old and new codes are a disaster. Backfill everything or replace everything; no "grandfathered codes" backdoors.

The counterintuitive take: it's never the worker's fault

Across 30-plus go-lives, every time this happened, management's first instinct was "more training" and "penalize errors." But misreading a long string of digits is just human — no amount of "be careful" fixes it, and fines fix it even less. You have two options: accept that humans will err and let the system catch it, or bet on humans never erring and spend days each month hunting "missing" freight. The first costs one digit; the second cost one client 2 million yuan on the books. You can do that math yourself.

One thing you can do tomorrow: open your WMS location master data tonight and check whether there's a check-digit field. If not, print the five-item checklist above, tape it to the wall, and walk it before your next go-live.

By Lin Xiao, WMS Implementation Consultant