Free tool · 48 checks

WMS audit checklist:
48 checks you can run from your own exports

A warehouse management system audit checklist about the data, not the building. Every check names the report to pull and the pattern that means it failed, so the answers come from exports rather than opinion. Score it here; answers stay in your browser.

  • Updated
  • Written by WMSAudit
  • A Ravenspire LLC company
  • 48 checks · about 2 hours with exports

Short answer

A WMS audit checklist tests whether the records your warehouse system holds can be trusted: receipts post once, case packs match what vendors ship, locations exist, confirmations are scanned, counts are blind and adjustments carry a real cause. This one has 48 checks in eight areas. Each names the export to pull and what a failing result looks like.

How to use this checklist

Most published warehouse audit checklists are about the building: aisle clearance, PPE, racking damage, labelling. Those matter, but they won't tell you why the system says 48 and the slot has 12. This one is about the record, meaning the data your WMS plans, replenishes and reports against.

Each check names the export to pull and what a failing result looks like, so it can be answered from data rather than from opinion. Mark each one:

Pass
You pulled the data and it looks the way the check describes.
Fail
You pulled it and found the failing pattern, even once. One instance of a mechanism usually means there are more.
Can't tell
The data doesn't exist, can't be exported, or nobody knows. Treat this as a finding, not a gap in the audit. A control you can't measure isn't working as a control.

Your answers are saved in this browser only. Nothing is sent anywhere unless you choose to email the summary. Work through it in one sitting with your inventory control lead, or over a week as the exports come in.

01 Receiving

Where most bad inventory data is born. A wrong quantity posted here is inherited by every downstream transaction.

  1. RC1 Each physical delivery posts exactly once.

    Pull Receipt transactions by PO line, with timestamp, user, device and entry method.

    Fail if A PO line carries two receipts of the same quantity a few minutes or hours apart, or an ASN auto-receipt and a manual receipt against the same line.

    Result for RC1

  2. RC2 Receivers count before they see the expected quantity.

    Pull Receipt lines with ordered, advised (ASN) and received quantity side by side.

    Fail if Received equals ordered on almost every line, including vendors you know ship short. That is receiving to the paperwork, not to the pallet.

    Result for RC2

  3. RC3 Over, short and damaged are recorded separately.

    Pull Receipt variance records with their reason codes.

    Fail if Variances are netted into one figure, or damaged product is received as available and adjusted out later.

    Result for RC3

  4. RC4 Every shortage above your threshold has a vendor claim.

    Pull Receipt shortages joined to vendor claims or debit memos.

    Fail if Shortage lines with no matching claim, or nobody can say who owns the hand-off from the dock to accounts payable.

    Result for RC4

  5. RC5 ASN accuracy is measured by vendor.

    Pull ASN lines against receipts, grouped by vendor.

    Fail if Nobody can produce ASN accuracy by vendor, or ASN receipts post without scanning each LPN or pallet.

    Result for RC5

  6. RC6 Received stock reaches a scanned storage location the same shift.

    Pull Receipt timestamp against putaway confirmation timestamp.

    Fail if Stock ages for days in dock or receiving locations, or putaway is confirmed without a location scan.

    Result for RC6

02 Item master and units of measure

One wrong field here is multiplied by every receipt of that item until someone corrects it. Fails in this section usually rank first by dollar impact.

  1. IM1 Every active item has a base UOM and complete conversions.

    Pull Item master with the full UOM conversion table (EA, IN, CS, PL).

    Fail if Active items with a blank, zero, or default-of-one case pack where the product plainly arrives in cases.

    Result for IM1

  2. IM2 Case pack matches what vendors actually ship.

    Pull Receipt variance per item and vendor, divided by cases received.

    Fail if Variance per case is the same non-zero whole number receipt after receipt. That is the pack field, not the receiver.

    Result for IM2

  3. IM3 Inner pack divides evenly into case pack.

    Pull The pack hierarchy: each, inner, case, pallet.

    Fail if An inner pack larger than the case, one that doesn't divide into it, or fractional conversions where the unit can only be whole.

    Result for IM3

  4. IM4 Dimensions and weights exist at every UOM level that is handled.

    Pull Dimensions and weights by UOM level.

    Fail if Each and case carry identical dimensions, or weights are missing at the level putaway and cartonization actually use.

    Result for IM4

  5. IM5 Pack and UOM changes are logged with who, when and why.

    Pull Item master change log, with effective dates.

    Fail if No change log exists, or pack fields change with no effective date and no named owner.

    Result for IM5

  6. IM6 You know what the WMS does to existing on-hand when a conversion changes.

    Pull The change log set against on-hand history for an item whose pack was edited.

    Fail if Nobody can say whether existing balances were restated, left alone, or restated for some transaction types only.

    Result for IM6

  7. IM7 Lot, expiry, hazard and storage attributes are populated where required.

    Pull Items flagged lot-controlled, dated, hazardous or temperature-controlled.

    Fail if Regulated or lot-controlled items with blank attributes, or hazard class missing on items that plainly need one.

    Result for IM7

