Skip to content
User guide

PoS, end to end — the complete guide

How to lay out the floor, take an order, settle a table bill or a bar tab, run the cash drawer and payment terminals — and the Swedish fiscal rules behind every receipt. Plain English, with a real screenshot for every step, on web and mobile.

Updated 19 July 202632 min readSweden edition · EnglishReal product screenshots
About POS & Waiter Waiter & PoS guide Start free trial

Chapter 1

Before you start — how the money moves

PoS is not one screen — it is a small set of screens that each own one job, all reading and writing the same live menu, tables and ledger. This chapter maps them once so the rest of the guide can just say "open Table Bills" without re-explaining what that means.

The shortest version: a waiter takes an order, it settles onto a table bill or a bar tab, the guest pays by card, Swish, cash or gift card, the payment lands in the cash drawer or the payment terminal's ledger, and — for Swedish restaurants — a compliant receipt and fiscal journal entry are produced automatically underneath it all.

The screens, and who normally opens them

Take an order (Dashboard → Take Order) is where a waiter builds a ticket at the table and sends it to the kitchen. Table Billing (Dashboard → Table Billing) is where an unpaid order becomes a bill the guest settles — either the "Table bills" tab (build a bill, guest pays by scanning the table QR) or the "Split a bill" tab (charge an existing order in parts). Bar Tabs (Dashboard → Bar) is the same idea for a bar running tabs instead of table bills.

Behind the till, Cash Drawer (Dashboard → Cash Drawer) tracks physical cash float, movements and the end-of-shift count. Payment Terminals (Dashboard → Devices → Terminals) is where you pair and manage the Android tap-to-pay devices at the counter. And for Swedish tenants, the Kassaregister panel (Dashboard → Compliance) shows the fiscal engine's status — the register number, the last receipt, and whether it's running certified or in sandbox mode.

