CamInvoice Technical Compliance: API Integration and Data Specifications

The CamInvoice system operates as a centralized clearinghouse model where all electronic invoices pass through the GDT's platform for validation, registration, and storage before being delivered to the buyer. This differs from the distributed model used in some European countries where invoices are exchanged directly between trading partners via certified access points. The centralized model gives the GDT real-time visibility into all commercial transactions, enabling automated VAT cross-matching, fraud detection, and fiscal analytics. The architecture comprises three layers: the Submission Layer (REST API and web portal for invoice submission), the Validation and Processing Layer (business rules engine, VAT calculation verification, digital stamp generation), and the Storage and Analytics Layer (invoice archive, audit trail, reporting dashboard). Businesses interact with the Submission Layer through either the CamInvoice API (recommended for high-volume enterprises) or the CamInvoice web portal (suitable for low-volume businesses). The CamInvoice API is a RESTful service accepting JSON-encoded UBL 2.1 invoice documents. The API supports synchronous validation (response within 3 seconds) and asynchronous batch submission (for bulk upload of up to 1,000 invoices per batch). Authentication uses API keys issued during business registration, combined with digital certificates for invoice signing. The API is versioned, with the current production version being v2.1, and the GDT commits to 12 months of backward compatibility for deprecated versions.

CamInvoice adopts the OASIS Universal Business Language (UBL) 2.1 standard for its invoice data schema, ensuring interoperability with international e-invoicing systems and alignment with ASEAN's emerging e-invoicing framework. The UBL 2.1 Invoice document type defines a comprehensive set of fields covering document metadata, seller and buyer identification, line item details, tax calculations, payment terms, and supplementary references. The GDT has published a Cambodian UBL Profile that specifies which UBL fields are mandatory, optional, and prohibited in the Cambodian context. Key mandatory fields include: the seller's TIN (cac:AccountingSupplierParty/cac:PartyTaxScheme/cbc:CompanyID), buyer's TIN (cac:AccountingCustomerParty/cac:PartyTaxScheme/cbc:CompanyID), invoice date (cbc:IssueDate), currency code (cbc:DocumentCurrencyCode), line item descriptions with HS codes for goods (cac:Item/cac:CommodityClassification), individual line amounts (cbc:LineExtensionAmount), VAT category and rate (cac:TaxCategory/cbc:Percent), and total payable amount (cac:LegalMonetaryTotal/cbc:PayableAmount). The Cambodian profile adds several custom extensions to standard UBL 2.1: a CamInvoice document type code (distinguishing standard invoices, credit notes, debit notes, and self-billing invoices), a payment method code indicating whether payment is via Bakong, bank transfer, cash, or credit terms, and a business sector code aligned with the GDT's industry classification system.

The CamInvoice submission workflow follows a defined sequence with clear state transitions at each stage. The process begins when the enterprise's billing system generates an invoice and formats it as a UBL 2.1 JSON document conforming to the Cambodian profile. The system signs the invoice using the enterprise's registered digital certificate, then submits it to the CamInvoice API endpoint. Upon receipt, the CamInvoice Validation Engine performs a multi-step verification process. Schema validation confirms the JSON document conforms to the UBL 2.1 schema. Business rule validation checks mandatory fields, TIN validity, date constraints, and mathematical accuracy (line totals, VAT calculations, document total). Cross-reference validation queries the GDT database to confirm that both seller and buyer TINs are active and that the seller is registered for CamInvoice. Duplicate detection checks whether an invoice with the same seller TIN, invoice number, and date has been previously submitted. If all validations pass, the system assigns a unique CamInvoice Reference Number (CIRN), generates a digital tax stamp containing the CIRN, timestamp, and GDT digital signature, and returns the stamped invoice to the submitter. The invoice status transitions to REGISTERED. If any validation fails, the system returns a detailed error response with specific error codes and field-level error messages, and the invoice status remains REJECTED. The enterprise must correct the errors and resubmit. The entire synchronous workflow completes within 3 seconds for individual invoices. Batch submissions of up to 1,000 invoices are processed asynchronously, with results available via a polling endpoint or webhook notification within 30 minutes.

