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 against a ministry, public institution, or state-owned enterprise 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. Private-sector B2B invoicing remains voluntary as of July 2026 and no B2B mandate date has been published. 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. [Verify the current schema version, endpoint, and authentication mechanism with GDDE before you build; the technical spec is issued to registered partners rather than published, and has changed during rollout.]

Who needs CamInvoice integration first?

The immediate scope is any business that issues invoices to Cambodian government counterparties: ministries, public institutions, state-owned enterprises, and government-linked bodies. If your revenue includes government contracts today (software vendors selling to ministries, utilities firms billing state agencies, construction and infrastructure contractors, professional services firms on government retainer), you are in scope now. 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. 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. No mandate date has been published [verify against the latest GDDE circular 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 the GDT API

These two systems are both part of Cambodia's digital tax and financial infrastructure, and they are often confused. The distinction matters because an existing GDT API integration does not give you CamInvoice coverage; they are separate systems with different submission models, different authentication flows, and different data schemas.

• Submission timing. GDT API: batched monthly return (due 25th of following month). CamInvoice: real-time at point of invoice issuance.
• Scope. GDT API: VAT returns, WHT returns, salary tax returns across all taxable transactions. CamInvoice: individual invoice documents for B2G and (eventually) B2B transactions.
• Authentication. GDT filing: TIN-based credentials via the GDT portal. CamInvoice: GDDE-issued partner credentials [verify the current authentication scheme with GDDE; it is issued to partners, not published].
• Response. GDT API: submission acknowledgement and period reference number. CamInvoice: per-invoice reference number (the CamInvoice ID) that must appear on the physical or electronic invoice delivered to the buyer.
• Rejection handling. GDT API: end-of-period rejection codes. CamInvoice: synchronous rejection at submission time; the invoice cannot legally be issued until CamInvoice accepts and returns a reference.
• Registration path. GDT API: GDT portal registration. CamInvoice: separate GDDE partner registration process with sandbox certification.

The practical consequence: if your ERP already has a GDT API adapter, you need a parallel CamInvoice module, not a replacement. Both can coexist in the same integration layer and share some upstream data (TIN, invoice dates, KHR amounts) but the submission flow is different. For a full technical breakdown of the GDT API integration 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 (Odoo, 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 follows the UBL XML clearance model described above; the adapter signs the document with its GDDE-issued credentials and submits it; GDDE validates, attests it, and returns the reference number and QR code; the adapter writes those back to the invoice record in the ERP; the ERP then finalises and dispatches the invoice to the buyer. [Confirm the current schema version and signing mechanism with GDDE before you build: the technical specification is issued to registered partners, not published, and it has changed during rollout.] 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 or SOE's registered TIN), invoice number, invoice date (ISO 8601), line items with unit price and quantity, KHR subtotals and VAT amounts, and a document hash. 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.

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. 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, GDDE sandbox certification, 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, multi-currency books (USD + KHR + THB), or businesses that need the adapter to handle both the GDT monthly return and the CamInvoice real-time channel from the same integration layer, the scope expands: USD 12,000 and above is realistic. We quote fixed-price after discovery, because time-and-materials on an unknown 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 (either as a business doing self-integration or as a vendor building adapters for clients), you register as an integration partner with GDDE. Broadly the process runs: submit legal entity verification documents; complete a technical integration in GDDE's sandbox and pass its validation; receive production credentials. [Verify the current steps, the certification requirements, and the lead time directly with GDDE — the onboarding process is not published in a stable public document and has changed during rollout, 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 sandbox validation failures 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 [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 sandbox 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 SOE 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 government counterparties 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

Can I access the CamInvoice sandbox before completing partner registration?

GDDE provides limited sandbox access for initial technical assessment without full partner registration. Full sandbox certification, which is required for production credentials, requires the registration process to be underway. Reach out to GDDE's digital economy portal or work with a registered integration partner who can provide sandbox access as part of a scoping engagement.

How does counterparty TIN validation work for government buyers?

The buyer TIN field must match the TIN in GDDE's national TIN registry for that ministry or SOE. GDDE does not provide a public TIN lookup API as of July 2026 [verify with GDDE; it publishes no developer reference you can check this against]. In practice, TINs for major ministries and SOEs are available from your procurement counterparty's official documents. Verify before go-live, not at submission time.

Can one adapter handle both the GDT monthly return and CamInvoice real-time submission?

Yes, in the same integration layer, but they are separate submission flows. A well-designed adapter shares the upstream data extraction (reading from your ERP), the currency conversion logic, and the audit trail storage, but branches into two separate modules: one for batched GDT monthly return submission and one for real-time CamInvoice per-invoice submission. We design integrations this way by default.

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

The invoice cannot be legally issued without a CamInvoice reference number. A synchronous 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?

CamInvoice submissions are per legal entity with its own GDDE partner credentials and TIN. Each entity in a group must submit invoices independently under its own credentials. There is no consolidated group submission path as of July 2026 [verify with GDDE whether group certificate options are available].

How do we handle foreign-currency invoices in CamInvoice?

The CamInvoice schema requires KHR amounts. Foreign-currency invoices (typically USD) must be converted to KHR at the NBC official exchange rate for the invoice date before submission. The same rate discipline as GDT filings applies: lock the rate, round in KHR, store the rate source in the audit trail. A USD invoice submitted with USD amounts in the KHR fields fails schema validation immediately.

Is there an existing ERP plugin for CamInvoice?

As of July 2026, no major ERP vendor (Odoo, 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 not source a 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 sandbox validation completed before you submit for production. Incomplete submissions restart the clock, so the cost of getting this wrong is measured in weeks.