One more distinction worth getting right early: Dashboard → Tables is the live floor (open a table, seat guests, see who's occupied) and is different from Dashboard → Tables → Designer, which is an offline seating-chart planning tool for events and reservations — it does not feed the live floor plan.

  • Take an order → waiters, building tickets table-side.
  • Table Billing / Bar Tabs → whoever settles the bill — often the same waiter, sometimes a cashier.
  • Cash Drawer / Terminals / Compliance → usually a manager or owner's daily and weekly rhythm.

From "order taken" to "money in the drawer"

An order sent from Take an order is unpaid by design — it's meant to be settled on the table bill later, once the table is ready to leave, not charged dish-by-dish. Table Billing and Bar Tabs are where that settlement actually happens: pick the tender (cash, card, Swish, gift card), and the payment posts to the same ledger the Cash Drawer and Payments reports read from.

A cash payment increases what the open cash-drawer shift expects to hold; a card or Swish payment through a paired terminal shows up against that terminal's shift. Either way, the same receipt — VAT broken down by rate, sequentially numbered — is available to print or email, and for Swedish tenants a fiscal journal entry is written alongside it automatically.

About the examples in this guide

Every screenshot in this guide is a real capture from the same demo restaurant used in the Staff & Shifts guide, "Luigi's Pizzeria" — six tables across a dining room and a small patio, a short bar, and one paired payment terminal. Menu prices, guest names and card numbers shown are fictional demo data.

For each step you'll see the web view (a laptop or tablet at the host stand) and the mobile view (the same screen on the phone a waiter actually carries). Every screen in this guide is fully responsive — nothing here requires a fixed till.

Chapter 2

Setup & daily operations — floor to close

This chapter follows the order you'll actually meet these screens: lay out the floor once, then live in ordering and billing every service, then run the drawer and terminals around the edges of the day.

Step 1 — Lay out your floor plan

Dashboard → Tables

Table Management is the live floor: a KPI strip (total tables, available, occupied) above a grid of table cards, each showing its shape, seat count and area. Add a table with a name, seat count and area (dining room, patio, bar…), and its status (available, occupied, or a maintenance state) updates as the day runs.

This is deliberately simple — a card grid, not a drag-and-drop floor plan. If you want an actual to-scale seating chart (for events or reservations, not live service), that's the separate Designer, covered next.

Table Management page showing the KPI strip and a grid of table cards — web view
Table Management page showing the KPI strip and a grid of table cards — mobile view
Mobile view
Table Management: six tables across the dining room and patio, with live status and a seat count each.

Step 2 — Open a table and seat your guests

Tables → tap a table → Open table

Tap "Open table" on any available table, enter the covers (party size), and the table flips to occupied with a running session — that session is what Take an order and Table Billing attach to. Need to move a party? "Transfer" moves the whole session to another free table without losing the order.

Closing the session (once the bill is fully paid) frees the table back to available for the next guests.

Open Table dialog with a covers (party size) field — web view
Open Table dialog with a covers (party size) field — mobile view
Mobile view
Opening Table 2 for a party of three — covers, then the table is occupied and ready to order.

Step 3 — The guest-facing QR code, per table

Tables → tap the QR icon on a table card

Every table has its own QR code that opens a guest-facing page: the live menu, allergen information, and a "call waiter" button — no ordering happens through it unless you've also enabled online ordering. Print one per table, or use "Download every table's QR (ZIP)" to get the whole set at once.

Guest QR modal for a table, with a bulk download option — web view
Guest QR modal for a table, with a bulk download option — mobile view
Mobile view
The guest QR for Table 4 — scan to browse the menu and allergens, or call the waiter.

Step 4 — The seating-chart designer (a separate planning tool)

Tables → Designer

The Designer is a drag-and-drop seating chart across one or more floors — round and square tables in several sizes, a banquet layout, per-seat guest assignment (name, diet, VIP flag). It's built for planning events and large reservations, and autosaves as you arrange it.

Step 5 — Take an order at the table

Dashboard → Take Order

Pick a table from the grid (or type an ad-hoc table number for an overflow table), and you're into the order builder. This is the screen your waiters live in every service — the full walkthrough, course by course, is in the companion Waiter & PoS guide; this chapter covers what an owner needs to know about it.

Orders sent from here are unpaid by design ("source: waiter", settled later) — they land on the table's bill, ready for Table Billing to close out once the guests are ready to pay.

Take Order table picker with a grid of tables and an ad-hoc table number field — web view
Take Order table picker with a grid of tables and an ad-hoc table number field — mobile view
Mobile view
Take an order: pick a table from the grid, or start an ad-hoc table for overflow.

Step 6 — Table bills: build, queue, and let the guest pay

Dashboard → Table Billing → Table bills

The "Table bills" tab is for two things: building a bill by hand (item, quantity, unit price — useful when nothing came through Take an order, like a quick round settled directly), and queuing an existing bill so the guest can pay it themselves by scanning the table's QR code ("table-side QR pay") instead of waving down a waiter.

Made a mistake on a bill that hasn't been paid yet? Void it — the guest sees "no bill ready" if they reload, and the void is recorded, never silently deleted.

Table Billing page, Table bills tab, with a new bill being built — web view
Table Billing page, Table bills tab, with a new bill being built — mobile view
Mobile view
Queue a bill for Table 4 — the guest can settle it themselves via the table QR, or a waiter takes payment directly.

Step 7 — Split a bill

Dashboard → Table Billing → Split a bill

Pick the unpaid order, then either tap a quick even-split chip (2, 3, 4 or 5 ways) or type a custom amount, choose the tender (cash, card, Swish) and an optional tip, and charge it. Repeat with the next guest's share until the order is fully settled — each partial charge reduces what's still outstanding.

Be precise with your team about what this screen can and can't do: the web dashboard only offers even-split and custom-amount splitting. If a table wants to split by exact item ("I had the salmon, she had the pasta") or by named seat, that finer split lives on the Android POS app, not here.

  • Web dashboard (this screen): even split (2–5 ways) or a custom amount, any tender, repeatable partial charges.
  • Android POS app: the same order can also be split by exact item or by seat — reach for the Android app when a table asks for that.
Split a Bill panel with even-split chips and a custom amount field — web view
Split a Bill panel with even-split chips and a custom amount field — mobile view
Mobile view
Splitting Table 4's bill three ways — each guest can pay with a different tender.

Step 8 — Bar Tabs: open a tab with a pre-auth hold

Dashboard → Bar

Bar Tabs is the bar's equivalent of a table: open a tab under a name or description ("tall guy in red", "Table 5"), optionally take a card's last 4 digits and place a pre-auth hold so an unpaid tab never walks. The tab tracks its running subtotal as drinks are added.

Bar Tabs page with a new tab open, showing a pre-auth hold status — web view
Bar Tabs page with a new tab open, showing a pre-auth hold status — mobile view
Mobile view
A tab open under "Erik — bar 2" with a held pre-authorization on his card.

Step 9 — Fast-pour, rounds and happy hour

Bar → a tab → Fast pour, and Bar → Settings

The fast-pour grid is a set of configurable one-tap buttons (label, price, linked product) for the drinks your bar pours most — no menu search mid-rush. Every add groups onto the tab as a "round", so the tab reads like a real bar tab, round by round, not a flat item list.

Configure happy-hour rules in Bar → Settings: which days, which time window, and a discount by percentage or amount, scoped to everything or one category. Items poured during an active window carry a visible "Happy hour" badge on the tab.

Bar tab showing the fast-pour button grid and drinks grouped into rounds — web view
Bar tab showing the fast-pour button grid and drinks grouped into rounds — mobile view
Mobile view
Round 2 on the tab, poured from the fast-pour grid — two items carry the happy-hour badge.

Step 10 — Age verification and the refusals log

Bar → a tab → Verify ID, and Bar → Refusals

If your settings require it, a tab must be age-verified before it can be settled — "Verify ID" marks it checked. If you decline to serve someone, log it in Refusals with a reason (underage, no ID, intoxicated, other): a record you can point to if it's ever questioned, not just a memory of the night.

Bar Refusals log listing declined service entries with reasons — web view
Bar Refusals log listing declined service entries with reasons — mobile view
Mobile view
The refusals log: every declined service, with who, when and why.

Step 11 — Open the cash drawer with a float

Dashboard → Cash Drawer

Start the day (or the shift) by opening a drawer session with an opening float — the cash you're starting with. From that moment the page keeps a live "Z-report": opening float, cash sales, cash refunds, pay-ins, pay-outs and the running expected total, all computed from real transactions, not typed in.

Cash Drawer page with an opening float being entered — web view
Cash Drawer page with an opening float being entered — mobile view
Mobile view
Opening today's drawer with a 1,500 kr float.

Step 12 — Log a cash movement

Cash Drawer → open shift → Pay in / Pay out

Petty cash leaving the drawer for a supplier delivery, or extra float coming in mid-rush — log it as a pay-out or pay-in with an optional reason. Every movement lands on the live Z-report immediately, so the expected total always matches what should physically be in the drawer.

Cash Drawer showing a pay-out being logged with a reason — web view
Cash Drawer showing a pay-out being logged with a reason — mobile view
Mobile view
A 200 kr pay-out for a produce delivery, logged against today's shift.

Step 13 — Close the drawer and the Z-report

Cash Drawer → Close & Z-report

At the end of the shift, count the physical cash and enter the total. The page compares your count against the expected total and shows the variance — ideally near zero. Closing produces a Z-report summary (expected vs. counted vs. variance) that joins the "Recent shifts" history below.

Cash Drawer close dialog showing counted total and variance — web view
Cash Drawer close dialog showing counted total and variance — mobile view
Mobile view
Closing the shift: counted total against expected, with the variance shown before it's final.

Step 14 — Pair a payment terminal

Dashboard → Devices → Terminals

Install the terminal app on an Android device and it shows a short pairing code — type that code (plus an optional lane or section label) into this page to pair it. Prefer the phone to scan instead? Generate a QR/short code from here (15-minute expiry, single use). For a dedicated counter device you plan to lock down, the managed enrollment flow (factory reset, tap the welcome screen six times, scan a one-scan enrollment code) pairs and locks it in one pass, Wi-Fi credentials included.

Payment Terminals page with a device pairing card and a generated QR code — web view
Payment Terminals page with a device pairing card and a generated QR code — mobile view
Mobile view
Pairing a new counter terminal by code, with the QR-pairing option alongside it.

Step 15 — Manage your terminal fleet

Devices → Terminals

Every paired terminal shows its online status ("Online now" or "Last seen…"), battery percentage, connection type (Wi-Fi, mobile data, or offline), device model, app version and its lane label. You can push a charge to any terminal directly from here (amount plus a reference) and watch the result come back — handy for testing a new device or handling a payment from the office.

Terminal fleet list showing online status, battery and lane for each paired device — web view
Terminal fleet list showing online status, battery and lane for each paired device — mobile view
Mobile view
One paired terminal at the counter — online, 78% battery, on Wi-Fi.

Step 16 — The Swedish fiscal panel

Dashboard → Compliance → Kassaregister

For Swedish tenants, this panel shows your fiscal engine's status at a glance: the mode ("Certified unit — live" or "Sandbox — not certified"), the control unit's serial, the last receipt number and the current Z-sequence. Two buttons pull a running X-report or run today's Z-close on demand — the same reports the legal chapter explains.

Read the status badge honestly: a new tenant starts in sandbox mode, and the panel says so in plain words rather than implying certification it doesn't have. The legal chapter (next) explains exactly what that means for you.

Kassaregister compliance panel showing sandbox status, last receipt number and Z-sequence — web view
Kassaregister compliance panel showing sandbox status, last receipt number and Z-sequence — mobile view
Mobile view
The fiscal panel, honestly labelled "Sandbox — not certified" until a real control unit is connected.

Step 17 — Payments, voids and refunds

Dashboard → Payments → an order

The Payments page totals the day's sales and refunds by method. Open any order to see its full payment history — charges and refunds side by side — and issue a refund or void directly from there if the guest needs one after the fact. This action is gated to owners and managers; add a reason if you have one (it's optional but recommended), and the refund is logged either way with who issued it and when.

