POS go-live and recovery checklist

1. Build an outlet and register acceptance register

Create one row per legal entity, outlet, warehouse, POS configuration and register. Keep training and production identifiers visibly separate, and use synthetic customers, products, payments and employee names for labs.

• Field group: Outlet identity; Minimum entries: Entity, outlet, warehouse, POS configuration and operating owner; Owner: Outlet manager
• Field group: Register; Minimum entries: Register ID, receipt sequence, invoice, bank and cash journals; Owner: Back-office owner
• Field group: Access; Minimum entries: User roles, refund and price permissions, release authority; Owner: System owner
• Field group: Evidence; Minimum entries: Hardware IDs, rollout wave, test environment, evidence location and reviewer; Owner: Acceptance owner

Restrict test users to least privilege and prohibit live customer or payment data in offline exercises. Record who can open and close a session, approve a refund, change a price, view cost, generate an invoice, reconcile the bank and release the outlet.

Synthetic acceptance example: Outlet C has two registers with different receipt printers and one shared back-office reviewer. Each register needs its own opening, transaction, offline and close evidence; a successful demonstration on one register cannot be copied as proof for the other.

Reviewed 6 November 2026 — research review, not legal signoff. Revalidation owner: Compliance reviewer (CR) with the country owner and named client advisers; unresolved human Singapore regulatory review by a qualified Singapore regulatory reviewer remains mandatory before release.

2. Prove network, browser and hardware before trading

Capture browser and device versions, network path, permitted URLs, managed-device restrictions, site-data retention setting, power arrangement and support owner. Test receipt printer, scanner, cash drawer, barcode or weighing equipment where relevant, customer display and network devices by exact model.

• Test area: Browser and network; Minimum evidence: Versions, permitted URLs, site-data setting and disconnection result; Owner: Technology owner
• Test area: Receipt output; Minimum evidence: Long descriptions, SGD values, refunds, multi-page receipts and readable references; Owner: Outlet manager
• Test area: Hardware; Minimum evidence: Exact model, driver, connection, scan, print and cash-drawer result; Owner: Hardware owner
• Test area: Recovery; Minimum evidence: Browser session, site-data safeguards and support route; Owner: Outlet and technology owners

Check duplicate print prevention and digital references as well as printed output. Hardware procurement and vendor support remain external responsibilities unless explicitly scoped.

The network drill includes a controlled disconnection and reconnection without closing or reloading the browser or clearing site data. Acceptance requires evidence that the test session remained identifiable and recoverable. No result is generalised to an untested browser, terminal, printer or outlet network.

3. Control invoices, petty cash, tenders and SGD close

Build test cases for a full tax invoice, simplified invoice where permitted, credit note, return, refund, mixed tenders, cash over or short, petty-cash purchase and register-to-back-office close. Preserve source order, receipt, invoice, payment, stock movement, accounting entry and reviewer links.

• Close field group: SGD cash; Minimum entries: Opening float, expected cash, counted cash and over/short; Owner: Cashier and outlet manager
• Close field group: Tender; Minimum entries: Mixed tenders, refunds, payment references and unmatched items; Owner: Payment operator
• Close field group: Petty cash; Minimum entries: Claimant or cardholder, receipt, purpose, supply category and aggregation eligibility; Owner: AP owner
• Close field group: Back-office close; Minimum entries: Uninvoiced orders, stock, accounting entries and residual review; Owner: Accounting reviewer

Applicable standard-rated sales use the reviewed 9% treatment; zero-rated, exempt and out-of-scope samples remain distinct and adviser-approved. Product precision, tax calculation, payment rounding and cash rounding are tested separately; the currency's two-decimal display does not justify a blanket close tolerance.

The outlet manager signs register close, while back office signs the cross-register and accounting close. Uninvoiced orders and unexplained tender differences remain open rather than being absorbed into a generic adjustment.

4. Treat PayNow QR as a request, then reconcile the bank

The Odoo 19 Singapore page documents invoice PayNow QR configuration, and POS QR documentation covers QR payment-method generation. Record bank account, journal, proxy type and value, recipient, invoice reference setting, participating institution and configuration reviewer.

The MAS E-Payments page was last updated 6 November 2026; its linked PayNow report is dated 25 June 2026. ABS PayNow guidance provides additional service context, including PayNow Corporate UEN addressing through participating institutions. Confirm actual Corporate UEN and institution support with the client's bank.

