Australian Odoo POS go-live and recovery checklist

Register each site, browser, device and accountable user

Build the readiness register per site rather than treating every lane as identical. Record location, network and wireless design, browser and version, POS session, receipt printer, scanner, cash drawer, cash float, user role and device owner. Include power, cabling, spare equipment and the person authorised to take a lane out of service.

Test the exact browser profile that the cashier will use. Shared logins, automatic site-data clearing, unmanaged extensions and uncertain browser updates can invalidate an otherwise sound recovery procedure. Device ownership includes who may change settings, who receives provider messages and who confirms that the lane has returned to normal operation.

Replace every synthetic example with your own evidence, assign an owner, record the evidence and result, and mark each item Passed, Blocked or Not applicable.

• Site and lane: Example Adelaide store, lane A. Owner: store manager. Evidence: site and lane sign-off. Result: Blocked pending client evidence.
• Browser and POS session: managed browser profile and named session. Owner: POS administrator. Evidence: version, permissions and startup test. Result: Blocked pending client evidence.
• Receipt printer and scanner: exact model and connection. Owner: device owner. Evidence: receipt, barcode and reconnect test. Result: Blocked pending client evidence.
• Cash drawer and float: approved synthetic float and count sheet. Owner: cash supervisor. Evidence: opening count and access check. Result: Blocked pending client evidence.
• Network escalation: store contact plus network provider. Owner: recovery owner. Evidence: escalation path and outage communication. Result: Blocked pending client evidence.

Reviewed 6 November 2026. General implementation guidance only; it is not tax, payroll, employment or legal advice. Confirm your obligations with a qualified Australian specialist. All examples are synthetic and do not establish device or statutory acceptance.

Validate the exact Tyro or Stripe payment flow

Payment acceptance identifies the exact provider, merchant account, terminal model, firmware, integration, network and intended Odoo 19 flow. Use the versioned Tyro or Stripe documentation to design the test, not to generalise support to a device class.

Exercise sale, decline, cancellation, refund, signature where relevant, duplicate-message handling and reconnect. Compare the POS order, provider transaction, merchant reference and later settlement. Record gross and net amounts, fees and delayed funding separately so a net bank deposit is not mistaken for the original sale value.

• Approved sale: exact merchant and terminal combination. Owner: payment operations owner. Evidence: POS order, provider reference and receipt. Result: Blocked pending client evidence.
• Declined payment: provider decline without order ambiguity. Owner: cashier and supervisor. Evidence: customer prompt, order state and retry rule. Result: Blocked pending client evidence.
• Refund: approved original transaction and refund. Owner: finance and store supervisors. Evidence: linked POS and provider references. Result: Blocked pending client evidence.
• Reconnect: temporary communication interruption. Owner: provider and POS support. Evidence: no duplicate charge and a clear final state. Result: Blocked pending client evidence.
• Settlement: gross sales, fees and net deposit. Owner: finance controller. Evidence: merchant report and bank reconciliation. Result: Blocked pending client evidence.

No payment-terminal function is claimed offline. The provider and merchant evidence belongs to the selected account and device; another merchant's successful test is not a substitute.

Separate GST treatment, receipts, invoices and tenders

Configure POS taxes from approved transaction samples rather than applying 10% to every line. Taxable, GST-free, input-taxed and out-of-scope distinctions remain relevant, and credit consequences require their own review. Include mixed baskets, discounts, refunds and credit notes so line, order, receipt and accounting results can be compared.

A customer receipt and a requested tax invoice are not treated as interchangeable evidence. Test the intended receipt format, ABN and other approved fields, then generate requested invoices only when the order is connected and synchronised. Cash, card, account and mixed tenders receive separate close and reconciliation expectations.

• Mixed GST basket: taxable and GST-free synthetic items. Owner: Australian tax reviewer. Evidence: line treatment, totals and accounting entries. Result: Blocked pending client evidence.
• Refund: original mixed-tender sale. Owner: store and finance owners. Evidence: correct tender, tax and stock reversal. Result: Blocked pending client evidence.
• Receipt and invoice: customer requests a tax invoice. Owner: finance and POS owners. Evidence: receipt distinction and synchronised invoice. Result: Blocked pending client evidence.
• Mixed tender: synthetic cash and card split. Owner: cash supervisor. Evidence: tender totals and cash count agree. Result: Blocked pending client evidence.
• Cash over or short: deliberate synthetic count difference. Owner: store manager and finance. Evidence: approved reason, account and sign-off. Result: Blocked pending client evidence.

The ATO's GST overview informs the reviewer boundary. It does not make POS tax configuration an automatic classification service.

Reconcile the normal close before testing an outage

A normal close proves the baseline before outage recovery is attempted. Count cash by denomination where used, compare card and other tenders, explain over or short amounts and obtain supervisor approval. Match POS orders to accounting entries, invoices, uninvoiced orders, stock movements and provider references at the same cut-off.

Stock acceptance distinguishes what the online system has recorded from what a disconnected browser may display. Backend-dependent availability and real-time stock functions are not assumed to continue during an outage. Finance and operations review their respective reports rather than relying on the POS close screen alone.

