CamInvoice in Cambodia: integration guide for finance and IT teams

What is CamInvoice?

CamInvoice is Cambodia's government e-invoicing platform, operated by the General Department of Digital Economy (GDDE) under the Ministry of Economy and Finance. It was soft-launched in December 2024, formally established by Prakas No. 075 MEF on 22 January 2025, and publicly launched on 12 May 2025. It centralises invoice submission between businesses and government counterparties: an invoice issued to a ministry or institution the mandate covers is submitted to the platform, validated, and returned with a reference number before the invoice reaches the buyer. This is a fundamentally different model from GDT's monthly return, which batches a whole period of data. CamInvoice is transaction-level. The B2G mandate is phased by ministry rather than universal from day one: Circular 003 MEF (January 2025) brought in the Ministry of Economy and Finance, the Ministry of Environment, and their suppliers; Circular 012 (July 2025) added six more ministries; Circular 017 (November 2025) took the total to fourteen; a fourth circular, dated 1 June 2026, added fourteen more ministries and institutions. Private-sector B2B invoicing remains voluntary as of September 2026, and we found no published B2B mandate date. Treat any B2B deadline you are quoted as speculation until GDDE publishes one.

The platform was announced in the context of Cambodia's Digital Economy and Digital Society Policy 2021–2035 and forms part of the broader government push to digitise public financial management. From the integration perspective, CamInvoice follows a centralised clearance model: the invoice is submitted to the platform in UBL XML, validated, attested to Cambodia's CamDL distributed ledger, and returned with a QR code and reference that must appear on the document the buyer receives. Unlike GDT's monthly filing, CamInvoice does expose an API for system integration, which is what makes an ERP adapter possible at all. GDDE publishes the API documentation at developer.e-invoice.gov.kh: documents follow UBL 2.1, authentication is OAuth 2.0, and the base URL and client credentials are issued once you have contacted the operator. The specification has changed during rollout, so read the current documentation before you build instead of trusting a summary, this one included.

Who needs CamInvoice integration first?

The immediate scope is narrower than the whole public sector. The four circulars apply to suppliers invoicing the central-level units of the ministries and institutions they name, twenty-eight as of June 2026, and they cover invoices for payment claims that go through public procurement procedure. If your revenue includes contracts with those bodies today (software vendors selling to ministries, construction and infrastructure contractors, professional services firms on government retainer), you are in scope now. State-owned enterprises and sub-national administrations are not named in any of the four, so check the current list before assuming either way. The eligibility is determined by who you invoice, not your own registration type.

• In scope now (B2G): businesses invoicing the ministries and public institutions already brought in by Circulars 003, 012, and 017 MEF, fourteen ministries as of November 2025, and their suppliers. The circular of 1 June 2026 adds fourteen more: the Ministries of Foreign Affairs and International Cooperation, Planning, Social Affairs, Water Resources and Meteorology, Information, Justice, Inspection, Culture and Fine Arts, Tourism, Cults and Religion, and Women's Affairs, the State Secretariats of Civil Aviation and Border Affairs, and the Anti-Corruption Unit. Check the current circular list against your own government counterparties rather than assuming the whole public sector is covered.
• In scope, date unpublished (B2B): GDDE has signalled large or high-risk private taxpayers first, then a wider rollout, with B2C later. We found no published mandate date: the newest circular GDDE lists (1 June 2026) still covers B2G only (checked 27 September 2026). Read the circulars GDDE lists on e-invoice.gov.kh before planning around a deadline.
• Likely deferrable: businesses with no government revenue and turnover below the eventual B2B threshold, but plan for it, because the compliance window will compress once dates are published.
• Hybrid businesses: start with the B2G channel now; the same adapter module is extended for B2B scope when mandated.

The practical signal: if you are already applying for government tenders or managing existing government contracts, your procurement counterparty may require a CamInvoice reference number on invoices even before the formal mandate catches up. Treat that as a soft mandate today.

How CamInvoice differs from GDT's monthly return

These two are both part of Cambodia's digital tax and financial infrastructure, and they are often confused. The distinction matters because filing the monthly return does not give you CamInvoice coverage: they are separate systems, run by different bodies, and only CamInvoice is one that software submits to.

