7 questions to ask before signing an ERP contract in Cambodia
Source-code ownership, GDT compliance, escape clauses, hidden per-user fees: the contract traps that cost Cambodian SMBs millions of riel.

- Most ERP vendors retain source-code ownership by default — put explicit transfer in writing.
- Ask vendors to demo a GDT e-VAT invoice in sandbox before you sign anything.
- If a vendor won't put answers to these questions in writing, that is your answer.
- Score 5 or more green answers before proceeding; 3 or fewer means walk away.
How to use these questions
Bring this list to every vendor pitch and pricing call. Each question maps to a contract clause that Cambodian SMBs routinely miss — and pay for later, in delayed go-lives, surprise invoices, or systems they cannot leave. Score each vendor's answer: direct and specific with a willingness to put it in writing is green; vague with promises to work it out later is red. Five or more green means proceed to due diligence. Three or fewer means walk away, no matter how good the demo looked.
1. Will the source code belong to us at go-live?
Ask this first because most vendors will not volunteer the answer. The default in most ERP contracts — especially SaaS subscriptions — is that you own nothing. You are licensing access. The moment you stop paying, the lights go off.
For custom-built systems, the situation is murkier. A vendor who builds bespoke modules on top of a platform like Odoo may retain IP over those modules even if you paid for every development hour. The contract needs to explicitly state: at go-live, all custom code developed for this engagement transfers to the client as a work-for-hire. If the vendor is using Odoo Community as a base, the modules can be yours — but you need that in writing. Odoo Enterprise modifications are subject to Odoo SA's licence, which adds a layer of complexity that must be resolved before signing. SAP Business One add-ons developed by a partner require partner sign-off on any IP transfer and may carry ongoing royalty obligations.
Red flags: the vendor says 'the code is on your server so it's yours' (hosting is not ownership), or 'this has never been an issue for any of our clients' (that means no client has ever tried to leave). What good looks like: a clause in the contract — not a side email — that says 'all custom modules and configurations developed under this agreement are assigned to [Client] as a work-for-hire upon payment of the final milestone.' Follow-up question: if we hire another developer in three years, can they modify the code without your involvement?
2. Does the system actually handle GDT e-VAT and CamInvoice?
Almost every ERP vendor operating in Cambodia will say yes. Fewer than half can demo it cleanly. GDT e-VAT support is not a checkbox — it requires generating a multi-line invoice with KHR and USD lines, applying withholding tax at 7% (or the correct rate for the transaction type), and submitting successfully to the GDT sandbox.
Ask for that demo in the sales process, not after signing. Specify: multi-line invoice, mixed KHR/USD, withholding tax 7%, submitted to GDT sandbox, result shown on screen. If the vendor cannot run that demo before contract signature, assume GDT support is roadmap, not production. The risk is that you spend six months on implementation only to discover the GDT adapter needs a separate development engagement — usually quoted at $3,000–$8,000 extra.
CamInvoice (the B2B e-invoicing mandate rolling out under GDT) is a separate but adjacent question. Ask: is CamInvoice integration on the product roadmap, and is it included in the current contract or separately priced? Vendors who have not thought about CamInvoice yet are behind the compliance curve. Red flag: 'CamInvoice is coming soon — we'll handle it.' What good looks like: a clear integration timeline and a commitment in the contract about who pays if regulatory requirements change before go-live. See also our deep-dive at /insights/gdt-e-vat-explained.
3. What happens to our books if we leave?
This is the vendor lock-in question, and vendors hate it. If you fire the vendor in year 3, can you walk away with your data and a working system — or does pulling out the vendor also pull out the business?
Specifically ask: can we get a full SQL dump of our data at any time, on request, at no charge? Will you provide migration scripts if we move to another platform? Do you have a documented offboarding process? What format is the data export — CSV, JSON, SQL? Will it be importable by a third party without vendor assistance?
For SaaS systems, this is especially critical. Zoho, SAP Business One On Demand, and similar platforms provide data exports — but the format and completeness vary. A CSV export of transactions is not the same as a full database dump with relationships intact. The difference matters enormously when migrating to a new system. For on-premise or self-hosted systems, you nominally own the database — but if the database schema is proprietary or undocumented, 'owning' it is largely theoretical.
Red flag: the vendor says 'we've never had a client leave' or charges a data-retrieval fee. What good looks like: a clause guaranteeing data export in open formats within 30 days of request, at no additional charge, at any point during or after the contract. The vendor's willingness to put this in writing tells you everything about how they view your relationship.
4. Are there per-user fees on logic we paid to build?
This is the trap that most Cambodian SMBs walk into on their second ERP engagement, not the first. The first contract looks reasonable. The custom module that the vendor built for your payroll workflow — you paid development costs — is now showing up as a per-user licensed feature. Ten users, $50/user/month: that is $6,000/year on top of the base platform fee, forever, for functionality you paid to build once.
The distinction to establish in the contract: platform licensing (per-user fees on the underlying system — Odoo Enterprise, SAP, whatever — is standard and expected) versus ransom on bespoke logic (per-user fees on custom modules developed specifically for your business, which you funded). The second category is not standard. It is a revenue model that treats your own IP as a product.
Ask explicitly: which features in our scope are subject to per-user licensing fees? Is any custom development we fund subject to per-user fees after delivery? Get the fee structure in writing as an exhibit to the contract — not just in the proposal deck. Red flag: 'per-user pricing applies to all modules in the platform' without distinguishing custom from standard. What good looks like: a clear exhibit listing which modules are platform-licensed (expected) and explicit confirmation that bespoke modules transfer free of ongoing per-user charges.
5. What is the actual go-live timeline — and what is the penalty for slipping it?
Cambodia ERP projects routinely slip 3 to 6 months past the quoted timeline. The reasons are predictable: data quality issues discovered late, scope creep on customisation, GDT integration delays, and key client-side staff unavailable during critical phases. Slippage is not a failure of effort — it is a failure of contract structure.
A quoted timeline without milestone-based payments and a penalty clause for vendor-caused slippage is not a timeline — it is a wish. Structure the contract around milestones: discovery sign-off, data migration validation, UAT completion, go-live, and post-go-live stabilisation. Each milestone should have a payment tied to it. If the vendor causes a milestone to slip — missing deliverables, non-responsive, defective work — there should be a financial consequence, even if it is modest.
Ask: what is your payment structure by milestone? What happens if you miss a milestone — who bears the cost? Is there a cap on the total project duration before we can exit without penalty? Red flag: 'payment is 30% upfront, 70% at go-live' with no intermediate milestones. That structure gives the vendor no financial incentive to hit interim deliverables. What good looks like: four to six milestones with payments tied to client-accepted deliverables, and a clause that entitles you to retain a holdback (typically 10-15%) until 30 days of successful live operation.
6. Who is the human you are going to call at 2am when payroll is broken?
Payroll failing on pay day is not a hypothetical for Cambodian businesses. It happens. When it does, you need a named engineer — not a support ticket queue — available in the Phnom Penh timezone, with the system access to diagnose and fix the problem inside an hour.
Ask: who is the named on-call engineer for production incidents? What is the response SLA — and is that response SLA in the contract or just in the pitch? What are the support hours — KH timezone business hours only, or 24/7? What is the cost of after-hours support: fixed monthly retainer or time-and-materials? Get the support terms as a schedule in the contract, not a separate 'we'll figure it out' verbal agreement.
Cambodia-specific considerations: if the vendor is headquartered in Singapore, Malaysia, or the USA, their standard support hours may not cover Phnom Penh business hours cleanly — particularly around Khmer public holidays and the Khmer New Year period when internal IT contacts are unavailable. Verify that on-call coverage explicitly includes Khmer public holidays, not just the vendor's home-country calendar. Red flag: support is handled by a shared helpdesk with no named engineers. What good looks like: a named primary and backup engineer, a documented escalation path, a response SLA of 4 hours or less for P1 incidents, and a fixed monthly support cost.
7. What does the upgrade path look like over 5 years?
This question is uncomfortable for vendors because the honest answer is expensive. Every major ERP platform goes through version migrations. Odoo releases a major version annually. SAP Business One releases periodic updates. Custom-built systems need ongoing maintenance. What the vendor quotes you today is not the total cost of ownership over five years.
Ask: what does a major-version migration cost — and who pays? Is there a cap on annual upgrade costs in the contract? What breaks during upgrades — are custom modules at risk of needing rework? What is the vendor's track record on upgrade delivery for existing Cambodia clients? If the vendor has been operating here for three or more years, they should be able to name clients who have gone through at least one major upgrade and give you references.
The five-year question also forces the vendor to be honest about platform trajectory. If the vendor is built on a platform that is losing market share or reducing Southeast Asia investment, that is relevant to your decision. A platform that is well-supported today may be in maintenance mode in year 4 of your contract. Ask: what is the vendor's plan if the underlying platform changes pricing or support terms? That risk needs to sit somewhere in the contract — usually as a change-of-control or force-majeure clause that protects the client. Red flag: 'upgrades are included' with no definition of what 'included' means or any cap on scope. What good looks like: an annual maintenance fee that explicitly covers minor-version updates, with major-version migrations scoped and priced in advance, subject to a reasonable cost cap relative to the original project cost.
What to do with these answers
Do not score the vendor on how confident they sound. Score them on whether they will put the answer in writing. A vendor who gives you a clear, direct answer in a meeting but hedges when you ask to include it in the contract is giving you the real answer: they do not intend to be held to it.
Scoring guide: 5 or more green answers — proceed to contract negotiation and legal review. 3 to 4 green — negotiate on the reds before proceeding; some may be fixable with better contract language. 2 or fewer green — walk away. The cost of a bad ERP vendor in Cambodia is not just the implementation fee. It is the staff time lost to a broken system, the risk of a GDT compliance gap, and the cost of a second implementation when you replace the first one.
If you want help evaluating vendor responses or structuring the contract negotiation, our system-solutions team works specifically on ERP selection and implementation for Cambodian businesses. See /services/system-solutions. If GDT e-VAT integration is the critical question, our integration team has built and maintained the adapter for multiple local deployments — see /services/integration/api. For migration context from your current system, read /insights/quickbooks-to-odoo-cambodia.
FAQ
- When in the sales process should I ask these questions?
- Ask them before the demo, not after. Vendors who know you are asking hard questions upfront will either bring a more substantive presentation or self-select out. Both outcomes save you time.
- Who in my organisation should be asking these questions?
- The owner or CFO must be in the room. These are not IT questions — they are business and legal questions. If only your IT manager attends the vendor pitch, you will not get contract-level answers.
- What if the vendor says 'trust us, we've worked with many businesses like yours'?
- That is the red flag. 'Trust us' is not a contract clause. Every commitment that matters — ownership, GDT compliance, timeline, support, upgrade costs — must be in writing. If a vendor is uncomfortable putting verbal commitments in writing, they are telling you exactly how much those commitments are worth.
- How do I compare answers across multiple vendors?
- Build a simple scoring sheet with these seven questions as rows and vendors as columns. Mark each answer: green (clear, specific, willing to put in writing), amber (partial answer, needs follow-up), red (vague, refused to commit, or avoided the question). The vendor with the most greens wins, assuming baseline competence is equal.
- What if I have already signed a contract and want to renegotiate?
- Review the contract for any clauses covering change requests, IP ownership, and data portability. Most ERP contracts in Cambodia are light on client-protective language — but if you are pre-go-live, you have more leverage than you think. Come to the renegotiation with specific language changes, not general complaints. If you are already live and experiencing problems, the questions in this list become your basis for a formal notice of breach or a structured exit negotiation.
- Is this different for cloud/SaaS ERP vs on-premise?
- The ownership and exit questions are more acute for SaaS — you own no code and no database by default. The support and upgrade questions are often better answered by established SaaS vendors with defined SLAs. On-premise gives you more control but more maintenance responsibility. Neither is categorically better; the contract structure matters more than the deployment model.
- What is a reasonable legal budget for ERP contract review in Cambodia?
- Budget $500–$1,500 USD for a Cambodian commercial law firm to review a standard ERP contract and redline on the critical clauses. That is a fraction of 1% of most ERP implementation costs and almost always worth it. Do not skip legal review because the vendor says 'this is our standard contract' — especially on IP, data portability, and support terms.