QuickBooks to Odoo migration in Cambodia: a step-by-step guide

Why Cambodian businesses migrate off QuickBooks

QuickBooks Online has no Cambodia localization and no KH chart of accounts, and multi-currency only appears on the Essentials tier and above [verify whether KHR is among the currencies QuickBooks Online supports for your subscription]. In practice, Cambodia SMBs on QBO run USD books and reconcile KHR manually, which works until GDT mandates real e-invoicing (the CamInvoice rollout started May 2025) or until the business grows past the point where manual reconciliation is sustainable. QuickBooks Desktop is better on the multi-currency front but has no API integration with GDT's e-VAT system and no path to the Cambodia chart of accounts without custom workarounds. The pricing model constrains you too, though not the way it is usually described: QuickBooks Online is priced per company file, not per user, and each tier caps the number of seats. US list pricing in 2026 runs $38 per month for Simple Start (1 user), $75 for Essentials (3 users, and the first tier to include multi-currency), $115 for Plus (5 users), and $275 for Advanced (25 users). Growth pushes you up a tier rather than adding a per-seat fee, and every additional legal entity needs its own subscription [verify current pricing for your region].

• No Cambodia localization and no KH chart of accounts; multi-currency needs the Essentials tier or above, and most Cambodian deployments end up USD-only in practice [verify whether KHR is available in QuickBooks Online multi-currency for your subscription].
• No GDT e-VAT API integration: monthly filings are manual re-entry, typically 2–3 staff-days per cycle.
• No Cambodia chart-of-accounts localization: WHT tax codes must be configured manually and are prone to error.
• Seat caps per subscription tier (1 user on Simple Start, 3 on Essentials, 5 on Plus, 25 on Advanced), and a separate subscription for every legal entity.
• No CamInvoice support: the GDDE B2G e-invoicing platform launched May 2025 has no QuickBooks adapter.

The triggering event for most migrations is one of three: a GDT audit that surfaces WHT misclassification or rounding discrepancies; a growth event (new entity, new business line, or new government contract) that the current system cannot handle; or a new hire finance manager who has used modern ERP and refuses to continue with manual workarounds. All three are happening more frequently in Phnom Penh in 2025–2026 as GDT tightens its API submission requirements. If the question is a wholesale system change rather than a like-for-like accounting replacement, our ERP in Cambodia guide frames that decision; businesses coming off Peachtree instead face a harder extraction problem, covered in our guide to migrating off Peachtree (Sage 50).

What is Odoo and why is it the most common KH replacement?

Odoo is an open-source ERP platform that ships a native Cambodia accounting localization. The l10n_kh module ('Cambodia - Accounting') comes from Odoo S.A., is licensed LGPL-3, and is included in the Community edition from Odoo 18 onwards; it installs the Cambodian chart of accounts, the VAT tax codes (10%, 0%, exempt), withholding-tax setup, and tax form templates. Odoo 17 and earlier have no official Cambodia localization. Community edition has no per-user licensing fee. Multi-currency support, including KHR/USD, is native. What the localization does not include is filing: it can post transactions to the correct KH accounts, but the GDT submission adapter is a separate custom module that reads from Odoo and pushes to GDT.

The KH localization module must be installed on a clean Odoo instance before any transactions are posted. This is the most common installation mistake: installing the localization on an instance that already has posted transactions does not retroactively remap those transactions to the KH chart. For a migration project, this means Odoo is set up fresh, the localization is installed first, and then the migration data is loaded, not the other way around.

• Odoo Community: $0 per-user licensing. Requires self-hosting (VPS or Odoo.sh). Custom modules allowed.
• Odoo Enterprise: priced per user per month, and Odoo serves a different pricelist depending on where you browse from, so a figure quoted in a blog post is not the figure you will be charged. Checked in July 2026 the Standard plan ran from roughly USD 9 per user per month on the Asia-Pacific list to around USD 25–31 on the US list [verify current pricing for your region on odoo.com/pricing]. Adds the full Accounting app, dynamic financial reports, bank sync, CRM, and manufacturing. Custom adapters are permitted on either edition.
• Odoo.sh hosting: $50–$200/month depending on instance size [verify against current Odoo.sh pricing for your worker count]. Managed hosting with custom module support.
• KH localization: native l10n_kh module from Odoo S.A., shipped in the Community edition from Odoo 18 onwards. No official Cambodia localization exists for Odoo 17 or earlier.
• Alternatives considered: SAP Business One (mid-market, higher cost), Zoho Books (USD-centric, limited KH localization), Xero (no KH chart, no GDT adapter).