• Opening and counted cash: approved float and final count. Owner: cash supervisor. Evidence: signed cash sheet and variance. Result: Blocked pending client evidence.
• Card and alternative tenders: POS totals match provider references. Owner: payment operations owner. Evidence: provider report and exceptions. Result: Blocked pending client evidence.
• POS to accounting: orders, payments and entries linked. Owner: finance preparer. Evidence: journal and reconciliation report. Result: Blocked pending client evidence.
• Stock and uninvoiced orders: online movements and order states checked. Owner: inventory and POS owners. Evidence: inventory report and uninvoiced-order list. Result: Blocked pending client evidence.
• Close approval: exceptions resolved or assigned. Owner: store manager. Evidence: supervisor and finance sign-off. Result: Blocked pending client evidence.

Record fees and gross or net provider settlement outside the sales total. Late settlements and corrections remain open items until bank evidence and reconciliation are complete.

Keep Basiq, statement imports and ABA evidence distinct

Basiq and Consumer Data Right connectivity is opt-in and provider-, institution- and account-specific. Feed availability, history and non-real-time limits are tested for each account using the Basiq product guidance. A statement import remains a controlled fallback, not proof that live synchronisation works.

Store and head-office procedures identify when POS settlement appears in the bank, how weekends or provider delays are handled and who investigates a missing deposit. Duplicate prevention is tested where feed lines and imported statements overlap. Fees and chargebacks are reconciled as separate values.

• Basiq feed line: proves the provider supplied an account transaction. It does not prove universal history or real-time availability. Owner: bank reconciliation owner. Result: Blocked pending client evidence.
• Imported statement: proves controlled source lines were loaded. It does not prove live feed connectivity. Owner: finance preparer. Result: Blocked pending client evidence.
• ABA file generation: proves a payment instruction file was produced. It does not prove bank approval, debit or supplier settlement. Owner: payment operator. Result: Blocked pending client evidence.
• Bank response: proves the bank supplied a status or account outcome. It does not prove original POS tax or stock correctness. Owner: treasury and finance. Result: Blocked pending client evidence.
• Merchant settlement: proves the provider reported gross, fees or net amounts. It does not replace bank-account evidence. Owner: payment and bank owners. Result: Blocked pending client evidence.

An ABA file upload is not payment proof. Bank approval, debit, settlement and reconciliation remain separate, and no universal Australian bank coverage is inferred.

Understand temporary browser-cache order retention

The reviewed Odoo 19 POS usage documentation and its documentation change record support temporary browser storage/cache order handling during an outage. Orders can subsequently synchronise after reconnection. This is not a full offline POS architecture.

Users must be reconnected and synchronised before requested invoices are generated. Payment terminals, customer or backend lookups, real-time stock and other backend-dependent functions require connectivity. Full fiscal and Peppol functionality is not claimed offline. A cached order is not proof of an accepted invoice or payment.

Do not reload or close the browser, or clear site data or the cache before synchronisation. The cashier keeps the affected lane under supervisor control, records the outage start and order references, and follows the client-approved contingency rather than improvising a second entry in another system.

• Temporary order retention: test that a synthetic order remains in browser storage/cache. Do not infer that full backend functionality remains available. Owner: POS test owner. Result: Blocked pending client evidence.
• Requested invoice: create it after reconnection and synchronisation. Do not treat an offline order as an invoice. Owner: finance and POS owners. Result: Blocked pending client evidence.
• Payment terminal: test connectivity and provider state separately. Do not infer offline card acceptance. Owner: payment provider owner. Result: Blocked pending client evidence.
• Stock and backend: check online state after recovery. Do not infer that real-time stock remained available offline. Owner: inventory owner. Result: Blocked pending client evidence.
• Fiscal and Peppol: use connected approved processes. Do not infer complete offline fiscal or Peppol functionality. Owner: tax and integration reviewers. Result: Blocked pending client evidence.

Run a synthetic outage and recovery exercise

Use a controlled test environment and synthetic customers, products, orders and payments. Disconnect the test lane under the recovery owner's instruction, create the approved synthetic orders and observe what the browser actually retains. Do not experiment with live customer data or assume that a previous browser version behaves identically.

Reconnect the same managed browser session and wait for synchronisation. Compare local and server order counts, references and states before creating requested invoices. Prove duplicate prevention by repeating the recovery observation and checking orders, payments, invoices and stock for unintended duplicates. Reconcile the backlog before reopening normal operations.

• Controlled disconnect: disable the test network at a recorded time. Owner: recovery owner. Evidence: outage log and initial lane state. Result: Blocked pending client evidence.
• Cached order: create an approved synthetic order. Owner: cashier and supervisor. Evidence: local reference and visible state. Result: Blocked pending client evidence.
• Browser prohibition: do not reload or close the browser, or clear site data. Owner: store supervisor. Evidence: cashier verbal and procedural check. Result: Blocked pending client evidence.
• Reconnection: restore the network and await synchronisation. Owner: POS support. Evidence: local/server count and reference comparison. Result: Blocked pending client evidence.
• Duplicate check: review repeated sync and backlog. Owner: finance and inventory owners. Evidence: unique orders, payments, invoices and stock. Result: Blocked pending client evidence.
• Delayed invoice: generate only after synchronisation. Owner: finance owner. Evidence: linked invoice and correct order state. Result: Blocked pending client evidence.