• Submission timing. GDT's monthly return: once a month, due the 25th of the following month when filed electronically, the 20th on paper. CamInvoice: real-time at point of invoice issuance.
• Scope. GDT's monthly return: VAT, withholding tax, and Tax on Salary, on one return. CamInvoice: individual invoice documents for B2G and (eventually) B2B transactions.
• Who submits, and how. GDT's monthly return: a person, your accountant or finance team, through GDT's E-Filing. CamInvoice: your system, through an API, authenticating with OAuth 2.0, with a client ID and secret issued by GDDE; access tokens expire after 15 minutes and are renewed with a refresh token.
• Response. GDT's monthly return: nothing comes back to your system, because the system sent nothing; the filing is the accountant's act in E-Filing. CamInvoice: a reference for each invoice, which must appear on the physical or electronic invoice delivered to the buyer.
• Rejection handling. GDT's monthly return: there is no rejection for software to handle; GDT's notices and queries reach the business as correspondence. CamInvoice: the submit call returns the documents that failed, each with a message, and the result follows by webhook; the invoice cannot legally be issued until CamInvoice accepts it.
• Registration path. GDT's monthly return: your own tax registration and your login to the e-Tax portal. CamInvoice: onboarding with GDDE (meeting, NDA, integration, system demo, MOU).

The practical consequence: a system that already produces your monthly return figures still needs a CamInvoice adapter if you invoice a body the mandate covers. The two draw on some of the same data (TIN, invoice dates, KHR amounts), but only CamInvoice is submitted by the system itself. For the monthly return side, see how GDT e-VAT filing works. If you are still choosing the system CamInvoice will plug into, our ERP in Cambodia guide covers that decision first.

What is the integration architecture?

Most ERPs (SAP Business One, Acumatica, QuickBooks Desktop, Xero) have no native CamInvoice support. The standard pattern is a custom adapter layer that sits between your ERP and the GDDE API. The flow: the ERP raises a draft invoice and fires an event (webhook or polling); the adapter maps invoice fields into the CamInvoice document schema, which is UBL 2.1 XML; the adapter authenticates with OAuth 2.0 and submits the document, Base64-encoded, through the API; GDDE validates and attests it, and returns a document ID and a verification link; the adapter writes those back to the invoice record in the ERP; the ERP then finalises and dispatches the invoice to the buyer. The published documentation shows no signing step on the sender's side: CamInvoice itself hashes the validated invoice and stores it on CamDL. Integration happens under an NDA, so confirm the current schema version and submission details with GDDE before you build. The buyer-facing document, whether PDF or e-mail, must carry the CamInvoice reference number.

Key schema fields in the CamInvoice payload include: seller TIN, buyer TIN (for government counterparties this is the ministry's or institution's registered TIN), invoice number, issue date (YYYY-MM-DD), document currency, line items with unit price and quantity, tax totals, and a tax exchange rate when the invoice is not in KHR. Tax is reported in KHR, so the KHR amounts must be computed at the NBC official exchange rate for the invoice date when the underlying transaction is in USD: the same rate discipline as GDT filings but applied per-invoice rather than per-period.

Read the actor column first. Three parties touch the invoice and only one of them makes it issuable: the invoice cannot legally be issued until CamInvoice accepts and returns a reference, so every row above step 4 is preparation and every row after it exists only because a response came back. This is one of the ways CamInvoice differs from the GDT monthly return, which covers a whole month and is filed by a person through E-Filing, with no rejection for software to handle. Step 5 is the row with a tail: the article notes that an adapter storing only the reference number leaves gaps that are expensive to reconstruct during a GDT audit, and that the Law on Accounting and Auditing 2016 mandates a ten-year retention period.

Hosting for the adapter runs as a lightweight microservice (Node.js or Python are both workable; we use Node). Infrastructure cost is typically USD 150–300 per month for a managed VPS or cloud function setup with monitoring and log retention. A CamInvoice integration for a single-system SMB takes 6–13 weeks end to end, longer than an ordinary integration because onboarding with GDDE runs beside the build. Within that, adapter development for a single source system (one ERP, one entity, one currency) typically takes 3–5 weeks. Multi-system or multi-currency scopes add 4–8 weeks.

