Bar Wine Waste and Breakage Tracking Guide
Madeleine Cruickshank
September 17, 2026 · 7 min read
What should a bar log when a bottle of wine is broken or spilled?
Log eight fields on every incident: date, shift, employee, bottle, quantity, reason code, approver, and cost. Anything less and the record cannot tell you who, when, why, or how much, which are the only four things a waste log exists to answer.
Most bars log two of those eight, usually bottle and a vague note, and then wonder why the waste data never explains a variance.
The Fields Every Waste Record Needs
Date. The date the incident happened, not the date it was entered.
Shift. Which service period, identified consistently. "Friday PM" is useful; "Friday" is not.
Employee. Who logged it, and where relevant who was involved. This is an attribution field, not a blame field, and the distinction matters for whether staff use it honestly.
Bottle. The specific product, at the same level of detail your inventory uses. If your count tracks vintage, your waste log tracks vintage.
Quantity. Full bottles, or a fraction for partial loss. A spilled glass from an open bottle is not a lost bottle and should not be recorded as one.
Reason code. From a fixed list, never free text. This is the field that makes the log analyzable rather than anecdotal.
Approver. Who signed off, for incidents above whatever threshold you set.
Cost. Value of the loss, at cost rather than menu price, so waste totals reconcile against purchasing rather than revenue.
Why does shift and employee matter on a waste record?
Because waste that clusters by shift or by person is a different problem from waste distributed evenly, and you cannot see the pattern without those two fields.
Evenly distributed breakage across every shift is usually a storage or workflow issue: a badly placed rack, a tight service path, glassware stored where bottles are handled. Breakage concentrated on one shift or one person is a training issue, or occasionally something else. Same total cost, completely different fix, and the raw number tells you nothing about which you have.
What date should be recorded, the incident or the count?
The incident date. Recording the count date collapses everything that happened between counts into a single point, which destroys any ability to see clustering by day or shift.
This sounds obvious and is one of the most common defects in a real waste log, because the log gets filled in retroactively at count time from memory. If your log is being completed during the count rather than during service, the date field is already lying to you.
Standard Reason Codes for Wine Waste
Use a fixed set. Seven codes cover nearly everything in a wine program:
Breakage. Bottle physically broken, before or during service.
Spillage. Wine lost during pouring or transport, without the bottle breaking.
Spoilage. Corked, oxidized, or otherwise faulty wine, including bottles returned by a guest for a genuine fault.
Comp. Wine given away deliberately, for service recovery or hospitality.
Tasting pour. Wine poured for a guest to sample before buying by the glass or bottle.
Staff training. Wine opened deliberately for staff education.
Returned by guest. Wine sent back for reasons other than a fault, such as the guest simply disliking it.
The last one is worth separating from spoilage even though both end with an unsold bottle, because one is a supplier and storage question and the other is a service and recommendation question.
Should comped and broken bottles use the same code?
No, and collapsing them is the single most common reason a waste log stops being useful.
A comp is a deliberate business decision with a return, whether that is service recovery or a regular being looked after. Breakage is an unintended loss. Both reduce inventory identically and mean completely different things. If they share a code, your waste total is a number you cannot act on, because you cannot tell what portion was chosen.
Who Logs It, and Who Approves It
Whoever is present logs it, immediately. Approval is a separate step and should be required above a value threshold you set, not on every incident.
The reasoning is practical. Requiring manager approval on a single spilled glass means the glass never gets logged, because nobody interrupts a manager mid-service for that. Requiring approval on a broken magnum means the loss gets seen by someone accountable. Set the threshold where it captures material losses without making routine logging into a request.
Two conventions worth adopting. Staff should log their own incidents rather than reporting them to someone who logs on their behalf, since every handoff loses detail. And a logged incident should never be punished in a way that makes the next one go unlogged; the moment staff learn that honesty costs them, your data stops reflecting reality and your variance gets worse rather than better.
How the Waste Log Feeds Variance
The waste log is the explanation layer for variance. Variance tells you the count is short; the waste log tells you why, and the portion of the gap it cannot explain is your actual shrinkage.
That reconciliation process is covered in full in our bar wine inventory count guide, which walks through counting and reconciling after a shift. For how software surfaces variance automatically and catches it earlier, see our guide to wine bar inventory software.
The only point worth making here that those posts do not cover: a waste log only reduces unexplained variance if incidents are logged at the time rather than reconstructed at count. A log completed during the count will always match the count, which makes it useless as an independent check.
Retention, Audits, and Cost Attribution
Keep waste records for at least as long as you keep purchasing records, so the two can be reconciled against each other during an audit or a supplier dispute.
Attribute waste cost to the period the incident occurred, not the period it was discovered, or your cost of goods by month will be wrong in both directions. And keep the approver field populated, since a waste log with no approvals on material losses is the first thing an auditor or an owner will question.
If waste is feeding into menu decisions, particularly on by-the-glass pours where tasting pours and spillage concentrate, see our guide to menu engineering with cellar analytics. For keeping the list itself current as bottles come and go, see our guide to cutting wine list update time and our restaurant wine list workflow guide.
See how InVintory handles waste, variance and service prep together: explore InVintory for hospitality →
A waste log is not a compliance exercise. It is the only record that explains the difference between what you bought and what you sold.
Talk to us about your wine program.
FAQ
What is a reasonable amount of wine waste for a bar?
This varies by program, pour volume, and how much by-the-glass business you do, so a single benchmark is misleading. What matters more is whether your waste is explained and stable rather than whether it hits a particular percentage.
Should tasting pours count as waste?
Yes, logged under their own reason code. They are a real cost and a deliberate one, and separating them from breakage lets you evaluate whether the tasting pours are actually converting to sales.
Who should approve a wine waste record?
A manager or whoever holds cost accountability, but only above a value threshold you set. Requiring approval on every incident reliably results in small incidents going unlogged.
Can waste tracking integrate with an existing POS?
Often, depending on the systems involved. For operators looking at integration specifically, the InVintory API is the starting point.
