Supermarket shrinkage: a worked example of where the margin goes

Every vendor's website has a case study. Most of them are unfalsifiable: a percentage, a grateful quote, no method. We would rather show you the arithmetic than ask you to trust a testimonial, so this post does something different.

Why this is a worked example and not a customer story

The group below does not exist. It is a composite, built from the shape of the supermarket rollouts we do, with figures chosen to make the arithmetic legible rather than to flatter anybody. Nothing here is a customer's reported result, no quote is attributed to a real person, and no number should be read as a promise about your shop.

We are doing it this way deliberately. A real case study needs a real customer who has given written consent, real numbers traced to named reports, and at least one thing that went wrong. Until we have all three on the record, publishing something that looks like a customer story would be a fabricated record, and a vendor who fabricates one number is telling you what the rest of the site is worth. When a customer does agree, we will publish that separately and say so plainly.

What you can take from this post is the method. The mechanics are real even where the group is not, and you can run the same arithmetic against your own numbers this week.

The group in this example

Groups like this grow the same way: one shop that works, then a second one nearby, then a lease too good to refuse. By the fifth branch, the systems that ran the first shop (a till at the counter, a purchase register in the office, a WhatsApp group for transfers) are being asked to do something they were never built for.

The problem: a number nobody could attribute

The annual count produces a variance. Say it comes to ৳48 lakh of stock value across the group over the year. That number is real, in the sense that the stock genuinely is not there. It is also useless, because it arrives once, twelve months late, with no branch, no month, no category and no cause attached to it.

The symptoms show up long before the cause does, and they are the same everywhere:

• Fast-moving lines show available stock in the system while the shelf is empty, so reorders get placed against numbers nobody trusts.
• Expiry write-offs are discovered at the shelf by whoever notices, not in a report, and nobody adds them up until year end.
• Day-end takes forty minutes a branch, and head office sees a consolidated picture the following afternoon at the earliest.
• When the variance is finally totalled, the honest answer to "where did it go?" is a shrug.

That last point is the whole problem. You cannot manage a number you measure once a year.

What most groups try first

Before changing systems, most retailers try these, in roughly this order, and it is worth naming the pattern:

1. 1More cameras. Useful for the one incident you catch. No effect on the monthly number, because most loss is not theft.
2. 2A second annual count, mid-year. Costs two nights of trading and produces another number nobody can act on.
3. 3A stricter register at goods-inward. Works at the branch with a disciplined storekeeper, and nowhere else.
4. 4A spreadsheet consolidating branch counts. Accurate for about three weeks after each count, then drifts.

Each of these aims at catching loss after it has happened, and none of them changes how often stock is checked. Our guide on how to reduce inventory shrinkage in a supermarket goes through the mechanics in more detail.

What actually changes the number

Four changes, in the order they pay off. The software makes them possible; the operational decisions are yours.

One item master, one price list, per-branch stock. Every branch sells from the same product record with its own stock figure, so a transfer out of Uttara is a receipt into Mirpur rather than two register entries that may or may not agree. Until this is true, every other number is built on sand.

Daily cycle counts instead of an annual count. Each branch counts a small set of lines every morning before the shutters go up (highest-value and fastest-moving first) and the variance is visible at head office the same day. Counting 40 lines a day at 12 branches is about 175,000 line-checks a year against one annual count of 9,000. That ratio is the entire trick.

Reason codes on every write-off. Damage, expiry, sampling, weighing loss and unexplained are separate codes. This is what splits one unusable total into the parts you can fix and the parts you cannot. Expect an argument with staff about it; have the argument.

Batch and expiry control on dated categories. Dairy, bakery and packaged food are received with expiry dates and picked FEFO, so near-expiry lines appear on a report before they appear in the bin.

See how the inventory module handles this and what multi-branch control covers.

The arithmetic, before and after

Here is the part a case study usually hides. These figures are constructed, but the relationships between them are the ones we see, and you can substitute your own numbers into the same shape.

Assume the group turns over ৳60 crore a year at retail, and the annual count showed ৳48 lakh of missing stock. That is 0.8 per cent of sales, which sounds survivable until you notice it is roughly a fifth of the group's net margin.

Once reason codes are running, a total like that typically splits something like this:

The first three are process problems with obvious fixes. The fourth is the one everybody assumes is theft, and it is usually the smallest slice, but you cannot know that until the other three stop hiding inside it.

Now the mechanism. If daily cycle counts catch a receiving error within a day instead of within a year, you can still raise it with the supplier. If the near-expiry report fires three weeks out, dairy gets discounted instead of binned. Neither of those needs a camera. Both need the count to happen more than once.

What we would not tell you is that this gets you to zero. It does not. It gets you a number with a branch, a week and a cause attached to it, which is the only kind of number anybody can act on.

How a rollout like this usually goes

The honest version, not the brochure version. A twelve-branch group typically goes live over six to eight weeks: one pilot branch first, then two branches a week.

• Data migration is the long pole. Nine thousand products with barcodes, supplier records and opening stock, and duplicate barcodes on loose items will cost you a week of cleaning nobody budgeted for.
• Training is quick for cashiers and slow for branch managers, because the managers are the ones being asked to change a routine.
• What usually breaks is the weighing-scale integration at one or two branches, and resistance to the morning count in the first fortnight. Both are survivable; both should be in the plan rather than a surprise.
• What groups say they would do differently is almost always the same: clean the item master before go-live, not after.

What we would tell a smaller group

If you run four branches rather than twelve, none of the mechanics change, only the arithmetic gets smaller.

1. 1Fix the item master before you fix anything else. Everything downstream inherits its errors.
2. 2Daily counts beat an annual count even if you count fewer lines than you think you should. Twenty lines a day beats zero.
3. 3Reason codes are worth the argument with staff, because they are what turns a total into a diagnosis.
4. 4Do not start with cameras. Start with the count.

If this sounds like your group

If you are running four or more branches and your shrinkage number arrives once a year with no branch attached to it, the mechanics in this post are the ones we set up for supermarket groups. See what MondayPOS does for supermarkets and grocery, read how to reduce inventory shrinkage, or book a demo and we will run a cycle-count and variance scenario on your own product list. Pricing is published per outlet at pricing page.