Billing-data backup and restore: prove the recovery before you need it

Separate four different promises

Local billing, a local backup, an off-device copy and a tested restore are different things. A desktop till may continue recording sales without broadband, yet lose its only data copy if its disk fails. A file called “backup” on that disk shares the same risk. A copied file on another device gives separation, but you still need to establish that it contains usable, sufficiently recent data.

Choose the data cutoff before discussing speed

Suppose the last verified copy contains transactions through 9 pm yesterday and the till fails at noon today. Restoring that copy does not recreate this morning’s sales. The business must identify the gap and agree how authorised staff will recover or reconcile those transactions from appropriate records.

Write down the latest transaction you expect the copy to include, not just the time shown in its filename. Ask the installer what the backup covers: business data, required configuration and anything stored separately. A copied application folder or a screenshot of today’s total is not evidence that the full database can be restored.

Choose a backup frequency that matches how much work the business can reasonably reconstruct. Record the decision in plain language: “We must be able to account for every sale since the last verified copy.” Avoid promising zero lost data unless the installed arrangement has actually established that outcome.

Rehearse on a separate approved system

1. Ask the authorised owner and installer to choose a test environment and the correct application version.
2. Keep an untouched copy of the selected backup. Confirm that the test cannot overwrite or synchronise back into the live business.
3. Record the backup’s source, cutoff, size and approved storage location without recording passwords.
4. Have the authorised person perform the supported restore procedure.
5. Confirm that the application opens, then run the record checks below.
6. Record elapsed time, failures, responsible people and the next test date. Protect or remove the test data according to the business’s approved retention procedure.

Do not test a destructive restore against the working till. If you are unsure whether an action replaces current data or reconnects to a live service, stop that test and ask the installer to establish isolation first. This checklist does not replace the version-specific restore instructions.

Check records, not just a successful login

Select a few known records from before the backup cutoff. Find a recent bill, an older bill, a product or menu item, an opening-stock item and the relevant payment record. Compare identifiers, quantities and totals against the original approved evidence. Include an outstanding balance or open restaurant order if that is part of the backup’s stated scope.

Use deliberately chosen examples. A database that opens but lacks the most recent trading period can look plausible until someone searches for a specific bill. A test also needs to reveal configuration differences: receipt format, printer destination or staff permissions may require separate setup even when the sales data restores correctly.

Keep the checks read-only where possible. If a disposable test transaction is necessary, have the installer confirm that it cannot send customer messages, alter a payment-provider record or synchronise into live stock.

Check the schedule when the till is normally closed

Posnic’s user guide distinguishes scheduled backups while the application is running from an optional operating-system task that can run when the application is closed. A shop that shuts its computer down before a scheduled job needs to verify what actually happens, rather than relying on the time configured in a settings screen.

For Bill Pondy, confirm the installed edition, operating system, schedule and power conditions with the person responsible for setup. Inspect backup history after the normal overnight routine. Do not assume the parent product’s optional cloud service is included in your quote, or that a scheduled job also copies its output off the original disk.

The offline billing feature guide explains local and connected dependencies. Use this recovery rehearsal to test the separate question: what happens if the original computer is unavailable?

The Posnic troubleshooting and backup manual provides the parent product reference. Confirm the supported recovery procedure for your installed version.

Agree who does what during a real interruption

Name the person who authorises recovery, the person with protected access to the backup and the person who helps reconcile the missing trading period. Keep contact details available outside the failed computer. Agree a temporary billing and record-keeping procedure that suits the business; do not improvise tax or payment treatment during an outage.

Ask about support availability, recovery assistance, replacement hardware and any separate charge in the written software quote. Record observed rehearsal time as an observation, not a guaranteed future recovery time.

The blank worksheet gives your team a repeatable evidence trail. Bring it to a Bill Pondy setup discussion in Puducherry or Karaikal, and use the migration guide when changing the live billing system.