What actually happens when you ring up a sale
A POS sale in AccountDesq is not a separate system that syncs to your books later - it posts to the same stock ledger and the same accounting ledger as an invoice, a vendor bill, or a bank match. The moment a sale is completed, stock for each item is drawn down and the corresponding ledger entries are created, using whatever costing method that item is set up with (FIFO, Standard, or Weighted-Average). There is no overnight batch job reconciling the register against the books - by the time the sale is done, it already agrees with them.
- 1
Open the register
Start a cash-drawer session for the shift. The register is scoped to a specific location, so it only draws from and affects that location’s stock and cash.
- 2
Sell
Ring up items, apply a gift card, loyalty redemption, or coupon if relevant, and take payment. Stock and the ledger update immediately.
- 3
Hold and resume if needed
A transaction can be paused and picked back up later without losing the cart - useful when a customer steps away mid-purchase.
- 4
Close the register
End-of-shift close reconciles the cash drawer against what was actually recorded as sold - a check on the till, not a check against a separate system.
Restaurant mode: the same POS, with tables and a kitchen display
Restaurant mode was built directly into the existing POS rather than as a separate product - the same register, cash-drawer sessions, held sales, and refunds apply. On top of that, it adds table management and a kitchen display screen, so an order placed at a table appears in the kitchen as it’s entered rather than after the fact. Every sale still posts to the same ledger and stock system as any other AccountDesq transaction.
This is recent functionality
Restaurant mode (tables and kitchen display) is newly added - if you’re evaluating it for a food-service business, confirm current coverage for your specific service style (counter service, full table service, or both) before committing.
Gift cards, loyalty, and coupons each have a real lifecycle
These are not checkout-time hacks - each is its own module with a full lifecycle, so what a cashier does at the register is backed by a real, auditable record rather than a manual note.
| Mechanism | Lifecycle | Where it’s managed |
|---|---|---|
| Gift cards | Sell, check balance, redeem, void, reissue, automatic expiry | Admin back office - separate from ordinary GL posting, for traceability |
| Loyalty | Points accrual on sale, redemption at checkout | Loyalty settings + balance lookup per customer |
| Coupons | Create, validate at checkout, automatic expiry scheduler | Coupon management screen |
What each mechanism actually supports
Registers are scoped to a location
A cashier assigned to one store’s register does not see or affect another location’s stock or cash drawer - access is scoped by warehouse, branch, or register. For a business running more than one till or site, this is what keeps register activity attributable to the right place without manually filtering reports afterward.
Worked example: a gift card redeemed at a different location than it was sold
A customer buys a gift card at Store A, then redeems part of its balance at Store B. Because gift card balances aren’t tied to a single register, Store B’s cashier can check the balance and apply it directly - the redemption still posts correctly, and the remaining balance updates in real time for whichever location the customer uses next.
Does the POS work offline?
This walkthrough covers the connected, online experience. If offline resilience during a connectivity outage is a hard requirement for your location, verify current support before relying on it during service.
Can I use a barcode scanner at the register?
The POS cart accepts scan-style input from keyboard-wedge scanners, which covers most common retail hardware. It is not a verified native camera-based mobile scanner - test with your specific hardware first if that distinction matters for your checkout volume.
Do gift cards post to the general ledger like a normal sale?
Gift cards are handled through a dedicated lifecycle (sell, redeem, void, reissue) separate from ordinary GL posting, specifically for traceability of stored-value balances rather than being treated as an ordinary revenue transaction at time of sale.
Resources
Was this guide helpful?