The CamInvoice Validation Engine applies over 120 business rules organized into five categories: structural rules (schema compliance), identification rules (TIN verification), calculation rules (mathematical accuracy), temporal rules (date constraints), and cross-reference rules (duplicate detection, prior invoice amendments). Understanding these rules is essential for building a submission system that achieves a high first-pass acceptance rate. The most common rejection reasons in the first quarter of mandatory operation were: incorrect VAT calculation (32% of rejections), where the document total did not match the sum of line items plus VAT; invalid buyer TIN (24%), where the buyer's TIN was either unregistered, inactive, or miskeyed; duplicate invoice number (18%), where the seller reused an invoice number from the same fiscal year; missing HS code (12%), where goods items lacked the mandatory commodity classification; and invalid date (8%), where the invoice date was more than 7 days in the past or in the future. Enterprise developers should implement client-side pre-validation that checks all 120 rules before submitting to the CamInvoice API. This reduces API round trips, improves user experience, and avoids the operational overhead of handling rejected invoices. CamFinTech provides a validation library (available in Java, Node.js, and Python) that implements the complete CamInvoice business rule set and can be integrated into ERP systems and billing platforms.

The CamInvoice digital tax stamp is the cornerstone of the system's integrity, providing cryptographic proof that an invoice has been validated and registered by the GDT. The stamp contains four elements: the CamInvoice Reference Number (CIRN), a 20-character alphanumeric code uniquely identifying the registered invoice; the registration timestamp in ISO 8601 format; a SHA-256 hash of the invoice content; and the GDT's RSA-2048 digital signature over the combined CIRN, timestamp, and content hash. The digital stamp is returned to the submitter in the API response and can be rendered as a QR code on printed invoice copies. The QR code encodes a URL to the CamInvoice verification portal, allowing any party (buyer, auditor, tax inspector) to scan the code and verify the invoice's authenticity and content against the GDT database. This verification mechanism is critical for supply chain finance applications, where financiers need to confirm that an invoice is genuine and has not been previously pledged as collateral. The GDT's digital certificate used for signing tax stamps is published on the CamInvoice developer portal, enabling offline verification by extracting the signature from the stamp and validating it against the GDT's public key. This offline verification capability is important for enterprise systems that need to verify large volumes of received invoices without making individual API calls to the CamInvoice verification endpoint. Enterprise systems should store the complete digital stamp data alongside each invoice record and implement automated verification of received invoices (from suppliers and vendors) to ensure they are genuine CamInvoice-registered documents before claiming VAT input tax credits.

CamInvoice supports invoice modifications through credit notes and debit notes, following the UBL 2.1 standard for adjustment documents. A registered invoice cannot be deleted or directly modified in the CamInvoice system. Instead, corrections are made by issuing a credit note (to reduce the original amount) or a debit note (to increase the original amount) that references the original invoice's CIRN. Credit notes (InvoiceTypeCode 381) must include the original invoice's CIRN in the BillingReference field, specify the negative adjustment amount, and provide a reason code from the GDT's enumerated list (pricing error, quantity adjustment, returned goods, discount applied, etc.). The GDT validates that the credit note amount does not exceed the original invoice amount and that the referenced invoice exists and belongs to the same seller TIN. Full cancellation of an invoice requires a credit note for the entire amount. Debit notes (InvoiceTypeCode 383) follow the same referencing pattern but increase the original amount, typically used for additional charges, late payment fees, or underestimated quantities. Self-billing invoices (InvoiceTypeCode 389) are used when the buyer issues the invoice on behalf of the supplier, common in agriculture and construction where suppliers lack invoicing systems. Enterprise ERP systems should implement automated credit note generation for common scenarios (returns processing, pricing adjustments, volume discount reconciliation) and ensure that the credit note workflow includes the original CIRN reference required by CamInvoice.

Integrating CamInvoice with enterprise ERP and billing systems requires careful architecture design to handle the real-time submission requirement, manage validation errors gracefully, and maintain consistency between internal records and the CamInvoice registry. CamFinTech recommends a middleware architecture that decouples the ERP system from the CamInvoice API, providing buffering, retry logic, and reconciliation capabilities. The recommended architecture comprises three components: an Invoice Gateway service that receives invoices from the ERP system, validates them against the CamInvoice business rules locally, and queues them for submission; a Submission Engine that processes the queue, submits invoices to the CamInvoice API, handles retries for transient failures, and stores the digital stamp response; and a Reconciliation Service that periodically compares internal invoice records against CamInvoice registry data to detect and resolve discrepancies. For enterprises using popular ERP platforms (SAP, Oracle, Microsoft Dynamics), CamFinTech has developed pre-built CamInvoice connectors that extract invoice data from the ERP, transform it to UBL 2.1 format, submit it through the middleware architecture, and write back the CIRN and digital stamp to the ERP invoice record. These connectors reduce integration time from 8-12 weeks of custom development to 2-4 weeks of configuration and testing.