Migration project shape

A QuickBooks to Odoo migration runs in six sequential phases. The critical constraint: do not skip or compress the parallel-run phase. One full month-end cycle in parallel (both systems open, both reconciled, before cutover) is the minimum. Skipping parallel run is the single most common cause of post-cutover chaos.

1. Discovery (1 week): audit the QuickBooks file, agree on a cut-off date, map stakeholders, and identify data gaps (missing TINs, unbounded rounding, unreconciled suspense accounts).
2. COA mapping (1–2 weeks): map every QuickBooks account to its Odoo KH equivalent. Gap decisions made in writing: absorb, create, or close-out.
3. Odoo setup (2–3 weeks): install Odoo, apply KH localization, configure tax codes, set up KHR and USD bank journals, configure NBC rate feed.
4. Data migration (1–2 weeks): migrate opening balances, open AR/AP invoices, fixed-asset register, customer and vendor master (with TINs).
5. Parallel run (2–3 weeks): both systems open. Month-end processed in both. Reconcile to riel and cent before cutover approval.
6. Cutover and GDT go-live (1–2 weeks): close QuickBooks as active system. Switch GDT filing to Odoo (adapter must be live). Archive QuickBooks for historical access.

Total: 8–13 weeks for a single-entity Cambodia SMB. Add 4–8 weeks per additional legal entity. The GDT e-VAT adapter runs as a parallel project from week 1 and should reach go-live on the same day as the main system cutover. See our API integration practice for the adapter scope and our accounting system solutions for the full migration context.

Cost

A fixed-scope QuickBooks to Odoo migration for a single-entity Cambodia SMB runs $4,000–$9,000. Scope variables that move the number: how clean the QuickBooks data is (unreconciled suspense entries multiply remediation time), whether fixed assets are in QuickBooks or a separate register, and whether the COA mapping is straightforward or requires substantive restructuring.

• Discovery sprint: $500 (deducted from project fee if you proceed).
• Migration build: $3,500–$8,500 depending on scope.
• GDT e-VAT adapter: quoted separately; see our API integration practice. Typical: $2,500–$6,000.
• Odoo ongoing: $0/year (Community self-hosted) or Enterprise at a per-user monthly rate set by your region's pricelist [verify current pricing for your region].
• Hosting: $50–$200/month VPS or Odoo.sh [verify against current Odoo.sh pricing].
• Training: budgeted at 2–5 days per accounting user. Not included in migration quote.
• ROI vs QuickBooks: positive within 12–18 months on licensing alone for teams of 5+ users.

Step-by-step migration plan

The eight operational steps below map onto the project phases above. Each step has a named owner, a clear deliverable, and a go/no-go gate before the next step starts.

