Days on hand, inventory turns, and aging buckets are only as reliable as the data they run on. Five problems - unit of measure mismatches, negative balances, ghost inventory, location gaps, and stale lead times - silently corrupt every metric your team uses to manage working capital.
Inventory analytics has a simple contract with the data: give it accurate on-hand quantities in a consistent unit of measure, a complete picture of where inventory physically exists, and cost figures that reflect what you actually paid - and it will tell you exactly how much working capital is tied up and whether that's getting better or worse. Break any of those inputs, and the metrics become confident lies.
The five data problems below are not exceptional. They are the default state of most multi-site manufacturing environments, particularly those that have grown by acquisition. Each one distorts the calculation differently. None of them triggers an error in your ERP. Days on hand comes back as 47. Turns come back as 6.2. The aging bucket shows 12% slow-moving. The numbers look like real answers.
A manufacturer thought they were running 52 days on hand at one facility. After resolving a UoM mismatch introduced in the prior year's acquisition, actual DOH was 18. The difference funded two quarters of capex.
IQ Insights runs a data quality pass before every inventory calculation. Each of the five problems below describes what goes wrong without detection, and how IQ Insights surfaces the issue before it reaches your working capital report.
When the same product is tracked in different units of measure across ERP systems - "each" at one site and "case of 12" at another - every inventory calculation is wrong by the conversion factor. A consolidated view sees 1,000 units at Site A and 1,000 cases at Site B. If the case contains 12, the consolidated on-hand quantity is either overstated by 12x for Site B or understated by 12x for Site A, depending on which convention the analytics layer inherits.
This distorts days on hand in both directions. A product that looks like it has 47 DOH at the consolidated level might actually be running at 4 DOH or 470 DOH, depending on which site's convention wins. Turns are inverted by the same factor. Aging buckets misclassify product as slow-moving or fast-moving based on a phantom quantity rather than physical reality.
The problem is especially common after acquisitions. Each acquired entity usually had its own item master conventions, and the ERP integration only mapped item codes - not unit of measure definitions. The mismatch goes undetected because each site's individual analytics look internally consistent.
When on-hand quantity is recorded in "cases of 12" and COGS is computed in "each," the numerator is inflated 12x. The same formula runs, returns a plausible number, and the analyst has no indication the units don't match.
ERP systems allow negative on-hand balances when a material consumption or shipment transaction posts before the corresponding receipt. In manufacturing, backflushing records component consumption at the point of production completion - if production completes before the inbound receipt clears inspection, the system deducts from a balance that hasn't been updated yet. In distribution, the same pattern appears when shipment processing outpaces warehouse receiving.
Negative on-hand balances don't represent a real physical state - you cannot have fewer than zero units on a shelf. But they corrupt every downstream calculation that uses on-hand quantity. A facility with 400 positive-balance SKUs and 80 negative-balance SKUs computes an average on-hand quantity that is artificially suppressed. Days on hand is understated. Turns are overstated - and in extreme cases, where negative balances dominate the denominator, turns become negative, which is mathematically valid but analytically meaningless.
The subtlety here is that many negative balances self-correct within 24–48 hours once the receipt posts. Daily snapshots - which is what most ERP reporting uses - capture these transient states and bake them into period averages as if they represented sustained inventory positions.
Ghost inventory refers to items with a positive on-hand balance in the ERP that have had zero demand and zero receipts for an extended period - typically 12 months or more - and are formally discontinued or inactive in the item master. The on-hand balance exists because no one ever wrote it off, consumed it, or transferred it out. It sits in the system as real inventory from the ERP's perspective, and it inflates every aggregate inventory metric.
The critical distinction from slow-moving stock is permanence. Slow-moving stock is still active, still theoretically sellable, and still receiving periodic demand - just at a reduced rate that may be correctable with the right commercial or operational action. Ghost inventory will never turn. Including it in the active item pool inflates aggregate days on hand, suppresses aggregate turns, and distorts aging bucket distributions by adding perpetual weight to the 365+ bucket.
Ghost inventory accumulates gradually and often goes unnoticed because each item individually carries a small balance. The problem is visible only at the population level: a facility discovers it has 340 "active" items with zero demand in the trailing year, carrying $420,000 of book value. That $420,000 is invisible in any period-over-period comparison because it never moves.
The inventory balance in the ERP only reflects what the ERP knows about. Off-system inventory - consignment stock at customer sites, floor stock held informally in production areas, bonded warehouse inventory in transit, and vendor-managed stock at supplier locations - is systematically absent from every ERP-derived metric. The ERP reports what it has been told. What it hasn't been told doesn't exist in the data.
For manufacturers with consignment programs, this problem is significant. A company with $3.2M in on-hand ERP inventory may have an additional $800K sitting at customer facilities on a consignment basis - inventory that belongs to the manufacturer until consumed, represents real working capital, and generates real holding cost. DOH calculated from ERP-only data understates the true capital position by 25% in this example.
The reverse problem also occurs: inventory recorded as received in the ERP before it physically arrives at the warehouse. In-transit inventory that has been posted as on-hand creates an overstatement - the ERP reports stock available for production that cannot actually be picked yet. Both directions corrupt DOH and turns, in opposite ways, and both are invisible without cross-referencing against a non-ERP source of truth.
The lead time field in the item master is set once - usually at item creation or after the last supplier disruption - and rarely updated again. Over time, the replenishment lead time the ERP uses for reorder point calculations drifts further from the demonstrated lead time that actual PO receipt history shows. A supplier who reliably delivers in 12 days is still triggering orders based on a 45-day lead time that was entered three years ago.
The problem compounds when buyers try to help the system. When a supplier is late once, the buyer adds buffer to the lead time field - "just to be safe." The system responds by ordering earlier. The supplier ships on time, but the order was placed three weeks ahead of need. The result is three extra weeks of on-hand inventory per order cycle, permanently. DOH inflates. Turns drop. Items age faster than their actual demand rate would predict. And crucially, the buyer has no visibility into why - the analytics show excess inventory, not a lead time field that was padded two years ago by someone trying to avoid a stockout.
The counterintuitive reality: padding a lead time does not create a safety buffer. It creates a permanent excess. A 20-day lead time entered as 45 days shifts the reorder point 25 days early. At 30 units consumed per day, that is 750 units of structural excess inventory per SKU - not buffer, just stock that arrives and sits until demand catches up. Multiply across a raw material base of 2,000 SKUs and the working capital impact is material.
Each of the five problems has a specific precondition that must be met before the corresponding analytics produce reliable output. These aren't aspirational goals - they are the minimum prerequisites for days on hand, turns, and aging to mean what they claim to mean.
None of the five problems operates in isolation. A manufacturer that acquired two companies in the past three years is likely running all five simultaneously: UoM mismatches introduced at the first acquisition, negative balances from a backflush timing issue at the second, ghost inventory from discontinued items that were never cleaned up post-acquisition, consignment stock that lives outside both ERPs, and lead times that were padded after an acquisition-era disruption and never corrected.
In that environment, every inventory metric is wrong in multiple directions at once. Days on hand may be overstated by the UoM mismatch and understated by the missing consignment position, with the net error depending on which plant's convention the analytics layer happened to inherit. Turns are distorted by all four quantity-side problems before padded lead times inflate the reorder points driving excess on-hand.
The right approach is to treat data quality as a precondition, not a cleanup task. Inventory analytics run on a known-clean dataset produces a number you can act on. Inventory analytics run on unvalidated data produces a number that looks identical - and may drive the wrong capital allocation decision.
Related reading: How to Calculate Inventory Turns and Inventory Aging Analysis: Identifying Dead Stock both assume clean input data. This article explains what clean means in practice.
Questions about inventory data quality and how it affects analytics.
IQ Insights runs a data quality pass before every inventory calculation - UoM validation, negative balance detection, ghost inventory identification, and lead time variance flagging against demonstrated PO history - automatically, across every ERP.