ERP implementation timeline in Cambodia: realistic phase-by-phase plan

What does a Cambodia ERP project actually take?

A Cambodia SMB ERP project (single entity, standard VAT, Odoo or equivalent) takes 16–22 weeks end-to-end when properly scoped and resourced. Mid-market projects with multiple legal entities run 26–40 weeks. Large enterprise deployments (multi-country, multi-system integrations, or complex manufacturing) run 40+ weeks. Cambodia-specific factors add 2–4 weeks versus the Southeast Asia average: GDT e-VAT API integration (a parallel workstream that does not exist in most regional deployments), KHR/USD dual-currency chart setup and reconciliation, Khmer-language documentation and training, and the KH accounting year-end pressure (many businesses want to cut over at the fiscal year boundary). Below: a phase-by-phase breakdown with realistic week ranges and the specific Cambodia factors that affect each phase. This assumes the buying decision is already made; if it is not, our ERP in Cambodia guide covers what an ERP costs here and which platforms fit.

Phase 0: Pre-engagement (1–2 weeks)

Before any contract is signed, the engagement starts with a pre-discovery sprint: a paid one-week assessment that produces a data audit, a GDT readiness score, and a fixed-scope project quote. This phase is non-negotiable for ERP projects in Cambodia; the state of the source data (QuickBooks, Peachtree, spreadsheets, or a legacy home-grown system) determines migration scope more than any other variable. Businesses that skip pre-engagement discovery and sign on a rough estimate routinely hit a 30–50% cost overrun when the real data state emerges during Phase 3.

• Data audit: extract and assess source system data (chart of accounts structure, customer and vendor TIN population rate, open AR/AP ageing, fixed-asset register completeness, and KHR/USD multi-currency transaction history).
• GDT readiness assessment: score the business against the 25-point GDT e-VAT checklist: VAT registration status, TIN on customer records, current filing workflow, and e-Tax portal credential health.
• Scope and fixed-price quote: produce a documented project scope with phase durations, deliverables, and acceptance criteria. Fixed-price quote issued after discovery, not before.

Phase 1: Discovery and scope (2–3 weeks)

With the pre-engagement data in hand, Phase 1 maps the business processes in detail. This is where scope is locked, module selection is made, and licensing decisions are finalised. The output is a signed scope document that both sides commit to. Changes after sign-off are formal change requests, not free additions.

• Process mapping: document the as-is workflow for each module in scope (order-to-cash, purchase-to-pay, inventory movements, payroll, reporting). Map to the target system's process model and identify gaps (processes the ERP does not cover natively that require customisation).
• Gap analysis: document every gap between the business's current process and the ERP's standard behaviour. Each gap gets a decision: accept the ERP's way, configure around it, or customise. Customisations are the primary driver of scope creep; identify them all in Phase 1.
• Licensing decision: Odoo Community vs Enterprise, or equivalent platform decision. Confirmed in writing with cost implications documented.
• KH-specific scope items locked: GDT adapter (yes/no, which tax types), CamInvoice readiness (yes/no, based on B2G exposure), Khmer UI requirements, bank integration scope (ABA, Wing, Bakong; each is a separate integration item).

Phase 2: System setup and configuration (4–8 weeks)

The ERP instance is installed (or cloud environment provisioned) and configured to the signed scope. This is the longest single phase for simple deployments and runs in parallel with data migration preparation. Configuration errors here (particularly in the chart of accounts, tax codes, and multi-currency setup) are the most expensive to fix post-go-live.

• Module installation and KH localization: install the Cambodian chart of accounts localization (on Odoo, the native l10n_kh module from v18 onwards). Agree the account numbering with your auditor rather than checking it against a national standard, because Cambodia mandates reporting standards (CIFRS), not a chart of accounts. Do not start with a generic chart and patch later; the rebuild cost is high.
• Chart of accounts (COA): configure all accounts required for GDT compliance: output VAT, input VAT credit, WHT payable (a separate account per rate you incur: 15% resident services, 10% rental, 14% non-resident), salary tax payable, KHR and USD bank/cash accounts.
• Tax codes: configure VAT 10%, VAT 0% (export), VAT exempt, the WHT rates you incur (15%/10%/14%), and Tax on Salary. Each must be linked to the correct COA account and tested with a sample invoice before migration proceeds.
• Multi-currency setup: configure KHR and USD journals, NBC daily rate source, and rounding rules. Test multi-currency invoice posting and verify KHR amounts match expected NBC-rate conversions.
• Customer and vendor master configuration: establish TIN field population as a mandatory field. Set up counterparty-type classification for WHT (resident company, resident individual, non-resident).
• Banking journals: configure separate KHR and USD bank journals. No bank feed integration with ABA, Wing, or Bakong is available natively; plan manual CSV import or commission a custom bank connector.

