Skip to content
Exodus Consulting Exodus Consulting
Book a free audit

Industries / Restaurants and bars

The money leaks between what you bought and what you sold.

A restaurant knows its sales to the penny and its costs to the month. The gap between the two is where the margin goes: the pour that ran heavy, the case that died in the walk-in, the invoice that crept up a dollar a kilo. We build software that puts purchased and sold on the same screen, on the POS you already run, so the owner sees the leak while it is still this week's problem.

Who this is for

How it actually runs

Before anything is built, this is the week we are describing.

No software can be scoped from a category name. These are the specifics of restaurants and bars that decide what is worth building and what is not.

  1. 01

    The week is run from the manager's phone.

    Orders go in by text to the sales rep. The schedule lives in one app, reservations in another, and the numbers arrive as an email from the accountant two weeks after the fact. The owner knows Friday was good because the till was full, not because any one screen said so. The person holding it all together is also expediting on Saturday night.

  2. 02

    Inventory is counted on Sunday, on a clipboard.

    Somebody walks the walk-in and the back bar with a sheet, eyeballs the tenths on each bottle, and types the result into a spreadsheet on Monday. The count is a week old by the time anyone reads it. Food cost comes back as one percentage for the whole month, so a case of striploin that vanished in week two looks the same as a slow week.

  3. 03

    The busiest night is the night the system breaks.

    Saturday at 8pm the kitchen runs out of halibut, but the server on table 12 has already sold two and the online menu still shows it. The printer jams, the delivery tablet is on a different network, and the phone rings for a party of ten nobody can seat. Every workaround gets invented live and forgotten by Tuesday.

  4. 04

    Ordering is done by feel.

    The chef looks at the shelf, remembers roughly what a long weekend does, and orders. Overshoot and the product dies in the walk-in. Undershoot and a dish comes off the menu at 7pm. Neither shows up as a line anywhere, so the same call gets made the same way next week. Par levels exist on paper from three menus ago.

  5. 05

    The pour is the most expensive thing nobody measures.

    A bartender free-pouring a quarter ounce heavy is spending the owner's money on every drink, all night. Comps and buybacks go through as voids, or do not go through at all. At month end the liquor cost is high and there is no way to say which bar, which shift or which bottle did it. So it gets absorbed and the price goes up.

  6. 06

    The guest data is everywhere except in your hands.

    The reservation platform knows the name. The POS knows the tab. The delivery apps know the address and keep it. The email list was built from a fishbowl of business cards in 2019. The owner can name the regulars by face and cannot pull a list of anyone who spent over 200 dollars and has not been back in sixty days.

Where it leaks

Every one of these is measurable. Most are not measured.

The free audit prices these in your own numbers before anything is scoped. You keep the map whether or not you hire us.

Where the money and the hours go in restaurants and bars, how it is measured today, and what closes it.
The leak How it is measured today What closes it
Liquor poured and never rung in: overpours, buybacks, unrecorded comps Monthly liquor cost percentage, one number for the whole building Recipe-based variance per bar and per shift, dollarised, reviewed by a manager
Food that dies in the walk-in because the order was a guess Waste sheet nobody fills in, and a food cost percentage at month end Reorder points off real consumption and bookings, with a drafted PO the chef edits
Phone calls unanswered during service and tables sitting empty after a no-show Not measured; the missed call log on the host stand phone if anyone looks A voice agent that books within the rules and a confirmation flow the host controls
Supplier unit prices creeping up a few cents a week across hundreds of lines Noticed once a quarter when the accountant asks why cost of goods rose Line-level invoice parsing that flags price drift and short deliveries as they land
Manager hours spent counting, retyping and building the weekly numbers Not measured; it is Sunday night and Monday morning, every week Counts on a phone against one catalogue, and a report that assembles itself from the POS and the counts

What we build

8 builds that pay for themselves here.

Each one states what it reads, what it does, and what a person still approves. Scope is agreed after the audit, one build at a time, against a baseline you sign.

Poured against sold, per bar, per shift

Every menu item carries a recipe in inventory units: one ounce of vodka plus a measured pour of soda. The system reads POS sales per terminal and multiplies by the recipe to get theoretical usage. Actual usage comes from the count, by scale where the bar wants speed. Theoretical minus actual is the variance, in ounces and dollars. A manager reviews every flag before it is raised with anyone.

