---
title: "Sessions"
description: "A session is one cash-drawer shift on one register: it starts when the cashier opens the drawer with a float, records every ticket sold in between, and ends with a counted drawer."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sessions

A session is one cash-drawer shift on one register: it starts when the cashier opens the drawer
with a float, records every ticket sold in between, and ends with a counted drawer. Each register
can have only one open session at a time.

## Opening

At the terminal, the cashier opens a session by entering the **opening float** — the cash placed
in the drawer to give change (for example 5,000 DA). They can itemize it by denomination (how
many 2,000-DA, 1,000-DA, 500-DA notes and so on); the breakdown must add up to the float.

## During the shift

Every sale, refund and void is recorded against the open session. You can peek at the takings at
any time with the **X-report** on the session page — the same summary as the closing Z-report,
taken mid-shift.

## Closing and counting

Closing ends the till's day, so it also ends whatever is still sitting on its counter: any
[tickets still open](./terminal.html#several-customers-at-once) and unpaid are thrown away with the
shift. The closing screen says how many there are, so they can be rung up or discarded on purpose
rather than by surprise.

To close, the cashier counts everything in the drawer (float included) and enters the total —
again with an optional note-and-coin breakdown. Beelocity then computes the **expected cash**
from the recorded tickets:

> expected cash = opening float + cash taken on sales − change given − cash paid out on refunds
> \+ cash paid in mid-shift − cash paid out mid-shift

Only cash affects this figure — card takings never sit in the drawer. (A cheque cannot be taken
at the till at all: the register has nowhere to record the instrument number, so it asks you to
invoice the customer instead.)

**Cash can move mid-shift without waiting for the close.** Banking takings to the safe, topping
up the float, paying a courier from the till — record it at the terminal under **Move cash** on the ⋯ menu,
with the amount and a reason. The expected figure follows the movement immediately, so a safe
drop never reads as a shortage at close. A movement is never edited afterwards: correct a
mis-keyed one with a movement in the other direction, and the shift's story stays complete. The
register refuses a payout larger than what the drawer holds.

Before you commit, the till shows what the tickets expect the drawer to hold and the difference
your count makes, updating as you type. If the two do not agree, the button asks you to review the
shortage or overage before it will close the shift — recounting costs nothing, and the figure that
gets recorded cannot be revised afterwards. A drawer that balances closes in one click.

The difference between the count and the expectation is the **over/short**: positive means more
cash than the tickets explain, negative means missing cash. It is stamped once at close, kept
forever, and shown prominently on the session page — a drawer that is repeatedly short is the
classic signal to review till procedures. A closing note lets the cashier explain a discrepancy.

## Settlement — automatic

Closing also **settles** the session, with no manual posting:

- One **sales invoice** covers the day's anonymous (walk-in) sales, with refunds already netted
  in. Tickets sold to a named customer get their own invoice on that customer's account. The
  invoice matches the tickets **to the centime** — what the drawer collected is what the
  document says — and a discount given at the till appears on it **as a discount**, not as a
  quietly lowered price.
- **One treasury receipt per payment method, for each invoice** the shift settles into. Each
  method's share posts into **its own treasury account** — cash into the register's drawer
  account, card into the account the card method names — and pays those invoices off, so they
  land fully paid.
- When a return outweighs the day's sales of that product — someone brings back yesterday's
  purchase and buys nothing similar — the difference cannot sit on an invoice, so Beelocity
  writes a **credit note** for it against the same invoice.
- A named customer returning an earlier day's purchase gets **their own credit note, on their own
  account**, whatever else the shop sold that day. Their statement then reads the way the shift
  actually went: the purchase invoiced, the return credited back.
- Whatever a return is too big for the day's sales to absorb, the cashier still physically
  handed back — so that part is recorded as **money paid out against the credit note, from the
  account it actually left by**: a cash refund out of the register's cash account, a refund put
  back on a card out of the card method's account. Each account keeps matching what really
  crossed the counter.
- A sale **paid by card and refunded in cash the same shift** cancels out on paper but not in
  money: the card payment is still on its way from the bank while the cash left the drawer. The
  close writes both sides anyway — the sale invoiced and **each payment method's share banked
  into its own account**, the return credited and its payout recorded — so every account keeps
  matching what actually happened. That holds even when the sale was split across methods: a
  purchase paid 60 by card and 40 in cash then refunded in cash banks the 60 and the 40 where
  each belongs and pays the refund out of the drawer, rather than lumping everything onto one
  method. Only when the refund went back **the same way the money came in** (card sale, card
  refund) is there truly nothing to record, and then nothing is.

The session page links to its invoice, and the invoice links back to the session.

Once a shift is closed, it is closed everywhere. The till goes back to offering **Open session**
straight away, whichever way the cashier leaves the closing summary — the **Closed** button or the
**View Z-report** link beside it.

## When a close does not finish

Closing has two halves: the drawer count (instant) and the settlement above. If the settlement
half fails — usually because something in Sales or Treasury is misconfigured — the session stops
at **Closing**. Nothing is lost: fix the cause and close again, and it picks up exactly where it
stopped.

The till says so itself. A register whose shift is stuck at Closing does not offer to open a new
one — it explains that the shift was counted but its paperwork did not finish, and offers
**Finish settling**. That asks for no recount: the count already taken is the record of a count
that really happened, so it stands, and only the paperwork is retried. If it stops again, the
reason it gives is the thing to fix.

A session left in Closing keeps its register busy, so no new shift can start on it. If closing
again keeps failing and you need the register back, a manager with the force-close permission can
open the session page and click **Closed** on the shift's status line — the row across the top of
the page that reads **Open · Closing · Closed** and shows where the shift has got to. It asks for
a reason, keeps that reason on the session forever, gives up on the rest of the settlement, and
frees the register — so anything the settlement had not written yet has to be entered by hand in
Sales and Treasury. It is a last resort, and it cannot be undone. Without that permission the
status line still shows the whole shift, and Closed is simply not a button.

## The Z-report

The **Z-report** is the shift's closing summary, computed live from the recorded tickets: totals
by payment method, by tax rate and by product category, plus ticket counts and the over/short.
Print it, file it, or read it straight from the session page.

The breakdowns by tax rate and by product category price what was **sold** — the goods on the
tickets. Cash rounding is not part of any of them: it is the few centimes a cash ticket is nudged
by so the customer can actually pay it. The bottom of the by-tax-rate table therefore reads down
in three steps — **Gross takings**, plus **Cash rounding**, equals **Net takings** — and net takings is the
figure that matches what the payment methods collected. On a shift with no rounding the middle
line is simply zero and the two ends agree.

## Finding a shift

The **Sessions** list narrows on its **filter button**: **Status**, **Register**, **Opened by**, **Closed by**, an **Opened** / **Closed** date window, or a range on the float, the expected and counted cash or the **Over / Short** figure — "which shifts were short last week" is `Over / Short` below zero with `Closed` in the window ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)). A register's own page lists its shifts on the **Sessions** tab with the same filters, and a session's tabs narrow their tickets by **Type** and **Status**, the cash counts by **Count**, the cash movements by **Direction**.

## What is kept on record

Everything the till does is recorded for later review, and so is everything anyone reads from it:
opening and closing a shift, each sale, refund and void, the Z-report someone printed, the daily
takings someone looked up. Settlement's own paperwork — the invoice, any credit note, and money
paid back to a customer — is recorded the same way, naming the shift it came from. Managers
with permission read all of it from the audit trail.

Source: https://docs.beelocity.com/en/pos/sessions/index.mdx