SGD migration and reconciliation guide

1. Register sources, periods and archive ownership

Create a client-owned register with controlled tabs for source systems, entities, GST registration intervals, data objects, extracts, mappings, import runs, exceptions, control totals and approvals. Name the client migration owner, source-system owners, accounting reviewer, GST adviser, operations reviewer and Oakland import operator.

For QuickBooks, Xero or spreadsheet sources, record edition or organisation, hosting, legal entity, base currency, financial year, incorporation and registration dates, voluntary or compulsory history, special filing periods, source cut-off and read-only archive decision. Preserve the original export, report parameters, timezone, row count and file hash.

• Register group: Source identity; Minimum entries: System, edition or organisation, entity, hosting and base currency; Owner: Source-system owner
• Register group: Registration history; Minimum entries: Incorporation, voluntary and compulsory history and special filing periods; Owner: GST owner
• Register group: Extract evidence; Minimum entries: Cut-off, parameters, timezone, row count and file hash; Owner: Extraction owner
• Register group: Archive; Minimum entries: Read-only location, retention, retrieval test and custodian; Owner: Client evidence owner

Synthetic acceptance example: Entity B has a ledger export, a separate open-item report and bank statements from another source. The migration lead must demonstrate their shared cut-off and explain missing allocations before any import. Acceptance is a signed source register and retrieval test, not a folder of unlabelled files.

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. Assign stable identities and dependency-controlled import waves

Every account, tax code, contact, item, document, inventory record, bank and payment reference receives an external ID containing the source namespace and durable source identifier. Names and row numbers are never the sole identity.

• Import control: Identity map; Minimum entries: Source namespace, durable ID, target model and target ID; Acceptance owner: Migration lead
• Import control: Transformation; Minimum entries: Target field, default, dependency and create-or-update rule; Acceptance owner: Data owner and import operator
• Import control: Run evidence; Minimum entries: Import-run ID, source hash, mapping version, expected and actual counts; Acceptance owner: Import operator
• Import control: Exceptions; Minimum entries: Rejection log, rollback decision, corrected rerun and duplicate check; Acceptance owner: Data owner and reviewer

Order waves from accounting foundations and registration settings to taxes and journals, then contacts and items, open documents, inventory, opening balances, allocations and bank evidence. Corrected records update or deliberately skip known IDs instead of creating duplicates.

Synthetic acceptance example: a supplier is rejected because its default tax code was not loaded, followed by a bill that depends on that supplier. The exception log preserves both failures, the corrected dependency wave and the rerun result. The migration operator signs technical repeatability; the source owner signs business identity and duplicate resolution.

3. Map the Singapore chart, tax history and report boxes

The Odoo 19 Singapore package, Boxes 1–21 data and GST tax templates provide a starting structure. Fine-tune accounts, UEN and permit fields, GST codes, fiscal positions and report mappings against approved entity evidence. This work does not prove direct F5, F7 or F8 filing.

For InvoiceNow mapping, distinguish standard-rated supplies and purchases, zero-rated supplies and purchases, and exempt supplies only; there is no general exempt-purchase category. Current 9% applies only to applicable standard-rated supplies; historical and exceptional rows retain their actual treatment.

• Tax mapping field: Source label and effective period; Purpose: Preserves historical meaning; Owner: Source owner and GST adviser
• Tax mapping field: Transaction category and target code; Purpose: Separates supplies, purchases and exempt supplies; Owner: GST reviewer
• Tax mapping field: Place/time-of-supply evidence; Purpose: Supports the underlying transaction decision; Owner: GST adviser
• Tax mapping field: GST box and reverse-charge analysis; Purpose: Connects mapping to return workpapers; Owner: Return owner

Box 13 is conditional on the out-of-scope transaction forming part of revenue under the General Guide. Other out-of-scope rows are omitted. Reverse charge depends on imported-service or low-value-goods rules and input-tax restrictions, not a supplier's overseas address. Acceptance compares source return workpapers with target report results for every selected synthetic category.

4. Test SGD and rounding without universal precision

