Xero and MYOB to Odoo migration with AUD reconciliation

Establish separate Xero and MYOB source inventories

Begin with a read-only source register, not an import file. Xero discovery records Xero organisations, base currencies, tracking categories, bank accounts, connected apps and repeating transactions. MYOB discovery records the exact desktop and online products and versions, company files, cards, jobs, categories, tax codes and payroll history. Do not invent a common export structure across those sources.

For every extract, retain the report or screen, product version, filters, timezone, encoding, raw headings, extraction owner, row count and control total. Keep the raw file unchanged and work on a versioned transformation copy. Record attachments and integrations as their own objects because their identifiers and history may not appear in ledger exports.

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.

• Source container: use an example Xero organisation or MYOB company file. Owner: entity finance owner. Evidence: source identity and entity mapping. Result: Blocked pending client evidence.
• Structure: use region and service-line tracking for Xero, or job and category reporting for MYOB. Owner: reporting owner. Evidence: source and proposed management reports. Result: Blocked pending client evidence.
• Export evidence: use a named organisation or company-file report with filters. Owner: extraction operator. Evidence: version-specific report and parameters. Result: Blocked pending client evidence.
• Related evidence: use a connected-app ID and repeating invoice for Xero, or a card ID, attachment and payroll reference for MYOB. Owner: integration and data owners. Evidence: relationship and identifier map. Result: Blocked pending client evidence.
• Cutover baseline: use trial balance, open-item, locked-period and company-file reports as applicable. Owner: finance controller. Evidence: reports at the agreed cutover moment. 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. The guide is an evidence checklist, not a promise of automatic conversion.

Choose object scope and preserve source lineage

Decide explicitly which masters, open documents, detailed history, bank history, inventory, tax records, payroll YTD and attachments belong in Odoo or a controlled archive. “Move everything” is not a scope decision. Each object receives a business reason, source owner, target owner, dependency position, retention decision and reconciliation report.

Create stable external IDs using the source organisation or company-file namespace plus a durable record identifier. Names, card labels and invoice numbers alone are unsafe. Preserve every approved merge relationship when duplicate contacts or items are consolidated, and retain raw source values beside transformed values.

• External ID: xero-org-demo-contact-001 or myob-file-demo-card-001. Target decision: unique namespaced key. Owner: migration lead. Evidence: rerun does not create a duplicate. Result: Blocked pending client evidence.
• Contact merge: two approved duplicate source IDs. Target decision: one target with both lineage IDs. Owner: data owner. Evidence: merge approval and lineage report. Result: Blocked pending client evidence.
• Tracking or job: synthetic region or project. Target decision: approved analytic or project structure. Owner: reporting owner. Evidence: source and target management reports. Result: Blocked pending client evidence.
• Raw tax value: retain the legacy source code. Target decision: reviewed Odoo tax and grid mapping. Owner: Australian tax reviewer. Evidence: approved mapping and sample transaction. Result: Blocked pending client evidence.
• Attachment link: retain the source document and file reference. Target decision: target attachment or controlled archive. Owner: data owner. Evidence: readable file on the correct record. Result: Blocked pending client evidence.

Dependency order normally establishes companies, currencies, accounts, taxes, parties and items before documents, payments and inventory. A rejected parent record stops its dependent records, or routes them through a documented exception path; it does not leave unowned orphan rows.

Use a field-level mapping and rejection register

The mapping register records source object and field, raw value, transformation, target object and field, default, external ID, dependency, owner and expected control. Account types, GST treatment, item costing, payment terms and payroll codes require their relevant business reviewers. A technically valid value can still have the wrong meaning.

Every run retains created, updated, skipped and rejected counts. Rejection entries include the source row, rule, reason, correction, rerun owner and outcome. Define whether a rerun creates, updates, skips or rejects each known external ID, and prove the behaviour on a fixed sample before processing the full wave.

• Source row and rule: missing parent account on an invoice line. Owner: migration lead. Resolution: correct the parent mapping and rerun dependent records. Evidence: rejection cleared without a duplicate document. Result: Blocked pending client evidence.
• Unexpected blank: missing item unit on an open order. Owner: operations data owner. Resolution: supply the approved unit. Evidence: item and document acceptance linked. Result: Blocked pending client evidence.
• Duplicate identity: repeated card or contact identifier. Owner: business data owner. Resolution: approved merge or source correction. Evidence: approved target and retained lineage. Result: Blocked pending client evidence.
• Tax mismatch: source code conflicts with sample evidence. Owner: Australian tax reviewer. Resolution: stop the wave for review. Evidence: decision and revised mapping signed. Result: Blocked pending client evidence.
• Partial wave: parent loaded and child rejected. Owner: migration lead. Resolution: targeted child rerun or rollback. Evidence: dependency and reconciliation report. Result: Blocked pending client evidence.

