Do I need my POS integrated with my purchasing system?

For a bar programme, no. Both systems already export what you need — a price list and a sales-by-item report. Matching those to one costed list monthly is faster to set up than any integration and survives a POS change.

What is the difference between a SKU and a PLU?

A SKU identifies a product — one bottle of one bourbon. A PLU identifies a button on the till — a 30 mL pour, a double, a bottle sale. One product routinely has several PLUs, which is why matching sales to products by name alone fails.

How do you catch a supplier price rise?

By re-importing the supplier's price list rather than re-keying it. When the list is matched to your products by the supplier's own codes, an updated list moves every cost that depends on those products at once, and the report shows which menu lines just lost margin.

Why purchasing and the POS never agree

Jesse Williams · 18 September 2026

In one paragraph

Purchasing and the point of sale disagree because they were never introduced. The supplier's system knows products by its article codes and case prices; the till knows buttons by PLUs and inc-tax prices; and nothing in between knows that the 700 mL bourbon on the invoice is the 30 mL pour on the button, or that the bourbon's price rose last week. The fix is not an integration — it is a reconciled product list that carries both codes, a price flow from supplier list to cost per serve, sales imported from the till and matched back to the menu, and a monthly check that the two systems still describe the same bar.

Every hotel I have worked in runs the bar on two systems that never agree. The purchasing side — the supplier portal, the procurement platform, the invoice folder — knows what was bought and at what price. The point of sale knows what was sold and for how much. Between them is a gap, and the beverage margin lives in the gap.

Two namespaces

The root of it is that the two systems name things differently, and both are right.

A supplier’s system has an article code for the 700 mL bottle of bourbon, and a case price. The till has a PLU for the 30 mL pour of that bourbon, another for the double, another for the bottle sold at the pool. One product, three buttons. Nothing in either system records that they are the same liquid.

Worse, the till’s names drift. “Bourbon 30”, “BOURBON SGL”, “Bourbon (pool)”. A report exported from the POS uses whatever the last person to edit the button typed. Matching by name works for a month and then silently stops.

The answer is a product list of your own that carries both codes: your SKU for the product, which faces the till and drives sales matching; the supplier’s code, which faces ordering and lets a price list land on the right record. Keep them separate. Writing the supplier’s code into the SKU field is the mistake that breaks sales matching for every product a price list ever touched.

The price flow

Costs move in one direction: supplier price list → product cost → prep cost → batch cost → cost per serve → menu GP. The flow breaks the moment the first link is re-keyed by hand.

Re-import the price list instead. A supplier’s spreadsheet has a shape — a code column, a description, units per case, a case price — and once that shape has been recognised and confirmed, it can be remembered for that supplier and applied to the next list. Supplier-owned fields update; your own pour sizes and prices stay. Every product the list touched re-costs everything downstream, and a report can tell you which menu lines just lost margin.

Hotel exports have their own habits. One POS product-mix report I work with arrives with thousands of merged cells and a revenue-centre column per outlet. That is a spreadsheet-tidying problem, not an integration problem, and it is solved once.

Sales come back the other way

A till report gives you what sold: by PLU, by name, by outlet, sometimes by daypart. Matched back to the costed menu — first by till code, then by product code, then by name and size — it becomes the sales mix that menu engineering runs on, and a venue-wide product-mix report lands one period per menu that sold, scoped to the outlet it sold in.

Unmatched lines are reported with their revenue, so a $6,000 line called “MISC BEV” is not something you can ignore. Once a line has been matched by hand, the alias is remembered so it matches itself next month.

The monthly health check

None of this is a one-off. The check I run monthly on a resort’s outlets is short:

Has every product the supplier lists been priced this month, and did any price move by more than a few percent?
Does every button on the till map to a product and a format?
Do the sales report’s unmatched lines add up to less than a rounding error?
Does the theoretical GP from the costing sit within a few points of the actual GP from the stocktake?

Where the answers are no, the gap has a name and a dollar figure, and the fix is specific: a product missing a code, a button never mapped, a batch being made short.

Nothing to install

I say this plainly because hotel IT will ask: I do not integrate with the POS or the purchasing system, and I do not claim to. Deluge works alongside whatever the venue already runs by importing what those systems already export — price lists and till reports, as spreadsheets. There is nothing to install, nothing to replace, and nothing that breaks when the hotel changes POS. Since the tools that became Deluge went in at the resort I run, cost of goods is down 3% and beverage cost is held at 24% across the outlets.