v1 page
System Solutions

ERP

One system for finance, sales, stock, and purchasing, with Cambodian compliance built in rather than bolted on: GDT e-VAT, KHR and USD side by side, Khmer-first screens for the people who use it daily. Configured on a platform where the flows are standard, built from the ground up where they are not. Fixed scope after a paid discovery, 8 to 24 weeks depending on entity count.

A long-form page for ERP with sample build, case study, and pricing band is coming. Until then, scope it directly with us.

What does an ERP actually replace in a Cambodian business?

It replaces the spreadsheets between your systems. Most Cambodian SMBs already have accounting software, a stock list, and a sales process. What they do not have is one place where those three agree. An ERP is the system where an order, the stock it consumes, the invoice it raises, and the tax that invoice owes are one record rather than four reconciled by hand at month-end.

The symptom is almost always the same. Someone in finance keeps a spreadsheet mapping the sales system to the accounting system. Someone in the warehouse keeps another mapping physical stock to whatever the system claims. Those spreadsheets are the business's real ERP, and they exist because the software underneath cannot answer a question that spans two departments.

That is the test worth applying before buying anything: name a question your business cannot answer without opening a spreadsheet. What did we actually earn on this order after landed cost. How much of that stock is committed against open orders. Which customers are past terms in KHR as opposed to USD. If those take a person and an afternoon, the gap is integration, not effort.

Should you configure a platform or build from the ground up?

It follows one question: how much of your operation is genuinely your own? Where the flows are standard (quote, invoice, stock, ledger) a configurable platform plus a Cambodian compliance layer is the economical route. Where the workflow is how you compete (your pricing logic, your routing, your production sequence) a ground-up build fits the software to the operation instead of the reverse.

Both answers are legitimate and we give both. Scale takes no referral fees from any platform vendor, which is the only reason that sentence is worth anything: a recommendation is only as honest as the incentive behind it.

The platforms that show up most in Cambodia are Odoo, SAP Business One, and Acumatica. Odoo has the largest local partner network and a Community edition with no per-user licence. SAP Business One is the incumbent in established mid-market distribution. Acumatica prices on consumption rather than named users, which suits businesses with many occasional users. None of the three ships Cambodia compliance natively: GDT e-VAT filing, KHR and USD handling, and the Khmer interface are localisation work on every one of them.

A custom build carries no licence line at all. The recurring commitment is infrastructure and support, and the source code, schema, and documentation are yours at go-live. That is the honest trade: more to build, nothing to rent, and no vendor able to reprice you later.

  • Standard flows, no unusual approvals: configure a platform and localise the compliance layer.
  • Workflow is the competitive edge, or the flows genuinely do not fit a package: build it.
  • Already running a platform that mostly works: extend it and add a GDT adapter rather than rebuild. Sometimes that is the honest answer, and it is the cheapest one.

What does Cambodian compliance require that global ERPs miss?

Three things, none of which ship by default. GDT e-VAT filing under Prakas 1033. Dual-currency books in KHR and USD converted at the NBC daily rate on the invoice date, not at a period average. And withholding tax at three separate rates, 7% resident company, 14% resident individual, 15% non-resident and royalties, each mapped to its own account.

A TIN is required on every B2B invoice. Most legacy systems treat that field as optional, which means it is missing on a large share of migrated customer and vendor records. Collecting them is a data project that has to finish before go-live, not during the first filing.

CamInvoice, the B2B e-invoicing mandate rolling out under GDT, is a separate and adjacent question. Ask any vendor whether it is on the roadmap and whether it sits in the current contract or is priced separately. "It is coming soon, we will handle it" is not an answer.

The compliance adapter is built in parallel with the rest of the system, not after it. See /services/integration/api for how the GDT and CamInvoice integration is scoped.

How long does an ERP take, and what drives the scope?

Eight to fourteen weeks for a single-entity SMB, sixteen to twenty-four for mid-market, with each additional legal entity adding meaningfully to both. What moves those numbers is rarely the software. It is entity count, how clean the data in the outgoing system is, how many flows are genuinely non-standard, and how much of your own team's time is available.

Scale starts with a paid discovery sprint rather than a free proposal. It produces a build-versus-configure recommendation with the reasoning attached, a module scope document, a data migration assessment, and a fixed-scope quote. If the recommendation is that you do not need what you came asking for, that is what it will say.

The projects that slip in Cambodia usually slip on client-side availability rather than engineering. Discovery needs your finance and operations leads in the room. Data migration needs someone who knows why the old records look the way they do. Parallel run needs your accountants to close one month twice. That time is real and worth planning for.

For an order-of-magnitude view before you talk to anyone, the /insights/cambodia-erp-cost-calculator tool takes module footprint, company size, and complexity and returns a range built from Cambodian project data.

0w5w10w15w20w25w30wSMB build12–18 wkMid-market18–28 wkPer extension+6–12 wk
fig. 01 · how an ERP engagement runs, phase by phase
FAQ

Questions worth asking any ERP vendor

  • Do we own the system at the end?

    On a Scale build, yes: source code, database schema, configuration, and a data dictionary are handed over at go-live, and the data sits in standard PostgreSQL any engineer can query. On a commercial platform you own your data but licence the software, and a licence can be repriced. Ask which one you are buying before you sign, because the two behave very differently over five years.

  • Does it work in Khmer, properly?

    Ask to see a Khmer screen used by someone who is not in the demo. Khmer as a community translation pack layered over an English product behaves differently from Khmer treated as a first-class language in the build. Field lengths, sort order, date formats, and printed invoices are where it usually breaks.

  • Can we migrate off QuickBooks or Peachtree mid-year?

    Yes. Year-end is the cleanest cut-off because the trial balance is closed, but mid-year migration is common. It needs an agreed cut-off date, usually the end of a completed month, and an in-year opening balance that reconciles to the old system to the cent. See /services/system-solutions/accounting for the full migration scope.

  • What happens when GDT changes the spec?

    The adapter is maintained, and that maintenance is part of the ongoing engagement rather than a surprise. It is worth pinning down in writing with any vendor: a compliance integration is not a one-time build, and a fixed-scope implementation that treats it as one will come back to you the first time the filing format moves.

  • How much of our team's time will this take?

    More than most proposals imply. Budget for your finance and operations leads through discovery, someone who knows the history of the old data through migration, and your accountants closing one month twice during parallel run. Vendors rarely price this because it is your cost, not theirs, but it is the single most common reason a Cambodian ERP project runs late.