POS: registers, devices & journal (add-on)

Under POS → Registers & devices you set up your business’s registers and connect the devices that will later run the VidiPOS app; with the Operators button there you decide who books at the till with which PIN. POS → Journal shows every transaction exactly as it is stored. Both belong to the “POS” add-on. The app for tablet and phone follows in the next stage, the TSE (the technical security device required by the German fiscal till regulation) is set up under POS → Fiscal (section TSE below).

You reach every POS page via the POS group in the left menu — in the order of the workflow: registers & devices, items, operators, journal, closings, cash book, reports, exports, fiscal, archive & auditor, register notification, printers, card terminal, subscription and settings. On a POS page the group is open and the current item highlighted; tabs above a page remain only for genuine sub-areas (items, cash book, settings).

Registers

A register is its own fiscal unit: when created it gets a fixed serial number (pattern VP-business-number), keeps a journal with gapless numbering and will later have its own end-of-day closing. You set its name, the business day change (transactions before this time count towards the previous day, e.g. 05:00 if you are open until 4 a.m.), whether training mode is allowed, the default payment method and the visible product groups.

A new register starts as a draft. You can already create a pairing code; the register can only book after Activate — the commissioning date is recorded. Retire register is permanent and only possible when no transactions are open; its devices can no longer sign in afterwards, and the journal is kept for record-keeping.

Operating the register

In the New register or Edit register form, the “Operation” section sets how the VidiPOS app behaves at this register. The values apply to all devices of the register. Nothing changes fiscally: receipt numbers, journal, TSE and end-of-day closing stay as they are.

• Name of the default table (required, 1 to 20 characters, “Counter” when created): this is what the quick register — selling without a table — is called in table selection, on the order, on the receipt and on the kitchen ticket. Technically it remains a transaction without a table: every sale is settled on its own and never combined with others into one joint bill. If no name is stored yet for an existing register, the form suggests the register’s name.
• Quick buttons in the order pad (at most three of cash, card (SumUp) and card (external terminal); cash when created): next to “Send” the app shows one quick button per payment method with the open amount, e.g. “Cash €19.60”. One tap, done: the app sends the lines not yet sent, takes the payment for the open amount, finishes the transaction, prints the receipt according to your print setting and returns to table selection. For card the card terminal flow starts for the open amount; “card (external terminal)” only records the payment. Please note when courses are switched on: paying means “everything is ordered” — the quick button also sends waiting courses to kitchen and bar right away (the button marks this with a dot). If a step fails, the app opens the normal checkout screen with everything entered so far. With no payment method ticked the app shows no quick button.
• Show the change calculator large next to cash (off by default): the key “… finish in cash” always counts as paid exactly — the transaction is finished at once and the cash drawer opens. For change there is “Calculate change”: when on, this key sits large next to the cash key, when off as a smaller side key. Cash handed over never becomes a tip.
• Sign out automatically after … minutes idle (1 to 60, default 15): if nothing is tapped on a device for this long, the app signs the operator out; the PIN is needed again afterwards. The same idle time applies on the server: an operator session ends after it, and before the Z closing an operator on another device only counts as signed in if they were active within this time (see Z only when all devices are off shift).
• Sign out when the app goes to the background or the device is locked (on by default): if someone switches to another app or presses the lock button, the operator is signed out as after idle time — with sign-out on the server and an entry in the operator log, not just a screen lock. The sign-in screen then suggests the last signed-in operator, so only the PIN is missing. A running card payment or print job is not interrupted.
• Call courses (on by default): when on, later courses on the receipt wait for their call (“Call”, “Call ‹course›”, see Courses). Off: “Send” sends all courses at once; the receipt shows no “Call” and no “waiting to be called”. The courses stay as sections on the receipt and the kitchen ticket, and the quick button asks nothing extra. Suits businesses that use courses only for sorting.
• Note ticket when moving positions (default off): when positions already sent are moved to another check (see Move positions), the register prints a note ticket “Moved table 9 → table 12” with the positions at their station. There is never a new production ticket — switched off, the kitchen learns nothing.
• Table attention (default off): Level 1 and Level 2 in minutes without activity (0 to 600, 0 = off). After that a table in the app’s table choice turns amber or red and shows “for 12 min” (see Table attention). With both levels set, level 2 must be greater than level 1; each level also works on its own.

Receipt when settling (next to the default payment): the preselected receipt output when settling — “Print receipt” (default), “Digital only (QR code, e-mail)” or “No print”. Staff can change it per receipt and also choose “Entertainment receipt” (“Invoice” feature). Without a receipt printer only “Digital only” and “No print” are offered. “Ask for the invoice recipient above €250” (on by default, only with the “Invoice” feature): when the receipt total is above €250.00 the app asks for the invoice recipient (company or host, suggested from the reservation or earlier receipts) before finishing and then prints the entertainment receipt with the recipient. Switch the question off for a quick or cash-only register. If the billing profile has neither a tax number nor a VAT ID, Registers & devices and Settings show the note “Action needed”: invoices above €250 would otherwise be incomplete.

All other register settings, such as the tip type or tipping on the card reader, stay unchanged when this form is saved.

Pairing and blocking devices

This is how you connect a tablet or phone:

1. Click Pairing code on the register. A nine-digit code appears.
2. In the VidiPOS app choose “Pair device” and enter the code.
3. The device appears under Paired devices with platform, model, app version, last seen and catalogue version.

The code is shown only this once, is valid for 10 minutes and for exactly one device; a new code invalidates the old one. Failed attempts are throttled per sender and overall; a stranger’s wrong code does not invalidate yours. Neither the code nor the device’s sign-in is stored in plain text. You block a lost or replaced device with one click — it can no longer sign in.

When pairing, every device gets a fixed device number per register (1, 2, 3 …, column “Device no.” in the device list); the number of a blocked device is never given out again. All devices of a register may keep settling in emergency mode (internet down) — several at the same time, too. So that receipt numbers never overlap, each device then uses its own numbers in the form <register>-<device>-<no.>, for example VP-12-1-2-15 for the 15th emergency receipt of device 2; online it stays <register>-<no.>. With the “Offline allowed” switch in the device list you take settling without internet away from a single device (taking orders stays possible) and give it back; every change is logged with your name.

How staff work with the app is described in Using the till, what applies without internet in Emergency mode. On the device, the “Open back office” button (Settings → Back office) leads straight to the back-office sign-in in the browser.

Operators and PIN

An operator is a person who books at the till. They sign in to the VidiPOS app with their PIN, and every transaction in the journal carries their name. The list under POS → Registers & devices → Operators shows each operator’s short code, name, role, linked account, whether a PIN is set, a current lock and whether they are active.

• Create from the team or free: pick the owner or an active team member — name and role are prefilled and the operator is linked to that account (at most one operator per account). Temporary staff without an account of their own are created free. If the linked account is blocked or the person leaves the team, the link is kept when you save (marked “account blocked” or “no longer in the team” in the form); it is only removed deliberately via Free (no account).
• Short code: two to three characters (letters A–Z or digits), unique per business; lower-case letters are converted to upper case. A deactivated operator keeps their short code too.
• PIN: 4 to 6 digits, required when creating and entered twice. VidiPOS stores only a hash, never shows the PIN again and never sends it anywhere — anyone who forgets it gets a new one via Set PIN. After 5 failed attempts the operator is locked for 15 minutes; the list shows “locked until”, and Remove lock releases them immediately. Set PIN does not remove a current lock — use Remove lock for that.
• Role = permissions on the device: what an operator may do at the till is decided by their role (next section); without a role they have no permissions. An operator linked to the owner’s account may do everything, and a blocked user account takes all permissions away from the linked operator.
• Escalation by a lead’s PIN: if a permission is missing — for example for a void after sending —, a shift lead releases exactly this action on the same device with their PIN. The approval is valid for 60 seconds; the operator and approver IDs are stored in the journal event, the operator name at the time of the start on the transaction.
• Signing out and deactivating: after the register’s idle time (default 15 minutes, see Operating the register) a sign-in ends by itself, after 12 hours at the latest. Deactivate ends all open sign-ins of the operator immediately; they no longer appear on the sign-in screen and can be activated again later. Operators are never deleted, so the journal stays complete.

Taking over from VidiClock

If you use the VidiClock roster, take over its staff as operators instead of creating them twice. Syncing only happens when you press the button — always with a preview.

