WMS audit:
what a warehouse system data audit actually examines

A WMS audit is a structured examination of the data a warehouse management system holds and the transactions that produced it. Its object is the record, not the rack. It asks what the system was told, whether the system did the right arithmetic with it, and whether the resulting balance can be trusted to direct physical work.

That is a narrower scope than the phrase sometimes implies, and the narrowness is the point. A WMS audit is not a software evaluation, not an implementation review, not a process-improvement consultancy and not a physical inventory. It is a data investigation, and it is valuable precisely because it can be done from exports — without system access, without interrupting operations, and without asking anyone to stop picking.

The output is not a corrected balance. It is a list of named defects, each supported by transaction evidence, each classified by mechanism, each counted across the population, and each carrying a quantified exposure. The method is root cause analysis applied to an entire dataset at once rather than to one variance at a time.

Seven areas, in the order they tend to produce findings.

A WMS posts inventory transactions continuously. The ERP receives them in batches — say a run at 23:30 and another at 00:15. A receipt posted at 23:47 on the last day of a period therefore lands in one period in the WMS and the next period in the ERP.

Take a receipt of 30 cases at a case pack of 24: 720 eaches, at a standard cost of $3.10.

Nothing is wrong here. The systems are eventually consistent and they became consistent 28 minutes later. A site that treats every period-end difference as an error will burn a great deal of effort on differences like this one.

The audit question is therefore not "do WMS and ERP agree at period end" — they frequently will not, for entirely ordinary reasons. It is: which of the period-end differences closed on the next interface run, and which are still open?

A difference that never closes is a different animal entirely. The message errored and was never requeued, or it was consumed and rejected silently, or it was replayed and double-posted. That difference is permanent, it does not appear in either system as an exception, and it compounds: every subsequent period inherits it, so by the time anyone investigates, the gap is the sum of an unknown number of unrelated failures. Separating the two requires the interface log, the batch window boundaries and both systems' balances at matched timestamps — which is why interface logs belong in an audit's export request even though they are rarely thought of as inventory data.

Findings group into the same five categories used in root cause analysis, because it is the same method applied at population scale.

All of these are standard WMS extracts. None requires access to a production system, and flat files are entirely sufficient.

Stating the limits is part of the method, because a finding is only as good as the boundary around it.

It cannot detect theft directly. A data audit can eliminate transaction-origin explanations for a variance and report what remains unexplained, which narrows the field considerably. It cannot demonstrate that stock was taken, by whom, or when, and any report claiming otherwise from exports alone is overreaching.

It cannot confirm physical condition. Damage, spoilage, mis-slotting and mixed locations are visible in the data only through their traces — a disposition code, an adjustment, a status change. Absent a trace, they are invisible.

It cannot prove intent. An override, a forced confirmation and a keyed location all look identical whether they were expedient, mistaken or instructed. The evidence supports a mechanism; it does not support a motive.

It is bounded by the export. Anything not in the extract cannot be examined. This is why the export request matters so much, and why gaps in it are reported as limitations rather than quietly worked around.

It describes a period, not a permanent state. Findings are true for the window audited. A defect fixed the week after the extract will still appear; a defect introduced the week after will not.

None of this makes the exercise weaker. It makes it defensible — a report whose limits are stated can be relied on inside the limits, which is more than can be said for one that claims everything.

These are complementary and are routinely treated as alternatives.

A physical count establishes present truth. It tells you what is in the building today, at considerable cost, and it produces adjustments that make the records correct as of that moment. What it does not do is explain how the records became wrong, which is why accuracy begins decaying the day after a wall-to-wall count at whatever rate the underlying defects dictate.

A WMS audit establishes causation. It cannot tell you what is on the rack right now — it has no physical observation in it at all. It tells you which mechanisms have been producing errors, how often, and at what cost, which is the one thing a count structurally cannot deliver.

The sequence matters. Auditing before a major count means the count corrects balances that will stay corrected, because the generators have been identified and can be shut off first. Counting first and auditing later means paying for the count twice: once to do it, and again when the same defects have rebuilt the same variances. The audit also makes the count cheaper to interpret, because variances that match a known signature need no separate investigation.

One further distinction worth drawing: a WMS audit in this sense is not a WMS implementation or software audit. That is a review of configuration, master data setup, workflow design and system fit, usually performed against a vendor's reference model. It is a legitimate exercise and a different one — it asks whether the system is set up well, whereas a data audit asks what the system has actually been recording and whether the resulting numbers are true.

A WMS balance is the sum of its transactions, which means it is auditable. Almost every inventory number a distribution business relies on can be reconstructed from the data that produced it, and where it cannot be reconstructed, that is itself the finding.

The value is not in the corrected balances. It is in the named defects, their occurrence counts and their quantified exposure — because a defect that has run for eighteen months will keep running for another eighteen unless something is changed, and the occurrence count is what makes the case for changing it.

The supporting methods: tracing a single discrepancy, identifying phantom stock, proving a root cause rather than an instance, and measuring accuracy honestly enough to tell whether any of it worked.