Cirrus — keep your till, gain the intelligence

If your venue runs on Cirrus, you don’t have to give it up to get the intelligence side of BiteTheMenu. You export your sales from Cirrus the same way you do today, drop the file onto your venue’s External POS sync page, and every sold dish gets matched against the menu you already built here. From that moment on, your forecasting, your popularity ranking, your deadstock alerts, your competitor pricing comparisons — every analytics surface — starts drawing on the real numbers from your till, not a guess.

What it does

The integration solves the problem almost every venue we meet has when they consider BiteTheMenu: “I can’t switch my till. I’ve trained ten people on Cirrus, my receipt printer talks to it, my card terminal talks to it, my accountant has six years of reports in its format. I just want what your app does, on top of what I have.” That’s exactly what this is.

The Cirrus exporter you already use (Details Sales By Date) gives you an XLSX file with every sale, broken down per item, per day, per shift. You upload that file to BiteTheMenu. The system reads each row, finds the dish on your menu that corresponds to the Cirrus item, and attaches the sale to it — without creating a duplicate. The next time you open the menu in the admin or in the data dashboard, every dish carries its real sales velocity (1,108 plates over six months, 8.2 per service on average, peaks Friday lunch) and that number powers every analytics surface downstream.

The V1 milestone is six months of history. That’s enough to make the data dashboard, the forecasting, and the popularity ranking all useful from day one without burdening you with multi-year imports up front. You can always upload more history later — Migration mode keeps the door open — but six months of clean daily data is the sweet spot for getting started.

The integration runs in one of two modes, picked when you set the connector up. In Source mode, Cirrus stays the system of record for sales — you keep ringing through Cirrus, you keep its reports for your accountant, and once a week you upload the file so BiteTheMenu’s intelligence stays current. In Migration mode, the upload is a one-time bulk import of your historical Cirrus data, and from then on BiteTheMenu takes over as the till. Same file format either way; the mode just tells the system whether to expect more uploads later.

The rule

Your menu is the truth. Cirrus brings the sales numbers. The integration’s only job is to attach the right number to the right dish — never to invent a dish that isn’t on your menu. And the most recent upload always wins: if you spot a mistake, re-export from Cirrus and upload again, and the new numbers replace the old.

One connector per location

If your business has multiple venues — say, an osteria at Hansar and another at Sukhumvit 31 — each one is its own venue inside BiteTheMenu, with its own menu, its own staff, and its own External POS sync connector. You don’t mix locations on one upload. You stand in Sukhumvit 31 in the admin, export the Cirrus report for Sukhumvit 31 only, and upload it to the Cirrus connector inside that venue. Then you switch to Hansar, export Hansar’s report, and upload it to that venue’s connector. The numbers stay cleanly separated, and the data dashboard for each venue shows only its own performance.

How to use it

You’ll be moving between Cirrus (to export) and BiteTheMenu (to upload and review). The first time takes about ten minutes; weekly uploads after that take about one.

Setting up the connector

Open Settings → External POS sync in the admin app. The page shows whichever connectors this venue already has (none, at first) and a button to add one. Click Add connector → Cirrus. Give it a name (most venues use their own location name — “Sukhumvit 31 — primary” — useful for the audit trail later). Pick the mode: Source — keep Cirrus as our till or Migration — Cirrus export is a one-time seed. Save. The connector now appears as a card on the External POS sync page with status Awaiting first upload.

Exporting from Cirrus

In Cirrus, open the report menu and navigate to Daily Sales → Details Sales By Date. Set the date range you want — for weekly uploads, this is the week that just closed; for the first historical seed, set six months back from today. Set Output Format to XLSX (not PDF — the system can only read XLSX). Run the report. When Cirrus delivers the file (by email or in its report queue), download it.

Uploading to BiteTheMenu

Back on the Cirrus connector card, click Upload sales. Drag the XLSX into the drop zone (or browse). The system reads the file in the background and shows a Preview page when it’s done — usually a few seconds for a week of data, up to a minute for six months.

The preview tells you three things, in three numbered groups, plus a banner at the top if anything looks structurally wrong with the file.

The banner — what’s missing. Before the three groups, the system tells you whether every day in the file’s date range has data. If your file covers Monday through Sunday and Tuesday has zero rows — not zero sales, but no rows at all — the banner says “Tuesday 12 May has no rows in this file. Was the venue closed, or is the export incomplete?”. This is the “sum of the day is missing” check: it catches the most common source of broken analytics, where Cirrus’s export quietly dropped a day and your forecasting later goes wonky because you have a phantom zero where the real number should be. You decide whether to acknowledge it (venue was closed — Mondays off) or re-export from Cirrus and upload again.

Auto-matched. Items the system is confident enough to attach silently. These are dishes whose Cirrus name and price both line up with a dish on your menu — PIZZA MARGHERITA at ฿320 in Cirrus, Pizza Margherita at ฿320 on your menu. The number here is usually the biggest of the three.

