Your POS Isn't a Cellar System of Record, Here's the Gap

"We already track inventory in our POS"

It's the most common objection in any conversation about wine inventory, and it's completely understandable. The POS is already there. It already shows an inventory screen. It already decrements stock when something sells. Why add anything?

Because a POS and a cellar system of record are answering two different questions, and only one of them is "what's actually in my cellar right now?"

A point-of-sale system is a genuinely excellent piece of software for what it's built to do: capture transactions. It knows what was sold, at what price, at what time, by which server, on which terminal. That data is valuable and you should absolutely keep it. The mistake isn't using a POS, it's expecting it to be a system of record for the cellar, when by design it's a system of record for sales. Those are not the same thing, and the gap between them is where wine programs lose trust in their own numbers.

This piece maps that gap precisely: what a POS knows, what it can't know, and how integrating the two, rather than choosing between them, closes the loop.

What the POS knows: the sell side

Be fair to the POS. It's brilliant at its job. It knows:

What sold. Every line item, every glass, every bottle that rang through.
At what price. The exact amount charged, including any discount applied at the till.
When, and by whom. Timestamps, servers, terminals, the full transactional context.

This is the sell side of your wine program, and it's real, useful data. Sales velocity, revenue by wine, peak times, the POS is the right source for all of it.

The problem is that "what sold" is only half the story of "what I have." Sales are one type of movement. A cellar experiences many.

What the POS can't know: the cellar side

Here's where the model breaks down. A POS reasons in counts depleted by sales. A cellar lives in lots changed by many kinds of movement. The POS simply has no representation for most of what happens to your stock.

It doesn't know your lots or cost basis

When you buy the same wine twice at different prices, that's two lots with two cost bases. The POS, at best, holds one count and one cost, usually a blended or last-known figure. It can tell you a bottle sold for 70; it can't reliably tell you whether that bottle came from the case you bought at 18 or the allocation you bought at 26. Your true margin depends on the lot, and the lot is exactly what the POS flattens away. (Why lots matter is the heart of our wine inventory guide.)

It doesn't know non-sale movements

Most of what changes your cellar never touches the till:

Purchases and deliveries, stock arriving (the POS only learns of stock when you tell it, if at all).
Transfers between sites, rooms, or storage units.
Pours, tastes, and comps that don't ring through as a standard sale.
Breakage, spoilage, and adjustments, the honest losses.

To the POS, these are invisible. A bottle transferred to your second venue didn't "sell," so the POS count doesn't move, even though that bottle is no longer in this cellar. A bottle broken in the back is just... gone, with no record of why. Multiply these across a busy operation and the POS count and the physical cellar drift apart, steadily, with no trail explaining the divergence.

It doesn't track pours at the millilitre

By-the-glass is the sharpest example. A POS records "one glass of the Chablis" as a sale. It does not record 150ml drawn from a specific 750ml bottle that's also serving tastes and comps. It can't reconcile a glass program against bottle stock because it doesn't represent partial bottles. (That specific leak gets its own treatment in by-the-glass margin.)

The gap, stated plainly

Put it in a table and the divide is stark:

Question	POS	Cellar system of record
What sold, when, for how much?	Yes, its core job	Inherited from the POS
What physically remains right now?	Only a sales-depleted count	Yes, lots and movements
Cost basis per lot?	Blended at best	Native, per acquisition
Transfers between sites?	Invisible	Tracked as movements
Breakage, comps, tastings?	Invisible	Logged with cause
mL-level pours?	No	Yes
Why is variance high this month?	Can't say	Read the movement history

The POS closes the sale. It does not close the loop on what physically remains in your cellar. That loop, purchase, pour, transfer, adjustment, all reconciled into a current, trustworthy stock position with an audit trail, is the job of a cellar system of record. It's a different question, and it needs a system built to answer it.

The fix isn't either/or, it's integration

Here's the part people miss: this is not a fight between your POS and a cellar system. You don't rip out the POS. You integrate it.

The right architecture uses each tool for what it's best at:

The POS stays the system of record for sales. It keeps doing what it does brilliantly, capturing transactions at the till.
A cellar system of record owns lots, movements, and cost basis. It models everything the POS can't see.
Integration connects them, so sales flowing through the POS automatically become movements in the cellar system. A bottle sold at the till depletes the right lot in the cellar record, no double entry, no manual reconciliation.

That's what closing the loop means in practice. Sales deplete stock automatically and the cellar system independently tracks the non-sale movements the POS never sees. Together they give you something neither can alone: a current, trustworthy stock position where every change, sale, pour, transfer, breakage, has a cause and a record.

Vinius is built for exactly this. It models inventory as lots and movements and is designed to integrate with the POS rather than replace it, POS integration lets sales flow in automatically while the cellar system owns the parts the POS structurally can't. The till stays the till; the cellar finally gets a real system of record.

Governing the connection

Integration introduces a fair question: if an external system is touching your data, how is that governed? Connecting tools shouldn't mean handing over blanket access.

The principle is scoped access. Integrations and headless clients operate with explicit, required scopes and tracked usage, they act within defined limits rather than with the keys to everything. A POS integration can write the movements it needs to write, and nothing more. That keeps the loop closed and governed, which matters more the larger and more multi-site your operation becomes. (We cover the multi-site governance angle in multi-venue wine pricing.)

What changes once the loop is closed

When the POS and a cellar system of record work together, the day-to-day shifts in concrete ways:

Your stock number is trustworthy. It reflects sales (from the POS) and every other movement (from the cellar system), so the menu and the cellar stop drifting apart.
Margins are real, not blended. Lot-level cost basis means you know what each sale actually earned.
Variance has an explanation. When the count is off, you read the movement history instead of starting a guessing game.
"86" moments drop. You see wines running low against real stock, in time to reorder. (And reorder thresholds can turn that signal into a supplier-ready order.)

None of this asks you to abandon the POS. It asks you to stop expecting it to be something it was never built to be.

The takeaway

Your POS is a superb record of what sold and a poor record of what remains, by design, not by defect. It reasons in counts depleted by sales; a cellar reasons in lots changed by purchases, pours, transfers, and adjustments the till never sees. The fix isn't choosing one over the other. It's integration: let the POS own sales, let a cellar system of record own lots and movements, and connect them so sales flow in automatically while the cellar tracks everything else, all under scoped, governed access. That's how you close the loop and finally trust your own numbers.