Shrinkage: How to Find Where Stock Is Disappearing Between Receiving and Sale

Every multi-location business has a number it dislikes: the gap between what the system says is on the shelf and what is actually there. Cycle counts come back short, a month-end adjustment gets posted, someone says "shrinkage," and everyone moves on. The label does a lot of work. It covers theft, but it also covers a mis-scanned pallet, a transfer that never arrived, a return put back on the wrong shelf, and a box of filters taken to a service bay with no paperwork.

Unexplained inventory variance is rarely a single problem. It is usually a dozen small ones, each living in a different system or a different team's habits. That is why one audit seldom fixes it. The audit finds a number, not a cause.

This article maps the points between receiving and sale where stock goes missing, shows what each one looks like in the data, and sets out a practical way to find the leaks and close them. It then explains how we approach the problem at The Ninjaz Group.

Shrinkage is a lifecycle problem

Most advice on how to reduce inventory shrinkage starts at the end, with the count that does not match. It works better to start at the beginning and follow a unit of stock through its life. At every handoff, a physical event has to be matched by a record. Loss happens where the two diverge.

A typical lifecycle has these stages:

• Receiving: goods arrive, and the purchase order, delivery note and physical count must agree.
• Putaway and storage: stock moves to a location, and the bin record must match where it really sits.
• Transfers: stock leaves one site, spends time in transit, and arrives at another.
• Internal use: workshops, field crews, demo fleets and back offices consume parts and supplies.
• Sale: the POS or dealer management system (DMS) decrements the right item, in the right unit, at the right location.
• Returns: stock comes back and is restocked, scrapped or sent to the supplier.
• Write-offs and adjustments: finance records whatever difference is left.

Each stage is usually owned by a different team and often by a different system: ERP for purchasing, a warehouse management system (WMS) for storage, POS or DMS for sales, and a finance ledger for adjustments. The causes of stock loss therefore cluster at the seams between these systems, not in the middle of any one of them.

Receiving errors and transfers: the quiet leaks

Receiving

Receiving is where inventory accuracy is set. If the record is wrong on day one, every later count inherits the error. The common failures are mundane:

• A short shipment is accepted as complete because the delivery note says so.
• A similar item is received under the wrong SKU.
• A case is booked as a single unit, or the reverse.
• Receipts are keyed in bulk at the end of the shift from the paperwork, not from a count.
• Goods are received against the wrong purchase order, which quietly distorts two orders instead of one.

In the data, these show up as receipts that match the order exactly, every time, with no exceptions, which is rarely true of real deliveries. They also show up as long gaps between a delivery's arrival and its posting, and as supplier invoices that do not reconcile to what was booked in. A three-way match between the purchase order, the receipt and the invoice, held across ERP and finance, catches most of these. It only works if all three records can be read side by side.

Transfers

Transfers are the classic black hole. The sending site posts a shipment, the receiving site posts a receipt, and in between the stock sits in an "in transit" status that nobody reviews. If the receiver never confirms, or confirms a different quantity, the difference slides into a transit account. Finance sees a balance. Operations sees nothing. Both assume the other is watching.

Useful signals are the age of in-transit items, the quantity sent versus received by site pair, and who confirms receipt and how quickly. A lane where confirmations are consistently a day late or a few units short is telling you something.

Returns, write-offs and unrecorded internal use

These three are the leaks that look like normal business, which is why they last.

Returns. A customer return is restocked without inspection, or restocked to the wrong location, or a credit is issued while the item never physically comes back. Supplier returns have the reverse problem: the box ships, but nobody decrements stock or claims the credit. Each return crosses at least two systems, sales and inventory, and often a third in finance.

Write-offs. Scrap and damage have legitimate reasons, but a generic "inventory adjustment" code accepts any reason at all. When write-offs are posted under one code, with light approval and no link to an event, they absorb counting errors, process failures and the occasional theft without distinction. The code is the problem: it destroys the information you need to separate one cause from another.

Unrecorded internal use. This one is the most underestimated of the causes of stock loss. A technician takes parts for a repair, a field crew pulls materials from central stock for a job, a branch uses consumables for a display, and no one raises a document. The item is gone, no sale was recorded, and the shelf count is now wrong. In a dealer group or a field-service business, the cure is to compare consumption against what should have consumed it: repair orders, job tickets or maintenance work orders. If parts leave stock at a rate that the work orders cannot explain, you have found a gap worth chasing.

How fragmented systems turn variance into a mystery