Measured by: Dollarised liquor variance per week, by bar

One catalogue, every site, one count

A multi-venue group gets one product catalogue with one name per item, so the same gin is not three products across three rooms. Each site counts its own stock on a phone against that catalogue. Purchased and sold sit side by side per site and per product, so a variance points at a room, not at the group. The operator decides what counts as a real discrepancy.

Measured by: Minutes per site count, and variance by site

Reorder points that draft the order

The system reads consumption from sales and counts, adjusts for day of week and the bookings already on the reservation platform, and fires a reorder point when stock will not last to the next delivery. It drafts a purchase order per supplier at par. The chef or bar manager edits and approves before anything is sent. The draft learns from what they change.

Measured by: Items run out per week, and dead stock written off per month

Live menu with auto-86

The menu is edited once and pushed to the POS, the printed menu file and the website. When the count of a recipe ingredient hits zero the item is marked unavailable on every surface at the same moment, so a server cannot sell what the kitchen no longer has. Bringing it back is a one-tap manager action, never automatic.

Measured by: Items sold after the kitchen ran out, per week

A voice agent that answers the phone

During service nobody can pick up. The agent answers, reads live availability and hours, books a table within the rules the owner set, and takes a large party or private dining enquiry with date, size and budget. Anything outside the rules is transferred to a person with the caller's details already on screen. It never takes a card number and never overrides the host.

Measured by: Calls answered during service that turned into a booking

A chatbot for the questions you answer daily

Hours, parking, menu, allergens, whether the patio is dog friendly, group booking policy. The bot reads the live menu record and the reservation rules, so its allergen answer is the kitchen's current answer. When a question needs a person, it opens an email with the conversation summarised. Staff answer the questions that need judgement and stop retyping the address.

Measured by: Repetitive emails and DMs handled by staff per week

Supplier invoices read and matched

Delivery invoices arrive as PDFs, emails and photos of a crumpled sheet. The system parses each line, matches it to the purchase order and the receiving count, and flags a unit price that moved or a case that was billed but not delivered. Each match carries a confidence score. A draft bill goes to accounting; the bookkeeper approves it before it posts.

Measured by: Unit price increases and short deliveries caught per month

Loyalty and campaigns off real spend

POS tabs, reservations and consented contacts are joined into one guest profile with visit count, lifetime spend and last visit. Segments build themselves: lapsed sixty days, big spender, birthday this month. The operator describes the offer and the system drafts the email or SMS to that segment. The owner approves every send. Consent and unsubscribe are enforced under CASL before anything goes out.

Measured by: Return visits from the lapsed segment within thirty days

The numbers

Borrowed statistics, with their sources and their limits printed.

None of these are our results. They are the published state of restaurants and bars, linked so you can check them, with the caveat attached where the number is a survey, a forecast or a vendor's own figure.

$101.4 billion, drinking places down 2.3%

Canadian restaurants and bars sold this much in 2025, and drinking places were the only segment to shrink

Statistics Canada, 2026

National figure for all food services and drinking places, released February 25, 2026. Sales, not profit.

44%

Share of Canadian restaurants operating at a loss or just breaking even in November 2025

Restaurants Canada, 2026

Industry association member survey, self-reported by operators. Up from 41% in June 2025, against 12% in 2019. The release does not split the 44% between operating at a loss and breaking even.

69%

Canadian restaurants that expected to increase their technology spend in the coming year

Toast, 2025

Vendor survey by a POS company that sells the technology in question. Sample size not stated on the page. The same survey found 85% of Canadian restaurants called inflation a challenge in 2025.

7.35 million tonnes, worth $17.73 billion

Avoidable food waste in Canada from production through retail and hospitality, per year

Second Harvest and Value Chain Management International, 2024

Whole supply chain figure, not restaurants alone. Charity research using industry data and estimates. The report puts it at about 12% of the $147.44 billion Canadians spent on food and drink at retail.

Where the data comes from

Your systems of record stay exactly where they are.

We read them, we do not replace them. Each one below says what we connect to, how, and the line the build does not cross.

Point of sale

Usually: Square for Restaurants, Toast, Lightspeed Restaurant, TouchBistro, Clover

What it holds. Items, modifiers, prices and tax codes; every tab with its tender, tip, void and discount; which terminal and which employee rang it, and when.

