Asked whether he wanted to see the inventory tooling, the owner of two brewpubs still counting by hand did not answer for himself.
“I guess I’d kind of. We could show [the person who’d be doing the counting].”
“I mean, ultimately, he’s gonna be the one doing it, so.”
It took him under five seconds, and it is the right answer to the question in this post’s title. The count is not owned by a system. It is owned by a person, and the only thing the software decides is how much of that person’s evening it takes.
What follows is the division of labor between the two systems that person stands between — your bar POS and whatever inventory platform you connect to it. If you want the sheet and the method, the bar inventory sheet has both. This post is about which system is supposed to know what, and what happens when they disagree.
Theoretical inventory
Theoretical inventory is what your point of sale says should be on the shelf. It starts from what you bought, subtracts what every sale should have used at the recipe you configured, and leaves a number. It is not a count. It is a prediction. A real count is the other number. The gap between them is the only figure in this post worth acting on, and neither number produces it alone.
How Do You Track Liquor Inventory?
Two systems track it and they track different things. Your POS records every pour it sells, so it can tell you what should be left. Your count records what is actually on the shelf. Decide now which one you will trust when they disagree, because they will.
Most of the confusion in this category comes from treating that as one job. It is two, and they fail in opposite directions. A POS is very good at the thing it watches — every ring, every recipe, every second of service — and completely blind to everything that happens without a ticket. A count is the reverse: it sees the shelf exactly as it is, once a week, and knows nothing about how it got that way.
Neither is the system of record for the other. The POS owns what sold. The inventory platform owns what you bought, what it cost, and what you counted. Writing that down before you connect them is most of the work.
What Does a POS Deplete Automatically, and What Does It Not?
It depletes what it sells, at the recipe you gave it. Ring a pour, and the system subtracts that pour. It cannot see a spill, a comp poured without a ticket, a heavy hand, a keg that foamed out, or a bottle that walked. Everything it cannot see is why you still count.
This is also where most operators are quietly doing the right thing and assuming they are behind. A brewery that sells from a taproom and a retail counter described its own approach to us:
“So, I mean, I’ll set two up just because one, like, is bar stock running.”
“I just bring kegs down so that I know where I’m at with kegs, but I don’t track them through, like pints and whatever.”
Kegs and spirit bottles, tracked. Pours, deliberately not. Twenty seconds later he added the part that matters:
“I’ve just been doing more manual stock taking recently.”
“But I’d like to have it more automated.”
He wants more automation, not more detail, and those are different asks. Every vendor page in this category implies that tracking everything is the goal. It is not. Tracking everything is how a weekly job becomes a two-hour job and then stops happening in March. Track what carries your money and deliberately skip the rest — then write down which is which, because that decision is the thing a new manager will not be able to guess.
The limit of what a POS can know is worth being blunt about, and the clearest version of it came from an operator rather than from us. He wanted live liters remaining in a keg:
“Unless you had like a live sort of tracking of how many liters of beers left in a keg that integrated, you know, like that would make.”
Then he answered his own question. Some venues fit flow meters, which measure the liquid itself rather than inferring it from sales. Most taprooms do not have them, and without them a POS is reporting a well-informed estimate — ounces sold subtracted from ounces filled. Foam, line cleaning and a heavy hand are invisible to it. Expect a close estimate, not a gauge.
How Do You Control Liquor Inventory?
Control is the gap between the two numbers, not either number alone. Subtract what the POS says should be left from what you counted, and the difference is your variance. Chase variance by product, weekly, on the twenty bottles carrying your money. Chase all of it and you will chase none of it.
The arithmetic behind that, along with par levels and how often to count, is covered in our brewery inventory guide and this post will not repeat it. What that guide cannot tell you is which number to doubt first, and the answer is almost always the matching rather than the count. An item that exists in one system and not the other produces a variance that looks like theft and is actually a configuration error.
What Should You Ask Before Connecting Bar Inventory Software to Your POS?
Five things: which system holds the master product list, how items are matched between them, what happens to an item that matches nothing, who creates a new product first, and how often the two sync. Get those answered before you buy, not during your first count.
Six things to settle before you connect the two systems
- Which system holds the master product list. One of them is where a product is born and the other follows. Decide which, write it down, and tell whoever adds products next month. We watched a venue answer this question in the middle of its build rather than before it, and the build is the expensive place to answer it.
- How items are matched. Usually a shared identifier on every product — a SKU or equivalent — carried in both systems. Matching identifiers link automatically. The matching key is the integration; everything else is settings.
- What happens to an item that matches nothing. On a live integration we watched recently, an unmatched item throws an error and the sale does not arrive in the inventory system at all. Ask this before you buy, because the answer tells you how much cleanup your first week contains.
- Where a new product gets created first. If a product can be created in only one system and must be copied into the other, that is a two-step job forever — and it is the step that gets skipped at 6pm on a Friday.
- What you are tracking, and what you are deliberately not. This is the item most operators skip and the one that saves the most time. You do not have to track everything, but you usually do have to map everything, including the items you chose not to track. Those get matched to a shared bucket so the sale still comes across. Give that bucket a name you will recognize in six months.
- Who owns the count. Not which system — which person. Whoever does the counting should be consulted on the tool, and if they are not on the demo call, it is worth getting them on the next one.
GoTab connects to fifteen inventory and purchasing platforms, and the six questions above are worth asking of any of them.
Can Your Liquor Cost Be Affected by Increased Inventory?
Yes, but not in the way the question implies. Holding more stock does not change what a drink costs you to make. It ties up cash and raises the odds of spoilage, breakage and loss. What moves the number is the purchase price behind each line, which is why a count with no vendor record is worthless.
That last clause is the whole reason the two systems have to talk. A count without a purchase price behind it is a quantity, not an inventory — it produces no value, no usage and no variance, and no amount of counting will turn it into one. The purchase price lives on the invoice, the invoice lives in the inventory platform, and the POS has no idea what you paid. Connect them and a count becomes a cost. Leave them apart and a count stays a number of bottles.
What Happens When Your POS and Your Inventory System Disagree?
Usually one of three things: an item exists in one system and not the other, the same item is matched twice, or a sale lands against the wrong product. All three show up as stock you think you have and don’t. Fix the matching before you blame the count.
Each one has a tell. A missing item produces a product whose stock never moves no matter how much of it sells. A double match depletes twice as fast as it should. A sale landing on the wrong product drains one line while another sits full. None of the three is a counting problem, and all three get blamed on the person counting. Check the product mapping first, every time, before anyone has a conversation about shrinkage.
And if you have not connected anything yet, you can still connect it later — two pre-opening venues we spoke to recently have deliberately deferred it to a second phase. The cost of waiting is not the integration. It is the product list: build it once in one system and the connection is mostly configuration, or build it twice in two systems over a year and the connection becomes a reconciliation project. Where your products, vendor records and stock levels live on the GoTab side is the manager dashboard.
Frequently asked questions
How do you manage bar inventory?
Count what is on the shelf on a fixed schedule, let the POS tell you what should have been there, and work the difference. Our brewery inventory guide covers cadence and par levels; the bar inventory sheet covers the columns that make the count usable.
What happens to an item that exists in only one system?
Nothing good, and usually silently. If it exists in the POS but not the inventory platform, the sale errors or lands nowhere and that product’s stock never moves. If it exists in the inventory platform but not the POS, you are counting something that can never sell. Both read as variance and neither is a counting error.
What is theoretical inventory?
What your POS says should be left, based on what sold at the recipes you configured. It is a prediction, not a count. Its value is entirely in the comparison: theoretical against actual is your variance, and variance is the number worth acting on.
How often should a POS and an inventory system sync?
It depends on the integration, and the honest question to ask a vendor is not “how often” but “what happens to a sale that lands between syncs.” If the answer is that it queues and arrives, nightly is fine. If the answer is vague, that is the thing to pin down before you sign.
Can you connect inventory software after you have already launched a POS?
Yes. The cost of waiting is the product list — you will reconcile two lists that grew apart rather than building one that was right from the start. If you know you will connect something eventually, build your product list as though it is already connected.