PayNow QR is not settlement or reconciliation. The evidence row keeps order and invoice IDs, QR reference, customer bank-app completion, independent bank reference, gross amount, fee where applicable, net settlement, settlement date and reconciliation owner separate.

• PayNow test: Matched receipt; Required evidence: Customer completion, independent bank reference and gross amount; Acceptance owner: Treasury/payment operator
• PayNow test: Fee and net settlement; Required evidence: Fee where applicable, net settlement and bank line; Acceptance owner: Treasury reviewer
• PayNow test: Unmatched or refunded item; Required evidence: Exception reason, refund reference and residual owner; Acceptance owner: Named residual owner

None of these cases is accepted from a screenshot of the QR itself. Coverage, customer completion and settlement remain institution/provider-specific.

5. Rehearse the exact offline restrictions

The Odoo 19 POS usage guide supports temporary offline order handling within documented limits. The drill must state what disconnected operation cannot do: no payment terminals, no customer creation, no real-time stock, no immediate invoices and no InvoiceNow submission. It is not full offline POS, payment or invoicing functionality.

Before disconnecting, record open register, cached products, existing synthetic customers, current order count and user. Create permitted synthetic orders and attempted exception actions, noting which are blocked. Do not close or reload the browser, clear cache or site data, or claim that stock, payment and invoices are current while disconnected.

• Offline control: Permitted order; Expected result: Synthetic order remains identifiable for later synchronization; Owner: Cashier
• Offline control: Blocked functions; Expected result: Payment terminals, customer creation, real-time stock, immediate invoices and InvoiceNow submission remain unavailable; Owner: Outlet manager
• Offline control: Browser safeguard; Expected result: No reload, cache clearing or site-data deletion before synchronization; Owner: Technology owner
• Offline control: Incident record; Expected result: Start time, available functions, blocked actions and customer communication; Owner: Outlet manager

The test stops if browser or site-data integrity is at risk. Acceptance is based on documented behaviour in the controlled environment, not on an assumption that every offline order will be valid after reconnection.

6. Reconnect, invoice and prevent duplicates before close

After the network returns, wait for synchronization to finish while preserving the browser session and site data. Compare local and server order counts, references and statuses. Investigate missing, duplicated or changed orders before generating required delayed invoices or closing the register.

Reconcile payments, stock movements, invoices, accounting entries and uninvoiced orders. Confirm that an offline order does not create a second server order or a second invoice, that delayed invoices use the intended sequence and tax evidence, and that any payment-terminal or PayNow step is independently matched after connection resumes.

• Reconnection check: Order synchronization; Acceptance evidence: Local/server counts, references and statuses; Owner: Outlet manager
• Reconnection check: Delayed invoicing; Acceptance evidence: Intended sequence, tax evidence and no duplicate invoice; Owner: Back-office reviewer
• Reconnection check: Operational reconciliation; Acceptance evidence: Payments, stock, entries and uninvoiced orders; Owner: Accounting reviewer

Synthetic acceptance example: one permitted offline order, one attempted invoice action and one duplicate-prevention check are reconciled end to end. The cashier explains the order state, the outlet manager approves register recovery, and back office approves invoice, stock and accounting results. Reconnection alone is not the acceptance signature.

7. Apply aggregation and non-Peppol rules without losing originals

Use the IRAS InvoiceNow requirement and FAQ amended 26 October 2026 to review permitted POS, simplified-invoice and petty-cash aggregation. Create separate aggregation rules by outlet, register, business date or other allowed basis actually selected; do not invent a universal daily rule.

Scope covers standard-rated supplies and purchases, zero-rated supplies and purchases, and exempt supplies only; there is no general exempt-purchase category.

• Data path: POS and simplified invoices; Required source and extraction evidence: Source orders, receipts, included and excluded counts and aggregation-rule version; Owner and acceptance: Outlet manager and GST reviewer
• Data path: Petty cash; Required source and extraction evidence: Original receipts, claimants, supply categories and included IDs; Owner and acceptance: AP owner and GST reviewer
• Data path: Sales invoices issued outside the Peppol network; Required source and extraction evidence: Original invoice, solution extraction method, extraction owner and field-confidence review; Owner and acceptance: Solution owner and GST reviewer
• Data path: Purchase invoices recorded in the solution; Required source and extraction evidence: Original supplier invoice, recording owner, field-confidence review and duplicate check; Owner and acceptance: AP owner and accounting reviewer