The retry strategy matters more than it sounds. CamInvoice is real-time, which means a network timeout or a 5xx from GDDE blocks invoice issuance. The adapter must implement exponential back-off with a dead-letter queue and alerting. A failed submission that silently drops means a buyer-facing invoice goes out without a reference number, which is a compliance breach. We build idempotency keys into every submission so that retries do not create duplicate CamInvoice records.

What does CamInvoice integration cost?

For an SMB with a single source system, one legal entity, and USD-only or KHR-only invoicing, the build cost typically falls between USD 3,000 and USD 7,000. That covers adapter development, testing with GDDE, production credential setup, and handover documentation. Ongoing hosting and monitoring runs USD 150–300 per month. Add a one-week paid discovery sprint (USD 500) before the build engagement. We scope after discovery, not before, because the field mapping surprises differ significantly by source system.

For multi-entity groups or multi-currency books (USD + KHR + THB), the scope expands: USD 12,000 and above is realistic. We quote fixed-price after discovery, because time-and-materials on an unfamiliar CamInvoice spec is how you end up with a six-month project at twice the original estimate.

Partner registration with GDDE

To integrate with CamInvoice you work with GDDE, the system's operator, and GDDE publishes two routes on e-invoice.gov.kh. A business connecting its own system meets the operator, signs an NDA, builds the integration, demonstrates the working system, then signs an MOU and becomes a member. An ERP or accounting-system supplier registered in Cambodia applies as a service provider: an application form, an NDA, technical testing with an information security checklist and system integration and user acceptance test documents, then a contract. GDDE lists both routes as free of charge, and neither page gives a lead time, so treat any timeline you are quoted, including ours, as indicative rather than committed. In our experience the failures that cause delay are mundane: TIN mismatches between the registered entity and the documents submitted, and validation failures in testing on edge cases, particularly KHR rounding and Khmer-script product descriptions.

Partner registration is open, and the pool of integrators with real CamInvoice experience is still small. That is our own read of the market from the integration work we see: we could find no published count of registered partners, so treat the scarcity as anecdotal rather than measured. The practical argument for starting early is capacity rather than listings: if a B2B mandate is published, everyone scopes an integration in the same quarter. We can handle the GDDE registration process as part of a full integration engagement through our API integration practice.

Common implementation pitfalls

These are the CamInvoice-specific failure modes we have encountered in integration work and testing. Not the obvious ones, but the ones that surface at go-live:

• KHR rounding inside line items: CamInvoice validates that line-item KHR subtotals sum exactly to the invoice total KHR amount. If your ERP rounds at the line level and the adapter rounds again at the total level, you get a 1-riel discrepancy that fails schema validation. Round once, at the total, after summing exact line amounts.
• UTF-8 encoding for Khmer-script product descriptions: CamInvoice accepts Khmer Unicode in product name and description fields. If your ERP stores product names in a legacy encoding (Windows-1252 or misconfigured UTF-16), the adapter must normalise to UTF-8 NFC before submission. Garbled Khmer characters in a CamInvoice submission result in a schema rejection that is slow to diagnose.
• Counterparty TIN validation mismatches: the buyer TIN field for government counterparties must exactly match the TIN held in GDDE's national TIN registry. Ministry and institution TINs sometimes differ between what is on the procurement contract and what is in the registry, a known data-quality issue that requires manual verification before go-live.
• Time-zone handling for real-time submission: CamInvoice timestamps are in ICT (UTC+7). If your ERP runs on UTC server time and the adapter posts timestamps without timezone conversion, invoices issued in the evening ICT can land in GDDE's system with the previous calendar date, which mismatches the invoice date field and causes rejection.
• Idempotency on retry: if a CamInvoice submission times out and the adapter retries without an idempotency key, GDDE may process the invoice twice, issuing two different reference numbers for what was intended as one invoice. Both will appear in GDDE's system; reconciling them requires manual GDDE support intervention.
• Audit trail completeness: each CamInvoice submission should store the full outbound payload, the GDDE response including the reference number, the submission timestamp, and a link back to the source invoice record in the ERP. An adapter that only stores the reference number leaves gaps that become expensive to reconstruct during a GDT audit, and the Law on Accounting and Auditing 2016 mandates a ten-year retention period.
• Issuing buyer invoices before the CamInvoice response returns: businesses that generate PDF invoices at draft stage and email them to buyers before the CamInvoice submission completes will occasionally send invoices without the reference number. The buyer-facing document is non-compliant without it. The adapter must gate invoice dispatch on a confirmed GDDE response, not on draft creation.