ISO 4217 identifies SGD as currency number 702 with minor unit 2, while the Odoo 19 SGD record uses S$, a 0.01 rounding factor and Cents. That display and currency-rounding evidence does not create universal precision for products, taxes, payroll, payments or foreign exchange. Cite the ISO list, Odoo 19 currency record and currency implementation.

Create separate policy rows for currency display, product and pricelist precision, tax calculation, discounts, payment and cash rounding, and foreign-exchange conversion.

• Test group: Currency display; Values and evidence: ISO reference, Odoo record, expected display and actual display; Owner: Accounting reviewer
• Test group: Product and tax; Values and evidence: Source amount, precision rule, tax result and rounding mode under test; Owner: Operations and GST reviewer
• Test group: Payment and cash; Values and evidence: Expected result, actual result and residual; Owner: Treasury reviewer
• Test group: Foreign exchange; Values and evidence: Rate value, date, source, expected SGD and actual SGD; Owner: Accounting reviewer

Synthetic cases include 0.01, 0.04, 0.05 and 0.09, plus -0.01, -0.04, -0.05 and -0.09, large values, mixed documents and multi-line invoices. These are non-commercial test values, not fees. No blanket reconciliation tolerance or single midpoint assumption is permitted.

5. Reconcile open items and foreign-exchange evidence

For every open invoice, bill and credit note, capture source ID, party, document and due dates, raw source currency and amount, transaction currency, exchange-rate value, rate date and source, original and outstanding amounts, tax lines, expected SGD, actual SGD, debit and credit control totals, allocation link, residual reason, owner and approval.

• Open-item field group: Document identity; Minimum entries: Source ID, party, dates, currency and original amount; Owner: AP/AR owner
• Open-item field group: Allocation; Minimum entries: Payments, credits, outstanding amount and allocation link; Owner: Accounting reviewer
• Open-item field group: SGD control; Minimum entries: Rate evidence, expected SGD, actual SGD and debit/credit totals; Owner: Accounting reviewer
• Open-item field group: Residual; Minimum entries: Reason, named residual owner, resolution and approval; Owner: Named residual owner

Include part payments, partial credits, voids, disputed balances, historical rate changes and later settlement. Where only a net open balance is exported, record the missing allocation evidence and obtain accounting approval for the chosen reconstruction. Do not create a fictitious payment or hide a difference in a general rounding account.

Synthetic acceptance example: a foreign-currency invoice has an opening allocation and a later settlement at a different reviewed rate. The reviewer must distinguish conversion difference, tax effect, rounding and unexplained residual. Acceptance requires open-item ageing, trial balance, currency entries and later bank matching to agree at their defined control levels, with every residual owned.

6. Bridge inventory, exceptions and late costs

Quantity, valuation and accounting are separate control totals. A stock export alone cannot prove all three.

• Inventory field group: Item identity; Minimum entries: Source item ID, target item, type, unit and tracking; Owner: Operations owner
• Inventory field group: Location and quantity; Minimum entries: Warehouse, location, quantity and open receipt or delivery; Owner: Inventory owner
• Inventory field group: Valuation; Minimum entries: Costing method, value, related accounts and late-cost evidence; Owner: Accounting reviewer
• Inventory field group: Exception; Minimum entries: Duplicate or missing rows, rejected dependencies, credit notes, voids and residual; Owner: Named residual owner

Exception cases include duplicate or missing rows, rejected units and accounts, credit notes, voids, historical cost changes, negative or zero quantities requiring review, late supplier costs and items sold before a related charge arrives. Record the source evidence, target treatment, accounting effect, operational effect, residual and owner. Do not use an unexplained opening entry to conceal missing valuation.

Synthetic acceptance example: a receipt is followed by a partial sale and then a late freight or supplier charge. Operations confirms quantity and availability, finance confirms valuation and entries, and both approve the resulting residual register. Any manual correction retains a reason, source attachment, preparer and independent reviewer.

7. Keep bank, PayNow and provider settlement columns apart

For each bank account, record institution, protected account reference, feed provider, edition, available history, last reconciled source balance and transaction, imported-history range, feed-start boundary, duplicate rule and manual statement fallback. Odoo 19 bank synchronization is institution/provider-specific and includes default 12-hour synchronization with non-real-time or beta limitations where documented.