Order payment detail page with a refund control and an optional reason field — web view
Order payment detail page with a refund control and an optional reason field — mobile view
Mobile view
Refunding part of an order — an optional reason stays on the record alongside who issued it.

Chapter 4

Real-world scenarios, handled

Twelve situations every till and bar eventually meets — what the system does on its own, and what you do.

A card declines mid-split

Situation: Splitting a table four ways, the third card is declined.

What the system does: Split a Bill only marks a share paid once its charge actually succeeds — a declined attempt leaves that share outstanding, and the running "settled so far" total stays accurate.

What you do: Ask the guest to try again, switch tender to cash or Swish, or let another guest cover the share — the split panel doesn't care which guest pays which portion, only that the total clears.

A guest walks out on an open bar tab

Situation: A tab with a pre-auth hold is abandoned — the guest left without settling.

What the system does: The pre-authorization already holds funds up to the authorized amount on the guest's card; it can be captured for the tab's actual total (up to the hold) without the guest present.

What you do: Capture the hold to settle the tab, and note it in the refusals/incident log if the venue tracks walk-outs separately from declined-service refusals.

Wi-Fi drops mid-service

Situation: The dining room loses its connection while three tables are actively ordering.

What the system does: Take an order queues unsent tickets in an offline outbox and shows "Saved — will send when back online" instead of failing outright.