When should you integrate?

The decision framework is straightforward: if you bill a ministry or institution named in the circulars today, integrate now. You are in scope and the compliance risk of invoicing without a CamInvoice reference number is already present. If you are purely B2B with no government revenue, you can wait for GDDE to publish the B2B mandate dates, but do not wait to plan. The compliance window will compress quickly once dates are announced, and integration vendors will have a queue. Starting discovery now while you are not yet under pressure is the lower-cost path.

For hybrid businesses (B2G revenue today, B2B revenue growing), start with the B2G channel. Build the adapter to be extensible: the same authentication and submission logic covers B2B when the mandate arrives; only the counterparty TIN validation and the scope of triggering invoices changes. Cost of waiting is a smaller monthly spend today but a rushed, compressed build at mandate date, typically at 1.3–1.5x the cost of an unrushed engagement.

Frequently asked questions

How does counterparty TIN validation work for government buyers?

The buyer's details must match what CamInvoice holds for that ministry or institution. GDDE's API documentation describes two checks a connected system can run: a member lookup that searches CamInvoice members, public-sector bodies included, by name or TIN, and a validate-taxpayer call that takes a TIN, a single ID and the company name and returns whether they match. Neither is open to the public without credentials. Take the TIN from your procurement counterparty's official documents, check it through the API, and do it before go-live, not at submission time.

Can one system handle both the GDT monthly return and CamInvoice?

Yes, but they are different kinds of work. For the monthly return the system produces the figures, and a person files them through GDT's E-Filing. For CamInvoice the system submits each invoice itself, through GDDE's API. A well-designed system shares the upstream data (the invoice records), the currency conversion logic, and the audit trail storage between the two.

What happens if a CamInvoice submission is rejected at the GDDE endpoint?

The invoice cannot be legally issued without a CamInvoice reference number. A rejection from GDDE means the adapter must route the invoice to a manual review queue, alert the finance team, and block dispatch to the buyer. Common rejection reasons: schema validation failures (rounding errors, encoding issues), TIN mismatches, or expired credentials. Each rejection code maps to a specific remediation step; your adapter should have a rejection-code handler, not a generic error page.

What happens to multi-entity groups: one submission per entity or consolidated?

One submission per entity. Each legal entity is its own CamInvoice member, with its own member ID and TIN, and each one authorises the connecting system separately, which then holds a separate access token for it. One integration can serve several entities, but GDDE's documentation describes no consolidated group submission: each submission is made with one entity's access token (checked 27 September 2026). If your group needs a consolidated route, ask GDDE whether one exists.

How do we handle foreign-currency invoices in CamInvoice?

An invoice can be issued in a foreign currency: the schema carries a document currency code, and GDDE's documentation shows both KHR and USD. Tax is reported in KHR, so an invoice in any other currency must also carry a tax exchange rate: the source currency, KHR as the target, and the rate applied. Use the NBC official exchange rate for the invoice date, and keep the same rate discipline as GDT filings: lock the rate, round in KHR, store the rate source in the audit trail.

Is there an existing ERP plugin for CamInvoice?

As of July 2026, no major ERP vendor (SAP Business One, Acumatica, QuickBooks, Xero) ships a native CamInvoice module. Third-party plugins exist for some platforms but have variable quality and limited support for Cambodia-specific requirements (multi-currency rounding, Khmer encoding, GDDE-specific rejection handling). A custom adapter built to your specific ERP and entity structure is the most reliable path for production use.

How long does GDDE partner registration take, and can we expedite it?

Plan for a few weeks rather than a few days, and confirm the current lead time with GDDE rather than with a vendor: we could find no published service standard, and no expedited path is advertised. What reliably avoids delay is clean documentation on the first pass: TIN exactly matching the registry, entity documents current, and testing completed before you ask for production credentials. Incomplete submissions restart the clock, so the cost of getting this wrong is measured in weeks.