03 Locations

A balance at a location that doesn't physically exist, or doesn't match its label, produces discrepancies that no count program can close.

  1. LC1 Every location in the WMS exists physically, and every physical slot exists in the WMS.

    Pull Location master set against a walk of the building or the rack drawing.

    Fail if Locations holding on-hand that resolve to no physical position, or physical slots missing from the master.

    Result for LC1

  2. LC2 Inactive and deleted locations hold nothing.

    Pull On-hand by location, joined to location status.

    Fail if Inactive, orphaned or unmapped locations still carrying quantity.

    Result for LC2

  3. LC3 Pick-face assignments match what is slotted there now.

    Pull Pick-face assignments against last pick date per item.

    Fail if Assignments pointing at items with no picks in months, or one face unintentionally assigned to several items.

    Result for LC3

  4. LC4 Capacity fields reflect what actually fits.

    Pull Location capacity against the maximum quantity observed in each location.

    Fail if Locations routinely above stated capacity, or capacity left at a default value on most records.

    Result for LC4

  5. LC5 Every location label scans to the location it is on.

    Pull A scan test on a sample of labels, including recently re-racked aisles.

    Fail if Missing check digits, or labels swapped after a re-rack or re-slot.

    Result for LC5

  6. LC6 Dock, staging and QA locations are cleared daily.

    Pull On-hand in non-storage locations, with the age of each balance.

    Fail if Quantity ageing in dock, staging, returns or QA locations.

    Result for LC6

04 Putaway and replenishment

These are the transactions most likely to post one leg and not the other, which leaves two locations wrong by the same amount in opposite directions.

  1. PR1 Putaway is confirmed by scanning the actual location.

    Pull Putaway confirmations with a scanned-or-keyed flag.

    Fail if A meaningful share of confirmations are keyed, or keyed confirmations cluster by user or shift.

    Result for PR1

  2. PR2 Directed putaway rules still match current velocity.

    Pull Directed location against actual location, with override reasons.

    Fail if Overrides are routine. The rules are being worked around instead of fixed.

    Result for PR2

  3. PR3 Min/max is set in the UOM the pick face consumes.

    Pull Replenishment settings with their UOM, against the pick UOM.

    Fail if Min/max stated in cases for an each-picked face, or the reverse.

    Result for PR3

  4. PR4 Replenishment tasks close with both legs posted.

    Pull Replenishment tasks and their transactions.

    Fail if Tasks that close with only the source decrement, or are cancelled after partial confirmation.

    Result for PR4

  5. PR5 Emergency replenishments are rare and explained.

    Pull Emergency replenishment count by item.

    Fail if The same items trigger emergency replenishment repeatedly, which usually means the pick-face balance is wrong.

    Result for PR5

05 Picking and shorts

A short pick is the cheapest inventory signal you will ever get. The failure is treating it as a picking problem.

  1. PK1 Short picks are recorded with a reason, never silently skipped.

    Pull Short-pick transactions.

    Fail if Shorts closed without a reason, or pickers pulling from alternate locations without telling the system.

    Result for PK1

  2. PK2 A short pick triggers a count of that location.

    Pull Short picks joined to count tasks.

    Fail if Shorts that do not generate a count task within a day.

    Result for PK2

  3. PK3 Pick confirmations scan both location and item.

    Pull Pick confirmation method.

    Fail if Keyed or bulk-confirmed picks.

    Result for PK3

  4. PK4 Repeat shorts are traced upstream, not just recounted.

    Pull Short picks by item over 90 days.

    Fail if The same items short repeatedly and nobody has linked them to receiving or pack data.

    Result for PK4

  5. PK5 Negative on-hand is blocked, or reviewed daily.

    Pull The allow-negative setting and current negative balances.

    Fail if Negative balances exist and persist.

    Result for PK5

06 Cycle counting

A count program measures accuracy and corrects it. It does not find the cause, and a badly designed one manufactures variances of its own.

  1. CC1 Counts are blind.

    Pull Count task configuration.

    Fail if Counters can see the system quantity.

    Result for CC1

  2. CC2 The system quantity is captured at count time, not post time.

    Pull Count capture timestamp against post timestamp.

    Fail if Counts posted hours later against a balance that has moved since.

    Result for CC2

  3. CC3 Out-of-tolerance counts are recounted by someone else.

    Pull Recount flags and counter IDs.

    Fail if First counts post directly, or the recount is done by the same person.

    Result for CC3

  4. CC4 Count selection targets problem items, not only an ABC calendar.

    Pull Count history set against short picks and adjustments.

    Fail if Items with repeated shorts are not counted more often than their ABC class requires.

    Result for CC4

  5. CC5 Accuracy is reported at location level, in absolute terms.

    Pull The definition behind the accuracy KPI.

    Fail if The headline figure nets overages against shortages, or measures at site level only.

    Result for CC5

  6. CC6 Items that fail count repeatedly are escalated for root cause.

    Pull Count variance by item over 90 days.

    Fail if The same items appear on the variance list month after month.

    Result for CC6