Consider a group with twelve locations. The ERP holds purchasing and finance. A WMS runs the two largest warehouses. The ten smaller sites use the stock module built into their POS or DMS. Transfers between sites are arranged by email and a shared spreadsheet, and someone at the receiving end updates the system when they get to it.

At month end, finance sees that the ledger value of inventory is lower than the sum of the physical counts, or higher, and posts a single adjustment. Nobody can say where it came from. It might be a receiving error at one of the warehouses, a transfer that was confirmed twice, a return restocked into the wrong site, or parts used in a workshop. Each system is internally consistent. The discrepancy is only visible when you join them, and joining them takes someone several days with a set of exports.

The joining is hard for ordinary reasons. The same part has one code in the WMS and another in the POS. One system tracks by each, another by box. Sites count on different calendars, so totals never line up on the same date. Timestamps differ because one system posts in real time and another batches overnight. A variance of a few units on a single SKU is then spread across systems in ways that look like noise.

So the business ends up with a total and no cause. It cannot tell a process problem at one site from a systemic problem in one lane, and it cannot tell carelessness from something worse. The result is blanket measures such as more counts, tighter cages and stricter rules everywhere, which cost a lot and rarely touch the actual leak.

The real cost of unexplained variance

The cost is not limited to the value of the missing stock, though that is the part that gets booked.

• Time. Branch and warehouse staff recount. Finance reconciles by hand. Managers hold meetings about numbers that nobody trusts. All of it is effort that produces no improvement.
• Inventory. Phantom stock, which the system shows and the shelf lacks, hides real shortages. The opposite also happens: stock sits unrecorded on a shelf while the system triggers another purchase. Either way, working capital goes into the wrong place.
• Lost deals. A salesperson promises a part or a unit that is not there. A service bay waits on a component the system said was in stock. The customer goes elsewhere or waits, and neither outcome is visible in the shrinkage report.
• Mistakes. Reorder points, margin reports and cost-of-sale figures are all built on stock records. If the records are wrong, the decisions drawn from them are too.
• Burnout. Warehouse and counter staff get blamed for losses they cannot explain. Managers spend their weeks firefighting discrepancies instead of running the site.
• Customer frustration. Delayed orders, cancelled jobs and repeated apologies add up, and customers remember them.

There is also a slower cost: finance stops trusting operations data, and operations stops trusting finance's adjustments. When that happens, nobody is looking at the same picture.

How to reduce inventory shrinkage: a workable sequence

None of these steps depends on a particular tool, though several depend on data from different systems being readable together. Work through them in this order.

1. Break the variance down by stage. Replace the generic adjustment code with specific reasons: receiving discrepancy, transfer difference, damage, customer return, supplier return, internal use, count correction. You cannot find a pattern in a single bucket.
2. Agree one item identity. Map part codes, units of measure and location names across ERP, WMS and POS or DMS so the same item is recognisably the same everywhere.
3. Match receipts to orders and invoices. Track the delay between delivery and posting, and review exceptions by supplier and by receiving site.
4. Manage in-transit stock as an account with owners. Age it, set a confirmation deadline, and escalate anything that passes it.
5. Tie internal consumption to a document. Every issue from stock should reference a work order, job ticket or cost-centre request.
6. Count by risk, not only by calendar. Count high-value, fast-moving and adjustment-prone items more often, and count soon after any anomaly.
7. Review adjustments by site, user, item and time. Concentration is the signal. A cluster of write-offs on one shift, or one lane's transfer differences, points to a cause.
8. Alert on exceptions as they happen. Waiting for month end means the evidence is cold and the people involved cannot recall what occurred.

Steps 2, 7 and 8 are the ones that tend to stall in a fragmented estate, because each requires data from more than one system at once.

How Ninjaz and the Operating Platform address it

The Ninjaz Group is a managed-services partner for multi-location, customer-centred enterprises, including automotive dealer groups, energy and industrial companies with field sites, field service, real estate and retail networks. Our work on stock loss follows the same path as any engagement.

It starts with a Blueprint. We map the operation and find where work is done twice, where data goes stale and where money leaks. For inventory, that means walking the lifecycle above with the people who receive, move, sell, return and account for stock, and recording which system holds each handoff and which do not. You keep the map, whatever you decide to do next.

Build & Link follows, and it involves no rip-and-replace. The software you have already paid for stays. Through Managed Link, the integration layer we build, own and maintain, we connect the existing ERP, WMS, POS or DMS, inventory and finance systems to the Ninjaz Operating Platform. The platform's unified data layer keeps one record per asset and order, so a receipt, a transfer and a sale refer to the same item instead of three variants of it.