• Settlement field group: Bank history; Minimum entries: Last reconciled balance, transaction, imported range and feed-start boundary; Owner: Treasury owner
• Settlement field group: Provider payout; Minimum entries: Gross sale, refund, fee, net settlement, payout ID and date; Owner: Payment operator
• Settlement field group: Bank match; Minimum entries: Bank line ID, duplicate rule, residual and reviewer; Owner: Treasury reviewer
• Settlement field group: PayNow evidence; Minimum entries: QR reference, customer completion, independent bank reference and reconciliation owner; Owner: Treasury/payment operator

Do not post a net deposit as sales or hide provider fees in an unexplained residual. A successful import or draft accounting entry is not settlement evidence.

For PayNow, retain invoice QR reference, customer bank-app completion, independent bank reference, gross receipt, any fee, net settlement and reviewer. The Singapore localization page documents invoice QR configuration. PayNow QR generation itself is not payment confirmation, settlement or reconciliation. Synthetic acceptance matches a QR-labelled invoice to an independently supplied synthetic bank settlement and then tests a refund and unmatched item.

8. Run rehearsal one as a traceable technical and financial test

Freeze the first source set and mapping version. Execute every wave with the intended operators and retain run IDs, source and expected counts, actual counts, rejects, rerun evidence and rollback results. Verify that corrected source rows do not create duplicates and that dependent failures remain visible until resolved.

• Reconciliation level: Finance; Required evidence: Source, expected, actual and residual for trial balance and open items; Acceptance owner: Accounting reviewer
• Reconciliation level: Tax; Required evidence: Source and target categories, GST boxes and return workpapers; Acceptance owner: GST reviewer
• Reconciliation level: Inventory; Required evidence: Quantity, value and accounting control totals; Acceptance owner: Operations and accounting reviewers
• Reconciliation level: Bank and providers; Required evidence: Balances, payouts, bank lines and settlement residuals; Acceptance owner: Treasury reviewer

Each business reviewer signs only their area. Technical import success is not accepted as proof of financial meaning.

Rehearsal one exit requires a defect register with severity, root cause, correction, rerun result and remaining limitations. Unknown source history, unavailable allocations and provider restrictions remain explicit. The team changes mapping or scope from evidence rather than introducing an unreviewed final-week transformation.

9. Run rehearsal two as the controlled cutover proof

The second of the two rehearsals uses corrected mappings and final-style extracts, roles, provider steps, cut-off rules and acceptance packs. Practise freeze approval, delta extraction, final imports, bank and provider boundaries, user access, operational smoke tests, reconciliation, release authority and rollback. Preserve differences from rehearsal one and explain why each correction works.

• Role: AP/AR; Practical acceptance: Collect and pay open items and apply credits; Evidence owner: Process owner
• Role: GST reviewer; Practical acceptance: Check categories, Boxes and return workpapers; Evidence owner: GST reviewer
• Role: Operations; Practical acceptance: Check inventory and outlet flows; Evidence owner: Operations owner
• Role: Treasury; Practical acceptance: Check bank and payment settlement; Evidence owner: Treasury reviewer
• Role: Administrator; Practical acceptance: Prove least privilege and audit access; Evidence owner: System owner

No accuracy percentage or elapsed implementation promise is inferred. Cutover proceeds only when the release authority sees signed control totals, resolved blockers, accepted residuals with named residual owners, working archive retrieval, provider evidence and a feasible rollback. Otherwise the release stops and the runbook is corrected.

10. Hand over the evidence and maintain version boundaries

The handover contains original extracts and hashes, source-to-target mappings, external IDs, import runs, rejection and rollback logs, both reconciliation packs, accepted residuals, archive instructions, provider contacts and revalidation owners. Client owners can reproduce the import decision without relying on an undocumented individual or private notebook.

Provider, access-point and session-company examples are educational only, never Oakland references, recommendations, Singapore delivery evidence or proof of statutory capability. Custom migration tooling, provider connectivity, core Odoo configuration and client accounting decisions remain separate acceptance layers.

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 POS go-live and recovery checklist and payroll boundaries and role-training guide. Each guide owns different evidence; none replaces the qualified human reviews or acceptance signatures named in this one.