Odoo's generic CSV/XLSX import guidance explains permanent imports and test options. It does not provide a native one-click or complete-history Xero or MYOB migration, and an import log is not business sign-off.

Test AUD currency and each rounding path separately

AUD is ISO 4217 code 036 with two minor units. Confirm the international definition in the ISO currency list, the Odoo 19 currency data and the currency model. Odoo 19's AUD record uses a 0.01 rounding factor.

That factor is not universal calculation precision. Unit-price and pricelist precision, tax calculation, currency rounding, payment allocation, FX conversion and cash rounding are configured and tested separately. Review cash rounding as its own feature rather than using it to explain unrelated differences.

• Cent boundaries: synthetic inputs A$0.01, A$0.04, A$0.05 and A$0.09. Owner: finance test owner. Evidence: stored, displayed, posted and reported values. Result: Blocked pending client evidence.
• Negative equivalents: synthetic inputs -A$0.01, -A$0.04, -A$0.05 and -A$0.09. Owner: finance test owner. Evidence: credit and negative-line behaviour. Result: Blocked pending client evidence.
• Multi-line document: mixed quantities, discount and tax. Owner: tax and operations owners. Evidence: line and document calculations reconciled. Result: Blocked pending client evidence.
• Payment: partial payment and later settlement. Owner: receivables or payables owner. Evidence: allocation, residual and bank value. Result: Blocked pending client evidence.
• Cash rounding: client-approved synthetic cash sale. Owner: finance controller. Evidence: separate rounding account and entry. Result: Blocked pending client evidence.

Write the expected result before running each test. Any residual receives an explanation, owner and disposition; no blanket tolerance or universal midpoint rule is accepted. Changing the expectation after seeing the result requires a documented review.

Reconcile foreign currency to source, expected and actual AUD

For foreign-currency rows, retain the original transaction amount and currency, company currency, exchange rate, rate date, rate source and selection policy. Then record source, expected and actual AUD values, debit and credit totals, GST amounts and residual. An exchange-rate field without its date and source is not sufficient lineage.

Test an invoice, later payment, partial payment, credit note and bank settlement in a mixed-currency scenario. Distinguish an accounting FX difference, a rounding difference and a migration error. The project does not invent an official rate provider or silently overwrite a residual to make the report appear balanced.

• Original amount and currency: synthetic NZD supplier invoice. Owner: payables data owner. Evidence: raw source line and document. Result: Blocked pending client evidence.
• Rate provenance: client-approved rate, date and source. Owner: finance controller. Evidence: rate record and selection policy. Result: Blocked pending client evidence.
• Expected and actual AUD: independently calculated expectation. Owner: migration reviewer. Evidence: document, journal and report values. Result: Blocked pending client evidence.
• Later settlement: partial payment at a different approved rate. Owner: treasury or finance owner. Evidence: allocation and FX entry reconciled. Result: Blocked pending client evidence.
• Residual: unexplained difference held open. Owner: finance controller. Evidence: reason, action, owner and closure approval. Result: Blocked pending client evidence.

No universal precision or residual tolerance is applied across currencies. Acceptance occurs at the agreed document, line, account and report levels with every remaining difference understood.

Prove open items, inventory, attachments and integrations

Open receivables and payables reproduce original documents, due dates, tax, currencies, payments, credits and outstanding allocations. Reconcile them with the trial balance at the same cutover moment. Avoid loading a summary opening balance and the same open documents twice.

Inventory acceptance includes item, unit, location, tracking, quantity, unit cost, value, valuation method and linked accounts. Attachments are checked for correct parent, readability, access and integrity. Integrations receive identifier, direction, error, duplicate and cutover tests; a master-data import does not prove the continuing interface.

• Part-paid invoice: payment and later credit note. Owner: receivables owner. Evidence: open balance and allocations agree. Result: Blocked pending client evidence.
• Supplier bill: deposit and partial allocation. Owner: payables owner. Evidence: payable and bank effects agree. Result: Blocked pending client evidence.
• Tracked inventory: partial receipt and later cost adjustment. Owner: inventory and finance owners. Evidence: quantity, value and ledger linkage. Result: Blocked pending client evidence.
• Attachment: long filename linked to a source bill. Owner: data owner. Evidence: correct readable target or archive. Result: Blocked pending client evidence.
• Integration: existing app receives a migrated invoice. Owner: integration owner. Evidence: stable ID, no duplicate and recoverable error. Result: Blocked pending client evidence.

Late supplier or customer corrections follow a controlled route that preserves source lineage. Any targeted rollback is limited to the failed wave and does not erase unrelated accepted records.

Reconcile bank history, Basiq and ABA payment evidence

An ongoing bank feed and historical statement migration are different workstreams. Review the Odoo 19 bank synchronisation and Basiq documentation, then check the exact institution and account against Basiq's supported-institution information. CDR connectivity is opt-in and provider-, institution- and account-specific.

