Offline-first

The counter keeps moving when the network stops.

Internet availability changes when work syncs—not whether a shop can bill a customer, check stock or produce the customer’s invoice.

First save

On the device

Customer output

Printable immediately

Retry

Automatic when online

Duplicates

Protected by operation identity

What you need to know

Clear details, without the jargon.

6 topics

01 · Local work

The device accepts the work first

A supported shop action is written to local storage before BillCountr depends on the server. The cashier can finish the customer interaction while the network is slow or unavailable.

Finalize and print an offline bill
Look up locally available products and stock
Record supported ledger activity
Use local reports needed for shop continuity

02 · Queue

Pending work waits safely

Each local action produces a JSON-safe sync operation with an organization, device, operation identity, timestamps, retry state and payload. Staff sees a simple status—not the technical queue.

Stable device identity across app restarts
Unique operation identity for every write
Pending work persists until confirmed
Retryable failures remain separate from conflicts

03 · Upload

Sync resumes without staff intervention

When connectivity returns, the client uploads pending operations. The API checks organization scope, permission and idempotency before applying any stock, ledger, report or audit effect.

Automatic retry for temporary network failures
Server confirmation updates the local status
Repeated uploads replay the first safe result
Multi-device work converges on confirmed state

04 · Status

Five labels explain the state

BillCountr avoids technical sync language. The interface uses the same small status vocabulary on mobile and web.

Synced — confirmed by the backend
Pending sync — saved locally, waiting to upload
Syncing — upload or confirmation in progress
Conflict — the action needs review
Offline — no network, local work can continue

05 · Conflict

A conflict is not treated like bad internet

Changed duplicate operations, stale stock assumptions, deleted records, outdated settings or permission denial cannot be fixed by blind retry. They receive a deterministic conflict result for review.

Changed duplicates never apply as new work
Stock version mismatches remain explicit
Permission failures are not silently bypassed
The audit trail preserves the outcome

06 · Bill safety

Offline bills remain real bills

An offline bill keeps its local calculation and settings snapshot, is printable immediately, and later uploads as the same operation. The server must not create a second invoice for a retry.

Integer-paise totals stay deterministic
Invoice output uses the finalized snapshot
Stock and ledger effects apply once
Original local operation identity is preserved

Common questions

Quick answers.

What can I do when the app says Offline?

Supported local work such as billing, stock lookup, ledger updates, printing and local reporting can continue. New actions show an offline or pending-sync state until connectivity returns.

Do I need to press a sync button?

No. Normal retry and confirmation happen automatically. Human review is reserved for real conflicts that cannot be applied safely as-is.

Can retrying create the same invoice twice?

The sync contract uses organization, device and operation identities plus a payload fingerprint so the backend can replay the first result instead of duplicating the business effects.

What happens if stock changed on another device?

If the offline action was based on an older expected stock version, BillCountr records a stock conflict for deterministic review rather than silently overwriting the newer state.

Ready for daily shop work