MyFacitMost cafe owners open the POS export once a week, glance at the total takings figure, and close the tab. That number tells you money came in. It does not tell you whether you kept any of it.
A point-of-sale export is a record of sales. On its own it can tell you a lot about how customers spend money in your cafe: which days are busy, what the average transaction looks like, whether trade is trending up or down. What it cannot tell you, by itself, is whether the business made a profit that week. For that you need to put wages and supplier costs next to the same numbers, for the same period.
This post covers how to read your cafe POS report the way that's actually useful: what a typical export contains, what each part is genuinely good for, where the data runs out (this section is worth reading twice), and what changes once you line it up against your wage costs and your invoices.
What's Actually in a Typical POS Export
Most exports, whatever system produced them, contain some version of the same fields: a transaction date and time, a total amount, a payment method, and sometimes a staff member or till identifier. Some systems also attach item-level detail to each transaction. Many do not, or only do so in a separate report that aggregates sales by product over a month rather than by transaction over a day.
Here is roughly what each column is useful for, and where it stops being useful:
| Column | What it tells you | What it can't tell you on its own |
|---|---|---|
| Date and time | When trade happened, and how it's distributed across the week | Why it happened (weather, an event, a public holiday) unless you note that separately |
| Amount | Total dollar value of the sale | Whether that sale was profitable |
| Payment type | Cash versus card mix, useful for reconciliation | Anything about cost or margin |
| Staff or till ID | Which register or shift a sale ran through | Whether that shift was adequately staffed for the volume |
| Item detail (when present) | What sold, if attached per transaction | Often unavailable at all; frequently only exists as a monthly aggregate |
Three Questions POS Data Can Answer on Its Own
Used correctly, POS data alone genuinely answers a handful of useful questions:
- Is revenue trending up or down? Compare weekly or monthly totals over a run of months and the direction is usually clear, seasonality aside.
- What does trading actually look like across the week? If your export includes timestamps, you can see which days and which hours carry the bulk of trade. This is the number that should drive your rostering, not a gut feeling about "Saturdays are always busy."
- What's the average transaction value doing? Total revenue divided by transaction count, tracked over time, shows whether customers are spending more or less per visit, independent of how many customers you're getting.
All three of these come from the date, time and amount fields alone. No item detail required.
The Honest Limit: What POS Data Cannot Tell You
This is the part most owners find out the hard way. Many POS exports give you a transaction date and an amount, and nothing else about what was actually bought. Item-level detail, when it exists at all, often only arrives as a separate report that aggregates sales by product across an entire month, not by transaction or by day.
If your POS export has a date and a dollar amount next to each other but no item name, that's not a gap in the report you're missing. That's the level of detail the system was built to give you.
The practical consequence: a question like "did our flat whites outsell our lattes on Tuesday" is frequently unanswerable from POS data, no matter how carefully you dig through the export. The daily, per-item detail simply doesn't exist in most systems' transaction-level output. Trying to reconstruct it by hand from a monthly total is a way to lose an afternoon for no reliable answer.
The other thing POS data cannot do, no matter how granular it gets, is tell you whether a sale was profitable. Revenue is only half the equation. Without wages and cost of goods sitting next to it, a busy Saturday and a quiet Tuesday look identical on the profit line, because the export was never built to show cost.
Working Around the Gap: Two Jobs, Two Data Sets
The fix isn't a better export. It's using each data set for the job it's actually suited to.
- Monthly product aggregates are the right tool for menu decisions: which items to keep, drop, or reprice. Review these monthly, because that's the resolution they arrive at. Trying to make a menu call from one busy day's takings, without item detail, is guessing.
- Daily transaction data (date, time, amount) is the right tool for revenue, labour and trading-pattern decisions. This is where you can genuinely see, day by day, whether the roster matches the trade.
As an illustrative example, not a claim about any real cafe: if a week's transaction data shows Thursday and Friday each running 40% above the weekly daily average, and the roster has the same headcount on Tuesday as it does on Friday, that's a mismatch you can see and fix from POS data alone, no item detail required.
Layering Wages Onto the Same Week
Once you put a week's wage cost next to that same week's revenue, a different picture opens up. Take a simple illustrative example: a week brings in $18,000 in sales, and the wage bill for that week is $5,400. That's a 30% labour cost for the week, a figure worth tracking over time rather than judging in isolation on any single week.
The useful part isn't the single number. It's watching that percentage move week to week against the trading pattern you already found in the POS data. If labour cost climbs on the same days that transaction volume is lowest, that's a rostering fix, not a revenue problem.
Layering Supplier Invoices Onto the Same Period
Supplier invoices, dated and totalled for the same week or month as the POS export, add the other half of the cost picture: cost of goods. Put revenue, wages and invoice totals on the same time axis and you get something a POS export alone never shows: an actual profit figure for the period, not just a sales figure.
This is also where the earlier point about item-level detail matters again. Cost of goods from invoices tells you what you spent on ingredients across the period; it doesn't map cleanly to individual menu items unless you've built recipe costings separately. That's a different, slower project. For a weekly read on whether the business is trading profitably, revenue minus wages minus invoice cost, for the same window, is the number that matters.
One Screen Instead of Three Spreadsheets
The practical setup that works: one view, refreshed weekly, that pulls the same date range from your POS export, your wage cost and your supplier invoices, rather than three spreadsheets kept by three different processes that quietly drift out of sync with each other. When the three numbers sit next to each other for the same week, the question POS data can't answer on its own, whether you're actually keeping any of this money, gets answered without extra manual work.
If you're doing this by hand today, the MyFacit dashboard is built to line those three data sets up automatically instead of you reconciling three separate exports each week. For a quick, no-signup read on where a single week stands, the cafe profitability snapshot tool is a good first look, and pricing has the detail if you want the ongoing weekly view.