1. Export QuickBooks data: use QuickBooks's built-in IIF export for accounts, customers, vendors, and items. Export the trial balance as of the cut-off date. Export open invoices (AR) and open bills (AP) as of the cut-off date. Export the fixed-asset schedule from QuickBooks or the external register. Note: QuickBooks Desktop IIF exports are more complete than QBO CSV exports; if on QBO, use the QBO API or the accountant export tools to get structured data.
2. COA mapping review: go through the exported account list line by line. Classify each account against the Odoo KH chart. Flag accounts with no clear equivalent (typically old suspense or clearing accounts). Decision gate: are any accounts being retired at cut-off? What happens to their balances?
3. Build and configure Odoo: fresh instance, KH localization first, then tax codes, bank journals, NBC rate configuration, and customer/vendor master with TINs. Do not import any transaction data yet.
4. Opening balances: post the trial balance as of the cut-off date as a single journal entry in Odoo. Verify that Odoo's balance sheet matches the QuickBooks trial balance at cut-off, to the riel. Any discrepancy here will compound through every subsequent reconciliation.
5. Open AR/AP migration: import outstanding customer invoices and vendor bills as of the cut-off date. These are the invoices that were open in QuickBooks at cut-off and have not yet been paid. Verify ageing schedules match between QuickBooks and Odoo for the cut-off date.
6. Fixed-asset register: rebuild the fixed-asset register in Odoo's asset module. For each asset: original cost, acquisition date, depreciation method, accumulated depreciation to cut-off date, and net book value. Verify the NBV total matches the balance sheet opening entry.
7. Parallel run (one full month-end): both systems open. Process all invoices and payments in both. Close month-end in both. Compare: P&L, balance sheet, AR ageing, AP ageing, and the VAT return output. Reconcile every discrepancy before declaring the parallel run clean.
8. Cutover: close QuickBooks as the active system. Switch all invoice processing and bank reconciliation to Odoo. Confirm GDT adapter is live and first filing will come from Odoo. Archive QuickBooks with access documented for the finance team.

Data migration: what transfers cleanly, what does not

Not everything in QuickBooks migrates cleanly. Knowing what transfers automatically, what requires manual work, and what gets left behind shapes the migration budget and timeline.