Test consent, account eligibility, available history and non-real-time behaviour. Controlled statement import remains a fallback. Record the last reconciled transaction, feed-start behaviour, older-history source, expected statement balance and duplicate-prevention rule where feed and imported lines meet.

• Historical boundary: statement import ends as the feed begins. Owner: bank reconciliation owner. Evidence: no missing or duplicate account lines. Result: Blocked pending client evidence.
• Pending transaction: feed status differs from the settled bank item. Owner: treasury owner. Evidence: status and later settlement retained. Result: Blocked pending client evidence.
• ABA upload: synthetic supplier payment file. Owner: payment operator. Evidence: file reference separate from bank response. Result: Blocked pending client evidence.
• Bank outcome: approval, debit and settlement checked. Owner: authorised finance roles. Evidence: bank evidence and reconciliation. Result: Blocked pending client evidence.
• Correction: rejected or late supplier correction. Owner: payables owner. Evidence: reversal or correction linked without a duplicate. Result: Blocked pending client evidence.

An ABA file's creation or upload is not payment proof. Bank approval, debit, settlement and reconciliation require separate evidence, and fees are not hidden inside an unexplained residual.

Scope payroll business flows and YTD migration

Accounting migration does not define payroll YTD migration. Identify the payroll system of record, employee categories, pay events, awards or agreements, allowances, super funds, YTD balances and opening liabilities. Decide which records belong in Odoo, which remain in the source and which require a specialist process.

The reviewed Odoo 19 Australian payroll documentation identifies business-flow exclusions for Foreign Employment Income (FEI), actors and performers, death-benefit reporting, withholding payer number (WPN) instead of an ABN, and allowances subject to varied withholding. These are not only YTD-import exclusions. Affected populations are outside standard Odoo Australian payroll scope and require joint Odoo and specialist assessment before configuration or migration.

• Standard payroll population: employee without an identified business-flow exclusion. Owner: payroll implementation owner. Evidence: approved configuration and source-to-target YTD reconciliation where relevant. Result: Blocked pending client evidence.
• Foreign Employment Income (FEI), actors and performers: synthetic excluded categories. Owner: Odoo and specialist assessors. Evidence: joint business-flow assessment before configuration or migration. Result: Blocked pending client evidence.
• Death-benefit reporting: synthetic excluded payment case. Owner: Odoo and specialist assessors. Evidence: assessment outside standard Odoo Australian payroll scope. Result: Blocked pending client evidence.
• Withholding payer number (WPN) instead of an ABN: synthetic excluded employer arrangement. Owner: Odoo and specialist assessors. Evidence: assessment before configuration or migration. Result: Blocked pending client evidence.
• Allowances subject to varied withholding: population requiring current award and payroll review. Owner: Odoo and specialist assessors. Evidence: classification, business-flow assessment and target decision. Result: Blocked pending client evidence.

Single Touch Payroll (STP), PAYG withholding, PAYG instalments, BAS and SuperStream remain separate acceptance paths. A QE-first design is correct; the ATO also accepts super liability plus ordinary time earnings (OTE) until 30 June 2027, so an accepted transition OTE submission is not impossible. Legacy quarterly payment assumptions do not replace Payday Super deadlines.

Complete two rehearsals and a signed cutover pack

The first rehearsal proves extraction, cleansing, mappings, dependency order, rejection handling and duplicate-safe reruns on representative data. The second uses corrected near-final extracts and includes attachments, integrations, user roles, bank history, inventory and payroll YTD decisions. Both retain source, expected and actual results and all residual ownership.

• Trial balance: debit, credit and account-level comparison. Owner: finance controller. Stop condition: unexplained imbalance. Result: Blocked pending client evidence.
• Open receivables and payables: documents, allocations and ageing. Owner: finance process owners. Stop condition: duplicate or incorrect open balance. Result: Blocked pending client evidence.
• Inventory: quantity, value, location and ledger. Owner: operations and finance. Stop condition: open valuation or quantity difference. Result: Blocked pending client evidence.
• GST and bank: tax workings, statement positions and duplicates. Owner: tax reviewer and bank owner. Stop condition: incorrect treatment or missing lines. Result: Blocked pending client evidence.
• Attachments, roles and integrations: readable evidence, access and interface tests. Owner: data, security and integration owners. Stop condition: critical access or duplicate failure. Result: Blocked pending client evidence.

Sign the cutover and preserve post-release evidence

The cutover runbook assigns the final export, freeze, deltas, integration switch, reconciliation and fallback decision. Keep the source readable under the retention policy. Acceptance applies to the named Odoo version and deployed build; later versions require separate assessment.

After sign-off, continue with the GST and BAS evidence guide, POS go-live checklist and payroll role guide. Their owners and acceptance packs join the same controlled release rather than being treated as secondary checks.