Phase 3: Data migration (3–5 weeks)

Data migration is the phase most businesses underestimate and the phase that most consistently causes overruns in Cambodia deployments. The core issue: source data is almost never as clean as assumed. QuickBooks and Peachtree files accumulated over 5–10 years contain unreconciled suspense entries, missing TINs on customer records, inconsistent exchange rates on historical invoices, and flat-file encoding issues that require remediation before loading.

• Master data migration: customer and vendor records (with TIN population; missing TINs must be collected before migration, not after go-live), product catalogue, employee records.
• Opening balances: agree on a cut-off date (ideally end of a closed accounting period). Migrate the trial balance as of that date as opening journal entries in the new system. Reconcile to the riel and the cent before proceeding.
• Open AR/AP: migrate all unpaid customer invoices and outstanding vendor bills as of the cut-off date. Reconcile ageing reports in old and new system before finalising.
• Fixed-asset register: migrate original cost, acquisition date, depreciation method, and accumulated depreciation to cut-off. Fixed-asset migration is more involved than it appears; do not leave it for the last week.
• KHR rounding audit: before loading, audit the KHR amounts on historical USD invoices for rounding consistency. Inconsistent historical rates surface during the parallel run and create reconciliation noise. Document the historical rate source and accept the variance in writing.

Phase 4: GDT integration (parallel, 4–8 weeks)

The GDT e-VAT adapter build runs as a parallel workstream from Phase 1 onwards, not sequenced after the ERP configuration. This is the most common sequencing mistake in Cambodia ERP projects: treating GDT as an afterthought that gets bolted on after the rest of the system is configured. When that happens, the adapter is not ready for the parallel run (Phase 6) and delays go-live by 4–8 weeks. Start the adapter build in Phase 1, run sandbox testing through Phases 2 and 3, and target adapter go-live readiness by the start of Phase 6.

• Week 1 (parallel with Phase 1): data mapping. Map ERP invoice fields to the fields GDT requires. Flag gaps (missing TIN fields, WHT code mismatches, KHR rounding rules).
• Weeks 2–6 (parallel with Phases 2–3): adapter build. TypeScript or Python adapter, GDT sandbox endpoint, retry logic, error alerting (email and Telegram), audit log table.
• Weeks 5–7 (parallel with Phase 3): sandbox testing. Run 30 days of historical invoices through the adapter against GDT sandbox. Reconcile filed totals. Fix edge cases in WHT classification and multi-currency rounding.
• Weeks 7–8: UAT. Your accountant runs live invoices through the adapter in parallel with the existing filing workflow. Resolve discrepancies before go-live.
• CamInvoice (if in scope): GDDE partner registration runs in parallel; start on day 1. Allow several weeks and confirm the current lead time with GDDE [no published service standard exists]; without production credentials you cannot go live on CamInvoice. See the CamInvoice integration guide for the registration path.

Phase 5: User training (2–3 weeks)

Training is consistently underestimated in Cambodia ERP projects. A 1-hour walkthrough the week before go-live is not training; it is the fastest path to a chaotic first month. Budget 3–5 days of structured training per accounting user, plus separate training sessions for warehouse staff, sales users, and management reporting consumers. Khmer-language training materials are not optional for businesses with non-English-speaking staff; producing them takes time and must be planned in this phase, not improvised at go-live.

• Role-based training: separate sessions for accounting (COA, journals, tax codes, GDT filing), operations (inventory, purchasing, sales orders), management (dashboards, reporting). Do not mix roles in a single training session.
• Khmer-language documentation: produce Khmer-language quick-reference cards for the most common accounting workflows (VAT invoice creation, WHT application on vendor bills, month-end closing steps). These do not need to be full manuals; one page per workflow is enough for trained users.
• GDT adapter training: finance manager specifically must understand how the adapter works, where to find the submission log, what error codes mean, and how to escalate a failed submission before the filing deadline.

Phase 6: Parallel run (2–4 weeks)

The parallel run is the highest-confidence gate before go-live: both the old and new systems run simultaneously through one full accounting cycle (one month-end close). Every transaction is posted in both systems; the trial balances and VAT return outputs are reconciled line by line. Do not skip this phase to save time. A parallel run that surfaces a $500 KHR rounding discrepancy is far cheaper than a GDT audit that surfaces the same discrepancy 18 months after go-live. Accept that your accounting team will be double-posting for 2–4 weeks; communicate this clearly before Phase 6 starts.