08 Interfaces and reconciliation

Differences between WMS and ERP are either timing, which closes by itself, or a dropped message, which doesn't. A single period-end snapshot can't tell them apart.

  1. IF1 Failed interface messages are visible and reprocessed.

    Pull Interface error log, with status and retry count.

    Fail if Errors accumulate with no daily review and no owner.

    Result for IF1

  2. IF2 WMS and ERP on-hand are reconciled by item on a schedule.

    Pull WMS on-hand against ERP on-hand, item by item.

    Fail if Reconciliation happens only at total value.

    Result for IF2

  3. IF3 Differences that survive two runs are investigated.

    Pull Reconciliation history.

    Fail if The same items differ every period.

    Result for IF3

  4. IF4 Period cut-off is defined against the batch schedule.

    Pull Interface batch windows and period-end timing.

    Fail if Nobody can say which receipts land in which period in each system.

    Result for IF4

  5. IF5 Message sequence gaps are detected.

    Pull Interface message IDs.

    Fail if Gaps in the sequence go unchecked.

    Result for IF5

  6. IF6 Transactions carry both an event time and a posting time.

    Pull A transaction history export.

    Fail if Only one timestamp exists, so timing cannot be separated from error.

    Result for IF6

  7. IF7 The exports an audit needs can be produced without an IT project.

    Pull An attempt at the receipt, adjustment and item master exports.

    Fail if Basic extracts take weeks, or can't be produced at all.

    Result for IF7

How to read the result

There is no pass mark, and any percentage would imply a precision the checklist doesn't have. Forty-eight checks aren't equal in cost. What the result is good for is deciding where to look first, and the order below is the one that usually matches where the money is.

First

Item master fails

A wrong case pack or conversion posts an error on every receipt of that item, indefinitely. It's the only category where one field produces a recurring, compounding variance. See item master audit and unit-of-measure errors.

Second

Receiving fails

Duplicate receipts and receiving to paperwork overstate on-hand at the front door, and the cost shows up weeks later as short picks and missed replenishment. See receiving discrepancies and phantom inventory.

Third

Confirmation discipline

Keyed putaway and pick confirmations don't change site totals. They move stock to the wrong location in the record. Site-level accuracy reports will look fine while picks keep shorting.

Then

Counts and adjustments

These don't create errors. They measure them, and too often erase the evidence. Fails here mean your accuracy number can't be trusted and your audit trail is thinner than it looks. See cycle count discrepancies and inventory adjustment analysis.

Always

A lot of "can't tell"

If a third or more of your answers are "can't tell", the first problem is visibility, not accuracy. Start with IF7: if the basic exports can't be produced, nothing else on this list can be verified.

What a checklist can't do

A checklist tells you that a control is missing. It can't tell you what that has cost, which items it hit, or whether the variance you are chasing came from it. A failed IM2 tells you some case packs are probably wrong. It doesn't give you the forty-one items, the vendor, the date the field was last edited, or the annual overstatement.

Getting from a failed check to a finding needs the transaction history: replay the balance, find the row where it breaks, then test whether that signature recurs across the dataset. That method is set out in inventory root cause analysis, and the symptom-to-mechanism lookup is in the root cause matrix.

That second step is what a WMS audit is. If you ran this checklist and have more fails than people to chase them, that's the point to bring in a second pair of eyes.

Questions

How often should a WMS audit be done?
Run this checklist quarterly, and after any event that changes how data enters the system: a WMS go-live or upgrade, a new vendor base, a re-rack, or a change in receiving process. A full data audit with transaction replay is usually warranted once a year, or when accuracy or write-offs move without an explanation.
Is this the same as a warehouse audit checklist?
No. A general warehouse audit checklist covers the facility: safety, housekeeping, equipment, layout. This one covers the records the WMS holds and the transactions that change them. Both are worth doing; they find different problems.
Who should fill it in?
Whoever can pull the exports and knows the process, usually the inventory control lead with someone from IT or the WMS administrator for the configuration checks. The answers should come from data, so a manager filling it in from memory will overstate the passes.
Can I use it for a 3PL's WMS?
Yes, if the 3PL will give you the exports. Receipts, adjustments, on-hand by location and the item master are reasonable to request under most service agreements. Several checks, such as reason-code distribution and count design, are good questions for a 3PL review in their own right.

Related WMSAudit guides