What you do: Keep taking orders as normal. Everything in the outbox sends automatically the moment connectivity returns — nothing needs to be re-entered.

A terminal's battery dies mid-shift

Situation: The counter terminal goes dark during a busy lunch service.

What the system does: The fleet list on Devices → Terminals shows it drop offline immediately, so it's obvious at a glance rather than discovered when a payment fails.

What you do: Plug it in or swap to a charged backup device and pair it — pairing takes under a minute with a typed code.

The wrong item got fired to the kitchen

Situation: A waiter sent "salmon" when the guest ordered "cod."

What the system does: Nothing prevents a correction before the item is paid for — it's still an open, unpaid line on the table.

What you do: Add the correct item, and void or adjust the mistaken line from the bill before it's charged. If the kitchen already started cooking the wrong dish, that's a floor conversation, not a system one — flag it to the kitchen directly.

An age-verification refusal

Situation: A guest at the bar can't produce ID for an alcoholic drink.

What the system does: The tab can be marked age-verified only once ID is actually checked — settling stays blocked on an age-restricted tab until then, if your settings require it.

What you do: Decline the order and log it in Bar → Refusals with a reason (no ID). The rest of the tab (non-alcoholic items) can still be served and settled normally.

The cash drawer doesn't balance at close

Situation: Counted cash comes up 85 kr short of the expected total.

