PourCostpour-cost and variance checks from read-only POS data

Facts on this page come from the PourCost README, its plan for item-level data, and its unit-cost check, all dated 2026-10-20 to 10-23. Not independently verified. No pour-cost results are published here, and no dollar figures from invoices or costs. There is no “after” yet because live runs have not started.

Earlier notes call this build Pour Cost Detective. It compares what the POS says was sold with what the bottles say was poured, to put a dollar figure on the gap.

PourCost is read-only. It never changes anything in the POS or the inventory system.

Problem

Pour cost is the share of a drink’s sales that goes to what’s in the glass. When it drifts, it is usually over-pouring, unrung drinks, wrong costs in the inventory system, or bad counts. Most bars find out at month end, if at all, and can’t tell which drinks caused it.

The goal: a daily, per-location view of theoretical pour cost by category and item, a weekly actual-vs-theoretical check after the inventory count, and silence unless something crosses a threshold.

Stack

• The POS, read through a read-only connector. Every location is reported separately, never combined.
• The inventory system: exports for bottle costs, bottle sizes and counts.
• A Python pipeline: one script saves the raw connector output, another builds recipe costs from the inventory exports, and compute.py produces per-item and per-category pour cost, variance, flags and severity.
• A single-file browser app (pourcost.html). It loads CSVs or the pipeline’s JSON. No install, no network calls; files never leave the device.
• Headless-Chrome tests for the app: hand-checked math, sorting, filters, flags, CSV upload and JSON import.

Steps

1. Pull sales for the business day (2 AM cutoff) per location, read-only.
2. Get a trustworthy net sales figure. The same rule as the morning-digest build: never use the connector’s own “net” (it includes tips). Derive net from tax, and if order counts don’t match across calls or the tax rate isn’t flat, report no number rather than a guess.
3. Cost each drink from inventory bottle costs and pour sizes. Anything missing is flagged as missing, never estimated.
4. Compute theoretical pour cost by category and item. Group by sales category, or by menu group when the source has none, and say which was used.
5. Weekly, after the Monday count: allocate counted bottles to the drinks that use them and compute actual vs theoretical.
6. Flag anything past the threshold. Over-use is severity “today”; under-use is “brief” (often a count error or an unrung drink).
7. Stay quiet when nothing is flagged.

Real numbers

Source: the owning agent’s files, 2026-10-20 to 10-23. Counts and settings, not results.

• Variance threshold: 2.0 points. Category targets are standard industry starting points, not the bar’s own: liquor 18%, beer 24%, wine 32%, cocktails 20%. A category with no match gets no target rather than a made-up one.
• The connector sees every location, but through it every tool returns a one-line text summary: no item-level sales.
• One historical item-level test on real data: a POS product-mix export for 8/22 to 10/2, theoretical pour cost only (no inventory count matched that window).
• 212 POS items have a costed recipe. 11 recipe lines are missing a cost or size.
• Pour costs computed from live daily data: 0 so far. Time saved: not measured.

Misfires

1. The connector only gives store totals. Live pour cost needs item-level sales, which the read-only connector doesn’t expose. A small read-only “product mix” tool was planned for it; that change is waiting on the owner’s OK, so daily runs give store-level net sales only.
2. Pour specs are a mapping, not house specs. The recipe pours came from an agent’s mapping (standard pours, cans, draft sizes), not from confirmed house specs. Signature cocktails have no recipe yet.
3. Pack prices costed as single cans. A unit-cost check found canned drinks in the inventory system priced per pack instead of per can, and liquor buttons depleting the wrong pour size. Both would show false over-pour. The fixes were drafted, not applied, because they need an owner’s OK.
4. Two inventory systems. A separate weekly inventory-ledger routine did overlapping work and stalled when several browsers were connected and it couldn’t pick one. It was merged into PourCost on 10/23 so there is one system.
5. Second location has no cost source. The other concept has no recipe or bottle-cost data, so it can’t be costed yet.
6. Missing is not zero. Early on it was easy to let a missing cost read as $0. The app now shows ”—” with the reason instead.

Copy-paste template

Routine prompt (a starting point, not one that has run):

Every day at [TIME] (after the [CUTOFF] business-day cut), for each location separately, pull yesterday's item sales read-only from [POS]. Compute net sales the approved way; if counts don't match, report no number. Cost each drink from [INVENTORY SYSTEM] bottle costs and pour sizes; flag anything missing, never estimate it. Compare theoretical pour cost by category to [TARGETS]. Flag anything more than [THRESHOLD] points off. Over-use = today, under-use = brief. If nothing is flagged, say nothing. Never change anything in [POS] or [INVENTORY SYSTEM].

Rules to keep: read-only, locations never combined, missing is never zero, standard targets labeled as standard until you set your own, and quiet when clean.

What’s next

• Owner decision on the read-only product-mix tool, then test it against a POS export for the same days before trusting it.
• Confirmed house pour specs and signature cocktail recipes.
• Apply the drafted inventory cost fixes after an owner’s OK.
• First weekly actual-vs-theoretical run after a Monday count, then real numbers here.

Live link or demo

No public live link. The recorded demo at the top of this page shows it end to end. Screen recording of a local copy running its built-in example data. 42 seconds, no sound. Nothing here is a real number.