Integration in Cambodia.

Your stack is rarely one thing. We stitch the pieces — your ERP, your bank, your e-commerce, GDT, your suppliers' EDI, your factory MES — so data flows where it needs to without spreadsheets in between. REST, GraphQL, EDI, webhook, file-drop, MQTT, SOAP — whatever the upstream system speaks, we build the bridge and the monitoring around it.

What does Scale's Integration practice cover?

Scale's Integration practice connects systems that were not designed to talk to each other — ERP to banking API, e-commerce to inventory, GDT to accounting, factory MES to operations dashboard — using REST, GraphQL, EDI, MQTT, and webhook architectures with observability and retry logic built in from the start. We operate across mobile, website, system, and pure API integration contexts, with a particular depth in Cambodia's local bank and government APIs.

The integration landscape that Cambodian operators face is more complex than it appears from the outside. A typical mid-size business in 2026 has: an ERP or accounting system (Odoo, SAP B1, QuickBooks, or custom), a banking relationship with ABA, Wing, or Bakong that it wants to read account statements from and initiate payments through, a GDT filing obligation that ideally runs automatically rather than manually on the 19th of each month, an e-commerce presence on Shopify, WooCommerce, or a custom storefront that needs inventory and order data to flow into the ERP, and increasingly, a factory or warehouse management system generating operational data that management wants to see in a single dashboard.

Each of those connections is a separate integration project — or a well-scoped phase within a larger integration programme. The difference between a well-built integration and a fragile one comes down to three things: the adapter pattern (does each integration have a clean contract that does not break when either side changes?), observability (can you see in real time whether the integration is running, how many records flowed, and what errors occurred?), and retry strategy (when the downstream system is temporarily unavailable, does the integration queue and retry correctly, or does it silently drop records?).