The GDT's phased CamInvoice mandate is structured to bring all registered businesses into compliance over a three-year period (2025-2027), starting with the largest enterprises and progressively including smaller businesses. Each phase defines the business size threshold, compliance deadline, and transitional provisions for businesses that are actively integrating but have not completed technical implementation. Phase 1, effective January 2025, covers large enterprises with annual revenue above KHR 1 billion (approximately USD 250,000). Approximately 12,000 businesses fall into this category, with 10,200 (85%) achieving compliance by the deadline. The GDT extended a 3-month grace period for remaining Phase 1 businesses that demonstrated active integration efforts. Phase 2, effective January 2026, covers medium enterprises with annual revenue between KHR 250 million and KHR 1 billion (approximately USD 62,500 to USD 250,000). This phase encompasses approximately 35,000 businesses and represents the most challenging compliance wave due to the lower technical maturity of mid-market enterprises. Phase 3, effective January 2027, covers all remaining registered businesses regardless of revenue. This phase includes approximately 470,000 micro and small businesses, many of which lack formal accounting systems. The GDT is developing a simplified CamInvoice interface (mobile app and USSD-based) for this segment, and is partnering with MFIs and accounting firms to provide free training and integration support.

One of the GDT's primary motivations for CamInvoice is automated VAT cross-matching, which compares the output VAT declared by sellers against the input VAT claimed by buyers. Before CamInvoice, this cross-matching was performed manually on a sample basis during GDT audits. CamInvoice enables real-time, comprehensive cross-matching across all registered invoices, dramatically increasing the GDT's ability to detect VAT fraud, underreporting, and ghost invoices (fabricated invoices used to inflate input VAT deductions). The automated cross-matching engine flags discrepancies in three categories: missing invoices (buyer claims input VAT for an invoice that the seller never submitted to CamInvoice), amount mismatches (buyer's claimed input VAT differs from the seller's registered output VAT), and timing mismatches (buyer claims input VAT in a different period than the seller reported the sale). Flagged discrepancies trigger automated inquiries to both parties and may escalate to formal GDT audit if unresolved within 30 days. For enterprises, the audit implications of CamInvoice are significant. Every invoice is now permanently recorded in the GDT database with full line-item detail, creating a comprehensive audit trail that the GDT can query at any time. Enterprise tax departments should implement internal controls to ensure that all VAT input claims are supported by valid CamInvoice-registered documents and that output VAT is correctly calculated and submitted for every issued invoice. CamFinTech provides CamInvoice compliance audit services to help enterprises identify and remediate gaps before GDT scrutiny.

Enterprise systems submitting high volumes of invoices to CamInvoice should implement performance optimizations to minimize API latency, reduce rejection rates, and ensure reliable delivery. Based on CamFinTech's experience with Phase 1 enterprise integrations, the following best practices are recommended. For throughput optimization, use the batch submission endpoint for volumes exceeding 100 invoices per hour. Batch submissions accept up to 1,000 invoices in a single API call and process them asynchronously, reducing network overhead and enabling the GDT to optimize server-side processing. Implement client-side pre-validation to catch errors before API submission, targeting a first-pass acceptance rate above 98%. Use connection pooling and HTTP keep-alive to minimize TLS handshake overhead for sequential submissions. For reliability, implement an outbox pattern where invoices are written to a local database table before API submission, ensuring that no invoice is lost if the CamInvoice API is temporarily unavailable. Use exponential backoff with jitter for retry logic (initial delay 5 seconds, maximum delay 5 minutes, maximum 10 retries). Implement circuit breaker patterns that stop submission attempts during prolonged CamInvoice outages and alert operations teams for manual intervention. For reconciliation, download the daily CamInvoice registry extract (available via the Reporting API at 06:00 ICT) and compare against internal records to detect any invoices that were submitted but not registered, or registered but not recorded internally. Maintain a reconciliation dashboard with key metrics: total submitted, total registered, rejection rate, average processing time, and outstanding discrepancies. CamFinTech provides monitoring templates for popular observability platforms (Datadog, Grafana, New Relic).