What the system does: The close screen shows the variance plainly rather than forcing a match — it records what was counted, not what "should" have been there.

What you do: Recount before finalising, check for an unlogged pay-out, and if it still doesn't reconcile, close it with the honest variance and flag it — the Recent Shifts history makes a recurring pattern visible.

A Skatteverket kassaregister control visit

Situation: An inspector makes a test purchase, then asks to see the receipt and the register's records.

What the system does: The receipt handed over already carries the sequential number, VAT breakdown and required markings; the Compliance panel can pull the day's X-report on the spot.

What you do: Hand over the receipt and, if asked, show the Compliance panel. If your control unit is still running in sandbox mode and your turnover is above the exemption threshold, that's the honest gap to close before the visit, not after — see the legal chapter.

A big party wants an exact per-person split, not even shares

Situation: Eight guests each want to pay for exactly what they ordered.

What the system does: The web Split-a-bill tab only offers even or custom-amount splits — it has no per-item or per-seat picker.

What you do: Reach for the Android POS app for this table: its Split Bill screen offers guests/items/amount modes, including checking off exactly which items each guest is paying for.

A guest wants to pay with two different tenders

Situation: One guest wants to put half on a gift card and half on a card.

What the system does: Both Table Billing and Bar Tabs support repeated partial charges against the same order or tab — each charge can use a different tender.

What you do: Charge the gift-card amount first, then charge the remainder to their card — the outstanding balance updates after each charge.

Happy hour ends mid-round

Situation: A round is poured at 18:59, happy hour ends at 19:00.

What the system does: Each item is priced (and happy-hour-badged) at the moment it's added to the tab — a round poured while the window was active keeps its discounted price even after the window closes.

What you do: Nothing — the tab's history is the honest record of when each round was actually poured.

A refund is needed after the guest has already left

Situation: A guest calls the next day disputing a charge on their bill.

What the system does: Every order keeps its full payment history — charges and any refunds, each with an optional reason when one was given — reachable from the Payments page regardless of when the order was closed.

What you do: Open the order under Payments, review the charge, and issue a refund if it's warranted — add a reason if you want one on record. Only owners and managers can do this, and it's logged either way.

Questions & answers

Frequently asked questions

What's the difference between "Take an order" and "Table bills"?

Take an order is where a waiter builds a ticket and sends it to the kitchen — it's unpaid by design. Table bills (part of Table Billing) is where that unpaid order becomes a bill someone actually settles, either by a waiter taking payment or the guest scanning the table's QR to pay themselves.

Can guests split the bill by exact item, not just evenly?