How we connect. API, two-way where the platform allows it. Fennec already syncs both ways with Square, Toast and Lightspeed: menus and prices push out, closed tabs pull back in. Where an API is thin we take a scheduled export. Each field gets one owner, written down before a credential is exchanged.

Where it stops. Nothing is deleted or repriced on a terminal without the owner signing off on the mapping first. Voids, comps and refunds are read for the variance report; the system never issues one.

Reservations and waitlist

Usually: OpenTable, Resy, Tock, Libro, Yelp Guest Manager

What it holds. Bookings, party size, time, guest notes, no-show and cancellation history, deposits where taken.

How we connect. API or webhook where offered, otherwise a nightly export. Bookings are read into the guest profile alongside the tab, so a name on the book and a spend at the table become one record. Availability is read so a voice agent or chatbot can answer honestly.

Where it stops. No booking is cancelled, moved or charged a no-show fee by the system. The host confirms placement, and a fee under Quebec's rules or any deposit policy is a person's decision every time.

Scheduling, payroll and tips

Usually: 7shifts, Push Operations, Homebase, Wagepoint, Payworks, ADP

What it holds. Shifts, clock-ins, wage rates, tip pools and declared gratuities, labour cost per hour.

How we connect. Read-only API or scheduled export. Sales per hour per employee from the POS are joined to the schedule, so labour as a share of sales is visible by shift rather than by month. Tip-out rules the owner sets are applied the same way every close.

Where it stops. The system never publishes a schedule, changes a wage or moves money. A tip split is calculated and shown; a manager approves it before payout.

Accounting and supplier invoices

Usually: QuickBooks Online, Sage 50, Xero, Dext, Plooto, Sysco and Gordon Food Service ordering portals, BC Liquor Distribution Branch wholesale

What it holds. Bills, payments, the general ledger, supplier price lists, delivery invoices as PDFs, emails and photos.

How we connect. Invoices are parsed from email and photo, matched to the purchase order and the receiving count, and posted to accounting as draft bills through the API. Unit prices per item are tracked so a quiet increase on a case of oil shows up the week it happens.

Where it stops. Nothing is paid and nothing is posted as final. A draft bill carries a confidence score, and the bookkeeper approves or corrects it before it touches the books.

Built around your rules

The regimes that govern this work, and how the build answers each one.

Constraints come first, because they decide the architecture. Bring us your hosting, residency and regulatory rules at the start and we design to them rather than around them.

