Ask a shop owner what happens at closing time and you will hear a familiar routine. The cashier prints the Z report. Someone photographs it, or exports a CSV from the POS app, or waits for the "accounting sync" to run overnight. The next morning the bookkeeper compares the POS total to what landed in the accounting software, finds a difference — a refund that synced as a sale, a card settlement that arrived net of fees, a product mapped to the wrong revenue account — and spends the first hour of the day explaining it.
This is so normal that most people do not think of it as a problem. It is just what having a POS is like. But it is worth naming what is actually going on: the business is running two systems of record that were never designed to agree, and paying someone to reconcile them every single day.
Why "sync" never quite works
A POS app that syncs to accounting has to answer questions it was not built to answer. Which revenue account does this product belong to? Is this tender a bank account or a cash drawer? Was the discount a price reduction or a marketing expense? Is a gift card sold today revenue today, or a liability until it is spent? Did the return go back into stock at cost, or was it written off?
The sync answers these with mappings — a product-to-account table, a tender-to-account table — that somebody set up once and nobody maintains. The day a new product category appears, or a new card acquirer, the mapping is wrong and the day-end gap appears. And because the POS posted a summary rather than the individual sales, the gap can only be chased by re-reading the POS's own reports.
The deeper issue is timing. A summary posted at day end means the books are always a day behind the shop, the stock figures in accounting are always a day behind the shelf, and any question that spans both — "how much did we make on that promotion, net of returns?" — needs both systems and a spreadsheet.
What a billing counter that posts looks like
The alternative is a billing counter that is part of the accounting system, so that completing a sale is the posting. In BIZA, when the cashier takes payment, one transaction writes:
- a tax invoice with the next number in the business's own sequence, flagged as a POS sale, with the cashier, terminal and shift on it;
- a journal entry — cash and bank per tender, revenue per line, output tax, discounts to a discounts-given account, tips to a liability, gift cards sold to a liability;
- stock movements at the outlet's location, including the exact serial number or batch;
- payment records for each tender, to the account it is banked in.
Either all of that happens or none of it does. There is no summary to post later, no mapping table to drift, and nothing to reconcile in the morning — because the Z report, the payment records and the journal are three views of the same rows. BIZA's POS dashboard shows the three side by side for exactly that reason: the reconciliation tab is not a tool for finding differences, it is a demonstration that there are none.
"But the internet drops"
The obvious objection to a billing counter inside the accounting system is connectivity. A shop cannot stop selling because the router rebooted.
The answer is to make the billing counter offline-first without giving up the single record. Every sale is saved on the device first and posted from a queue — in order, and exactly once. If the connection drops mid-shift, receipts keep printing with the billing counter's own reference; when it returns, the queue drains and each sale gets its invoice number. Because each sale carries an idempotency key, a retry can never double-post; because the queue is ordered, a sale can never overtake the shift it belongs to. Two offline sales always produce exactly two invoices. The cashier sees a small "3 to send" indicator and nothing else changes.
The important part is what does not happen: the offline sales are not batched into a summary. They arrive at the ledger as individual, numbered invoices, exactly as if the connection had never dropped.
What you get once the two systems are one
Some of the benefits are obvious — no morning reconciliation, stock that is right in real time, tax returns that include today's sales. Others only show up once you have it:
- Promotions have a cost line. A 10 % deal is booked as gross revenue and a debit to discounts given, so the promotion's cost is a number on the P&L rather than an invisible lower price.
- Gift cards and loyalty points are liabilities, correctly. A card sold is not revenue until it is spent; points outstanding sit on the balance sheet at their redemption value. The billing counter does the accounting because the billing counter is the accounting.
- Tips are never revenue. They go to a payable, the tips report shows who is owed what, and nobody has to strip them out of sales at month end.
- Cash control is real. Every drawer open, void and cash movement is a posted, audited event with a person's name on it, and the shift's variance is a ledger fact rather than a note on a printout.
- Questions span the whole business. "Which outlet has the highest refund rate?", "what did that batch actually earn before it expired?" — one system, one query, or one sentence to the assistant.
How BIZA helps
BIZA's point of sale runs on desktop, tablet and phone, prints to the thermal printers and cash drawers you already own, applies promotions and loyalty at the counter, and switches into a full restaurant mode — tables, kitchen display, split bills, tips, QR ordering — on the same engine. Every sale, in every mode, posts to the same books as the rest of your business.
See the POS feature page, read the POS guides, or talk to the team.