The counter
Selling face to face, on the same records as everything else
Akkad is an operations platform built around inventory, and the counter is one of its surfaces — not a separate product, and not the headline. A sale rung up at the till becomes exactly the same order record as a storefront checkout: same statuses, same pricing rules, same effect on stock. What this page describes is the extra machinery a physical counter needs on top of that: a drawer that has to balance, a scanner that has to be fast, and — in a restaurant — a floor of tables that have to stay straight through a service.
Plenty of products lead with the till. Akkad does not, because a till is the narrowest possible view of a business: it knows what was sold in the last eight hours and nothing about what you own, what you paid for it, what is expiring, what a courier is holding, or what a customer still owes. The counter here is a way into the same order book that the storefront, the landing pages, the delivery desk and the reports all read from.
The practical consequence is that nothing has to be reconciled between systems, because there are not two systems. A counter sale deducts stock through the same path a website order does. A pricing rule you wrote for in-store only is evaluated by the same engine that prices your storefront cart. A shift that closes at ten in the evening feeds the same annual money box that a bank transfer received at noon feeds. There is no nightly export, no matching job, and no window in which the two disagree.
One order book, seen from the counter
Four things stay identical between a counter sale and every other kind of order. They are worth stating plainly, because they are what makes the rest of the platform usable by a shop that also sells online.
A counter sale is a source, not a separate ledger
Cashier is one of the four order sources, alongside internal, landing page and website. It lands in the same orders list, exports in the same file and appears in the same reports.
It starts at delivered, because it is
The default status is vertical-aware: a counter sale opens at delivered, since the customer already left with the goods. A processing state would be a fiction that someone would eventually have to clean up.
The same pricing rules apply, with channel targeting
Rules carry a channel list, so a promotion can be in-store only, storefront only, or everywhere. Staff at the till never have to remember which online offer is currently running — the rule knows where it lives, and the scan cart evaluates it as items go in.
Stock moves through the same door
A till sale deducts against the same single stock pool, respecting the same per-item stock management, the same negative-stock setting and the same first-expiry-first-out batch logic used everywhere else.
Opening and closing a drawer
A cashier session is a shift with money in it. One user can have exactly one open session at a time, which removes the whole category of “which drawer did that sale go into”.
- 1
Open with a counted opening balance
The cashier records what is physically in the drawer at the start. Everything the close computes is measured against this number, so it is the one figure that has to be right before the shift begins.
- 2
Every sale links itself to the session
Orders taken during the shift carry the session, so the close does not have to guess a time window or infer membership from timestamps.
- 3
The close reads the orders, not a running tally
At close, the session totals are computed from the linked orders themselves — cash orders to cash, card orders to card, and split orders broken apart by their own recorded cash and card amounts.
- 4
Expected is compared against actual
Expected cash in the drawer is the opening balance plus the cash collected. If the cashier enters what is actually there, the discrepancy is the difference — recorded, not silently absorbed.
- 5
The totals are cached on the session
Once computed, every figure is stored on the session row. A shift report can be reprinted next week without recomputing anything, and it will be identical to the one printed on the night, even if an order has been edited since.
What the close actually counts
Split payments are where most drawer arithmetic goes wrong: a half-cash, half-card sale counted whole into one bucket throws the count off by exactly the other half, every time.
| Order payment method | Counts toward cash | Counts toward card |
|---|---|---|
| Cash | The order's full total | — |
| Card | — | The order's full total |
| Split | The order's own recorded cash amount | The order's own recorded card amount |
Expected in drawer = opening balance + total cash collected. Cash discrepancy = actual counted − expected. Because a split order stores its cash and card halves as separate fields rather than as one total with a label, the close reads them directly rather than apportioning anything.
Rules around the drawer
Blind counting, if you want it
A setting forces a cash count at close, so the cashier enters what is in the drawer rather than being shown the expected figure and confirming it. Whether that is appropriate depends on the shop, so it is a switch rather than a policy.
Denominations you actually use
The counting sheet is built from the note and coin denominations configured for your organisation, so counting the drawer means entering how many of each — not doing mental arithmetic at the end of a shift.
Who may close what
Owners and holders of the cashier-management permission can close any session. A plain cashier can close only their own. Corrections to an opening balance, a counted amount or the notes are limited to the same management permission.
History that opens where you need it
Session history is paginated at up to 100 per page with open sessions listed first, because the question you usually arrive with is “which drawer is still open”.
Tiles and scanning
Two ways of getting an item into a sale, aimed at two different kinds of shop.
Up to 30 pinned tiles
Pin your fastest-moving items as a grid of quick-sale tiles in an order you set by hand. The counter knows whether anything is pinned, so a shop that never uses tiles is never shown an empty grid.
Any scanner you already own
The counter reads raw keyboard input from the scanner into a scan buffer, which is how hardware barcode scanners present themselves over USB. There is no driver, no pairing step and no supported-model list — if it types, it works.
It works when the connection does not
A scanned code is looked up through the API or through the local offline cache, so a dropped connection at the counter does not stop the queue moving.
Unknown code, new item, no interruption
Scanning something the catalogue has never seen offers to create it on the spot with the barcode already filled in — instead of forcing the cashier to abandon the sale and go to the catalogue screen.
Strip or box, resolved by the barcode
Where every pack level carries its own barcode, the scan resolves straight to the right pack. Where the base unit or a pack level has no barcode of its own, a selection sheet opens so the cashier picks which one this is.
Discounts evaluated as you scan
Items dropped into the scan cart are priced by the same discount rules the storefront uses, so a volume ladder or an in-store-only promotion fires at the counter without anyone having to remember it.
Four scan modes
The dedicated scan screen does four jobs, and it remembers which one you were last doing — because a shop that spends its mornings receiving and its afternoons selling should not be re-selecting a mode all day.
| Mode | What it does |
|---|---|
| Create order | Scan items straight into a cart. A persistent sheet holds the scanned lines with quantity steppers, variant and pack handling and live discount evaluation. A cashier-actions layout puts the order summary beside the live camera with search, customise, new sale and charge to hand, and a missing item can be created inline without leaving the flow. |
| Define item code | Scan to assign a SKU or barcode to an existing item — the fast way to code up stock that arrived unlabelled. |
| Find order | Scan an order's barcode or QR code to open that order directly. |
| Scan to return | Scan an order code to process a return. A full return is a status change on the whole order; a partial return opens a sheet where you keep specific lines, and the order is saved as the lines that were kept. |
Partial returns are handled as “keep these lines” rather than “remove those lines” deliberately: the person holding the goods is looking at what the customer is keeping, and stock, totals and the order record all follow from that single decision.
The distinction that makes the numbers true
The cashbox is money you are holding, not revenue
Almost every disagreement between an owner and their software about “how much did we make” is really a disagreement about when money counts. A sale is revenue on the day it happens. Cash is in the box on the day someone actually hands it over — which for a delivered-on-credit order, an installment plan or a refund is a completely different day. Akkad keeps an annual cashbox that answers the second question honestly, in three buckets: cash, card and bank.
Collected when it was collected
An order with payment-ledger rows contributes those rows, dated when they were paid and sorted into each row's own method bucket. A partial payment is visible as a partial payment. An installment collected in March 2027 lands in the 2027 box, not in the box for the year the order was placed. Orders with no ledger rows keep the simpler rule: marked paid means the full total, dated when the order was created.
Refunds take money back out, because they do
A refund is a negative row in the payments ledger, so it reduces the box. That is not a special case in the reporting code — it falls out of the ledger being signed.
One definition of “money moved”, used twice
The same function that computes the cashbox balance computes the financial report. There is exactly one definition of a money movement in the platform, so the box and the report cannot tell you different things about the same day.
A year that closes, and stays closed
Each year runs active, then grace, then closed, with the grace period ending on 1 May of the following year. Closing snapshots the closing balances and records who closed it — a system auto-close is recorded as such. A closed year serves the frozen snapshot rather than a live balance, and reopening it is a deliberate act rather than a side effect.
Questions
Is this a point-of-sale product?
It is a point-of-sale surface inside an operations platform. If a till is all you need, a dedicated till will serve you. Akkad is worth it when the counter is one of several ways you sell and you want stock, costs, debts, couriers and reporting to be the same set of records rather than four systems that have to agree.
Do I need a specific barcode scanner?
No. The counter reads raw keyboard input, which is how USB barcode scanners present themselves, so any scanner that types works. Lookups run against the API or the local offline cache, so a brief loss of connection does not stop the queue.
How does a split payment affect the drawer count?
Correctly. A split order stores its cash and card halves as separate fields, and the close routine reads each into its own bucket rather than assigning the whole total to one method. Expected cash is the opening balance plus the cash collected, and any difference against the counted amount is recorded as a discrepancy.
What is the difference between the drawer and the cashbox?
The drawer is one cashier's shift. The cashbox is the organisation's money for a whole year, split across cash, card and bank, and it tracks what you are physically holding rather than what you earned. Money enters the box when it is actually collected, which for installments and credit sales is often a different year from the sale.
Can a cashier close someone else's shift?
Only if they hold the cashier-management permission, or they are the owner. A plain cashier can close their own session and nothing else. The same permission governs correcting an opening balance or a counted amount after the fact.
If a waiter's phone drops mid-round, will the kitchen get the items twice?
No. Round appends carry their own request identifier with a uniqueness constraint, and the round number is allocated by the server under a lock. A retry returns the original round rather than creating a second one, and an order that has already been settled rejects the append outright.
Related
Orders
The record a counter sale becomes — statuses, the totals engine, cash rounding and idempotency.
Reporting
The financial report, driven by the same definition of a money movement the cashbox uses.
Verticals
Where dine-in, dosage fields and the rest of the per-industry tuning actually live.
Pruébelo con su propio catálogo
Empiece con el plan que le sirva, importe sus productos desde una hoja de cálculo y tenga tienda, mostrador y libro de pedidos funcionando el mismo día.
Hay un plan gratuito. No se necesita tarjeta para probar. La importación trae consigo su catálogo actual.