1. Create a token in VidiClock: in VidiClock, create an integration token for the VidiReserve POS under Settings → Integrations. VidiClock shows it only once.
2. Enter it in VidiReserve: on the Operators page, paste the address of your VidiClock account (e.g. https://your-business.vidiclock.com) and the token into the VidiClock card and choose Connect. Only the owner may do this. VidiReserve stores the token encrypted and afterwards only shows its last 4 characters. When connecting, VidiReserve fetches the staff list once as a test fetch: a wrong token or address shows up right away, and nothing is saved.
3. Preview: Take over from VidiClock fetches the current staff list and shows what would change — split into new, changed, left and active again. Every row has a checkbox (preselected); for new operators you choose the role, “POS: Service” is preselected if the business has that role. The preview shows at most 250 rows per run; the rest follows at the next sync. The short codes of new operators are suggestions and may still change when applying if a code has been taken in the meantime.
4. Apply: VidiReserve fetches the list once more and only carries out the ticked rows that still apply; everything else is skipped and counted. The card then shows the last sync with its counts. A preview is valid for 15 minutes and only for the window opened last — if it has expired, simply reload it. Operators with an unknown VidiClock identifier (for example after manual data edits) are not synced; the preview counts them and shows a notice so you can check them manually.

• What changes: new staff become operators with the name from first and last name and a short code from the initials (if it is taken, a digit is added, e.g. “AB2”). For changed only the name is taken over. Anyone who is inactive in VidiClock, has left or is missing is deactivated — open sign-ins end immediately; anyone who is active there again is activated again.
• What stays: the sync does not change the short code, role or PIN of an operator taken over earlier, and it never touches operators created by hand. PINs do not come from VidiClock: new operators have no PIN — set it afterwards in the list via Set PIN.
• Disconnect: Disconnect deletes the address and the token (owner only); the operators taken over stay. If VidiClock rejects the token, create a new one there and connect again. If VidiClock cannot be reached, nothing changes.

Permissions and POS roles

Every function of the till has its own permission with the levels none, view and edit. In the role editor under Staff → Roles they appear in eight groups “POS · …”:

• Service: order entry, notes on items, choose a course, takeaway, misc items & open price, items on the device, training mode.
• Voids & changes: void before and after sending, discount, cancel receipt, restore transaction.
• Payment: take payments, split bill, record tips, redeem vouchers, charge to invoice. Discounts and prices already in the order are carried over when settling without a new discount approval — the “discount” permission is only needed for an additional discount on the receipt.
• Receipts: receipt archive & journal, print receipt copy, share receipt digitally.
• Tables: see or edit other staff’s tables; resolve held transactions (a transaction the server did not accept is discarded or submitted again). Held transactions are visible on all devices of the business and can be resolved from any device; the reporting device applies the decision on its next refresh. Such a decision stays in place even if the reporting device reports the transaction again before that — it only shows up as open again if it is held again afterwards. Every resolution is recorded in the operator log with device, operator and result; the list also names the reporting and the resolving device and — if a feature was switched off — which one (e.g. “feature discounts switched off”). A decision made on another device stays pending for the reporting device until it has applied and confirmed it — even if it was switched off for a long time. Each device can have at most 200 open held transactions; resolved and confirmed ones disappear from the list after 30 days. “Discard” only removes the device’s held entry — the transaction in the journal stays unchanged; if it is still open on the server, the register then goes on settling it (no second receipt beside it) — if another open receipt of the device is already at the table, the discarded one is aborted instead (reason “verworfen”). If a table only has receipts without an open position and without a payment (e.g. everything voided), “Settle” offers “Close table”: the empty receipts are aborted and the table is closed. “Abort transaction” is possible as long as no payment has been booked on the server — payments recorded only on the device are dropped with the abort. A discount carried over from an order can also be approved by someone allowed to edit “payments”.
• Closing & insights: shift and cash count, cash book, reports, statistics & insights, exports (CSV, DATEV, DSFinV-K), tips of all staff.
• Administration: item management, manage courses, printers, register settings, registers & devices, operators & PINs, TSE & fiscalisation, settings (features, cash movement types, DATEV accounts), submit register notification to the tax office, auditor package & auditor access.
• Device: device settings, pair and unpair device.

You can already grant “statistics & insights”, “exports” and “settings”; they take effect as soon as statistics, exports and the POS settings are available in VidiPOS. The same applies to “submit register notification to the tax office” and “auditor package & auditor access”: both are meant for the owner (the “Owner” template has them, Service and Shift lead do not); “submit register notification to the tax office” applies to POS › Register notification (view: status, preview, data sheet; edit: master data, notification, consent), “auditor package & auditor access” takes effect as soon as the auditor data handover is available in VidiPOS. In the back office the registers & devices page requires the permission “POS: registers & devices” (view; pairing code and blocking a device: edit). Creating, changing, activating or retiring registers additionally requires “POS: register settings” — so this permission presupposes at least view on “POS: registers & devices”. The operators require “POS: operators & PINs”, the journal “POS: receipt archive & journal”. The owner always has all permissions.

Create POS roles (owner only) creates three templates: Service (order entry with notes and courses, takeaway, take payments, split, tips, vouchers, void before sending, receipt copy and sharing, all tables, items on the device, discount in percent only up to 10 %, view archive and device settings), Shift lead (additionally void after sending, discount, open price, receipt cancellation, restore, charge to invoice, shift, cash book, reports, all tips, training, pairing, device settings and resolving held transactions; view items, statistics, register settings and POS settings) and Owner (everything). Afterwards the roles can be changed freely; roles with the same name are not overwritten. Existing roles therefore do not get new POS permissions (most recently “submit register notification to the tax office” and “auditor package & auditor access”) automatically: edit the role under Roles & permissions and set the permission.

Discount limits per role

Below the permission “POS: discount” the role editor sets two values: the discount type — “percent only”, “percent and amount” or “none” — and the maximum in % (a whole number from 0 to 100; empty = no limit). Both apply only when “POS: discount” is set to edit. The templates come with defaults: Service percent only up to 10 %, Shift lead percent and amount up to 50 %, Owner without a limit. Roles for which no discount type was ever saved behave as before: with “edit”, percent and amount without a limit.

On the register the discount panel shows only the allowed type, names the limit (e.g. “up to 10 %”) and offers the quick picks only up to the maximum. A higher rate or another type is still possible: the register then asks for the approval of a colleague whose role allows that type and rate (PIN as for a void). The limit also applies to “Change price”: what counts is the reduction in percent of the original price of the changed positions. An amount discount counts as its share of the sum of the positions that can take a discount. The basis is always the price the guest pays: with an option that lowers the price (say “small dish” −2.00 € on 8.00 €) that is 6.00 € — 0.60 € is 10 % there. A percent discount together with a price change reaches the server as one amount and therefore needs an approval with “percent only”. Discounts and price changes already in the order are carried over when settling without a new approval.

The server checks the same limits before every discount — also for transactions recorded in emergency mode and sent later. Without the approval the transaction stays on the device with “approval needed” until someone with sufficient rights approves it. Voucher discounts do not count against the limit; their value comes from the voucher.

Journal

The journal shows all transactions of a register for one business day — or all days including open transactions — with journal number, receipt number, type, status, operator, device time and server time, total and references (for example “cancelled by …”). Clicking a transaction opens its lines with the stored names, prices, tax rates and options, the void lines, the payments, the event log with revision and checksum, and the TSE status. Below that you find the tax by rate (net, tax, gross after discount), the discount with its reason and its share per item, and all TSE attempts of the transaction: state, time, revision, transaction number, signature counter, start and end according to the TSE, the serial numbers of TSS and register, the signature (shortened, expandable with algorithm, public key and QR code data) and any error.

Closed transactions cannot be altered, as the German GoBD rules require: a cancellation is always a separate counter-receipt, never a change. Every transaction carries a checksum that includes the previous one (hash chain). With the Check chain button at the top of the journal VidiPOS recalculates this chain for the selected register — including the checksum of every event: green means the numbers are gapless and all checksums match; red names the first break — please contact support in that case. The result stays above the list with its time until you check again. The journal is a view for checking and support, not a report; end-of-day closing and exports come with the next stages. Item management is described in the chapter POS: items, product groups & options.

Invoice for a till receipt

If a guest wants a proper invoice after paying — for example with a company address for the accounts or for the entertainment expense record —, create it afterwards for the till receipt. Open the receipt in the journal and click Create invoice at the top. The button only appears for a completed till receipt that has not been voided (no training, no void receipt), when the Invoice function is on in the register settings, your business uses the Invoicing add-on and you may view the journal and edit invoices. Receipts up to €250 may get an invoice as well.

In the dialog you enter the recipient. It is prefilled with the invoice recipient entered at the till when settling, otherwise with the billing company and address of the table's reservation. You can pick a customer from your list instead — then their details apply. You also choose the language of the invoice and whether the entertainment expense record is attached (a form below the invoice with place, date and host plus blank lines for occasion, persons entertained and signature; wording and blank lines as in the receipt design). Create draft creates an invoice draft in the invoicing module and opens it: the items are listed as on the receipt — description, quantity, amount after discount and tax rate, a tip for the business as a separate line; the tip for the staff never goes on the invoice. The header text reads “Invoice for till receipt no. … of …”, the date of supply is the day of the receipt. A manual invoice has no minus items (such as a deposit refund or a discount line): they are deducted from the largest item with the same tax rate, whose text says so (“less …”). If that is not possible, no invoice can be created for the receipt — write it by hand instead. Invoices for till receipts cannot be copied or turned into a series.

Review the draft and issue it like any other invoice (Writing an invoice). You may change descriptions and order, but not the amounts per tax rate: if they differ from the till receipt, the invoice cannot be issued (“Items differ from the till receipt”). The invoice gets its own number from the invoicing module and is issued right away as paid — with the end of the receipt as payment date and the receipt's payment method (cash, card; mixed or by voucher “recorded manually”). The PDF, the XRechnung and the ZUGFeRD part carry a fixed note: paid on …, till receipt no. …, TSE transaction … and “The sale is recorded through the till; this invoice does not replace the till receipt.”

Why paid, and why no double revenue? The sale is already recorded in the till with the receipt — TSE, cash book, end-of-day closing and DSFinV-K stay unchanged, the till receipt is not altered. So that it does not show up a second time in the accounts, the invoice for the till receipt, including its cancellation and credit notes, is left out of the DATEV export of the invoicing module, the Lexware transfer and the bank statement matching. In the invoice list its origin reads “till receipt no. …”.

The receipt in the journal then shows “Invoice R-… on … by …” (or “Invoice draft of … by …”) with a link instead of the button. Each till receipt has at most one valid invoice. If something is wrong, cancel the invoice in the invoicing module (Cancellation and credit note); the button is then available again, and the cancelled invoice stays visible as history. A deleted draft also frees the receipt again.

Fiscal: TSE and DSFinV-K (fiskaly)

Every register in Germany needs a technical security system (TSE) that signs each transaction. VidiPOS uses the cloud TSE fiskaly SIGN DE for this (certificate BSI-K-TR-0717-2025). Each business has one TSS (the actual security device with its own serial number), and every registered register is its own client there — with its serial number from Registers & devices.

Under POS → Fiscal you see the environment (TEST or LIVE), the mode, the organisation ID, TSS ID, TSS serial number, the state at fiskaly, the certificate and, per register, the client ID, client serial number and registration date. You need the TSS serial number and the certificate when you report the register to the tax office.

1. Commission TSE creates an own organisation for your business at fiskaly (name and address from your business details), creates the TSS, initialises it and registers the first active register. If fiskaly does not allow an own organisation, the TSE runs in the VidiReserve main organisation — the page then shows a notice, and the signatures are not affected.
2. Setup runs in steps, and every step is saved. If it stops (for example because fiskaly cannot be reached), the page shows the error, and Resume continues exactly there — nothing is created twice. A second click while setup is still running is rejected.
3. If a register is added or activated later, the notice “Not yet registered with the TSE” appears with the button Register with the TSE — see “One register per location” below.
4. Refresh status asks fiskaly for the state of the TSS. If fiskaly reports it as defective, the page warns you. Then choose Replace TSE and give a reason: the registers are deregistered from the current TSS; it is kept for the export. All previously registered registers are registered with a new TSS — without a new confirmation. The old registrations stay in the history with date and reason — nothing is overwritten.

VidiPOS stores credentials, PUK and PIN of the TSS only in encrypted form; they never appear on the page. Everyone with the permission TSE & fiscalisation (view) can open the page; the buttons only appear with “edit”. As long as the fiskaly connection is not configured, the page only shows that notice. If the TSE fails during operation, the register keeps working; the transaction is then completed without a signature and marked on the receipt — fiskaly does not allow signing afterwards.

One register per location

At fiskaly, every client is a separate billing unit — that is, every register registered with the TSE. The standard is therefore one register per location: several devices (tablets, phones) share one register — simply pair more devices with the existing register under Registers & devices. Commissioning therefore registers only the first active register. If you create another register under Registers & devices, the form reminds you of this; nothing is blocked.

If you really need a second register (for example a separate bar with its own accounting), register it under POS → Fiscal with Register with the TSE. A dialog points out the costs: every additional register is a separate fiskaly unit with additional monthly costs and a 12-month minimum term. The register is only registered once you confirm this. Only users with the permission TSE & fiscalisation (edit) may do so. Until then the register books without a signature — so register it before it is used in operation.

The table “Registers on the TSE” shows the signatures this month per register and the total below it. Every start and every completion of a transaction is one signature. fiskaly allows at most 20,000 signatures per client and calendar month; from 80% a warning appears. If the limit regularly gets tight, a second register makes sense — feel free to contact us.

DSFinV-K cash registers

For handing data to the tax office (DSFinV-K), fiskaly keeps a DSFinV-K cash register for every register signed up with the TSE. VidiPOS creates it automatically as soon as a register is signed up with the TSE — at commissioning, with Register with the TSE and after a TSE switch. Every signed-up register is a cash register of its own of type master with this register's TSS; its client ID is the same as at the TSE. The devices you pair with this register are input devices and do not get a cash register of their own — this also matches “One register per location”.

The cash register states “VidiScope” as manufacturer, “VidiPOS” as model and software, and as software version the newest app version of the paired (not blocked) devices of the register. Every device reports its app version with every call; after an app update the cash register is therefore brought to the new version by itself. As long as no device has reported a version, it shows “none reported yet”, and fiskaly only receives the software name. The transfer runs in the background, usually within a minute — never while you are booking at the register.

Under POS → Fiscal the section DSFinV-K cash registers shows per register the client ID (shortened), the type, the software version, the state (waiting for transfer, transferred or error), the time of the last transfer and, if any, the error message from fiskaly. If fiskaly is briefly unreachable, VidiPOS tries again after a few minutes. If fiskaly rejects the cash register, the error is shown there and VidiPOS tries again at most once a day or as soon as the version changes — please contact support then. After a TSE switch the cash register of the former client stays visible (marked as “former client”): the closings from the time before belong to it.

Closings sent to fiskaly (DSFinV-K)

Every Z closing goes to fiskaly as a DSFinV-K cash point closing — with the Z number as the closing number, the business day and all transactions assigned to the Z (receipts, cancellations, cash movements, training bookings, aborts, orders and transactions delivered late), plus the totals per tax rate and payment type from the stored Z. This happens in the background, usually within a few minutes; the closing at the register never waits for fiskaly. Before a closing is sent for the first time, VidiPOS stores it unalterably with a checksum in your fiscal archive (10 years) — every repeat sends exactly this file, never recalculated data, and never a new Z number.

Under POS → Fiscal the section Closings sent to fiskaly shows the last 30 closings per register with Z number, business day, state, number of attempts, time sent and completed and, if any, the error. The states: waiting for transfer (not sent yet, or fiskaly could not be reached — VidiPOS retries with growing intervals from one minute up to an hour, with longer intervals of up to a day if access is denied or the cash register is not there yet), accepted by fiskaly or being processed by fiskaly (VidiPOS checks every minute, after half an hour every five minutes), transferred (done — only such closings go into DSFinV-K exports) and the alarm states error at fiskaly (with the report from fiskaly to expand), rejected by fiskaly, conflict (fiskaly holds a different closing under the same ID) and mapping error (the totals of the Z could not be mapped consistently; nothing is sent then). A closing in progress for more than three hours, or waiting for the transfer for more than three hours (whatever the reason, for example an archive or cash register error), is marked as stuck and counts as an alarm. The closings of a register go to fiskaly in the order of their Z numbers: while an earlier Z is still waiting, the next one waits too. Every alarm shows a notice at the top of the page — please contact support then: a faulty closing is never resubmitted automatically, because the Z number cannot be reset at fiskaly. If a closing is waiting after a network error, Send again sends it right in the next run (permission TSE & fiscalisation, edit; the click is logged) — there is no such button for errors, rejections and conflicts. A transaction taken over offline with a total difference between device and server goes to fiskaly with the device totals (as it stands in the Z) and a balancing line “Summendifferenz Gerät (sum_mismatch)”. In the list POS → Closings and in the Z detail a small badge shows the state (DSFinV-K: transferred, pending or error); the POS app shows it in the Z view. With a mapping error nothing was ever sent, and a rejection by fiskaly was not stored by fiskaly: in both cases VidiPOS checks the mapping again once a day, and Check mapping again does it right away (permission TSE & fiscalisation, edit; logged) — if it works, the closing goes to fiskaly as usual with the same Z number (a rejected closing only if its data has changed; otherwise it stays rejected and support will help). This way there is never a gap in the Z numbers. The section Archive shows the latest TSE export per TSE and the latest DSFinV-K export per register with the missing months; the section Register notification shows each register's notification status with the tax office and the running deadlines (see Register notification).

Fiscal archive: retention, exports, checksum and restore

Under POS → Archive you find all fiscally relevant files of your business: the closings exactly as they were sent to fiskaly (JSON), the DSFinV-K exports (ZIP — the data format the tax authorities require for a cash register inspection or a tax audit) and the TSE exports (TAR — the signed logs of the technical security device). fiskaly keeps this data for only about three months; keeping it is your duty — VidiPOS does it for you. Every file gets a SHA-256 checksum when it is stored, is never overwritten and is kept for 10 years (until 31 December of the tenth year after its period); before that it can neither be changed nor deleted. The list shows per file the type, period, register or TSE, size, the shortened checksum (in full when you hover over it), the date created and “Keep until”; you can filter by type and year.

Download checks the checksum first and never delivers an altered or missing file; every download is logged with user, time and an anonymised fingerprint of the IP address. Check recalculates the checksum of one file, Check all files that of the whole archive (result: intact, missing or altered) — this needs “edit” and is possible at most once every five minutes; for a very large archive one run checks only what fits into its time and names the number of files not checked. If a file is missing or altered, please contact support: it is restored from the server backup — but only if the backed-up file has exactly the same checksum; any other file is rejected, the altered file is kept next to it as evidence, and every restore is logged.

Exports are created automatically: the DSFinV-K export monthly per register, at the earliest on the 3rd of the following month from 3 am and only once every closing of the month has reached fiskaly and is complete (closings with an error are left out and named as a note on the export row; a closing whose mapping is still being checked holds the export back for at most one week). If a closing that was left out is completed later, VidiPOS creates the monthly export again — the earlier file stays in the archive. The TSE export runs monthly per TSE — started at night between 1 and 5 am, because an export keeps the TSE busy for a moment — and additionally, when the TSE is replaced, as a final export of the entire old TSE; if the TSE is too large for that, it is split into monthly exports automatically. VidiPOS catches up missed months of the last 12 months by itself. Every downloaded file is checked for its format before it is stored (TAR, or ZIP with an index); a damaged file is not archived but downloaded again. The table Exports shows state, attempts and notes (for example “No data in this period” or an incomplete ZIP structure); if fiskaly is busy or reports an error, VidiPOS retries with growing intervals — after ten failed attempts the export shows “error”. Retry export then starts a new attempt with a new export ID (the old row stays, marked “replaced”). With Request a DSFinV-K export you create an export for your own period (up to yesterday — up to today once all of today’s Z reports of the register have been transferred to fiskaly —, at most 12 months) and a register, for example for your tax adviser; at most five requests per register can run at the same time. Requesting, retrying and checking all files need the permission TSE & fiscalisation with “edit”; viewing, downloading and checking a single file already work with “view” — except for the files of the register notification (preview and result PDF, ELSTER XML, consent, data sheet): they contain the tax data unredacted, so here too they can only be downloaded and checked with the permission Submit register notification to the tax office set to “edit”; without it the row is listed without buttons. An auditor access never sees these files. After the retention period a documented deletion run removes only the file; the entry stays as evidence, marked “deleted after the retention period”.

Auditor: data access Z1, Z2 and Z3 (cash register inspection, tax audit)

During a cash register inspection (section 146b AO) or a tax audit the tax office may access your register data — the GoBD name three ways: Z1 direct access (the auditor looks into the system themselves, read only), Z2 indirect access (you run analyses as instructed) and Z3 data handover (you hand over the data on a storage medium or as a download). Under POS → Archive & auditor VidiPOS prepares Z1 and Z3; for Z2 use Reports and Exports.

Auditor package (Z3): choose the period (up to yesterday; up to today once every register with sales today has its Z report and all of today’s Z reports have been transferred to fiskaly — for example for a cash register inspection on the same day; at most 24 months) and the register (or all registers) and click Request package. VidiPOS builds the ZIP in the background (usually within a few minutes) with the DSFinV-K exports (ZIP) and TSE exports (TAR) from the fiscal archive, CSV files per month (journal, receipts with lines, payments, Z reports, cash book — without guest e-mail addresses or phone numbers), the Z reports as PDF, for at most 500 receipts also the single receipts as PDF, the file systemstand.html (registers, devices and app versions, TSE with serial number and certificate, DSFinV-K cash registers, settings with fiscal relevance, archive index and a short description of the procedure), a LIESMICH.txt (read-me) and the table of contents inhalt.csv with type, period, size and SHA-256 checksum of every file. If the DSFinV-K export of a month is missing, VidiPOS requests it from fiskaly first and waits up to two hours; if something is still missing afterwards (for example the TSE export of the current month), a note is added to inhalt.csv. It also notes a DSFinV-K export that lacks closings (for example a Z report fiskaly rejected with an error) — such an export does not count as complete. With very many receipts a time budget limits the PDF generation; PDFs not generated are listed as a note in inhalt.csv (the data is in the DSFinV-K export and the CSV files). If a run aborts, the package shows “error” — then request it again. The finished package is itself kept in the fiscal archive (with its own checksum). You keep the complete procedure documentation of your business (processes, responsibilities, cash instructions) yourself — systemstand.html only describes the technical state.

Download link: right after the request VidiPOS shows a link once, which you copy and give to the auditor (VidiPOS does not send it). It works as soon as the package is ready and is then valid for 7 days; an expired link reports “expired”. With New link you create a new link for a finished package — the old one then stops working. Only a checksum of the link is stored, never the link itself. Every download (via the link or in the back office) is logged with time and an anonymised IP fingerprint and counted. Viewing and downloading need the permission Auditor package & auditor access with “view”, requesting and new links “edit”.

Auditor access (Z1): if the auditor asks to look into the system themselves, only the owner sets up a temporary access: the auditor’s e-mail and name and the duration (default 14 days, at most 90). The auditor receives the usual team invitation by e-mail and an account with the role Auditor (read only): they see journal, closings, cash book, reports, exports, TSE & fiscal, archive and register notification — they cannot change anything, and staff, guests, reservations and marketing stay hidden. The role can neither be edited nor taken away from an auditor access. When it expires the access ends immediately (on the next page view, without delay); you can extend it or revoke it at any time. Every set-up, extension and revocation is logged. If you remove the auditor under Staff, their auditor access disappears as well. To set up a revoked or expired access again, simply use the same e-mail address: VidiPOS reactivates the existing account with the new duration (without a new invitation — if the auditor never set a password, they use “Forgot password”). An expired auditor access can no longer sign in via the partner app either and no longer appears in selection lists or as a recipient of notifications.

Register notification to the tax office (section 146a (4) AO)

Anyone who acquires an electronic recording system — that is, a register with a TSE — or takes one out of service must notify the tax office within one month (section 146a (4) of the German Fiscal Code, AO). Under POS → Register notification VidiPOS does this via fiskaly (SUBMIT DE), which transmits the notification to ELSTER. At this stage transmissions only go to the fiskaly test environment; consent text, power of attorney and deadlines are subject to review by a tax adviser and a lawyer.

1. Master data: the taxpayer — a company with its name and legal form (as an ELSTER code; the name belonging to the code is shown in the notification’s preview PDF — check it there; so far only 31 = stock corporation is confirmed, your tax adviser can give you the other codes of the official list) or a sole proprietor with salutation, first and last name, date of birth and tax identification number. The identification number is stored encrypted and never shown in full, not even on the data sheet. ELSTER needs the tax number with 13 digits in the nationwide format (four digits tax office, a 0, eight digits); the notation on your tax assessment differs by federal state — your tax adviser can give you the 13-digit form, VidiPOS does not convert it. VAT ID and tax office number are optional; the house number consists of digits only, letters go into the suffix. Add the business premises (suggested from your business details). VidiPOS only checks the format of the data, not whether it is correct. If several businesses use the fiskaly main organisation, only one of them can be the taxpayer — a second business is locked and needs its own managed organisation (support).

2. Registers: every register signed in at the TSE appears with type (tablet/app POS system), manufacturer VidiScope, model and software VidiPOS, the app version, the acquisition date (default: when the register was created — please check and change if needed) and the commissioning at the TSE. The status shows “notified”, “not notified”, “changed” or “out of service — retirement notification needed”.

3. Notification: Prepare notification bundles taxpayer, business premises and all registers; VidiPOS sends it to fiskaly in the background, ELSTER checks it, and the preview (PDF from ELSTER) appears on the page and in the archive. Nothing is transmitted until you have checked the preview, ticked the box and clicked Consent and transmit. The consent is logged unalterably with name, time, language, the wording, the checksum (SHA-256) of the preview shown and an anonymised fingerprint of the IP address, and archived as a file. It is valid for 24 hours and only for exactly this preview. You can consent only after opening the preview — opening it is logged. The files from ELSTER (preview, result, error response) are kept unredacted in the archive on purpose, because they are the evidence; only users who may edit the register notification can retrieve them. In error texts and the excerpt on the page the tax identification number is redacted. If fiskaly does not confirm a triggered transmission within one hour, the consent lapses and you consent again. Afterwards you see the state up to “transmitted”; if the check or the transmission fails, the ELSTER response (shortened) is shown in the history and in full as a file in the archive. While a notification is in progress, master data and registers are locked; use Discard notification to correct something before consenting.

Changes and retirement: a new register, a new device or a TSE replacement (new client) is a change — the status shows “not notified”, the deadline runs and the next notification has the occasion “change”. When you take a register out of service, choose Retire for it: date, reason (sale, disposal, theft, defect, relocation, other) and a remark — VidiPOS prepares a new notification from it. Every notification contains all registers of the premises; the retired one goes out with date and reason. If an entered retirement should not be reported after all (notification discarded, failed or never prepared), use Withdraw retirement at the register — only as long as it has not been transmitted and no notification is running; date, reason and remark are deleted and the step is logged. After discarding a retirement notification VidiPOS points this out.

Deadlines: for each register without a successful notification one month counts from acquisition (after a TSE replacement from commissioning of the new client) or from taking it out of service. From day 14 a notice warns under POS → Register notification and POS → Fiscal; after the deadline the register is “overdue”. Whether the deadline starts at acquisition or at commissioning is something to clarify with your tax adviser.

Data sheet: if you prefer to notify yourself via Mein ELSTER, download the notification data sheet (PDF) with all data in the order of the ELSTER form; it is archived as well. Viewing, preview, files and data sheet need the permission submit register notification to the tax office with “view”, everything else “edit”.

TSE outage

Every transaction is started at the TSE when it begins at the register and finished when it ends — including orders, training postings (as training receipts), cancellations (as receipts with negative amounts) and aborted transactions (as aborted receipts). The TSE usually answers within a fraction of a second. If it does not answer within three seconds, the register does not wait: the transaction is still booked, and the journal shows the attempt as failed (the request certainly did not arrive, for example because fiskaly was unreachable or the TSE was busy) or as unknown (the request went out, but the answer was missing).

A background check resolves “unknown” within a few minutes: it asks fiskaly whether the signature was created after all. If so, a new signed row with the data and time of the TSE appears in the journal; if not, a row “did not reach the TSE”. Nothing is ever signed afterwards — fiskaly does not allow it, and the German cash register regulation does not provide for it. If the completion of a transaction never reached the TSE (for example because the connection dropped at exactly that moment), the check notes “Abschluss nicht gesendet” (completion not sent) two minutes later and counts the transaction towards the outage. The check also reads the state of the TSS every minute; if fiskaly reports it as defective, POS → Fiscal shows this and the outage stays open until you replace the TSE.

If a TSE is set up for your business but a register is not (or no longer) registered with it — for example an additional register without confirmed registration or after an interrupted TSE replacement — this register keeps booking, but every attempt appears in the journal as failed “TSE nicht aktiv” (TSE not active) and counts as an outage. Register the register under POS → Fiscal. Only a business that has never set up a TSE books in test mode without such a note.

Under POS → Fiscal VidiPOS keeps an outage log per register (the latest 50): the first failed or unknown attempt of a register opens an outage with its start, cause “TSE” and the time of the last successful signature; every further affected transaction increases the count; the first successful signature ends it. If a register works without internet in emergency operation, it sends the closed transactions later in one batch. These transactions are not signed; the journal shows “Kasse im Notbetrieb (offline)” (register in emergency operation), and the log shows an outage with cause “Internet” from the first start until receipt. A transaction begun in emergency operation is only started at the TSE when it is finished online (start and completion together); if it is also finished or aborted offline, it stays unsigned and belongs to the emergency operation.

The tax office requires (AEAO on § 146a no. 1.14) that you document an outage, make it recognisable on the receipt and remove the cause without delay. The log is this documentation; if an outage lasts longer than a few minutes, check the internet connection and the status under POS → Fiscal and contact support if needed.

If the TSE is unreachable during a batch upload or a cancellation with restore, VidiPOS tries only once per request and books the remaining transactions immediately as “TSE nicht erreichbar (übersprungen)” (TSE unreachable, skipped) — so the register waits at most three seconds. Under Open at the TSE, POS → Fiscal shows per TSS how many transactions are closed at the register but still open at fiskaly (for example closed during emergency operation). A TSS accepts at most 2000 open transactions; from 1000 on a warning appears — please inform support then. Counted are transactions whose TSE start is older than ten minutes; the table also shows the oldest open start per TSS, and a notice above it sums up number and time. At the very top of POS → Fiscal you find the fiscal status: it sums up all sections of the page (closings sent to fiskaly with an error or stuck for more than three hours, missing monthly exports, failed exports, notification deadlines, TSS state, open TSE transactions, cash registers) — “OK”, “Note”, “Warning” or “Action needed”. VidiReserve platform support sees the same check in its overview of all businesses.

Receipt and digital receipt

The receipt of a finished transaction is created by the server: the register loads it after payment and shows or prints it. It contains all mandatory details under § 6 KassenSichV and for small-amount invoices: name and address of the business with tax number or VAT ID (from your billing profile, otherwise from the business details), register with serial number, receipt number, server, table, start and end of the transaction, the items with quantity, price and tax rate code (A = 19 %, B = 7 %), a granted discount with its reason, the VAT per rate after discount, the total and the payment methods — including voucher and deposit (“Deposit from reservation #…”). Tips are listed separately below and are not included in the total; tips to the business are included in the tax at the standard rate (note on the receipt). Options (such as side dishes) appear on the English receipt with the English name they had when they were entered — renaming them in the catalogue later does not change old receipts; without an English name the German one is shown. If your business is registered as a small business (section 19 UStG) in the billing profile, the receipt shows no tax rates and no tax table but “No VAT is charged in accordance with section 19 of the German VAT Act (UStG).”, and the TSE receives all amounts without a VAT rate (an assumption — please confirm it with your tax adviser). What counts is the setting when the transaction is finished: if you change the billing profile later, receipts that are already finished stay as they were — receipts finished as regular before switching to the small business scheme stay regular, too; a cancellation follows its original receipt. A cancellation carries the note “Cancellation of receipt …” and negative amounts, a training posting the note “Training receipt”.

If the transaction was signed by the TSE, the receipt shows the TSE data (serial numbers, transaction number, signature counter, times, check value, algorithm, public key) and the verification QR code according to DSFinV-K, which the tax office can use to check the receipt. If the TSE failed or the register ran in emergency operation, the receipt instead says “TSE not available” with the cause and the start of the outage — as the application decree requires for an outage. Without a connected TSE it says “Not a valid receipt · test mode”. A receipt of another server can only be retrieved with the “print receipt copy” permission and is then marked as a copy.

Every receipt also has a digital receipt: a page at an address with a long key that cannot be guessed, which your guest can open without logging in, print or download as a PDF (German or English). The register shows a QR code for it. Because the page can be opened without logging in, it shows less than the receipt at the register: the server only by short code, for a deposit only “Deposit applied” without the reservation number, and for a voucher no characters of the code. The page is not indexed by search engines and not cached; no PDF is stored — it is generated from the journal on every request. Without the address nobody can retrieve the receipt — not even with the number of the transaction.

Revoke receipt link: the link to the digital receipt never expires. If a guest asks for their receipt to stop being available, open the transaction under POS → Journal and choose “Revoke receipt link” (reason optional; this needs the “POS: receipt archive & journal” permission with edit). Revoking is final: afterwards nobody can open the receipt page or the PDF, the register no longer shows a QR code for this receipt and it can no longer be sent by e-mail. The receipt stays unchanged in the journal — it remains part of your records.

Receipt by e-mail

If a guest wants their receipt by e-mail, staff tap “Receipt by e-mail” at the register. If the transaction belongs to a reservation, the register suggests its e-mail address — for data protection only shortened (e.g. “m***@d***.de”); if staff accept the suggestion, the server fills in the full address from the reservation. Any other address can be entered instead. The e-mail is sent in the name of your business (replies go to your business address), has the subject “Your receipt … – your business”, shows the receipt number, date and total, attaches the complete receipt as a PDF and — if the digital receipt is switched on — a button to the receipt page. The language follows the choice at the register, otherwise the language of the reservation, otherwise your own language. You can adapt the text under Settings → e-mail templates (“POS receipt by e-mail”).

Purpose limitation: the e-mail is sent only on explicit request — never automatically on payment. It contains no advertising and does not sign anyone up for a newsletter. The address is not stored: it only appears in the e-mail itself. In the journal the transaction only shows time, server, device, language and whether sending worked under “Receipt by e-mail”. Do not use the address for any other purpose.

Permissions and limits: sending requires the “POS: share receipt digitally” permission (edit); a receipt of another server additionally needs “POS: receipt archive & journal” (view). Training receipts, open transactions and receipts with a revoked link cannot be sent. To prevent abuse, at most 200 receipt e-mails per business in 24 hours and at most three per receipt within one hour are sent; beyond that the register reports “too many receipt e-mails” and the journal notes “limit reached”. A device can request the address suggestion at most 30 times per hour; every request is recorded (without the address) in the operator log.

Designing the receipt (receipt design)

Under POS → Settings → Receipt design (permission “POS settings”; “edit” to change) you decide how your receipt looks — on the receipt printer of every register, on the page of the digital receipt and in the PDF. You can freely choose: a logo at the top, a header text below the business details (e.g. “Welcome”, Wi-Fi name), a footer text after the payments and before the TSE details (e.g. thanks, Instagram, opening hours), each at most 5 lines of 48 characters in German and English (empty English = German text; on 58 mm paper, lines over 32 characters wrap), the font sizes of business name, receipt number, items, total and footer (normal, tall, wide, large), the separator (dashed, double, solid, none), the size of the verification QR code, blank lines before the cut, whether operator, table and split number appear, a compact tax table (one line per tax rate) and a compact card section (card and authorisation code), and the note “Tips are not included in the total”. For the entertainment receipt you choose the labels for occasion and persons, how many writing lines are pre-printed for the persons entertained (1–8) and the space above them; occasion or persons can be left out. Texts may only contain characters the receipt printer knows (umlauts, ß, € and the usual punctuation yes, emojis no) — otherwise the form names the line.

What stays fixed: the mandatory details under the German cash register regulation cannot be switched off — business details with tax number or VAT ID, receipt number, date and times, items with quantity, price and tax code, the tax table (also compact with net and tax per rate), payments and change, the TSE block with the verification QR code, the invoice recipient and the marks training, copy and without TSE. “Start and end in the header” only hides the header line of the digital receipt; the TSE times and the times during a TSE outage always stay on the receipt.

Tips for the logo: the logo comes from the business profile (Profile → Logo); if one is on file and still off on the receipt, the page asks at the top “Your logo is on file — show it on the receipt?”. Thermal printers only print black and white: a single-colour, high-contrast logo in landscape format without fine lines and without light grey areas works best; choose the height small (12 mm), medium (18 mm) or large (24 mm). For photos and gradients, “Dither grey tones” helps. The preview shows the real black-and-white version exactly as the printer receives it. A large logo makes every receipt longer and costs paper; thermal paper yellows over time and fades in sunlight — for receipts guests keep, the digital receipt is the better choice.

Preview and sample print: next to the form, the preview shows the receipt for 58 and 80 mm while you type (approximate, optionally with the entertainment receipt). “Open sample PDF” shows the digital receipt with the saved design. The sample print sends a sample receipt with fixed example data and the mark “SAMPLE — not a receipt” to the receipt printer of a paired device’s register — like the test print from the back office (the app must be open). Save first, then print. “Reset to standard” restores the receipt as before; every change is listed in the page’s log.

Switching the logo off at one register: if a slow printer prints the logo sluggishly, tick “Do not print the logo on the receipt” in the settings of that register (POS → Registers). The other registers and the digital receipt keep showing the logo.

Filling in the entertainment record online

For business meals, your guest can fill in the entertainment expense record for their receipt online. If the receipt has a digital receipt (QR receipt switched on, link not revoked), the entertainment receipt — on paper and in the PDF — shows a QR code below the record with the line “Receipt as PDF + fill in the entertainment record online”. It leads to the receipt page, where the guest enters the occasion, the persons entertained (one per line), the host with address and the tip. Place and date of the entertainment are fixed from the receipt. If staff entered an invoice recipient at the register, that recipient is the host and cannot be changed; otherwise the guest enters name and address — this is only a detail in the record, not an invoice recipient. The tip is prefilled with the tip on the receipt; the guest can add a tip given in cash. Training and reversal receipts have no form.

Versions instead of overwriting: “Finalise” creates an unchangeable version (version 1, 2, …). The form is then locked; a change creates another version via “Create a new version”, and all earlier versions remain stored and available as PDF. The entertainment receipt as PDF contains the complete register receipt and the filled-in record with a footer line (version, time, checksum and signature); the guest can download it or have it sent by email (through the same delivery as “Receipt by email”, with the same limits). The host provides the signature by hand on the printout — nothing is signed in the system.

Signature: VidiPOS signs every version on the server: a checksum over the content, chained to the previous version, and a signature with a secret server key. “Verify version” on the receipt page and the “Entertainment records” section in the journal (POS → Journal → receipt, read-only) recompute content, chain and signature and show “valid” or “invalid”. This is not a TSE signature: the TSE signs register transactions, not documents — the register receipt itself, its TSE data and the DSFinV-K export are not affected by the record.

Privacy and retention: Only the details in the record, the time and an encrypted checksum of the request are stored (no IP address in plain text). Only people with the link to the receipt and your business can see them. The records belong to the register receipt and stay with it in the journal for as long as receipts are kept (at least ten years); they are deleted together with the receipt when the retention period ends.

Receipt printers

Under POS → Printers & stations you set up the receipt printers of your business. VidiPOS prints over the network: the printer is connected to your local network by LAN or Wi-Fi and accepts receipts in the ESC/POS standard on port 9100 — common receipt printers with a network port can do this. Bluetooth printers are not supported at the moment.

For each printer you enter a name, the IP address or host name in your local network (without http:// and without a port), the port (default 9100) and the paper width (58 or 80 mm), and assign it to a register — in the dialog that the “New printer” button at the top right opens; “Edit” in a printer’s row opens the same dialog with its details. The table shows each printer’s role (“Register printer · register …”, “stations only”), address, paper, register, stations and status. At most one printer is active per register; you can only activate a second one after deactivating the first or assigning it to another register. Give the printer a fixed IP address in your router so the register finds it again after a restart. A deactivated printer stays in the list and can be activated again at any time.

For your security VidiPOS only accepts targets in your local network: private IP addresses (10.x.x.x, 172.16.x.x to 172.31.x.x, 192.168.x.x or IPv6 addresses starting with fd) or local host names ending in .local, .lan, .home.arpa or .fritz.box (not names without a dot such as “receiptprinter” — they may point to the device itself), plus the ports 9100 to 9103. The form rejects public addresses, “localhost” and special addresses, and the app only connects if the resolved host name points to a private address as well. A retired register cannot be newly assigned to a printer; an existing assignment is kept. A target saved earlier that no longer meets these rules is marked in the list (“Target no longer allowed”) — the register does not use the printer until you change the target. Every change of a printer’s register, address, port and active state is logged with user and time; the latest entries are shown at the bottom of the page in the collapsed printer target log (“Show log”: time, user, printer, change old → new; for a new printer “created: …”).

If a register has an active printer, the app prints the receipt by itself after payment — with all mandatory details, the TSE data and the verification QR code; if the TSE failed, it says “TSE not available”. If a cash drawer is connected to the printer (tick “Cash drawer connected to the printer”), it opens with the receipt for cash payments, but not for copies and training postings. If the printer cannot be reached, the transaction stays finished and nothing is lost: the app says “Printer not reachable”, shows the QR code of the digital receipt for scanning and offers “Print again”. From the app's archive you can print a copy marked as such with the “print receipt copy” permission.

You set the Font size on receipts and tickets per printer: “normal” or “large”. With “large” the app prints the items of the receipt (quantity, item, amount, below them options and notes, plus a discount) and on the production ticket also options, note and “take away” in double height — easy to read in the kitchen or for guests with weaker eyesight, but it uses more paper. The width of the characters and so the characters per line stay the same (32 on 58 mm, 48 on 80 mm); long item names wrap as usual. Header, total, taxes, TSE data and the closing (X and Z report) stay unchanged, the content of the receipt does not change. The register picks the setting up the next time it loads its data.

The app starts a test print under Settings → Receipt printer (permission “device settings” at least view): it shows name, address and paper width, a ruler line and the special characters € ä ö ü ß. The server itself cannot print because it cannot reach your local network — from the back office the test print therefore goes through a paired device (test print from the back office). Staff with the “printers” permission (edit) may create and change printers; with “view” they only see the list.

Blank slip? Flip the roll

If the test print or the first receipt comes out as a blank slip, the paper roll is almost always in the wrong way round. Receipt printers print on thermal paper: only one side is coated, and exactly this side has to face the print head. Put the roll in so that the paper runs out of the printer from below towards the front (not from the top over the roll), and close the cover firmly. Not sure which side is coated? Do the fingernail test: scratch firmly across the paper with your fingernail — the coated side shows a dark line, the other side does not. The side with the line belongs to the print head. Then repeat the test print in the app.

Switch off Secure Print on the Epson TM-m30III: On this printer (and other newer Epson models) “Secure Print” may be switched on from the factory. The printer then accepts data on port 9100 — the app reports no error — but prints nothing. Switch “Secure Print” off in the printer’s web interface (open the printer’s address in a browser) or with the Epson configuration tool and restart the printer. If the slip still stays blank or the app says “Printer not reachable”, check the printer’s address, port and network (see above).

Test print from the back office

You can also check a printer from the office: Register → Printers & stations, in the row of an active printer the “Test print” button (permission “printers” edit). As the server cannot reach your local network, a paired device of your register prints instead of the server: the dialog lists the devices of the printer’s register (for a printer used only for stations, all devices of the business) with “last seen … ago” and the operator status (“Operator signed in: code” or “no operator signed in”). Devices that reported within the last 2 minutes can be chosen; older ones are shown greyed out below, so you can see which device is not reachable right now. The app must be open on the device (in the foreground) — no operator needs to be signed in, the sign-in screen picks up jobs too. If no device can be chosen: open the app and sign in, then open the dialog again.

After “Send” the back office waits up to 2 minutes until the job is picked up and printed. A device in use picks up the job at once, an idle one within a minute; it prints the test page with the line “test print from the back office” and your name on exactly this printer and reports the result: “Printed.” — or “Printer does not answer” with the device’s text: then check the printer’s address and network, “Secure Print” on the Epson and the paper roll (see above). “The device did not pick up the job” means the device was not open or had no network; the job expires after two and a half minutes and is never printed later. If a blank slip comes out although “Printed.” appears, the roll is the wrong way round or Secure Print is on. The test print is not a receipt and opens no cash drawer; per printer at most one test print every 10 seconds and 10 per hour.

Production tickets per station (kitchen, bar)

In the section Production tickets per station on the same page you choose for each station — kitchen, bar, counter and pastry — “No printer” or an active printer of your business and save with “Save stations”. One printer may print several stations, the printer that prints the receipts at the register as well. Which station gets which ticket is set under Production tickets on the super group, the product group or the item (see Ticket types and rules); an item is printed only when “production ticket” is switched on for the item group and the item. The switch “Kitchen/bar tickets by station” under POS → Settings must be on as well. Every change of the stations is logged with user and time in the printer target log (field “Stations”).

When an operator taps Send in the app (or calls a course), the app prints without further rules one ticket (grouped ticket) per station with a printer, with all sent items of that station — at a table across all transactions of the table together. The ticket shows the station and the table (or “Quick register”) in large print, below it the operator (short code and name) and the time, then per item the quantity and the item, indented the options and the note, “Takeaway” for take-out; with courses switched on the items are ordered by course. It shows no prices — the production ticket is not a receipt and has nothing to do with the TSE; the cash drawer never opens. It prints directly over your local network, so also offline in emergency operation: the ticket does not depend on the server's answer.

When an item that was already sent is voided, the reversing line goes to the station with the next “Send”: it then prints a ticket of its own headed VOID with the voided items and quantities. Tickets for the same printer — say a receipt and a bar ticket on the counter printer — are printed one after the other. If a station printer cannot be reached, sending goes on all the same; the app shows the note “Production ticket Kitchen not printed” (or “Void ticket …”) with Print again and Discard. The app does not repeat the print by itself; the ticket stays in the app's memory until it printed or was discarded after a question — please tell the station about the order another way then. If an assigned printer is deactivated, the assignment stays and the page shows “Printer inactive”; the station prints again once you activate it or choose another printer.

Naming stations freely

The card Stations on the printer page lists the four previous stations (kitchen, bar, counter, pastry) and every station you create yourself — for example pass, grill, meat or service. “New station” opens a dialog with name (German and English, at most 40 characters, unique per business), default printer and the switch Complete ticket for every send: the station then gets an extra ticket with all positions on every send — handy for the pass or the service staff. A station is never deleted, only deactivated; its rules stay, but an inactive station gets no more tickets (the list shows a note). Which printer prints a station in an area is set as before in the matrix printers per area.

Ticket types and rules (inheritance)

There are three ticket types: single ticket — one ticket per position, with quantity 3 three tickets of 1 (switchable per station to one ticket “3 ×”); grouped ticket — one ticket per station with all its positions of the send (the previous behaviour); complete ticket — one ticket with all positions of the send across all product groups. On the super group, the product group and the item you choose under Production tickets one or more ticket types per station, e.g. “Kitchen · single ticket” and “Pass · complete ticket” — the register then prints both. The most specific level with a choice always wins: item before product group before super group. Without a tick a level inherits; the form shows what applies then (“inherited from product group …”). The page Ticket rules shows the whole tree with the tickets in effect. With the switch-over every product group with a station got a rule “station · grouped ticket” — so everything prints as before until you change something. Void tickets follow the same rules. Every ticket carries course, check and the counter “Ticket 2/3” of the station in this send.

Ticket layout and preview

In the dialog of a station you set the layout of its tickets: size of table and check, item line and options and notes (normal, double height, double width, large), quantity bold, course heading as an inverted bar, bold or none, lines between positions and courses, prices (automatic only on complete tickets and at stations with complete ticket, always or never), server and time in the head, device in the footer and the footer itself. The standard layout is preset for every station: table and check large, beside it small time and server, below small “Kitchen · Ticket 1/2”, the course as a black bar, quantity bold and item double height, notes with “!”, voids with a black VOID bar. Wide print fits only half the characters per line, the register wraps accordingly. If a printer cannot print inverted, switch off “Printer can print inverted” — the bars then print bold. The preview in the dialog shows a sample ticket in 58 and 80 mm and redraws on every change (toggle “as void”).

Test print of a station

“Test print of this station” sends, like the test print from the back office, a job to a paired device; the app prints a sample production ticket in the station's layout on its default printer. If an empty slip comes out, the roll is the wrong way round — turn the roll. If an Epson prints nothing although it is reachable, switch Secure Print off on the printer.

Printers per area and receipt per area

Once your business has at least two active areas (e.g. “Restaurant” and “Beer garden”, maintained under “Manage sections”), the stations section of the printer page becomes a matrix: the rows are the stations and finally the receipt, the columns are “Default (all areas)” and one column per area. In the default column you choose the station's printer as before. In an area's column you choose “as default” (the first column applies) or another active printer. Example: Bar default “Counter inside”, column beer garden “Counter outside” — the app then prints drinks for a table in the beer garden at the outside counter and in the restaurant at the inside counter. Desserts can be routed the same way with the pastry station per area.

What counts is the table's area when sending: if a transaction moves to a table in another area, the next send and a void ticket print at the printer of the new area. A table without an area, the quick register and takeaway without a table print at the station's default printer.

The receipt row routes the receipt: choose a printer for an area and the app prints the receipt of a table in that area there (with that printer's paper width and font, also “Print again” and copies). Without a choice and at the quick register the register's receipt printer prints. The cash drawer always opens at the register's receipt printer, even when the receipt comes out at another printer. The assignment applies to the whole business; a register limited to certain areas only uses the columns of its areas. Every change is logged in the printer target log (fields “Stations per area” and “Receipt per area”). The devices take the assignment over once they reload the register (after signing in) and keep it for emergency operation.

Bluetooth printers

VidiPOS cannot print over Bluetooth. A receipt printer that only supports Bluetooth cannot be set up under POS → Printers and cannot be used. This applies to receipts, production tickets and the test print alike.

What you can do instead:

• Network printer on Wi-Fi or LAN: A receipt printer with a network port (Ethernet or Wi-Fi) joins your local network and accepts receipts on port 9100. This is the normal case for VidiPOS.
• ESC/POS Wi-Fi printer: Many receipt printers come in a Wi-Fi version instead of a Bluetooth one. When buying, look for “ESC/POS”, “Wi-Fi” or “network”, and a paper width of 58 or 80 mm.
• Replace an existing Bluetooth printer: If a device has Bluetooth as well as LAN or Wi-Fi, use the network connection. If it only has Bluetooth, you need a different printer.

How to set up a network printer is described above in this section; how to print on the go without your own Wi-Fi is described in Operation on a phone hotspot.

Operation on a phone hotspot

Without Wi-Fi on site — at a festival, a market or a pop-up, for example — you can use a smartphone as a hotspot. VidiPOS needs nothing special for this: the register devices and the network printer together form a small network, and the register looks for the printer in it as in any other local network.

1. Everything on the same hotspot: Connect all register devices and the printer to the hotspot. The printer must be a Wi-Fi printer (see Bluetooth printers); a LAN-only printer needs a small Wi-Fi or travel router that is itself connected to the hotspot.
2. Fixed address for the printer: A hotspot often hands out new addresses when devices reconnect. Set a fixed IP address in the printer, taken from the hotspot's address range. If your hotspot or router allows it, create a DHCP reservation for the printer instead. Enter the same address under POS → Printers. The addresses of common hotspots are in the private range and accepted by VidiPOS (see above); the hotspot settings of the phone show the address range.
3. Test beforehand: Before opening, start a test print in the app (Settings → Receipt printer). If nothing arrives, some hotspots isolate devices from each other (“device isolation”, “client isolation”) — switch this off or use a small router.
4. Battery and coverage: A hotspot uses a lot of power. Connect the phone to a charger or power bank and check mobile reception at the location. If the hotspot drops, the register and the printer are cut off from each other.
5. Internet for the register: The devices also get internet through the hotspot. This uses mobile data (sign-in, sync with the server, card payment, digital receipt), so check your data allowance. Printing itself runs only on the local network and does not need internet.
6. Emergency mode when the internet is gone: If mobile data fails but the Wi-Fi link to the printer stays up, the register keeps working in Emergency mode and prints receipts and production tickets as usual. The receipts are “provisional” and are sent to the server automatically later. If the hotspot itself fails, the app says “Printer not reachable”: the receipt is still finished; tap “Print again” once fixed. Until then, tell the station about orders by word of mouth.

Cash movements and cash book

Any money that enters or leaves the till without a sale is booked in the POS app as a cash movement: the opening float (change in the morning), a cash deposit, a cash withdrawal, an expense (for example a purchase with a till receipt — enter its voucher number), the tip payout to the team, the cash transit to the bank as well as owner deposit and owner withdrawal. You choose the entry type, enter the amount and — for withdrawal, expense, owner deposit, owner withdrawal and custom entry types — a reason. The direction (in or out) follows from the entry type; you always enter the amount without a sign.

A cash movement is a full transaction in the journal: it gets a receipt number from the same sequence as your receipts, is part of the hash chain, is signed by the TSE and can be printed as a cash voucher (“Cash voucher – Expense”) with amount, reason, voucher number, payment type cash and the note “not taxable”. A cash movement cannot be changed or deleted afterwards. If you made a mistake, cancel the movement in the app: the cancellation is a reversing entry with the same amount and the opposite sign, and the original and the cancellation both stay in the cash book. Cash movements are only possible with an internet connection and not in training mode. Operators with the “cash book” permission (edit) may book and cancel them; without it, an approval by a person with the permission helps as everywhere. With “view” an operator sees the day's movements and the expected cash balance in the app.

Under POS → Cash book you see, for a period of up to 366 business days and separately for each register (or for one chosen register), every business day with: the opening balance carried over from the previous day, every cash movement on its own with time, receipt number, entry type, reason, voucher number of the expense, operator and TSE state, the daily cash takings as one summary line (all cash payments of the day's receipts minus change, cancellations negative), the cash tips split into staff and business, and the closing balance. The closing balance is the expected cash: carry-over + opening float + cash takings + cash tips + deposits − withdrawals, expenses, payouts and cash transit. Cash takings include every cash payment of a finished transaction — also a cash payment on an order; it is shown on its own line “other cash takings” so that no cash silently drops out of the expected amount. The daily cash line states the number of receipts and, separately, the number of cancellations. Card payments, invoices, vouchers and deposits are not included (nor their tips), training postings never. With the daily closing (Z report) the cash book also shows the count and the difference; the counted cash is then the carry-over for the next day.

With the additional “exports” permission (view) you download the cash book as a PDF or as a CSV for Excel (columns business day, time, register, receipt no., type, text, voucher no., in, out, balance, operator, TSE). If the period has more than 10,000 rows, shorten it or choose a single register.

Cash entry types

Under POS → Cash entry types you maintain the types that can be chosen in the app. The system types (opening float, cash deposit, cash withdrawal, expense, tip payout, cash transit to bank, cash difference, owner deposit, owner withdrawal) are tied to their business case under DSFinV-K; you can change their name (German and English), the DATEV account for the later export and “active”. Opening float and cash difference always stay active because the daily closing needs them; only the daily closing itself books the cash difference, never an operator. A deactivated type can no longer be chosen in the app, old entries keep it.

You create custom entry types with a kind: deposit (money into the till), payout (money out of the till), owner deposit, owner withdrawal, cash transit out of the till (to the bank) or cash transit into the till (for example change from the bank) — this sets the direction and the business case for the TSE and the export. Once a custom type has been used for a booking, its kind can no longer be changed (name, DATEV account and “active” still can); every booking keeps the name and business case it was booked with anyway. For custom types the reason is always required. Staff with the POS “settings” permission (edit) may create and change entry types; with “view” they only see the list.

Daily closing: X report, Z report and cash count

Every register is closed per business day. The X report shows the running state of the day straight from the journal at any time — it is preliminary and not saved. The Z report is the same report, frozen: it is saved with a consecutive Z number per register, secured against changes by a hash and cannot be changed afterwards. Both reports contain gross and net sales and the tax per tax rate (receipts and invoices, cancellations negative; tips to the business belong to the standard rate and are shown below as “of which tips to the business”), the payment types with count and amount, tips split into staff and business per payment type, card, voucher redemption, applied deposits and “on invoice” as separate lines, discounts on the receipt and on items (also per operator), receipt and line cancellations, sales, receipts and tips per operator, the cash movements by entry type, the cash (carry-over, opening float, cash takings, deposits, expenses, expected cash), the number of guests and the period from the first to the last transaction. Orders and aborted transactions only appear as a count, training postings only as an information line — they are not included in any total.

For the Z closing you count the cash in the till by denomination (notes from 500 € to 5 €, coins from 2 € to 1 cent). The total is the counted cash; the register compares it with the expected cash. If they differ, the closing books the cash difference automatically as a cash movement of this business day (signed by the TSE, with its own receipt number) — after that the expected cash matches the counted cash, and the counted amount is the carry-over for the next day. The count record stays stored with the Z. A closing is only possible when no transaction of that day is still open on the register: otherwise the register lists the open transactions (table, operator, start), and you finish or abort them first. The days are closed in order — an earlier open day first. A second Z for the same day is not possible; the register then shows the existing Z. You can do a cash count (counting without closing) at any time: it shows the difference to the expected cash and appears as an information line in the cash book, but books nothing.

Day lock: after the Z no further transaction belongs to this business day. If a transaction, cash movement or cancellation whose business day already has a Z is finished afterwards, the register books it into the next open business day — with a connection (“booked after the closing”) just as without one (“delivered late (offline)”, if a device kept selling without a connection). This way no paid sale is lost, even if it was started in the minute before the Z. The next Z report lists such transactions with their original day and the reason under “late deliveries and transactions booked after the closing”; reports, cash book and DATEV batch count them on the day they were booked and point them out. Cancelling a receipt from a closed day counts towards today's business day. There is no second Z for a closed day. After the Z the POS app shows the next open business day (the day bookings now go into) in the cash book and the closing; in the archive “Next day” goes up to that day. Aborted transactions appear in the archive on the business day of the Z the server assigned them to (before their Z on the day they were aborted, after the last Z on the running day). Choose the closed day explicitly if you need it. How long a business day lasts and when the hint “closing overdue” appears is explained in the next section.

Counting rules in the report: the count per payment type only counts payments of receipts; payments of cancellation receipts appear separately in the “Reversals” column (the amount includes them as negative). An item discount cancelled before the closing only appears under line cancellations, not under discounts. Cash movements are also counted without their reversals, which are shown separately as “Reversals”. Guests of a table count only on the business day of its first receipt, aborted transactions only on the day they were aborted. Counted later: if you close an earlier day after the register has already taken cash on the following day, that cash is already in the drawer. The Z therefore deducts it from your count (“cash of later days considered in the count”) — the difference only concerns the closed day; the count record keeps the full count. If the Z was triggered on the device with an approval, the approver is shown in the Z report. A retired register can still close its open days in the back office; it books no new transaction — a difference is then only recorded in the Z.

Under POS → Closings you see per register the open business days, the X report of an open day and the Z reports of a period with sales (with “of which employer tips” below it if tips to the business were included — also as a separate column in the CSV) as well as expected and counted cash and difference. If your business is a small business (section 19 UStG), the report carries a note at the top: net and tax per rate are then only a computed split (subject to your tax adviser). The Z detail shows the stored report, the count record, the assigned transactions, the difference posting and the hash check (“unchanged”, also in the PDF and the CSV). X and Z report (page, PDF and app) show the tips per operator in full only with the “POS: tips of all staff” permission — otherwise only those of your own operator and “—” for everyone else; the stored Z is not affected; download it as a PDF for your records, and the list as a CSV with the “exports” permission (view). You can also trigger the Z in the back office (form with denominations) — with the same rules as in the app; a difference is then booked via the most recently active device of the register, and if there is none, close the day in the app. Anyone with the “POS: open/close shift, cash count” permission (view) sees the X report, the Z list and the Z detail; counting and Z closing need it with edit — if it is missing in the app, an approval helps as everywhere.

Business day = open shift (not the clock)

Every register has a switch time (default 05:00, set per register under POS → Registers & devices). It defines when a new business day starts — but only once the previous one is closed. As long as a register's business day has no Z yet, its shift is open: all further receipts, orders, cash movements and cancellations of this register belong to this open business day, even after the switch time. Example: switch time 05:00, the last guest pays at 05:30, the Z is done at 06:00 — the sales from 05:00 to 06:00 count towards the old day, and the Z contains them. The transaction times stay real (in the DSFinV-K export a closing then reaches past the switch time). The new business day starts with the first booking after the Z, by the clock and the switch time; if a table was opened before the switch time (say at 20:00), the day it was opened counts. A device selling without a connection knows the open day from its last connection. A shift only opens with a real transaction — training entries and cancellations do not open a shift.

After the Z the day lock applies as above: a transaction that would fall into the closed day by the clock goes into the next open day and is marked “booked after the closing”. A receipt that a device finished without a connection before the Z and transmitted only afterwards belonged to the closed shift — it is booked into the open day and shown as “delivered late (offline)” with the day of that Z.

Closing overdue: if the open business day still has no Z two hours after the switch time of the next day (with 05:00 from 07:00), the POS app shows operators with the right “POS: open/close shift, cash count” the hint “closing overdue — business day … is still open”, also without a connection. In the back office “Closing overdue since …” appears under POS → Closings and on the page POS → Fiscal below the traffic light. Then do the Z — the closing tab of the app suggests the open day.

Z only when all devices are off shift

When several devices (tablets, phones) work on one register, the Z only closes the business day once all other devices of the register are off shift: no operator is still signed in on any of them, and none still reports bookings not yet sent. For this, every device sends with each call how many rows of its queue have not reached the server yet and since when (transactions refused for good, which are never sent again, do not count). The device on which you run the Z may be signed in; it sends its own bookings first. Otherwise the register shows — in the app as in the Z form in the back office — the list “Still on shift”: per device its name and device number, the operator signed in, the number of unsent rows and since when. Sign the operator out on the device or switch the device on and connect it to the network — once it has sent its bookings, the Z works. A report older than 12 hours, or rows made only after the end of the business day, do not hold up the Z.

Device lost or broken: only then confirm “Confirm lost/broken” per device (in the app after a question, in the back office with the button at the device) and run the Z again. This needs the same permission as the Z (“POS: open/close shift, cash count” with edit; in the app otherwise with an approval). The confirmation is recorded in the operator log with the operator or user, the device, the reported number, the time and the business day, and it ends all sign-ins on that device. If the device later reports new unsent rows, the confirmation no longer counts. If it sends bookings after the Z after all, they are not lost: they go to the next open business day as “delivered late offline”. Independently of this, the X report (app and back office) and the Z form show “Devices of this register” with last contact and reported rows — also devices without a report that have not been in touch for more than 15 minutes (“no contact since …”), as a hint.

Open transactions (shift lead)

A Z closing only succeeds when no transaction of the register is open any more. Sometimes a receipt, a training or an order gets stuck: the device was blocked, the app deleted, a tablet lost, or someone left the settlement without finishing it. So that the shift lead can solve this without help, there is the list “Open transactions” — in the app under menu ☰ → “Cash register” → tab “Closing” and in the back office under POS → Registers & devices → view the register (section below the settings). For each transaction the list shows its kind (receipt, training or order), the table or “without a table”, how long it has been open (e.g. “for 3 h”), the device with number and name (a blocked one too) and when it last reported (“last seen …”), the operator and the open amount. It also lists orders whose positions no receipt took over when settling (note “Settling cancelled — positions not settled”).

• Abort: a receipt or training without a payment can be aborted after a confirmation. The register books an abort with the fixed reason “Abgebrochen durch Schichtleitung” (aborted by the shift lead) into the journal — in the app with the device and the operator who abort, in the back office with your user account (and the operator linked to your account). At the TSE the transaction ends like any abort. A training is discarded this way. Positions the receipt had taken over from an order are not lost: they stay open at the table and then appear in the list as an order.
• With a payment: once a payment is captured or a card payment is running, no abort is possible (the money would otherwise have no receipt). Finish the receipt on the device, or wait until the card payment is booked.
• Unsent bookings: if the transaction's device still reports bookings not transferred, a note stands at the row and in the confirmation — an abort may discard them; switch the device on first if you can. A lost or blocked device does not hold the abort up. On the device itself the app only aborts once its own bookings of this receipt are transferred (“Bookings of this receipt are still waiting on this device — send them first”).
• Open order of a lost device: an order belongs to the device that books it. It can only be aborted here once that device has not reported for at least 15 minutes or is blocked — until then the row says “Device is active — abort on the device” and the button is disabled; abort the order in the device's order pad then. The confirmation asks for a reason (at most 120 characters, suggested “Device lost”) that goes into the journal with your user account; at the TSE the order ends like any abort, and the table becomes free if nothing else is open there. If the device turns up later and still sends bookings for this order, the register no longer accepts them — the device shows them as “not taken over”, nothing is booked silently. Book missing positions again at the table then.
• Order with open positions: it is not aborted but settled — in the app “Open table” leads straight into the order pad of that table, then “Check out”. If it was booked by mistake, void the order's receipt as usual.
• Permission: anyone allowed to edit “POS: open/close shift, cash count” (owner and shift lead) may abort — also other operators' and devices' transactions, without “other staff's tables”. In the app an approval for exactly this transaction helps otherwise. With “view” you only see the list.

When the Z closing refuses with “Transactions still open”, “To the list” (app) or the link in the Z form (back office) leads straight here. Then run the Z again.

“Outages” report

Under POS → Closings → Outages you see the outage log of your registers by business day (at the business day change of each register), filtered by register and period like the Z list: per outage the start, end (or “ongoing”), duration, cause (TSE, internet/emergency operation, server, unknown), the last successful signature before the outage, the number of affected transactions, the reporting device (device no.) and a note, with the total per day below (number and total duration). With the “Exports” permission (view) you download the list as CSV. The Z detail shows the outages of its business day at this register. The report is read-only — anyone who may see the closings can see it.

Reports

Under POS → Reports you analyse the journal for a range of business days (at most 366 days), for all registers or one register and for all operators or one operator. Only finished receipts and invoices are counted, cancellations as negative. Orders, cash movements (deposit, expense, change …) and aborted transactions are not sales; training postings only appear as a separate figure above the tabs and are not included in any total. At the top you see gross sales, receipts, cancellations and the average receipt.

The tabs: product groups (sales per product group and super group after discount — a receipt discount is split across the items exactly as in the journal; net and tax per group are calculated from the gross total per tax rate, the Z report remains authoritative for the tax per rate), items ranked by quantity (top sellers), the active items with the lowest quantity (slow sellers, also those not sold at all) and a favourites suggestion: the best-selling items — as many as you have favourites today, at least eight — and which current favourites are not among them; the favourites themselves are not changed. Line discounts are not items: they are not ranked but appear as a separate row “line discounts” above the total. Further operators (sales, receipts, average receipt, discounts, receipt cancellations, tips), payment types (count without cancellation payments, reversals separately, amount without change and tip, tips split into staff and business), registers, hours (hour the receipt was finished in German time, summer and winter time per point in time), tips per operator and payment type, discounts by type and reason per operator and cancellations (receipt cancellations with reason, line cancellations before finishing). The totals match: product groups, payment types, operators and registers add up to the same sales as the Z reports of those days — without the tips to the business: the Z report counts them as sales at the standard rate (line “of which employer tips”), whereas the reports only list them on the tips tab. Sales in the reports = sales of the Z minus “of which employer tips”.

Anyone with the “POS: reports” permission (view) sees the reports. Items, registers and hours additionally need “POS: statistics & insights”. The tips of other operators only appear with the “POS: tips of all staff” permission — otherwise you only see your own, as in the POS app; this applies to the operators, payment types and tips tabs (for payment types only your own tips are counted, the amount stays complete).

Exports

Under POS → Exports you download CSV files for Excel or your tax advisor (semicolon, German number format; cells starting with = + − @ are neutralised). Choose the period and register, then the area: journal (one transaction per row with transaction and receipt number, type, state, times, operator, gross, tax per rate, training, cancellation, offline, delivered late, TSE state and hash), receipts with items (one row per item with discount share and tax rate), payments, items and sales per group (line discounts as a separate row at the end), Z reports (header per Z with expected and counted cash, difference and hash check, plus the totals per tax rate and payment type) and the cash book.

Journal, receipts, payments and items only contain closed business days — days with a Z report of the respective register. If the period still contains open days, the page lists them with the hint “day not closed yet”; close them first under POS → Closings. A file has at most 10,000 rows: if it would be larger, you get a hint instead of a shortened file — then choose a shorter period or one register. Exports need the “POS: exports (CSV, DATEV, DSFinV-K)” permission (view) and additionally the permission of the area: reports for journal, receipts, payments and items (items additionally “POS: statistics & insights”, like the top/slow sellers view), “open/close shift, cash count” for the Z reports, cash book for the cash book. In payments, amounts are only shown for captured payments — pending, failed or refunded payments carry their status and are not part of any total. Without “POS: tips of all staff”, amount, tip and tip type stay empty for payments of other operators (the amount includes the tip). Below them you find the DATEV posting batch of the POS (next section).

DATEV posting batch of the POS

Under POS → Exports, below the CSV files, you create a DATEV posting batch of the daily takings (EXTF format, posting batch, Windows-1252 with semicolons — the way DATEV imports it). One batch covers all registers: per business day and register a group of bookings with the business day as document date and “Z number – serial number” as document field 1. Only days with a Z report count; open business days are listed with the notice “day not closed yet” and are missing from the batch. Training never appears. Only completed calendar days up to yesterday within one fiscal year can be chosen (shortcuts: last month, the month before, last quarter, current fiscal year). In the cash book, the “DATEV” button (with the exports permission) takes you here with the chosen period, limited to closed days up to yesterday; the batch always covers all registers.

All bookings run through the cash account: revenue per account and tax rate (gross after discount; account of the product group, otherwise of the main group, otherwise the account of the tax rate; cost centre of the product group as KOST1), staff tips to the transitory account, employer tips entered with the payment as revenue at the standard rate of the register's country (19 % in Germany; a separate “employer tip” line on the receipt, by contrast, is ordinary revenue at its own rate), card payments (including tips) to cash transit, vouchers to the voucher liability, applied deposits to advance payments received and cash movements to the account of their entry type (owner deposits and withdrawals, cash transit and cash difference otherwise to the accounts of the settings, a tip payout without its own account to the tips account — tips account to cash; an opening float without an account is not booked and is listed as a notice). Cancellations enter the totals with their sign. Receipts paid by invoice do not create an invoice in the invoicing module; they are booked per receipt (document field 1 = receipt number, so the open item can be settled individually) against the collective receivables account from the invoicing settings (without an entry a 1 followed by zeros up to the account length, 10000 for four digits). If a product group (or main group) has its own revenue account, it may only receive sales of one tax rate — otherwise the preview reports an error. Deposit with guest invoice: if a receipt applies a deposit whose reservation has a (not cancelled) guest invoice, the deposit is already booked there; the preview blocks the batch naming the receipt — clarify the booking with your tax adviser. A payment that refers to an invoice of the invoicing module and cash on a transaction without revenue (order, transfer) are blocked as well.

The page only calculates the preview when you click “Calculate preview” (opening the page alone calculates nothing); the download appears afterwards. It shows the totals per contra account, all bookings and a checksum per Z: the balance of the cash bookings must equal the change in cash of the day (counted cash of the Z minus carry-over). If a case that occurs has no account, or the checksum differs, the preview names case, register and day and blocks the download — nothing is ever booked wrongly without notice. Every download is logged with period, rows, balance and the SHA-256 checksum of the file. Preview and download need the “POS: exports (CSV, DATEV, DSFinV-K)” permission and — because the batch contains Z totals and cash movements — additionally “POS: open/close shift, cash count” and “POS: cash book” (view each). Transactions booked after the closing of their day or delivered late offline are named as a note on the day they were booked.

Rounding and small businesses — please agree with your tax adviser: the batch books revenue per product group and rate gross after discount; DATEV calculates the VAT via the tax key per booking. It can therefore differ by a rounding cent per booking from the tax per rate in the Z report (the Z calculates per receipt); the preview mentions this below the bookings. If the end date is after yesterday, the page computes no preview but tells you that the period can end yesterday at the latest — with a link “Compute preview up to …”; it never shortens the period silently. If your business is a small business (section 19 UStG), the page shows a note: the batch still books the revenue as calculated per tax rate — your tax adviser clarifies whether the accounts and tax keys fit (subject to your tax adviser).

You maintain the accounts under POS → DATEV (“POS: settings” permission): adviser and client number, fiscal year, chart of accounts (SKR03/SKR04), account length and locking — prefilled from the invoicing module but stored separately — as well as cash, cash transit, tips, owner deposit and withdrawal, advance payments, voucher liability, cash difference and revenue per tax rate. Voucher and cash difference deliberately have no default. All defaults are suggestions: agree the accounts with your tax adviser before you hand over the first batch.

Settings: POS features

Under POS → Settings (tab “Features”) you switch individual POS building blocks on or off for your business: courses (assigning items to a course), kitchen/bar tickets by station, floor plan, split bill, discounts (manual discounts on the receipt and on items — redeeming vouchers always remains possible, as does a discount carried over from the order; a free price on an item is not a discount and depends on the permission “misc items & open price”), invoice and hospitality receipt (payment type “on invoice”), cash movements on the device (deposit, withdrawal, expense and cash book in the app), digital receipt (link/QR code for the guest) and Order & Pay (takes effect with the module of that name). Next to “Features” you also reach the entry types and the DATEV settings.

A switched-off block disappears from the POS app at the register's next sync and is additionally rejected by the server — also for data a device delivers late after emergency operation, and also when a manager grants an approval: an approval raises permissions but never switches a feature on. If a device delivers a still open transaction using a switched-off block, the server only refuses exactly that transaction; all other transactions of the sync are booked. A transaction that was already completed during emergency operation is accepted, though, if you switched the feature off — the sale took place and the record must not be lost. If the feature is locked by your plan, this only applies to transactions started before the last plan change; later ones are refused. The journal shows the note “Delivered late … a feature that has since been switched off” on an accepted transaction; VidiReserve sees the number of such transactions of the last 30 days. Switching the digital receipt off only affects new receipts: they carry no link; links of receipts finished before stay valid (revoke a single link in the journal). The link of a receipt finished while the digital receipt was off does not open later either (the page reports “not found”). Daily closing (X and Z report) and the cash count can never be switched off. Cancelling cash movements remains possible so that mistakes can be corrected.

Plans: if your business has a VidiPOS plan (for example “Bar” or “Counter till”), it sets the defaults. Features your plan does not include are shown with the note “not in your plan” and cannot be switched on (for “Bar”, for instance, courses). When the plan changes, only switches you have never changed yourself follow it; your own changes stay (marked “changed by you”). Removing the plan never switches on a switch you turned off yourself. Without a plan everything can be switched freely — existing businesses keep working unchanged. The number of devices included in the plan is shown; booking, extra devices and billing are described under Subscription.

Employer tips: under Tip type per register you decide who receives the tip recorded with a payment at a register: the staff (AN) — not taxable, the default — or the business (AG). Devices take over the setting the next time they load the register; payments already recorded keep their type. The POS reports tips to the business to the TSE at the standard rate and books them as revenue at the standard rate in the DATEV batch. This is an assumption — please have it confirmed by your tax adviser. Anyone with the “POS: settings” permission (view) sees the page; staff with “edit” may change it.

Subscription: prices per till, cloud TSE, term, devices and cancellation

Under POS › Subscription the owner of the business sees its VidiPOS subscription — other staff do not see this item, not even with all POS permissions. VidiReserve books the subscription; the booking freezes the plan, base price, included devices, price per extra device and the features of the plan. Later price changes of the plan do not apply to your subscription. New bookings no longer have an introductory price. If a subscription was booked with an introductory price, it is shown with the note “Introductory price, secured permanently” and stays for the whole term.

Prices and terms: all prices are net plus statutory VAT. The price of a plan applies per till — a till is one recording system with its own TSE (for example the till of one location). Devices are the input devices on this till (tablet, smartphone): Gastro and Bar include three input devices, each additional one costs €19.90 per month; the counter till has exactly one device. The subscription page shows the values frozen with your booking.

Cloud TSE, fiscalisation & digital receipt: besides the software there is a second, separately shown item — €199.00 net per till and year, billed yearly in advance from the activation of this till’s TSE. It covers the TSE signature, the DSFinV-K export, the fiscal archive, the preparation of the till registration, the receipt with verification QR, the digital receipt (receipt page and PDF) and the receipt by e-mail. Every till with an active TSE gets its own invoice line “Cloud-TSE, Fiskalisierung & digitaler Beleg (je Kasse, 12 Monate) — Kasse <name> (<serial number>), <period>”; the next one follows a year later. A test TSE (training mode) is never charged, nor anything before your subscription starts. The yearly price is frozen with the booking for the booked term. The subscription page shows the price, the number of tills with an active TSE and the date of the next annual invoice.

Term of 12 or 24 months: with 24 months this is also the minimum term. If you choose 24 months in advance, the software appears once as one invoice line “Software 24 Monate, 2 Monate Rabatt” (software 24 months, 2 months discount) — 22 monthly prices are charged; during these 24 months there is no monthly software line, extra devices are still billed monthly and the cloud TSE yearly. After the booked term the subscription renews for 12 months, billed monthly; 24 months in advance only if you expressly choose it. Price guarantee: the price applies for the booked term. An adjustment is only possible due to legal requirements or changed costs of the cloud TSE and is announced for the renewal.

One-off services: on request there is a personal onboarding for €99.00 net (video appointment: till setup, menu including import, operators, printers, first closing, training) and an on-site setup by arrangement. They appear as a separate item on the next invoice.

Billing: the software of the POS module is billed monthly in arrears — as a separate invoice next to your VidiReserve subscription, with its own items: base price and, if booked, extra devices. The first month is charged per day (start to end of month), every later calendar month in full. Extra devices cost the full monthly price for every started month. The invoices are listed on the subscription page and arrive by e-mail like your other invoices. Without a VidiReserve subscription (or with a subscription exempt from billing) no invoice is created for the month, and the month is not charged later either. If a monthly invoice is cancelled, the next billing run reissues the month. If a subscription starts in the future, the plan and the device quota apply from the start date. A new subscription after one that ended starts the day after its end at the earliest; a business gets an introductory price at most once.

Devices: every subscription includes a number of devices (for example three). If you need more, enter the number under “Extra devices”. More devices apply immediately and count in full for the current month. Fewer devices apply from the end of the month; no more devices may be paired than are then allowed — otherwise the page asks you to unpair devices first. While a subscription is running, another device can only be paired if the quota (included + extra devices) has room; the page POS › Registers & devices shows the status before you create a pairing code, and the app otherwise reports “device quota reached”. The pairing code stays valid until an extra device is booked or another device is unpaired. A requested reduction already counts for the quota from the request. If more devices are still paired at the end of the month than the new number allows, the reduction is not applied (history: “Reduction … not applied”) — unpair devices first and reduce again.

Cancellation: a cancellation always takes effect at the end of a month, at the earliest at the end of the minimum term (for example twelve months from the start). You can cancel at any time, but it only takes effect on that date; an earlier date is refused. You can withdraw the cancellation until that date. The month of cancellation is the last month billed. Afterwards the subscription ends; your POS data and feature settings are kept. A change of plan is made by VidiReserve; a change to a smaller plan is not possible during the booked term.

VidiPOS access: partner.vidipos.com

You reach the POS back office at partner.vidipos.com. It is the same application as partner.vidireserve.com: the same account, the same business, the same data — only in the VidiPOS look. On partner.vidipos.com the POS menu group sits at the very top, and after signing in owners land directly on POS → Registers & devices; reservations, guests and all other areas follow below as usual.

Signing in: a sign-in applies per address. If you switch between partner.vidipos.com and partner.vidireserve.com, sign in once on each — with the same credentials. A passkey (sign-in with fingerprint or face recognition), however, only works on the address where you created it; create one on both addresses if you need it. Signing in with Google or Facebook is not available on partner.vidipos.com.

Registering: at partner.vidipos.com/registrieren you create your account and business and choose your plan (Gastro, Bar or Counter POS). A link from the pricing page on vidipos.com preselects the plan. Once you have confirmed your email address and created the business, the POS is activated for you, and the chosen plan determines which features the POS shows. The plan is noted, not booked: no invoice is issued until we book the subscription together with you (section Subscription). The trial runs as with every registration.

First steps: after the business has been created, VidiPOS takes you straight to the Set up POS assistant (section Setup assistant). Only once it is complete can the POS be armed.

Emails: a business registered via VidiPOS receives its emails from VidiPOS — confirmations, staff invitations and digital receipts carry the VidiPOS sender name, logo and links, even while someone is working on partner.vidireserve.com. Links in these emails lead to partner.vidipos.com.

Setup assistant: set up POS

A business that registered itself via partner.vidipos.com sets up its POS with the POS → Set up POS assistant. Until it is complete, the whole POS area shows the notice “POS not set up yet — open assistant”, and arming is blocked: the TSE cannot be created, no register can be commissioned, no register notification can be prepared, and we can only book the subscription afterwards. The assistant shows the progress at the top; you can pause at any time (“continue later”) — all entries are kept.

1. Business and tax details: taxpayer (company with legal form, or person), tax number in the 13-digit ELSTER format, VAT ID optional, address and business premises. It is the same form as under POS → Register notification — the details then appear in both places.
2. Register and location: each register with name and business day change, plus its acquisition date (not in the future). It later goes into the register notification; the commissioning date is set by the register itself when arming.
3. Plan and devices: your plan from the registration is preselected (Gastro, Bar or Counter POS), with net price, included devices, price per additional device, minimum term and the yearly item cloud TSE, fiscalisation and digital receipt. You confirm the plan and the number of additional devices — noted, not booked.
4. Operators and roles: create the three POS roles (section Permissions and POS roles) and at least one operator with a PIN (section Operators and PIN).
5. Printers and payment methods (optional): receipt printers and default payment method per register — or “set up later”.
6. Terms, DPA and payment method: you accept the terms when you first sign in; here you agree to the data processing agreement in its current version and choose the subscription's payment method (bank transfer on invoice or card/SEPA). Version, time and person are logged.
7. Summary: all steps with their status; once all required steps are green, release the POS with “Arm the POS”. Then continue on the familiar paths: set up the TSE (POS → Fiscal), commission the register (POS → Registers & devices), register notification (POS → Register notification); we book the subscription with you.

After the release, plan and consents are fixed in the assistant; you then make changes on the respective POS pages. Businesses that used the POS before the assistant existed are not affected.