If the browser state is uncertain, stop the lane and escalate. Do not clear data to make the screen look clean or re-enter orders without checking for duplicates.

Drill cashier, supervisor, finance and support roles

Each role practises both routine work and exceptions. Cashiers handle declines, printer failures and outage communication. Supervisors control cash-only contingency, lane stop/go decisions and escalation. Finance reviews delayed invoices, provider fees, duplicate warnings and reconciliations. Support manages browser, network, provider and backlog evidence.

A cash-only contingency is used only when approved by the client for the specific circumstances. It does not imply that card payments can be accepted offline, and it does not remove the need to record, synchronise and reconcile orders later. Communication tells staff what can be sold, how customers are informed and when the lane must stop.

• Cashier: routine sale, mixed tender and receipt; exception drills for declines, printer failure and outage instructions. Owner: store supervisor. Evidence: observed task and prompt sheet. Result: Blocked pending client evidence.
• Store supervisor: routine float and normal close; exception drills for cash-only approval, stop/go and escalation. Owner: recovery owner. Evidence: signed decision and communication log. Result: Blocked pending client evidence.
• Finance: routine POS entries and settlement; exception drills for delayed invoices, fee differences and duplicate warnings. Owner: finance controller. Evidence: reconciliation and exception resolution. Result: Blocked pending client evidence.
• Inventory user: routine receipt and stock check; exception drill for post-outage stock and backlog reconciliation. Owner: inventory owner. Evidence: inventory report and variance ownership. Result: Blocked pending client evidence.
• POS or provider support: routine startup and connection check; exception drill for a network, browser or provider incident. Owner: support lead. Evidence: incident timeline and recovery evidence. Result: Blocked pending client evidence.

Attendance is not role acceptance. The assessor observes the user complete the task, state the prohibition and retrieve the required evidence without bypassing permissions.

Make stop/go and hypercare decisions on evidence

Go-live review includes site and device registers, provider tests, tax and receipt samples, normal close, outage recovery, user drills and open exceptions. A failed critical payment, duplicate-prevention, reconciliation or browser-retention control stops the affected lane or release under the agreed authority. No recovery-time promise is inferred from a rehearsal.

Hypercare triages defects, provider incidents, user errors and process gaps separately. Each item has severity, owner, next action and evidence needed for closure. Repeated manual work or unreported offline orders trigger investigation rather than silent workarounds.

• Site readiness: devices, network, browser and float accepted. Owner: store and POS owners. Exit condition: all critical site rows signed. Result: Blocked pending client evidence.
• Provider readiness: exact sale, refund and settlement tests. Owner: payment operations owner. Exit condition: no open critical provider failure. Result: Blocked pending client evidence.
• Recovery readiness: synthetic outage and duplicate checks passed. Owner: recovery and finance owners. Exit condition: backlog reconciled and roles competent. Result: Blocked pending client evidence.
• Operational close: orders, entries, stock and tenders reconciled. Owner: store, inventory and finance. Exit condition: signed close with owned residuals. Result: Blocked pending client evidence.
• Hypercare exit: stable operations and transferred exceptions. Owner: operational owner. Exit condition: named long-term owners and support route. Result: Blocked pending client evidence.

Acceptance applies to the named Odoo version and deployed build; later versions require separate assessment. Retest after material browser, build, provider, firmware or network changes.

Assemble the release pack and related workstreams

The final pack contains the approved scope, exact device and provider inventory, transaction expectations, normal and outage results, close reconciliations, role assessments and open exceptions. Each row links to its raw evidence and identifies whether the behaviour belongs to Odoo 19, custom work, a provider or a client procedure.

No offline payment acceptance, universal device support or statutory outcome is claimed. The checklist supports implementation readiness only; human Australian review and provider acceptance remain necessary where relevant. OXP or provider-customer material, if used in training, is educational only and never becomes an Oakland customer reference.

• Configuration: POS, taxes, tenders, roles and approved custom items. Owner: POS solution owner. Acceptance evidence: versioned configuration record. Result: Blocked pending client evidence.
• Devices and providers: models, firmware, merchant and test references. Owner: device and payment owners. Acceptance evidence: exact combination sign-off. Result: Blocked pending client evidence.
• Recovery: outage log, sync comparison and duplicate evidence. Owner: recovery owner. Acceptance evidence: synthetic recovery accepted. Result: Blocked pending client evidence.
• Finance and stock: close, settlement, invoices, entries and inventory. Owner: finance and inventory owners. Acceptance evidence: reconciliations and residuals signed. Result: Blocked pending client evidence.
• People and support: role drills, escalation and hypercare ownership. Owner: store and support leads. Acceptance evidence: operational handover approved. Result: Blocked pending client evidence.

Continue with the GST and BAS guide, AUD migration guide and payroll readiness guide to connect the POS release to the wider Australian control pack.