---
title: "Registers"
---

> 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.

# Registers

A register is one till. Before anyone can sell, an administrator creates the register under
**Point of Sale → Registers** and binds three things to it:

- **Warehouse** (and optionally a location inside it) — where sold stock is taken from. Every
  completed ticket immediately decreases on-hand there; every refund puts it back.
- **Cash account** — the Treasury account that represents the physical drawer. When a session
  closes, the takings post as ordinary treasury receipts — one per payment method, for each
  invoice the shift settles into (the day's walk-in invoice, plus one per named customer) — and
  each method's share goes into **the treasury account that payment method names**: card money
  into the card method's account, mobile money into its own. Only methods that name no account of
  their own — cash, typically — post here, into the drawer. That split is what lets this account
  reconcile against the physical cash count while the card account reconciles against the bank
  statement.
- **Price list** — where the register looks prices up. A register with no list of its own sells
  from the organization's default list instead; whichever list applies, a product that list does
  not price falls back to the product's own base price. (The organization default is the
  *alternative* to the register's list, not a second place to look after it.) Tip: dedicate a
  retail price list to your registers so shelf prices stay independent of your B2B pricing.

Two switches shape how the register behaves:

- **Tax-inclusive prices** (on by default). The Algerian retail norm: the price on the shelf is
  what the customer pays — 119.00 DA means 119.00 DA. Beelocity works out the tax share inside
  that price for your reporting; nothing is added at the counter.
- **Sell without stock** (off by default). When off, a sale that asks for more than the system
  has on hand is refused with a clear message. When on, the sale always goes through — useful
  when the shelf sometimes holds stock the system hasn't caught up with — and the difference is
  found later during cycle counting.

**Maximum discount** (0% by default) is the largest discount a cashier may key into a line at this
register. Leaving it at 0 means no discounting at the till at all, which is the safe setting for
most shops: a discount is money out of the drawer with nothing to show for it, and a till that can
give 100% off can give the goods away. Raise it only for registers you want to trust with
give-aways — and note that every discounted ticket is recorded in the audit trail with the
discount named, whatever the ceiling.

Some products are simply not sellable at a register and are refused with a clear message: a
product that comes in **variants** must be sold as a specific variant, and **bundles** and
**service/virtual** products have no goods to hand over.

The **Registers** list narrows on its **filter button** by **Warehouse**, **Price List**, **Cash Account**, **Tax-inclusive prices**, **Sell without stock** or **Active** ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).

You can also give each register a **receipt footer** — a line or two printed at the bottom of
every customer receipt (opening hours, return policy, a thank-you) — and a **receipt language**:
the language customer receipts print in at this register, whatever language the cashier reads
the till in. Left unset, it follows your organization's document language. A till whose cashier
works in Arabic can still hand every customer a French slip, or the other way round — the receipt
belongs to the shop, not to the shift.

A register that still has an **open session cannot be deactivated or deleted** — close the
session at the terminal first. For the same reason, while a session is running you cannot change
what the register is bound to: its warehouse, location, price list, cash account or tax-inclusive
setting. Changing any of those halfway through a shift would settle the session against something
other than what the cashier was actually selling. Everything else — the name, the receipt footer,
the receipt language, the discount limit — can be edited at any time.

The **price list and the cash account must be in the same currency**. Beelocity refuses the
combination when you save the register, rather than letting the till sell all day and then fail at
closing time.

That currency — the cash account's — is also how the back office reads the register's money:
every float, expected, counted and over/short figure on the sessions and tickets pages is shown
in the register's own currency, even when the organization's default is a different one. The
dashboard cards that add several registers together use the one currency all registers share;
with registers in mixed currencies those totals fall back to the organization default.

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