Money
Money answers: what came in, in what currency, and what is still unsettled.
Choosing a range
Section titled “Choosing a range”Today, a trailing week, or a custom range with start and end dates
(YYYY-MM-DD). Everything on the screen follows the range you pick.
Start with a week. “Today” early in the service day looks alarming and means nothing.
Revenue
Section titled “Revenue”Confirmed revenue for the range, and revenue by branch.
Two words matter:
Confirmed. This is money a cashier or a payment provider confirmed — not money that was claimed. A guest who says they transferred is not revenue until someone confirmed it. If revenue looks low and your payment queue is long, those are the same fact.
By currency. Different currencies are shown separately and never added together. There is no single number that silently mixes them, because there is no honest one.
Payment health
Section titled “Payment health”How payment is going: what is waiting, what is stuck, what is failing. A rising waiting figure is a staffing signal — orders are blocked until a cashier decides.
Transactions
Section titled “Transactions”The list of transactions in the range, page by page, with Inspect on each.
It is read-only, and the screen says why: corrections happen in Sitora Pro as compensating records. An owner cannot reach into a transaction and change it. If something is wrong, a correction is recorded — the original stays.
That constraint is what makes the list worth anything as evidence.
Owner reports
Section titled “Owner reports”Reports answer specific questions — payment methods, daily summaries, and similar. Open one for its detail.
They are not a general query tool, and deliberately so. Each report exists because owners kept asking that question.
Business analysis
Section titled “Business analysis”Beyond the numbers on screen, Sitora will generate an analysis of your business: a spreadsheet and a document you can keep, send to an accountant, or read on a plane.
You choose a pack — a named set of subjects — a date range, and which branches. Sitora builds it in the background and tells you when it is ready. It is not instant and it is not meant to be; a two-year workbook is real work.
What it can cover
Section titled “What it can cover”Analysis is organised into sections, each one a subject:
| Group | Sections |
|---|---|
| Operations | Trade and demand · Menu mix · Service and incidents · The dining room · Loss and leakage · Delivery economics · Courier reliability · Payments and cash control · Branch comparison · Staff activity |
| Money | Cost and margin · Labour · The bottom line |
Trade and demand, Menu mix, Service and incidents, and Payments and cash control are free on every plan — including a lapsed one. Your own operating record is always yours to read. The rest, along with consolidated multi-branch analysis, ranges longer than a month, and scheduled monthly delivery, come with the plan.
A section that cannot say anything says so
Section titled “A section that cannot say anything says so”Before you generate anything, each section tells you whether it can actually answer — and if not, why, in words. There are three different “no”s and they are not interchangeable:
- No data. Nothing has been recorded that this section reads. Cost and margin needs recipes; labour needs shifts. Nothing is wrong; the answer does not exist yet.
- Not on your plan. It exists and is behind the subscription.
- Out of scope. Usually consolidated multi-branch on a single-branch restaurant, where there is nothing to consolidate.
An empty branch is never sent to a payment screen, and a plan limit is never disguised as missing data.
People are not in it by default
Section titled “People are not in it by default”Analysis names branches and roles, not people. Two sections are about people — Staff activity, Courier reliability — and are simply left out unless you deliberately ask.
Even inside sections that stay, the per-person tables come out: labour cost is a money figure whose detail is a list of names, so the figure stays and the table is replaced by a note saying it was removed. It is not anonymised, because a staff ranking with the names stripped still ranks the same people in the same order.
Asking for a version that does name people is a per-report choice, and the record of who asked outlives the file.
Reports expire; the record does not
Section titled “Reports expire; the record does not”A generated file is kept for 30 days on request, or 13 months for scheduled monthly packs. After that the file is deleted and the record of the run stays — what was asked for, over what range, by whom, and how it turned out. An expired report shows as a row you can regenerate, never as a broken link.
The retention window is printed on the report’s own cover, so a file that has travelled by email still says how long the original was kept.
Fair use
Section titled “Fair use”Six reports an hour, thirty a day, two building at once. These are capacity limits rather than a paywall, and the app says which one you have hit.
Declaring your trading hours
Section titled “Declaring your trading hours”Some figures need to know how long a branch was actually open — occupancy, and revenue per available seat-hour. If you have not told Sitora your week, it infers your hours from when sessions opened and closed, and labels those figures as estimates.
Declaring the week moves them from estimated to derived. It is worth ten minutes per branch.
Trading hours are versioned rather than edited: a change starts a new record from a date, and older analysis keeps being computed against the hours that were actually in force.
Day-to-day recipes
Section titled “Day-to-day recipes”Revenue is lower than I expect. Check the range, then check payment health. Unconfirmed payments are the most common cause, and they are a queue somebody has to work, not a loss.
One branch shows nothing. Either it took nothing in the range, or it is not taking payments through Sitora. Open the branch and check its payments configuration.
I need last month’s numbers. Use a custom range with both dates.
Something in the transaction list looks wrong. Inspect it, then take it to the branch. The correction happens in Sitora Pro, where the cashier records a compensating entry.
I want to compare two branches. Use revenue by branch over the same range. Comparing across different ranges is the easiest way to reach a wrong conclusion.
What you cannot do here
Section titled “What you cannot do here”- Edit a transaction. Read-only, permanently.
- Confirm a payment. That is a cashier’s decision in Sitora Pro.
- Issue a refund. Refunds happen with the branch and, where a provider was involved, through that provider.