When the register goes offline — what survives, what doesn’t

Most retail POS vendors built around card-present transactions. When the internet drops, the card terminal can’t auth — the sale can’t happen — the register stops being useful. That model leaks straight into how cannabis POS is built, even though the cannabis register doesn’t need card auth at all (cash-only by design in WA + OR + MI). The register is doing inventory decrement + tax math + receipt print + audit log + traceability sync. Three of those five can run on the local register without ever touching the cloud.

The register is local-first. Local means ‘the SQLite database lives on the iPad / Mac mini next to the till, and writes happen there before they sync.’ Concretely:

• **Inventory lookup.** The product catalog (every SKU + price + tax category + on-hand qty) is mirrored locally on every register. Lookup is instant; no network round-trip.
• **Cart build.** Add product → cart updates. Apply discount (loyalty / heroes / first-visit) → math runs locally against rules cached at start-of-shift. The cart never waits on the cloud.
• **Tax math.** State-by-state rates baked in (WA 37% / OR 17%-20% / MI 10%) — not pulled per-transaction.
• **ID scan + age verification.** Local scanner + local rule (21+ recreational / patient lookup against locally cached endorsement list). Sale-to-minor block enforced offline.
• **Receipt print.** Receipt printer is USB to the register, not networked. Prints regardless of upstream link.
• **Cash drawer open.** Drawer trigger is wired to the register, not to the cloud. Open / close / balance happen locally.
• **Audit log row write.** The transaction commits to local SQLite. Nothing is lost.

Honest list. These all wait for the link to come back.

• **WSLCB-CCRS / METRC traceability submit.** State traceability requires a real-time sync. Transactions queue locally; they push to CCRS / METRC the moment the link returns. The state doesn’t know whether the row arrived in 2 seconds or 47 minutes — the receive timestamp is what matters, not whether it crossed the wire instantly. (Per WAC 314-55-083 + the 2026 CCRS technical guide, end-of-day reconciliation is the bar.)
• **Cross-store inventory transfer.** Same-licensee inventory transfer to a sibling store needs both sides online for the manifest to commit. If one side is offline, the transfer queues; the manifest commits when both are reachable.
• **Loyalty point accrual via cloud rules engine.** If the loyalty rules are cloud-side only, the customer earns the points retroactively when the link returns. Better: rules-cache locally so the receipt shows the point earn in real-time. (CannAgent caches; many vendors don’t.)
• **Online order claim.** Customer ordered ahead via the public site? The pickup pre-reservation lives in the cloud. Offline registers can still complete a walk-in cash sale of the same product, but the ‘mark online order picked up’ sync waits.
• **Vendor portal sibling-store hop.** A vendor logging in to look at the other store from this register’s screen is a cross-store auth flow — needs the cloud.
• **Real-time dashboard for the owner phone.** Doug’s phone refresh of /admin/today shows whatever the cloud knew at last sync. Lag is the price.

The order matters. Sync isn’t one batch — it’s a priority queue.

1. 1**Audit-log rows first.** Compliance writes are the highest-priority sync target. The state doesn’t care about the timing within reason; it cares that the row exists.
2. 2**Inventory decrement reconciliation.** If two registers were offline simultaneously and both sold the last unit of a SKU, the sync detects + flags the conflict for the inventory team to resolve manually. Better than silently double-selling.
3. 3**Cash-drawer close + variance.** The till count for the offline window flows up the moment the link returns. Variance > $10 triggers the standard amber-flag review (per Kat’s till-count policy).
4. 4**Loyalty point accruals.** Customer’s account updates retroactively. Customer-facing communication: ‘Your points from earlier today have posted’ — never ‘our system was down.’
5. 5**Online-order pickup status.** Last to sync. The customer who walked in for an online order while the link was down already left with the product; the marker just catches up.

Tone matters. The customer doesn’t need to hear ‘our system is down.’ They need to hear that the sale is going through.

• **Right:** ‘Cash sale, easy — register handles this locally.’ (For the cash-only customer, internet is irrelevant. Don’t make them anxious about something that doesn’t affect their purchase.)
• **Right (loyalty member):** ‘Points will post in a few minutes — receipt shows what you earned.’ (Honest + reassuring; the receipt math is local + trustworthy.)
• **Right (online order):** ‘Your online order is in our local system. We can hand it to you now; the “picked up” flag updates when our connection comes back.’ (Honest about the queue without making it the customer’s problem.)
• **Wrong:** ‘Our system is down — I’m not sure if I can ring you up.’ (Telegraphs panic; loses the sale.)
• **Wrong:** ‘Sorry, can’t do anything until our internet comes back.’ (False — the register can almost certainly do this transaction.)

• Cloud-only POS that locks the register on a network blip. (Several vendors still ship this; ask before signing.)
• Manual paper-tracking of offline sales. (Some shops keep a notebook for outages — recipe for variance + audit trouble.)
• ‘Sorry, our system is down’ sign on the door. (Walks customers to a competitor.)
• Owner phone calls to the IT vendor mid-outage. (The register architecture should make this irrelevant.)