Cambodia-specific integration targets that we have built for: ABA Bank (account inquiry, fund transfer, payment initiation via ABA's business API), Wing Money (disbursements, balance inquiry), Bakong (KHQR QR code generation and payment confirmation via the NBC Bakong API), Pi Pay (payment confirmation webhooks), GDT e-VAT API (invoice submission, monthly declaration), CamInvoice/GDDE B2G e-invoicing (issuer registration, invoice issuance, status polling), and the NBC daily exchange rate API (KHR/USD rate for multi-currency ERP configurations).

International integration targets we regularly connect: Shopify (product sync, order ingestion, fulfilment webhooks), WooCommerce (order sync, stock level updates), Stripe (payment confirmation, refund events), QuickBooks Online (invoice read, payment sync), and major logistics APIs (DHL, FedEx, local logistics providers where APIs exist).

What systems can Scale connect?

We connect ERPs, banking platforms, GDT and CamInvoice government APIs, e-commerce storefronts, payment gateways, factory MES systems, third-party SaaS platforms, and any system that exposes an API, database view, or structured data export. If it has a documented interface — or even an undocumented one we can reverse-engineer — we can build an adapter for it.

• ERP and accounting: Odoo (v14–v17, webhook and Odoo RPC), SAP Business One (DI API, B1if, Service Layer), Acumatica (REST API, webhook framework), QuickBooks Online (QBO REST), QuickBooks Desktop (IIF/CSV extraction), Peachtree/Sage 50 (flat-file extraction), MAQSU, and custom-built accounting systems.
• Cambodian banking: ABA Bank business API (account statements, fund transfer, payment initiation), Wing Money (disbursement API), Bakong NBC (KHQR generation, payment webhook, settlement), Pi Pay (payment confirmation webhooks). Note: ABA and Wing API access requires a business account and a formal API partnership agreement with the bank — we assist with that process.
• Government APIs: GDT e-VAT API (invoice declaration, monthly VAT submission), CamInvoice/GDDE (B2G e-invoice issuance, status polling), NBC daily exchange rate API.
• E-commerce: Shopify (Admin API, webhooks), WooCommerce (REST API), custom storefronts (we define the event contract and build both sides if the storefront is ours).
• Payment gateways: Stripe (Events API, webhook ingestion), PayWay (Cambodia-specific payment gateway), ABA Pay (QR generation and confirmation), Wing Pay.
• Factory and operations: Modbus/MQTT for industrial sensor data, OPC-UA for factory equipment interfaces, custom MES system APIs, barcode scanner event streams.
• Third-party SaaS: Salesforce, HubSpot, Mailchimp, Slack, Google Workspace, Microsoft 365, and any SaaS platform with a published REST or GraphQL API.

How do we approach integration architecture?

Every integration Scale builds follows the same architecture principles: adapter isolation (each system connection is an independent module with a defined contract), observability first (every message logged, every error alerted, every retry tracked), and idempotent design (duplicate messages do not create duplicate records in the target system).

The adapter pattern means that when Odoo updates its API between versions, or when ABA changes its payment initiation endpoint, only the affected adapter changes — the rest of the integration pipeline is unaffected. This is not the way most bespoke integrations are built (most are monolithic scripts that mix business logic, API calls, and error handling in a single file), but it is the only architecture that is maintainable over a 3–5 year horizon.

Observability means every integration we build ships with: a log table recording each message (source system ID, target system ID, payload hash, timestamp, result status), a monitoring dashboard showing submission counts and error rates over time, and real-time alerting (Telegram and email) for any message that fails after exhausting its retry queue. Your operations team can see exactly what is flowing, what failed, and why — without calling us.

Retry strategy uses exponential back-off: a failed submission is retried after 1 minute, then 5 minutes, then 30 minutes, then 2 hours, then 24 hours. After five failures, the message is parked in a dead-letter queue and an alert is sent. Dead-letter queue items are visible in the monitoring dashboard and can be manually reprocessed after the underlying problem is fixed. This means a 2-hour ABA Bank API outage does not lose any payment confirmations — they queue and drain automatically when the API comes back.

Idempotency is implemented by hashing the source record's unique identifier and rejecting duplicate submissions before they reach the target system. For GDT specifically, a duplicate invoice submission would create a double-reporting error in your VAT declaration — the idempotency check prevents that regardless of how many times the source system retries.

How long do integration projects take?

A single integration (one source system, one target system, one data type) typically takes 4–8 weeks for an SMB scope. Multi-system integration programmes — connecting ERP, banking, GDT, and e-commerce in a single coordinated build — run 12–16 weeks for mid-market scope.

Projects that involve government API registration (GDT or CamInvoice) have an independent registration lane that must start on day one. CamInvoice GDDE partner registration takes 2–4 weeks and involves physical document submission — it cannot be accelerated by code. Plan for this dependency explicitly; it is the most common cause of integration timeline overruns for government-API projects.

• Week 1 — Discovery and mapping: Document the source and target systems, API access and credentials, data schemas, field mapping, error handling requirements, and submission frequency. Identify gaps (missing fields, TIN data, rate lookup requirements).
• Weeks 2–4 — Adapter build: Develop the adapter in TypeScript/Node (or Python for SAP B1 integrations). Wire to staging endpoints. Implement retry logic, dead-letter queue, audit log, and alerting.
• Weeks 4–6 — End-to-end testing: Run historical or synthetic test records through the full pipeline. Validate output against target system records. Fix edge cases (multi-currency, duplicate detection, schema edge cases).
• Week 6–7 — UAT: Your team runs live records through the adapter in parallel with the existing process. Resolve discrepancies.
• Week 7–8 — Go-live and hypercare: Adapter runs in production. Daily monitoring for the first 30 days. Handover of runbook and monitoring dashboard access.

What does Integration cost?

A single integration (one source, one target, one data type — e.g. Odoo to GDT e-VAT, or Shopify to QuickBooks inventory) is typically quoted at $2,000–$8,000 on a fixed-scope basis. Multi-system integration programmes connecting 3–6 systems in a coordinated build run $15,000–$40,000.

The core cost drivers for integration are: API complexity (a well-documented REST API is faster to integrate than a legacy SOAP or flat-file interface), data transformation complexity (field mapping and currency conversion add cost; full data normalisation across mismatched schemas adds more), error handling requirements (basic alerting is included; custom business-logic error routing adds scope), volume and frequency (high-frequency real-time integrations need more infrastructure than daily batch runs), and whether registration or third-party onboarding is required (ABA API partnership and CamInvoice GDDE registration add time, not cost, but they add duration to the project).

We quote fixed scope, fixed price after a 1-week discovery engagement ($500, deducted from the project fee if you proceed). The discovery output is a data-mapping document, a field-gap register, an architecture diagram, and a final quote. Multi-system programmes are quoted as a combined scope with a phased delivery plan.

Ongoing hosting and monitoring after go-live runs $100–$300/month per integration, covering server costs, monitoring, error alerting, and NBC rate pulls for currency conversions. Schema-change updates (when GDT or ABA updates their API) are quoted as fixed change orders, not open-ended retainers.

What about GDT and CamInvoice specifically?

GDT e-VAT and CamInvoice are the two government API integration tracks that every VAT-registered Cambodian business will eventually need. GDT e-VAT automates monthly invoice declarations to the General Department of Taxation. CamInvoice is GDDE's B2G e-invoicing platform for businesses that sell to government entities, launched May 2025.

GDT e-VAT integration reads confirmed invoices from your ERP or accounting system, converts USD amounts to KHR at the NBC daily rate on the invoice date, maps your internal tax codes to GDT's TVET code table (handling VAT 10%, VAT 0%, VAT exempt, WHT at 7%/14%/15%), and submits to the GDT API with retry and audit logging. The adapter eliminates the manual re-entry that most Cambodian accountants perform today — copying invoice data from an accounting export into GDT's web portal before the 20th of each month.

CamInvoice (GDDE B2G platform) is newer, more complex to onboard, and affects a narrower set of businesses — those with government contracts or sales to state-owned enterprises. The integration requires: GDDE partner registration (2–4 weeks, physical document submission), issuer credential setup, a different document schema from GDT's API (CamInvoice uses a structured XML envelope), and status polling to confirm government receipt. We build and maintain CamInvoice adapters as part of ERP implementation projects for government-facing clients.

For the full GDT e-VAT integration guide, including Cambodia-specific pitfalls, see /insights/gdt-e-vat-explained. For the CamInvoice integration guide and GDDE partner registration process, see /insights/caminvoice-integration-guide. For integration pricing and project structure, see /services/integration/api.