Needs review. Items the system thinks it knows but wants you to confirm. Usually these are dishes whose Cirrus name is close but not identical (MARGHERITA EXTRA CHEESE vs Pizza Margherita), or whose Cirrus price has drifted from your menu price by more than a small margin. For each one, you see the Cirrus row on the left and the system’s best guess on the right, with a confidence note (“Same name, price differs ฿20”). Click the green check to accept the match, the swap icon to pick a different menu item, or the X to send it to the unmatched tray.

Unmatched. Items the system can’t link to any dish on your current menu. Discontinued dishes from old sales periods, one-off specials that never got added to BiteTheMenu, modifiers Cirrus tracks as separate items — anything without an obvious home. For each row, you have three choices: Match to existing (pick a dish from a dropdown), Create new menu item from this row (the system seeds a draft with the Cirrus name + price), or Dismiss (the row will never be matched on this or any future upload — useful for retired dishes).

When you’re happy with the three groups and you’ve acknowledged any missing-day banner, click Commit upload. The matches save, the velocity stamps update on every linked dish, and within seconds the data dashboard’s Menu page shows the new numbers.

Re-uploading next week — and fixing mistakes

Next week’s upload goes through the same screens, but the system remembers everything you decided on past uploads: a Cirrus dish that matched a menu item last week matches it again automatically this week (using the Cirrus item code, not the name — so even if the menu item is renamed, the link survives). Dishes you dismissed stay dismissed. Only genuinely new rows show up in the review and unmatched groups.

If you spot a mistake — wrong shift selected on the export, missed transactions, a typo someone caught a day late in Cirrus — just re-export the corrected window from Cirrus and upload again. The system uses a date-plus-shift key for every sales row, so the new file’s numbers replace the old file’s numbers for the same days. The latest upload is always assumed to be the truth. You can’t double-count: re-uploading Monday on top of Monday simply overwrites, never adds.

Worked example

Marco runs iO Italian Osteria at Sukhumvit 31. He’s been on Cirrus for four years. Last weekend he finished setting up his BiteTheMenu menu — 240 dishes plus 60 drinks — and now wants the last six months of sales to flow in so his data dashboard isn’t empty on opening night.

He opens Settings → External POS sync, clicks Add connector → Cirrus, names it “Sukhumvit 31 — historical seed”, picks Migration mode (this first upload is the big one), and saves. He exports Details Sales By Date from Cirrus for the last six months — about 10,000 rows. The file lands ten minutes later; he downloads the XLSX and drops it on the upload zone.

The preview comes back twenty seconds later. The banner at the top says: “Your file covers 27 Nov 2025 – 27 May 2026. Two days have no rows: Mon 23 Dec (Christmas closure), Mon 1 Jan (New Year closure). Acknowledge or upload a corrected export?” — Marco acknowledges; both were planned closures.

The three groups show 211 auto-matched, 17 needs review, 34 unmatched. He clicks through the review group first — twelve are pizzas that got renamed from English to Italian when he migrated the menu (PIZZA MARGHERITA in Cirrus vs Margherita on the menu); he accepts those. Four are dishes where the price changed (a ฿380 Carpaccio that’s now ฿420); he accepts and notes that historical sales keep their historical price. One is something he doesn’t recognise; he sends it to the unmatched tray.

In the unmatched tray, he sees 35 rows. Twenty are clearly discontinued dishes from earlier in the year — old daily specials, retired pizzas, a wine that’s no longer poured. He dismisses them in batch. Nine are modifiers Cirrus tracked as separate stock codes (ADD MUSHROOM, EXTRA CHEESE); he dismisses them and makes a note to set those up in the modifiers section later. Six are genuinely new dishes he served but never added to BiteTheMenu; for each, he clicks Create new menu item from this row, and the system seeds a draft he can polish later.

He clicks Commit upload. The system attaches 229 matches, stamps every linked dish with its six-month velocity, and the connector card updates: Active — last upload 9,857 rows, 27 Nov 2025 – 27 May 2026. He opens his menu in the admin app, navigates to Pizza Margherita, and sees a new section near the top: 1,108 plates sold in the last six months, 8.2 per service on average, busiest Friday lunch.

The same numbers feed his forecasting dashboard, his popularity ranking on the menu engineering view, his deadstock alert. The full numbers also start flowing into the data dashboard at data.bitethemenu.com on the next sync run (Cirrus data joins the rest of his sales there a few minutes later). He’s a few clicks away from working analytics on day one.

Two days later, he notices Cirrus had the wrong shift code stamped on Tuesday’s lunch service — the numbers look low for what he remembers selling. He re-exports the same week from Cirrus with the corrected shift, uploads the new file. The preview shows zero unmatched rows (everything already linked), 1,247 rows that will overwrite existing entries. He commits. The data dashboard refreshes within seconds — Tuesday’s numbers now reflect the corrected export.

Menu items — every matched Cirrus row attaches its sales velocity to a menu item; the menu is the truth the integration matches into.
Suppliers and cost — Cirrus brings revenue per dish; pair it with cost per dish to get true margin.
Forecasting — per-day, per-shift Cirrus data feeds the forecasting model directly.
Multi-venue setup — each location’s Cirrus reports go to a separate connector inside that location’s venue, kept separate in the analytics.