Your register counts drinks, not bottles
A point of sale system counts units: one Negroni, one beer, one shot. A bottle of liquor isn't a unit. It's 750 milliliters, going out a pour at a time in whatever size the drink called for, over days or weeks, sitting part-full for nearly all of that time. That's the whole problem, and it isn't a software bug.
The mismatch is physical, not technical
A unit and a reservoir aren't the same thing
Someone orders a rum and coke. The bartender pours it, the register rings "1 rum and coke," a card gets charged, and as far as the point of sale is concerned that transaction is finished. It did its job. Somewhere behind the bar, the bottle that pour came out of still has about twenty-four ounces in it, and will for another two or three weeks depending on how the night goes. The register has no way to know that, and it was never built to.
That's the fact everything else here comes back to. A POS decrements units. A bottle isn't a unit, it's a reservoir: one object that gets a little emptier with every pour, sits open on a shelf between pours, and doesn't finish being sold until the last ounce is gone, sometimes weeks after the first one left. Ring up a sale and the system can tell you a drink went out the door. It can't tell you what's actually left in the bottle that supplied it, because nothing about a sale event carries that information forward.
Where it actually breaks
A Negroni pulls partials from three bottles. One drink, three spirits, each pulled at a different rate. The register logs "Negroni, 1." It has no idea it just touched three separate reservoirs, so nothing about that sale tells you the gin moved faster than the vermouth this week, or that the Campari you're running low on came almost entirely from cocktails, not from anyone ordering it neat.
A free pour is 1.5 ounces, plus or minus a bartender's night. The POS records the sale at whatever size is on the menu. The bottle empties at whatever size actually left the spout, and those two numbers drift apart a little more with every shift.
"Make it a double" changes two things, and the register only sees one. The price goes up, that part's easy. The depletion should double too, and on most systems it doesn't, because the item on the register is still just "Negroni" with a modifier, not two units of gin coming out of the well.
Spills, comps, staff drinks, and tastings are real consumption with no sale attached. A round on the house, the pour someone tastes to check a keg, the glass that gets knocked over: all of it is liquid actually leaving a bottle. None of it rings anything up, so none of it shows up anywhere the register looks.
What the blind spot costs you
Every number you build on top of it inherits it
None of this is dramatic on any single night. A quarter ounce here, a comp there, a double that only counted once. The cost is that the gap never announces itself. It grows quietly, and everything you calculate afterwards is calculated from it.
Your pour cost, your margin on a category, the variance report that says you're three bottles short: all of them start from a picture of the shelf that the register was never able to see. You aren't being lied to. You are being told, accurately, about something else.
A sale, taken apart
A drink is a list of withdrawals
So we stop treating a sale as one event and start treating it as what it actually was. The register says "Negroni, 1." A Negroni is equal parts, an ounce each of gin, Campari and sweet vermouth, so that sale was three withdrawals from three different reservoirs, not one unit of anything.
We hold that mapping, so a sale coming off the register turns into amounts leaving specific bottles. A neat pour of the same gin takes an ounce and a half. A double takes three. The Negroni takes one. All of it comes off the same gin, because it is the same gin.
The register carries on doing the job it is good at, which is telling us what sold. What it never had to know is what that sale took off the shelf.
Not a knock on your register
A register is excellent at what it does. It authorizes cards, splits checks, tracks tips, and closes out a shift fast enough to survive a Friday rush. We integrate with Square for exactly that reason. It is good software, doing the job it was built for.
We are not going to tell you your POS is bad. It was built for a different job. Selling things is the job. Modeling a slowly draining reservoir that gets touched by a dozen different drinks in a dozen different amounts was never part of the brief, and no register vendor claims otherwise.
And the mapping only knows what a drink was supposed to take. We cannot see the spout. A heavy hand on a Friday leaves the bottle further down than any recipe says it should be, and the only thing that catches that is somebody walking over and looking at the bottle.