Regulatory and professional obligations that shape a build in restaurants and bars.
Regime What it demands here How the build complies
PIPEDA and BC PIPA (Alberta PIPA, Quebec Law 25 where you operate there) Guest names, phone numbers, emails, birthdays and spend history are personal information. Collect only what the purpose needs, tell guests what it is for, protect it, and hand it over or delete it when they ask. Quebec adds a privacy officer, a published policy and breach logging. One guest profile with a recorded purpose and source per field. Employee access by role, so a server sees a table and not a lifetime spend. Hosting in Canada when the owner wants it. Deletion on request wipes the profile and every campaign list built from it.
CASL (Canada's Anti-Spam Legislation) Every marketing email or SMS needs express consent, or implied consent from an existing business relationship that expires two years after the last purchase. Each message must identify the sender and carry an unsubscribe that works within ten business days. Consent type, date and source are stored on the guest profile. Implied consent segments age out automatically. No campaign sends to a contact without a consent record, every message carries the venue's identity and a one-click unsubscribe, and opt-outs are honoured the same day.
PCI DSS Card data taken at the terminal, online or over the phone must be handled inside a compliant environment. Storing full card numbers outside the payment processor puts the venue on the hook for the breach. We never touch card numbers. Payments stay inside Square, Toast, Lightspeed or the processor. Our systems read tender type, amount and tip, and the voice agent is built so it cannot accept or record a card number, only transfer to a person or a hosted payment link.
BC Liquor and Cannabis Regulation Branch, Food Primary and Liquor Primary licence terms Keep liquor purchase records, a register of liquor purchased and received, liquor sales records with quantity and price, disposal records, food sales and employee records for at least six years. Licensees, managers, servers and anyone left in charge hold Serving It Right, with the certificate number and expiry on file. Every purchase, count, transfer and sale is a timestamped record retained for six years and exportable for an inspector. Staff records carry the Serving It Right number and expiry, and the schedule flags a shift with nobody certified in charge.
BC Food Premises Regulation, enforced by the regional health authority A permit to operate, FOODSAFE for the operator and for at least one employee on shift when the operator is out, a written food safety plan with critical limits, a sanitation plan, and potentially hazardous food held at 4 degrees or below or 60 degrees or above. FOODSAFE certificates and expiry dates sit on the staff record beside Serving It Right. Temperature and receiving checks can be logged on the same phone as the count so the food safety plan has evidence. The system prompts; a person takes the temperature and signs.
Quebec Consumer Protection Act, no-show fee rules (July 2025) A Quebec restaurant may charge up to $10 per person for a full no-show on a booking of two or more, only if the fee was disclosed before booking, a confirmation with a cancellation link went out between 6 and 48 hours before, and guests could cancel at any time up to three hours ahead. For Quebec venues the confirmation flow sends in the window, keeps the cancellation link live, and records disclosure at booking. The system reports which no-shows qualify. Charging the fee is a manager's decision, made per booking, never automatic.

What we will not automate

  • We will not void, comp or refund a tab automatically. The system reads voids for the variance report; a manager with a key still approves each one, because a void is where theft hides.
  • We will not send a supplier order or pay an invoice without a person. Draft POs and draft bills are the system's job. The chef and the bookkeeper sign.
  • We will not charge a no-show fee, cancel a booking or move a table on the system's own judgement. The host owns the book, and a guest dispute is a person's conversation.

A person stays in the loop

Anything that spends money, sends something irreversible, or carries a professional obligation arrives as a draft with a named reviewer. The system prepares the work. A person decides whether it ships.

You own the code and the data at the end of the engagement.

The product, running

Three screens from the inventory and guest work, running.

These come from Fennec, the venue operating system we built. The same mechanics sit under the B-Side Group inventory build, which is still in progress and has no figures to show yet.

FIG. 01 Product gallery, 3 live surfaces

Scroll or select a surface

Weight-based variance panel with columns for product, type, remaining millilitres, poured, expected and variance.
The variance report compares what the POS says was poured against what is actually left, and prices the difference.

Purchased against sold, per product

Recipes turn POS sales into a theoretical pour, and the close-of-night count gives the actual. The difference is the variance, priced. It points at a bar, a shift and a product rather than arriving as one food cost percentage at month end.

Live product capture

Guest database screen with summary tiles and a table of guests showing tiers, visits and lifetime spend.
Guest records with tier, visit count, lifetime spend and last visit, built from closed tabs rather than a sign-up sheet.

Regulars, in a list rather than in your head

Visit count, lifetime spend and last visit on every guest, built from the tabs the POS already closed. That is what a lapsed-sixty-days segment needs to exist, and it is the difference between a mailing list and knowing who to call.

Live product capture

Flow builder canvas showing a node palette and a wired automation from trigger through to a personalised send.
A guest flow on the builder canvas: trigger, wait, condition, then a drafted send that a person approves.

A campaign you can audit

The trigger, the wait, the condition and the send, laid out where a manager can read them. Consent is checked before anything is composed, and the owner approves the send. No message goes out because a system decided it should.

Live product capture

Our work here

What we have built in this industry, at its real status.

Live means running now. In build means under construction, with some phases delivered and some not. Shipped means delivered and closed. Where there is no number yet, we say so instead of borrowing one.

B-Side Group: inventory across three restaurant venues, in build

A hospitality group brought us in to build customised inventory management across three of their restaurants. The shape of the build: stock counts done per site on a shared catalogue so the same product has one name in every room, purchased set against sold as variance per site, and reorder points that fire from real consumption. It is under construction, so no count is running in our software yet and no variance figure exists. When there is one, it will appear with its arithmetic beside it.

Fennec: recipe-based inventory and two-way POS sync, live

Fennec, the venue operating system we co-founded, runs live at Harbour Event Centre, TradeX, The Pit UBC and The Show Ottawa. It syncs both ways with Square, Toast and Lightspeed, matching tabs to tables. At Harbour every menu item carries a recipe, every terminal maps to the employee working it, and open bottles are weighed at close over a Bluetooth scale. Sales times recipes is theoretical usage; the weigh-in is actual; the gap is the Revenue Loss Calculator's dollarised variance, per bartender. The live menu pushes one edit to print, digital and POS and auto-86es when stock runs out.

Palapa Tours Ottawa: tip-out software, shipped

A floating tiki-bar cruise operator with a different crew every sailing. Gratuity splits shifted cruise to cruise and the crew argued about pay. We built software that totals the pool when the cruise closes, applies the split rules the operator set once by role, and records every payout per staff member. The variance went away, so the disputes had nothing left to be about. Shipped, closed, and owned by the client. No dollar figure is claimed because none was given.


What the work taught us

  1. 01

    A variance report is only as honest as the item list under it. Clean the catalogue against what is actually on the terminals first; three names for one gin will produce three wrong numbers.

  2. 02

    Count speed decides whether a count happens. A weigh-in over a Bluetooth scale that takes minutes gets done every week. A clipboard hour gets done when someone remembers.

  3. 03

    Tie the terminal to the person. A liquor cost percentage for the building is a complaint. A dollar variance per bar, per shift, per bartender is a conversation with evidence.

  4. 04

    Decide who owns each field before connecting anything. If both the POS and the inventory system can edit a price, they will disagree on the busiest night of the year.

  5. 05

    The marketplaces own the discovery, the venue must own the guest. Keep selling on the reservation and delivery platforms, but pull every buyer into your own profile with consent, because a room full of strangers has no reason to come back.

The objections

The reasons an owner here says no, answered straight.

Good. We do not replace the till. Fennec already syncs both ways with Square, Toast and Lightspeed, and that is the pattern we build on: menus push out, closed tabs pull in, and each field gets one owner in writing before anything connects. The staff keep the terminal they know.

The count probably is fine. The problem is what happens to it: it lands in a spreadsheet a week later as one food cost percentage. Purchased against sold per product, per week, is a different number and it points at a shelf. The chef keeps counting. The count just goes somewhere useful.

Nearly half of Canadian restaurants were at a loss or breaking even at the end of 2025, and the leaks are usually in liquor variance and dead stock. We start with a free audit that prices the leak in your own numbers. If the arithmetic does not clear, we tell you and you keep the map.

Staff use things that are faster than the alternative. A count on a phone against a catalogue with the right names beats a clipboard. A menu that goes off everywhere when the kitchen runs out beats a server getting yelled at on table 12. We build for the person on shift, not for a dashboard the owner reads.

Most die because the item list under them was wrong: three names for one gin, recipes nobody kept up, a POS that never mapped. The first real day of our work is cleaning that catalogue against what is actually on the terminals. The count is the easy part once the names agree.

Questions

The questions we get asked in restaurants and bars.

No. You choose the cadence per bar. A weekly count with a scale and a Bluetooth connection takes minutes, and a nightly count on the high-value shelf is a few more. The variance is calculated against whatever period you count. Nightly gives you a per-shift answer; weekly gives you a per-week one. Most rooms start weekly and tighten where the number tells them to.

It tells you where the ounces went: which bar, which shift, which product, and where terminals map to employees, which person's sales. That is a conversation starter with evidence, not a verdict. Heavy pours, unrecorded comps and a bad recipe all look like variance until a manager looks. The system flags; the manager decides what it means.

Only if you have told it that it can. Large parties, private dining and anything outside the rules you set are transferred to a person with the caller's name, number, date and size already captured, so the conversation starts halfway through. Routine bookings within your rules it takes itself. It never takes a card number.

It is the normal case. Each site keeps its own terminals and its own count, but the catalogue is shared: one name per product, one recipe per menu item. The sync maps each site's terminal items to that catalogue. Variance is then comparable across rooms, and a reorder point can see stock at the venue next door before it drafts an order.

You do, both. The guest profiles, consent records and spend history sit in your database, hosted in Canada if you want it there. The code is written into the agreement as yours before anything is built. We agree the baseline number in writing first, the clock starts at deployment, and if the system misses the bar we keep working at no extra cost until it clears.

What happens next

Start with the audit, and know the number before you commit.

Three to five days. We map where the hours and the money go in your restaurants and bars operation and hand you a ranked plan with the payback attached.

We map where time and money leak, and show the arithmetic before you commit to anything. You keep the map whether or not you hire us. If we do build, we agree the baseline in writing first, the clock starts at deployment rather than signature, and you own the code.

Who you talk to
Shiv and Vishal. No account managers, no slide decks.
Direct
shiv@exdsconsulting.com
Read next
What we build, then Our work.