Cashier

The cashier workspace is where money becomes true. A payment is not settled because a guest says they paid — it is settled because a cashier confirmed it. That decision is yours, and it is recorded.

The tabs

Seven. The tab bar puts them in this order for a reason: the one you act on comes first, then the two about money that is recorded but not finished with, then the review queues. This page explains them in a slightly different order, starting with the queue most people meet first.

Tab	What it holds
Take payment	Collecting a payment at a station, and settling whole tables
Unmatched money	Money a provider says arrived that matches no record here
Fiscal receipts	Money recorded whose fiscal receipt has not been issued
Pending payments	Payment claims waiting for your decision
Recent decisions	Decisions already made
Payment issues	Mismatches, missing proof, and blocked cases
Archive	The record over a date range

Payments waiting for a decision.

Taking a payment at a station.

Pending payments — the decision queue

Each entry shows what you need in order to decide: the customer, the method, the order type, when it was submitted, and how long it has been waiting.

For a transfer, it shows proof — files or a note the guest attached. Open it and look before deciding.

Two outcomes:

Confirm. The money is real. The order is marked paid and can move on.

Reject. It is not. You give a reason, and the guest sees it. The order stays blocked until the payment is resolved.

The order is waiting on you

An unpaid order is blocked from being prepared. A pending queue that nobody works is a kitchen that has not started. Oldest wait on the queue shows the worst case — keep an eye on it during service.

Filters cover order type (dine in, takeout, delivery), payment method (cash, card, transfer, wallet, online, other), and sort (queue order or oldest first). My decisions shows just yours.

Take payment — collecting a payment

The Take payment tab is for collecting payment at a physical station.

Binding a station

Before collecting, you bind to a station. The station list shows each one’s state:

State	Meaning
Available	Free — you can bind
Yours	You hold it
Held by another cashier	Someone else has it
Stale — claimable	Held, but idle long enough that you may take it
Not active	Out of service

Binding prevents two cashiers driving the same terminal at the same time. If your hold lapses, the app tells you “Your station lease is no longer live” — bind again before collecting. Release it when you step away.

Collecting

Pick the unpaid order, then the route. There are four, and the station offers only the ones it can actually complete right now:

• Cash — you took cash
• Terminal (attested) — the card terminal completed and you are attesting it
• QR (guest pays online) — the guest pays through a provider from a code
• Smart POS (payment app) — handed off to a payment app on the device

You never type the amount. It comes from the order, on every route.

A payment in progress moves through states you can watch: Open, Presented, Processing, Collected — or Declined, Expired, Cancelled.

Why the app asks you to attest a terminal payment

A card terminal can tell Sitora that something happened, but a device is not allowed to declare that the restaurant received money. A person confirms that. This is the same principle as transfer proof: money becomes true when a responsible human says so, and the record shows who.

Settling a table’s tab

Where the branch runs tabs, a table’s whole visit is settled in one act rather than order by order. Take payment has a Tables lane for exactly this: the tables that still owe, each showing its spot, its session number, how many orders are on it, how long it has been open, and whether the guest has already left. You can search it by table or session number, so you find the table without needing a view of the floor.

Each table carries two entrances.

Settle the tab walks every outstanding order on that visit through the ordinary payment path — cash, terminal or Smart POS, the attested routes only. Nothing new happens to the money; it is the same collection you would do for a single order, repeated.

A part-settled tab is a real thing, and the app says so

Settling a tab is deliberately not all-or-nothing, and the sheet warns you before you hold: “This settles [n] orders one by one. If one refuses, the rest still settle and you will see exactly which.” Money that has been taken has been taken, so the app will never un-record a settled order because a later one failed.

Write the tab off is the other entrance, and it is on the same row. It records that the money will never be collected, under your name. You pick a reason — guest left without paying, waived by a manager, a service failure, or other, which then requires you to say what happened.

A write-off is not a settlement, and the app is loud about it

The sheet says it plainly: “No money moves. The orders stay unpaid — the loss is recorded, not hidden — and the branch owner sees the amount.” Clearing a table and forgiving a bill are different acts, and this one carries your name to the owner.

It is a separate permission. If you hold it but have no live station lease, you can still write a tab off — the app tells you so: “Settling needs a live station lease and payment access. You can still write this tab off.”

Unmatched money

A payment provider sometimes reports money that matches nothing in Sitora. Those events land here rather than being quietly dropped, with the provider, the method, the provider’s own transaction reference, when it arrived, and the amount.

Two outcomes, both needing a reason:

Confirm from evidence. You type the order number the money belongs to. The sheet is blunt about what that means: “This records real money against the order. Confirm only what the provider evidence proves.”

Dismiss. The event closes without recording money, and the provider record stays for audit.

If your role does not let you resolve these, you can still read them: “You can view this event, but resolving it isn’t available for your role.”

Payment issues

The issues queue.

Cases that need attention rather than a straight yes or no:

• Mismatch — the amount does not match the order
• Already paid — a second claim against a paid order
• Cancelled — a payment against an order that no longer exists
• Blocked — something is preventing a decision

High-priority issues are marked. Work these before the ordinary queue: they are usually a guest standing at the till.

Fiscal receipts

Where fiscal receipts are required, this tab lists money already recorded whose receipt has not been issued. The money is never at stake here — every screen in this tab says so in its own words, because a receipt that is late is a paper problem, not a takings problem.

A strip at the top names the branch register’s state: Not set up, Activation pending, Issuing, Behind, Paused or Operator paused. Each one explains itself — “Nothing is issued while the register is paused. Receipts keep queueing until it resumes.”

Below it, each queued receipt shows its order, amount, whether it is a Sale receipt or a Refund receipt, and where it has got to: Queued, Sent, Issued or Not issued. Counters call out how many are Overdue and how many Need action.

You can push a stuck one. Open it and use Send the receipt again, with a reason. That is the one action in this tab.

If the queue keeps growing, the register itself is the problem — raise it with your branch admin.

Archive

Everything decided, filterable by Today, 7 days, 30 days or 90 days, and searchable by transaction, order, customer or note.

Use it to answer “what happened with that payment yesterday”. You cannot change anything from here — history is a record.

Day-to-day recipes

A guest says they transferred but the queue is empty. Check the branch. Then check whether they attached proof — a claim with nothing attached may be sitting under Issues.

The amount does not match the order. Do not confirm it. It belongs in Issues as a mismatch. Confirming a wrong amount makes the restaurant’s records wrong and is not something you can undo.

I rejected a payment by accident. You cannot un-reject it. The guest submits again and you confirm the new one. Nothing is edited — the record shows both, which is the point.

The station says it is held by someone else. It is. Find them, or wait for it to go stale and become claimable.

I am offline. You cannot record decisions. Reconnect first. Deciding against a stale picture is how the same payment gets confirmed twice.

Cash arrived from a courier delivery. Confirm it here like any other cash payment. The order stays unsettled until you do, and the courier’s record shows outstanding cash until then — so do it the same day.

What a cashier cannot do

• Change an order’s items or total. Payment is decided against the order as submitted.
• Un-decide. Corrections are new records, not edits.
• Refund from the app. There is no refund verb anywhere in Sitora Pro. Refunds are handled with the restaurant and, where a provider was involved, through that provider. Writing a tab off is not a refund — it forgives money never collected, rather than returning money already taken.
• Mark an order paid without a payment. There is one route to paid, and it runs through a confirmed payment.

Next

• Waiter · Branch admin
• Troubleshooting