On the web dashboard, Split a Bill offers even-split shortcuts (2–5 ways) or a custom amount — not a per-item or per-seat picker. That fuller split (by exact item or by named seat) lives on the Android POS app's Split Bill screen.

What is the seating-chart Designer, and is it the same as the live floor?

No — they're separate. Table Management (Dashboard → Tables) is the live floor you run service from. The Designer is a drag-and-drop planning tool for events and reservations, with its own floors, table shapes and per-seat guest assignment; it doesn't feed the live floor plan.

How does a bar tab's pre-authorization work?

Opening a tab can place a pre-auth hold on the guest's card for a set amount — funds are reserved, not charged. When the tab settles, the hold is captured for the actual total (up to the held amount); if the guest never returns, the hold can still be captured to cover what was poured.

What happens to an order if the internet drops mid-service?

Take an order keeps working — unsent tickets queue in an offline outbox and show "Saved — will send when back online" rather than failing. Everything sends automatically the moment the connection returns.

Is Restora's Swedish cash register certified?

Not out of the box. The fiscal engine produces receipts, journals and X/Z-reports in the certified format, but runs against an uncertified sandbox control unit until you connect a real certified cloud control unit (Restora integrates with fiskaly-se and infrasec). The Compliance panel states your actual status plainly — "Sandbox — not certified" or "Certified unit — live" — rather than assuming you're covered.

Do I legally need a certified cash register at all?

Most cash/card-taking restaurants do, under Kassaregisterlagen — with a small-business exemption below roughly 235,200 kr in annual cash/card sales (about 4 "prisbasbelopp"). Confirm your own threshold and obligations with Skatteverket or your accountant; this guide is an orientation, not a ruling on your specific business.

What's the difference between an X-report and a Z-report?

An X-report is a running snapshot of the day's sales so far — you can pull one any time with no effect on the register. A Z-report is the end-of-day close: it totals the day, advances the register's Z-sequence, and can never be re-run for that day once it's closed.

Can a waiter issue a refund?

No — refunds and voids on a settled payment are gated to owners and managers from the Payments page, and every refund is logged with who issued it (a reason is optional but recommended). A waiter can still void an unpaid line on a bill before it's charged.

How do I pair a payment terminal?

Install the terminal app on an Android device — it shows a short pairing code you type into Dashboard → Devices → Terminals (with an optional lane label). You can also generate a QR/short code for the phone to scan, or use the one-scan managed-enrollment flow for a dedicated counter device you want locked down.

What does the cash drawer's "variance" mean?

It's the difference between what the system expects in the drawer (opening float, plus cash sales, minus cash refunds and pay-outs, plus pay-ins) and what you actually count at close. A variance near zero means the drawer reconciles; a recurring variance on the same shift is worth investigating.

Which payment methods can PoS take?

Cash, card, Swish and Restora gift cards, including split and mixed tenders on the same bill or tab. Card and Swish through Restora need your payment provider (and Swish merchant enrollment) activated first; cash and gift cards work from day one.

Does VAT get calculated automatically on mixed bills?

Yes. Menu items carry their own VAT rate (12% for most food, 25% for alcohol, and so on), and every receipt — till, table bill or bar tab — breaks the total down by rate automatically, even when a single bill mixes food and alcohol.

What does PoS cost?

It's included in the Basic plan at 299 kr/month (billed yearly), alongside Kitchen Display, tables, staff and reports. Stock control is not part of Basic — it's a 29 kr/month add-on there. Prefer no monthly fee? Pay As You Go is 0 kr/month with 7% per transaction and everything included. Every plan starts with a 7-day free trial — no card to begin.

Looking for the waiter's day-to-day view? Read the Waiter & PoS guide — taking orders, splitting bills and handling the floor.
Managing staff and shifts too? Read the Staff & Shifts guide — PIN clock-in and the personalliggare.
Something unanswered? Talk to a human — a real person replies within a business day.

Ready when you are

See it with your own restaurant

Everything in this guide is included in the Basic plan — 7-day free trial, no card to begin.