• System of record for GDT filings during parallel: one system files; the other produces the output for reconciliation only. We recommend continuing to file from the old system during parallel run and switching on the same day as cutover.
• Reconciliation targets: trial balance must agree to riel and cent. VAT return output from new system must match old system within an accepted variance (document the variance and the reason before sign-off). Open AR/AP ageing must match.
• Go/no-go decision: at the end of the parallel run period, the project team and finance manager formally sign off that reconciliation is complete and the new system is ready to become the system of record.

Phase 7: Cutover (1 week)

Cutover is the shortest phase but requires the most discipline. The data freeze date is announced at least two weeks in advance: no new transactions in the old system after that date. The cutover sequence: final data freeze in old system, any remaining open items migrated to new system, GDT filing switches to new system, new system becomes the live system of record. The go-live decision must be made by a person with authority to make it (typically the CFO or owner), not the IT team or the implementation partner.

• Data freeze date: announce 2 weeks before cutover. All open transactions must be completed or parked before the freeze.
• GDT filing cutover: the adapter goes live on the same day as system cutover. The old filing workflow is retired on the same day; do not run both in parallel after cutover.
• Archive plan: document where the old system data is archived, who has access, and how long it will be kept. Cambodia's ten-year record retention requirement means the archive must stay accessible for at least ten years after the records were created, not ten years after cutover.

Phase 8: Hypercare (4–8 weeks post-go-live)

Hypercare is the 4–8 weeks of intensive post-go-live support. The first month-end close in the new system almost always surfaces issues: not because of implementation errors, but because real transaction volume exposes edge cases that testing did not cover. Hypercare means daily check-ins with the finance team, same-day resolution of critical issues, and a named escalation path for GDT filing problems before the monthly deadline.

• Daily standups for the first 2 weeks: finance manager and implementation partner review the prior day's transactions for anomalies: unexpected journal entries, WHT misclassifications, rounding variances.
• First month-end close supported: the implementation team is present (physically or remote) for the first month-end close in the new system. This is not optional.
• GDT first filing supported: the first live GDT filing from the new system adapter is monitored in real time. Submission success confirmed before the filing deadline.
• Knowledge transfer: by week 6 of hypercare, the finance team should be able to run the system independently. Documented runbooks for all recurring tasks: month-end close, GDT filing, WHT remittance, bank reconciliation.

Where Cambodia projects actually slip

Six patterns that account for the majority of Cambodia ERP project overruns. All are predictable if you catch them in Phase 0.

• Bank reconciliation discrepancies discovered mid-migration: USD invoices in the source system were posted using inconsistent exchange rates: sometimes manual estimates, sometimes NBC rates, sometimes the same rate for an entire month. When these hit the parallel run reconciliation, the variance is often larger than expected and requires manual resolution per invoice. Resolution time: 1–3 weeks.
• KH holiday calendar conflicts: Cambodia's paid public holidays are set annually by a Prakas from the Ministry of Labour and Vocational Training, and both the instrument number and the lunar dates change every year, which is a large part of why holiday counts and dates quoted online disagree with each other. Work from the current year's Prakas rather than last year's calendar [around 22 paid days, but sources differ; confirm the count and the dates against the published list for your planning year]. Khmer New Year is 3 statutory days in mid-April, though most businesses close longer; Pchum Ben is 3 days falling in September or October depending on the lunar calendar; Visak Bochea is a further day. A project that schedules UAT or parallel run across a major holiday will lose a week. Check the current year's Prakas and build in a buffer for any phase landing in April, September, or October.
• Tax-year boundary timing: many Cambodian businesses want to cut over at the fiscal year boundary to avoid mid-year opening balance complexity. For almost all of them that boundary is 31 December, because the Cambodian tax year is the calendar year. A different year-end exists only by GDT approval under Prakas No. 1481 MEF (2007), available in practice to companies that are 51% or more foreign-owned and mirroring an offshore parent, so do not assume a March or June year-end applies to you. This creates a hard deadline that compresses the parallel run and hypercare phases. If you want a year-end cutover, plan the project to start at least 20 weeks before that date, not 12.
• GDT sandbox API issues: the GDT sandbox environment is not always stable. Periods of limited sandbox availability, particularly around GDT system updates, delay the adapter's sandbox test phase. This is largely outside the project team's control, but it is predictable: budget a 2-week buffer in the Phase 4 timeline for sandbox availability issues.
• Customer concurrent-project workload: the business's accounting team is usually managing the ERP migration on top of their normal monthly workload: GDT filings, month-end close, payroll, audit preparation. When those normal obligations pile up (e.g. during Khmer New Year close or year-end audit), the ERP project gets deprioritised. Structure the project so that the most client-intensive phases (parallel run, training) do not coincide with the accounting team's heaviest workload periods.
• TIN data collection lag: after the data audit reveals missing TINs on customer records, someone has to collect them, which means contacting customers and waiting for responses. For businesses with 200+ active customers, this process takes 2–4 weeks and cannot be automated. Start TIN collection immediately after the data audit; do not wait for Phase 3 to begin.

