Skip to content

Cash Shift Flow

Published: · Updated: (12 days ago)· IZI Team

A cash shift in IZI is the operational period owned by one admin — from clicking “Open shift” to clicking “Close shift”. Every balance top-up, refund, operation-article entry, and cash movement is grouped inside that period. At close, IZI builds a final Z-report broken down by payment method (cash, card, app) that the admin reconciles against the physical register. IZI supports multiple parallel registers simultaneously — cash, POS terminal, and online acquiring are tracked separately and consolidated into a single shift report. For owners this means clean accountability per shift and per admin; for admins it means a single dashboard that shows the live register balance at all times.

A shift is an operational container for all financial events in the club during a working period. Technically it is a database record with a status of OPEN or CLOSED, an opening timestamp, a closing timestamp, the ID of the user who opened it, the ID of the user who closed it, the opening cash amount, and the final closing amount.

Shift lifecycle:

  1. Opening — the admin clicks “Open shift”. From that moment all club transactions are tied to the current shift. The float (opening cash amount) is calculated automatically as the balance left from the previous shift, or entered manually when opening for the first time.
  2. Active shift — the dashboard shows real-time metrics: revenue, refunds, register balance, payment-method breakdown. Everything updates via subscription (WebSocket); no page refresh needed.
  3. Mid-shift cash collection — if cash needs to be removed before closing, use the “Cash collection” operation. The collected amount is recorded as a transaction and subtracted from the register balance; the shift stays open.
  4. Closing — the admin clicks “Close shift”. IZI shows the final breakdown; the admin optionally adds a comment and confirms. The shift moves to CLOSED status and its data moves to history.

Shift rotation. A shift cannot stay open for more than 24 hours. If a transaction is attempted on a shift older than one day, IZI prompts the admin to confirm rotation: the old shift closes automatically and a new one opens immediately. If the club has a fixed auto-rotation time configured, a background process closes and opens the shift without any admin action.

IZI tracks three parallel payment sources, each with its own balance and transaction history:

SourceHow it enters the registerWhat appears on the dashboard
CashAdmin accepts payment and records a top-upRevenue, refunds, register balance
Card (POS terminal)Payment through the club’s acquiring terminalRevenue and refunds by card
App (online acquiring)Customer pays through the mobile appRevenue and refunds through the gateway

On the shift dashboard the three blocks are shown visually. When the shift closes, IZI builds a total for each source and an overall “Register total” — the sum of cash and card, which should match the fiscal Z-report. App payments appear as a separate line “from app (not in fiscal register)” because they go through the payment gateway, not the physical register, and are therefore excluded from the Z-report.

Float. Cash in the register at shift open = physical bills in the drawer for giving change. IZI calculates it automatically: the previous shift’s closing balance minus any cash collections. If this is the first shift or the register was fully collected to zero, the opening amount will be zero — that is expected.

Cash collection. To move cash to a safe or hand it to a courier mid-shift, use the “Cash collection” operation on the dashboard. Enter the amount (full or partial) and add a comment. The operation immediately reduces the register balance and is recorded as a transaction inside the current shift.

IZI breaks receipts down by payment method (section “Shift” → Payment methods):

MethodWhat is included
CashBalance top-ups in cash, direct cash payments for sessions
CardCard payments through the club terminal
AppPayments through the IZI mobile application
BonusCustomer bonus-balance debits (not money)

Most revenue arrives through balance top-ups rather than direct session payments:

  1. Customer tops up balance → cash enters the register
  2. Customer starts a session → balance is debited → revenue is recorded

This means: register balance ≠ shift revenue. If a customer tops up 100 and spends 60, the cash revenue = 100, but session revenue = 60. The remaining 40 is a liability to the customer (their balance).

Operation articles are custom categories for manual income and expense entries that are not directly connected to gaming sessions or balance top-ups.

