Someone raised the buffer on 38 SKUs. Nobody could tell me who.

Last November our reorder queue looked wrong. Thirty-eight SKUs sat in the out-of-stock bucket, and I could see stock on the shelf for most of them. A stainless keyring blank showed 58 units available and a red flag. I walked out to the racking to check. There were 58.

My first assumption was a sync problem. That cost me an afternoon.

It wasn't a sync problem. The buffer on those 38 SKUs had been changed from 10 to 60. Someone on the team had done it with good intentions, ahead of the Christmas rush, and nobody remembered doing it. I asked in the group chat. Three people said it wasn't them, and one said maybe.

What a buffer does to a number

Stocura treats a SKU as out of stock once available units drop to the buffer. That is the point of a buffer: it is the cushion you refuse to touch. For a keyring blank selling about 5 a day, a buffer of 10 is two days of sales. A buffer of 60 is twelve days.

So the same 58 units on the shelf meant two different things. Under a buffer of 10, I had 58 - 10 = 48 sellable units, nearly ten days of stock. Under a buffer of 60, I had nothing, and the queue told me so.

The cost of that wrong flag is easy to price. Raising the buffer by 50 units on a blank that costs me $1.40 locks up $70 of stock per SKU. Across 38 SKUs that is $2,660 sitting in a cushion nobody had decided to build. Not a disaster. But in November I had better uses for $2,660, and I was about to place orders to cover a shortage that didn't exist.

Finding who did it

The money bothered me less than the next problem. I had no way to answer a simple question: who changed this, and when?

In the old setup, with settings spread across Cin7 Core fields and a spreadsheet or two, I would have been guessing. I'd have checked file histories and asked people to remember a Tuesday three weeks ago.

Stocura keeps an audit log with field-level diffs. I opened it, found one of the affected SKUs, and the entry was there: buffer, 10 to 60, the user who saved it, the date. Same edit, same user, a run of other SKUs within a few minutes of each other. It took about four minutes.

The explanation was ordinary. A team member had been told to "make sure we don't run out of the Christmas lines." She did exactly that, SKU by SKU, in one sitting. Nobody told her what the buffer feeds into, because nobody had written it down. That was my miss.

Three weeks is too long

The change was live for three weeks before I noticed. In that time the queue over-reported shortages, and two of the 38 had already made it into a draft PO. I caught those before they went out. I'd rather not think about the ones I wouldn't have caught.

The buffer is a quiet setting. It doesn't break anything. It just tilts every decision downstream by a small, consistent amount, which is the hardest kind of error to see.

What I do now

A few rules, boring on purpose.

Every buffer change gets a note. Stocura lets you add a note to a SKU and resolve it later. If someone raises a buffer, they leave a note saying why and when it should come back down. "Raised to 40 for the Mother's Day run, drop back after May 15." When the date passes, the note is still open, and an open note is a thing someone can see.

Seasonal buffers have an end date. This is the one that would have saved me. A buffer raised for a peak and never lowered is a permanent tax on cash. I put the reset date on the calendar the day I raise it.

I read the audit log on Monday. Ten minutes scanning the recent entries. I'm not looking for wrongdoing. I'm looking for the edit I didn't know about. Most weeks there's nothing. The week there's something, it's a lot cheaper to find it on day six than on day twenty-one.

I also changed how I brief people. Anyone who touches stock settings now gets a two-line explanation of what the number does downstream. Stocura has admin and viewer roles, and I've been more careful about who gets admin. People will always want to help. Telling them what the buffer feeds into costs less than the correction.

A quick check on your own buffers

Pull a list of every SKU where the buffer is above the global default. For each one, ask whether you can say why it is higher and when it comes down. If you can't, that buffer is probably a leftover.

Then multiply the excess units by unit cost. Mine came to $2,660 on 38 SKUs. I'd guess most operators with a few hundred SKUs have a number like that hiding in the settings.

This week

Sort your SKUs by buffer, highest first. Look at the top twenty. Reset the ones you can't explain, and put a reason and a date on the ones you keep.