• Transfers cleanly: customer and vendor master data (name, address, contact), open invoices (unpaid AR/AP as of cut-off), chart of accounts structure (after mapping), product and service list (name, price, tax code).
• Requires manual work: TINs on customer/vendor records (often missing in QB; must be collected before go-live), fixed-asset register (cost and accumulated depreciation must be entered asset-by-asset), bank reconciliation history (import statements into Odoo; do not try to migrate the reconciliation itself).
• Does not migrate (stays in QB archive): closed historical invoices (invoices paid before cut-off), bank reconciliation history (pre-cut-off), memorized transactions and recurring entries (must be rebuilt as Odoo automated entries), custom QuickBooks reports (must be rebuilt in Odoo's report engine or a BI tool).
• Specifically complex: multi-currency historical invoices where the exchange rate used in QB differs from the NBC rate. Document the methodology; do not attempt to reconcile historical rates to NBC; accept the legacy variance and enforce NBC discipline from the cut-off date forward.
• Fixed-asset depreciation history: 80% of Cambodian QB files have a fixed-asset schedule that was tracked outside QuickBooks (in Excel) rather than inside it. The Odoo migration involves building the asset register from scratch using the external schedule; this is manual work, typically 2–5 days for a business with 20–100 assets.

Common pitfalls

These are the failure modes we see repeatedly across Cambodia QuickBooks migrations: not edge cases but recurring patterns.

• KHR rounding drift: QB invoices in USD converted to KHR at historical rates produce cent-level differences when reconciled in Odoo at NBC daily rates. These accumulate into filing discrepancies. Accept the historical variance at cut-off; enforce NBC rates in Odoo from day one. See the GDT e-VAT rounding rules.
• WHT code misclassification: QB does not enforce the Cambodian WHT rates (15% on services, royalties, and interest paid to residents, 10% on rental, 14% on payments to non-residents) by counterparty and payment type. When migrating vendor records, each vendor must be classified so the correct WHT rate applies in Odoo automatically. Businesses that skip this step get WHT misclassification notices from GDT, one of the silent failure modes catalogued in the GDT e-VAT pitfalls.
• VAT codes mapped to wrong accounts: QB uses 'GST' as its tax code in some locales; Odoo KH uses 'VAT 10%/0%/exempt'. If these are mapped incorrectly during migration, the VAT return totals in Odoo will be wrong from the first filing. Verify tax code mapping against a real test invoice before processing live transactions.
• Missing TINs: QB allows invoice creation without a buyer TIN. GDT does not. Customer TINs must be collected and entered before go-live, not during the first month of live operation.
• Year-end timing mismatch: if the migration cut-off date is mid-year, the Odoo opening balance reflects an in-year position, not a clean year-end close. The Odoo P&L for the full year will only show the post-cut-off period; the pre-cut-off period stays in QB. This is expected and manageable, but must be clearly communicated to the auditor before year-end audit.
• GDT adapter not ready at cutover: the single most dangerous gap. If the Odoo system goes live but the GDT adapter is not ready, the business must continue manual filing from QB or file manually from Odoo exports, which is exactly the workflow the migration was supposed to eliminate. Start the adapter project at week 1, not week 8.

Should you migrate now or wait?

Use this decision framework. Migrate now if: you have more than 5 accounting users (licensing ROI is immediate); CamInvoice is in scope for your government contracts (no QB adapter exists); you have significant KHR exposure that requires NBC-rate discipline on every invoice; or a GDT audit has surfaced discrepancies in your current system. Defer if: you are below 5 users, USD-only, no government contracts, and the current manual GDT workflow is manageable at your filing volume. On timing, be honest about what is known: no B2B mandate date has been published, so anyone quoting you one is guessing. Plan on the business case rather than on a deadline, and treat a published B2B circular as the moment the queue for integration vendors forms.

FAQ

Can we keep QuickBooks running as a read-only archive?

Yes, and you should. QuickBooks remains accessible for historical reports and audit queries. The licence can be downgraded or cancelled for new transactions; some businesses keep an offline Desktop licence specifically for this purpose. Document the archive location and who has access before migration closes.

How much training time do accounting staff need for Odoo?

Budget 2–5 days per accounting user for structured training, plus 30 days of supported live use post-go-live. Users trained on QuickBooks find Odoo's double-entry model familiar; the difference is the journal-centric workflow and the more granular tax-code discipline. Do not skimp on training; a confused accountant posting to the wrong journal in month 1 creates reconciliation problems that take months to unwind.

Do we need to switch at year-end?

No, but year-end is the cleanest cut-off. Mid-year migrations are common: agree on a month-end cut-off date, migrate the in-year opening balance, and run parallel through one month. The auditor needs to know the cut-off date and the methodology so they can reconstruct the full-year P&L from two systems.

Can we keep QuickBooks for payroll and migrate only accounting?

Possible but creates a data-flow problem: payroll journal entries from QB must be manually re-entered in Odoo each pay cycle. Better to scope the full migration including payroll or to use Odoo's payroll module from day one. Hybrid setups where one system handles payroll and another handles accounting are a recurring maintenance burden.

What about ABA Bank / Wing / Bakong integration?

Odoo has no native ABA, Wing, or Bakong bank feed. Bank reconciliation in Odoo for Cambodian banks is typically done by importing bank statements (CSV or MT940 format) manually or via a custom bank-feed connector. This is a known gap for Cambodian Odoo deployments; plan for manual bank statement import in the initial setup. See our API integration practice for custom bank integration scope.

What if we have custom forms in QuickBooks (custom invoice templates, custom reports)?

Custom invoice templates must be rebuilt in Odoo's QWeb report engine. Custom reports must be rebuilt in Odoo's built-in report designer or exported to a BI tool. These are typically scoped as separate deliverables after the core migration; do not include them in the migration budget unless specifically scoped.

Can we run Odoo Community on Odoo.sh?

Yes. Odoo.sh supports Community edition with custom module installation. Odoo Online (cloud SaaS) does not; it restricts custom module installation, which means the GDT adapter cannot run on Odoo Online.

What if we want Xero or Zoho instead of Odoo?

Both are valid accounting tools but have the same GDT gap as QuickBooks: no native KH e-VAT integration, no Cambodia chart-of-accounts localization at all, where Odoo ships the native l10n_kh module from Odoo 18 onwards. A custom GDT adapter is needed regardless of which platform you choose. For very small businesses (under 5 users, USD-only, minimal GDT exposure), Xero or Zoho Books may be simpler to operate. For businesses with KHR complexity, government contracts, or ERP expansion plans, Odoo is the stronger foundation.