Examples:

  • Income: “Merchandise sale”, “Room rental”, “Supplier overpayment returned”
  • Expense: “Beverages purchase”, “Cleaning supplies”, “Advance payment to staff”

Each article is configured in Settings → Operation articles:

  • Type: Income (INCOME) or Expense (EXPENSE)
  • Name up to 60 characters
  • Articles can be archived — they disappear from the selection list but remain in history

When an admin records an operation, they select the article, specify the register, enter the amount, and must add a comment. The operation is tied to the current shift and appears in analytics as a distinct transaction type. This keeps gaming-session revenue separate from overhead expenses when analyzing shift results.

Operation articles are configured at the club level and are not shared across clubs in a network — each club maintains its own categorization.

Correct shift handover in three steps:

Step 1 — Count cash before closing. The outgoing admin counts the physical bills in the register. The amount must match the “Register balance” shown on the IZI dashboard. If there is a discrepancy, find the cause before closing (a missed cash collection, an unrecorded operation article).

Step 2 — Close the shift with a comment. The close modal shows the final breakdown: cash, card, app, and overall total. The admin adds a comment (optional but useful for post-incident analysis) and confirms. If a fiscal register is connected, the system compares IZI totals against the register’s internal counters and warns of any mismatch.

Step 3 — Open a new shift. The next admin clicks “Open shift”. The float transfers automatically — it is the cash balance remaining from the previous shift. The incoming admin should verify that the physical cash in the drawer matches what the system shows.

Every shift in history carries the names of the admin who opened it (openedByUser) and the admin who closed it (closedByUser), the timestamp, duration, and financial totals. This is the primary tool for reconstructing incidents after the fact.

Both reports apply only to registers with a connected fiscal register (KKM). Without a fiscal register the X-report button is unavailable.

X-reportZ-report
When generatedAny time during an open shiftAt shift close
What it showsInterim fiscal register counters at the current momentFinal fiscal register counters for the entire shift
Effect on countersCounters are not resetFiscal register counters reset to zero
Shift after the reportRemains openCloses
Typical useMid-day check when running multiple shiftsMandatory procedure at each shift close

X-report — “look inside the register without closing it”. Useful for an interim reconciliation if multiple shifts run in a day or the admin wants to confirm that the fiscal register and IZI agree before the end of the working day.

Z-report — the final shift document. After it is generated the fiscal register counters reset and start from zero for the next shift. The Z-report figures match IZI’s “Register total” (cash + card). App payments are not included in the Z-report.

Important: if the shift included app payments, the IZI “Overall total” will be higher than the Z-report total by exactly that amount. This is not an error — IZI highlights this with a dedicated block at shift close.

IZI supports two modes of working with register hardware:

Receipt printer mode. A standard receipt printer (non-fiscal) is connected. Receipts are printed but not transmitted to the tax authority. Used in jurisdictions where fiscalization is not required, or temporarily while a full fiscal register is being set up.

Fiscal register mode (KKM/KKT). A fiscal register is connected through KkmServer — an agent running on a Windows machine at the club. IZI sends commands to the fiscal register on every payment and refund; the register prints a fiscal receipt and transmits data to the fiscal data operator (FDO), which forwards it to the tax authority. Integration is configured in Settings → Register (KKM).

The connection status is visible on the dashboard: if KkmServer is unreachable or the fiscal recorder does not respond, IZI shows a warning with recovery instructions. You can still process operations when the fiscal register is offline — the system stores a “receipt not printed” flag and lets you reprint the receipt later.

The shift history is the primary tool for after-the-fact control. Each shift in “Shift history” expands into full metrics: revenue by category (sessions, bar, combo), refunds by payment method, bonus activity.

Things worth checking regularly:

  • Register balance discrepancy. If the physical cash does not match the “Register balance” at close, that is a signal. IZI records the discrepancy in the shift comment.
  • Unusual operation-article entries. Large expenses with no comment, or an atypical article — worth clarifying with the admin.
  • Unclosed shifts. A shift older than 24 hours means either auto-rotation is not configured or the process is not being followed.
  • Filter by admin. The shift history has a filter by employee — you can see all shifts for a specific person over any period.