Access Points do not convert paper or PDF documents into Peppol invoices. For both non-Peppol paths, preserve originals, extraction owner, field-confidence review, duplicate controls, accounting link, submission and acknowledgement.

Send the invoice data by whichever comes first: the date the relevant GST return is actually filed or that return’s filing due date. Record both candidate dates, aggregate submission timestamp, late reason and owner. Source orders and receipts remain available behind the aggregate for at least five years under the applicable recordkeeping review.

8. Match solution payloads and acknowledgements to accounting

The InvoiceNow acceptance row identifies the InvoiceNow-Ready Solution, activated GST submission feature, provider product/version, listed API, access point, payload ID and credential custodian. PINT-SG XML generation or import in Odoo 19 is not transport or an IRAS connector.

Singapore is absent from the reviewed lists of countries eligible for Odoo-operated Peppol registration in Odoo 19 and Odoo 20. This is not a statement that Singapore businesses cannot use Peppol; the separate provider and access-point path must be proven.

For each transaction or permitted aggregate, reconcile source orders, invoices, accounting entries, solution payload, provider submission list and IRAS acknowledgement ID. An acknowledgement confirms receipt. It is not buyer acceptance, confirmation of tax treatment, a GST return or payment. It does not establish IRAS clearance or bank reconciliation.

The SFFS Odoo page developed by Port Cities Singapore Pte. Ltd. lists InvoiceNow-Ready only; it is not evidence for core Odoo, Odoo S.A., Oakland or F5/F7/F8. Other SFFS and InvoiceNow-Ready Solution Provider (IRSP) rows verify only the expressly named provider products and APIs, not endorsement, security or statutory compliance.

The provider accepts transport and status evidence, the GST reviewer accepts data scope, and the return owner retains separate filing responsibility. Store correction versions, retries and duplicate-prevention references.

9. Reconcile the outlet chain and issue go/no-go decisions

The daily evidence chain connects order, receipt, invoice, stock movement, payment, accounting entry, aggregate InvoiceNow payload where applicable, provider acknowledgement, PayNow or other bank settlement and GST-return workpaper. Each link has a count, reference, expected state, actual state, residual and owner.

Review bank-feed timing independently. Odoo bank synchronization can involve default 12-hour synchronization and non-real-time or beta limitations depending on institution, provider and edition. A missing bank line at register close is routed through the documented pending and later-reconciliation procedure rather than marked settled from the POS screen.

• Go/no-go area: Outlet operation; Required acceptance: Hardware, access, invoices, refunds, mixed tenders and cash close; Owner: Outlet manager
• Go/no-go area: Recovery; Required acceptance: Offline incident, reconnection, delayed invoices and duplicate prevention; Owner: Back-office reviewer
• Go/no-go area: Settlement; Required acceptance: PayNow and other bank settlement with residual owners; Owner: Treasury reviewer
• Go/no-go area: InvoiceNow; Required acceptance: Aggregation, payload, acknowledgement and return workpapers; Owner: GST reviewer and provider

One outlet's acceptance does not automatically release another. The release authority reviews unresolved residuals and rollback evidence before go-live.

10. Hand over outlet-specific controls and training assets

The outlet pack contains configurations, hardware results, synthetic transaction scripts, opening and close templates, offline incident log, reconnection evidence, PayNow and bank reconciliation, aggregation rules, acknowledgements, unresolved exceptions and rollback contacts. Champion handover includes reassessment when provider, hardware, browser, network, tax guidance or procedure changes.

Provider, access-point and session-company examples are educational only, never Oakland references, recommendations, Singapore delivery evidence or proof of statutory capability. No session company, hardware vendor or payment institution is presented as an Oakland customer or local reference.

Odoo 20 capabilities require a separate comparison of actual manifests and views and acceptance on the deployed build; they are not Odoo 19 evidence. The GST and InvoiceNow readiness guide holds the canonical release-note and view-comparison boundary for Singapore PDF and Singapore Financial Reporting Standards questions.

Continue with the SGD migration and reconciliation guide and payroll boundaries and role-training guide. The unresolved qualified Singapore regulatory review and outlet-specific acceptance remain required before release.