What fast-track looks like (and when not to)

A compressed 12-week fast-track timeline is possible for a Cambodia SMB ERP deployment under specific conditions: single legal entity, clean source data (confirmed in pre-engagement audit), standard VAT only (no CamInvoice, no complex WHT edge cases), Odoo Community on a pre-configured instance, and an accounting team that can commit 50% of their time to the project during the compressed period. What you trade: the parallel run is shortened to 2 weeks instead of 4, training is condensed, and hypercare is reduced from 8 to 4 weeks. The risk profile is higher: a reconciliation issue that a longer parallel run would have caught may surface in live production instead.

When not to do a fast-track: when the data audit reveals significant data quality issues (missing TINs, unreconciled suspense accounts, inconsistent exchange rates on historical invoices); when CamInvoice integration is in scope; when multiple legal entities are in scope; or when the accounting team has less than 30% of their capacity available for the project. A rushed ERP implementation that fails to go live cleanly is always more expensive than a properly paced one that goes live once. The business case for speed must be weighed against the cost of a failed first attempt.

Frequently asked questions

Can we self-implement without a partner?

For Odoo Community, partial self-implementation is possible; the software is open and documented. In practice, most Cambodia self-implementations stall at the GDT adapter build and the KH chart of accounts configuration, both of which require specific Cambodia compliance knowledge that is not in Odoo's standard documentation. A hybrid model (self-implementation with a consultant for the KH-specific pieces) is workable for technically capable businesses.

Can we phase the modules: accounting first, then inventory, then payroll?

Yes. Phased module deployment is the standard approach for most Cambodia SMB implementations. Accounting and GDT compliance first (Phases 0–8 above); inventory and purchasing in a second wave (add 8–12 weeks); payroll in a third wave (add 4–6 weeks). The advantage: the accounting team is not overwhelmed trying to learn three modules simultaneously. The disadvantage: data flows between modules are not live until the later modules go live, which means some manual bridge processes in between.

What about hosted Odoo or Acumatica versus self-managed?

Hosted (Odoo.sh, Acumatica cloud) reduces infrastructure management overhead and provides automatic backups and version updates. Self-managed (VPS or cloud VM) costs less per month but requires an internal or outsourced server administrator. For most Cambodia SMBs, hosted is the right default; the total cost of managing a VPS over 3 years often exceeds the hosting fee when you factor in the staff time and the risk of an unmanaged server incident. Odoo Community on a self-managed VPS is the exception: it is the cost-optimised path for technically capable teams.

What if we miss the tax-year cutover?

A missed tax-year cutover date does not stop the project. Migrate mid-year using a mid-year cut-off date (end of a completed month). The parallel run and opening-balance migration are slightly more complex (the opening balance is an in-year trial balance rather than a year-end close), but this adds 1–2 weeks of reconciliation work, not months. The accounting team will need to pull prior-period comparatives from the old system for the rest of the year, which is manageable if the archive plan is clear.

Who owns the project on the business side?

The finance manager (or CFO) must own the project on the business side, not the IT manager, not an external consultant. The business-side project owner is accountable for: data provision during Phase 3, decision sign-offs at phase gates, training attendance, and the go/no-go decision at the end of the parallel run. ERP projects that assign ownership to IT or to an external party consistently take longer and cost more than those with active finance leadership.

How do I evaluate an implementation partner's real Cambodia ERP experience?

Ask for: (1) the name of a live Cambodia ERP deployment they completed, not a demo environment; (2) evidence of a completed GDT adapter build (real filed returns, not a staging screenshot); (3) the KH chart of accounts localization approach they use. If they cannot answer all three with specifics, they have not done it before. For platform-specific selection, see our Odoo vs SAP Business One vs Acumatica comparison.

What is the right budget contingency for a Cambodia ERP project?

Budget 15–25% contingency on top of the fixed-price quote. Even with a proper discovery and fixed-scope contract, changes and edge cases emerge, particularly in GDT adapter edge cases (WHT code mismatches, multi-currency rounding), data quality issues discovered mid-migration, and business process changes decided during configuration. 15% contingency is the minimum for a clean data set; 25% is appropriate when the pre-engagement data audit reveals significant data quality issues.

How do we know when we are truly ready to go live?

Three gates must be clear: (1) trial balance reconciles to riel and cent between old and new systems; (2) the GDT adapter has produced a successful sandbox submission and the accountant has reviewed and accepted the output; (3) the finance team can complete the five most common daily tasks (VAT invoice creation, vendor bill with WHT, bank reconciliation entry, month-end close, and GDT submission trigger) without assistance. If any of these three gates is not clear, the parallel run is not done.