Transactions within a shift are available in the “Transactions” section linked to the shift ID. Searching by cashShiftId isolates all operations for a specific period.

DiscrepancyLikely cause
More cash than reportedPayment received outside IZI (cash taken without recording in the system)
Less cash than reportedChange given incorrectly, lost receipt, refund processed outside the system
Card total higher than expectedDouble terminal swipe without a corresponding refund

All discrepancies are investigated through the transaction history.


Related: What is IZI · Staff roles and permissions · Analytics and reports · Tariffs and pricing · Top-up bonus program

Frequently asked questions

What is a cash shift in IZI?

A cash shift is the operational period during which one admin is responsible for all club transactions. The shift opens when the admin clicks 'Open shift'; from that moment IZI groups all top-ups, refunds, and cash-register operations under that period. Closing the shift produces the Z-report and resets the counters for the next admin.

How do you open a shift in IZI?

On the shift dashboard, click 'Open shift'. IZI starts the timer and begins tracking transactions. If the previous shift has been open for more than 24 hours, IZI offers automatic rotation: the old shift closes and a new one opens immediately.

What goes into the Z-report?

The Z-report is built when the shift closes and includes: cash total, card total, combined revenue, refunds, and the register balance at the moment of closing. App payments appear as a separate line — they go through the payment gateway, not the fiscal register, so the fiscal Z-report and the IZI shift total may differ by the amount of app payments.

Can you run multiple registers at the same time?

Yes. IZI supports parallel registers: cash, card acquiring (POS terminal), and online acquiring through the app. Each register maintains its own balance and its own transaction history. On the shift dashboard they appear as three separate blocks: Cash, Bank cards, and App.

What are operation articles?

Operation articles are custom categories for manual income and expense entries — for example, 'Consumables purchase', 'Customer refund', or 'Advance payment'. Each article has a type (Income or Expense) and is linked to a specific register. When recording a payment the admin selects the article, enters the amount, and must add a comment.

How do you hand over a shift between admins?

The outgoing admin closes the current shift — IZI shows the final payment-method breakdown and offers a comment field. The next admin opens a new shift. Each shift records who opened it, who closed it, and the cash amount at opening (the float).

What happens if someone forgets to close a shift?

Shifts live for a maximum of 24 hours. When that time is up, IZI prompts for rotation on the next operation, or closes the shift automatically via a background job if the club has an auto-rotation time configured. All transactions are saved in the history of the shift in which they were processed.

Can you reverse an operation after the shift is closed?

Transactions are saved in history and are always visible in the shift history section. You cannot modify a closed shift — this guarantees financial report integrity. If an erroneous operation occurred, correct it with a reverse operation (refund or expense article) in the current open shift.

How does IZI enforce cash discipline?

IZI automatically tracks every cash movement: each cash top-up is tied to the open shift, cash collection is recorded as a separate transaction and subtracted from the balance. Register balance = sum of all cash receipts minus sum of all collections. At shift close the system shows the expected balance for the admin to verify against the physical count.

How are refunds and reversals processed through the register?

Refunds are processed through the customer card or directly via the transaction. The refund amount appears in shift metrics as a separate line (Refunds) broken down by payment method. When a fiscal register is connected, a refund receipt is printed automatically.

How are card and cash revenues tracked separately?

Each payment method goes to its own register with a separate balance. Cash register = physical money in the drawer. Card register = turnover through the POS terminal. Online register (app) = payments through the payment gateway. At shift close IZI shows a total for each and warns you that app payments will not appear in the fiscal Z-report.

Where are bonus payments shown in the shift flow?

Bonus payments are not cash — they are a debit of the customer's bonus balance. They do not increase the register total but are included in accrual-basis revenue. In the payment methods block, bonuses appear as a separate line.