From a won deal to a GDT-filed invoice: what a CRM hands over
What a won deal carries into the order and the invoice, what the CRM never writes, and how a quote in dollars reaches a VAT return in riel.
- A CRM issues no invoice and files no VAT. A won deal becomes an order in Sales and an invoice in Accounting; the ERP files the monthly return, and the CRM files nothing.
- Six fields carry across once: customer, TIN, currency, quoted price, delivery address, rep. If any of them is typed again in accounting, the two systems sit beside each other, not on one record.
- Two currency rules, one each. The pipeline converts once at each deal's stored rate. The invoice converts at the NBC rate on the invoice date, and the return reports in riel.
- The CRM never writes a journal line, a tax line or a stock movement. That boundary is what keeps the books a single record for the ten years the Law on Taxation asks for.
- Two customer lists is the failure to design against: one legal name, one TIN, one billing address, one currency of account, each held once.
Does a CRM issue invoices or file VAT in Cambodia?
No. A CRM records the deal up to the moment it is won. The order is raised in Sales, the invoice in Accounting, and the monthly VAT return goes to the GDT from the accounting ledger, so the ERP files the VAT and the CRM files nothing. A vendor who says otherwise is describing an accounting system with a pipeline screen on the front, or an adapter that does not exist inside the CRM.
Four stations sit between a handshake and a filed return, and the figure below draws them left to right: Deal (CRM), Quote and order (Sales), Invoice (Accounting), Monthly VAT return (filed by the ERP to GDT). Under each is what it writes: the stage and the quoted price; the sales order and the stock movement; the journal line and the tax line; the VAT return, in riel. A bold line after the first station reads: the CRM stops here. What crosses it is a set of fields, not a document. The rail beneath the stations lists what is carried across, customer, TIN, currency, quoted price, rep, ticked at every station. Under the first station one row is struck through: journal line, tax line, stock movement: never written here.
The boundary matters to a finance lead because the accounting ledger is what the GDT audits. The Law on Taxation 2023 (Royal Kram NS/RKM/0523/004) requires medium and large taxpayers to keep accounting records for ten years and small taxpayers for three (Article 201), and VAT invoices for ten years (Article 80). A CRM that wrote its own tax line would be a second set of books with a shorter memory and more authors. How GDT e-VAT filing works covers the return itself, including the 25th-of-the-following-month deadline for electronic filing. This page covers what reaches it.
What carries from the deal to the order without retyping?
Six fields: customer, TIN, currency, quoted price, delivery address, rep. Each is typed once, on the deal or the account, and read by every station after it. The order in Sales inherits them when the deal is marked won. The invoice in Accounting inherits them from the order. Nobody in accounting opens a second screen to find out who the customer was or what the rep agreed.
Whether a vendor's handoff is real takes one question in a demo: where is the TIN typed? If the answer is on the customer record, once, the CRM and the accounting system sit on one record. If the answer is again, in accounting, they sit beside each other, and the field the GDT checks on every B2B invoice now has two owners. The CRM service page puts that TIN test in the buyer's checklist. The table below runs it field by field.
| Field | Typed where | Read where | The TIN test result if typed twice |
|---|---|---|---|
| Customer (legal name) | On the account record, when the lead is qualified | Order, invoice, VAT return | Two spellings of one buyer, the Khmer one on the invoice and the Latin one in the pipeline; reports disagree on who bought |
| TIN | On the account record, before the first quote | Order, invoice, VAT return | Two TINs for one customer, or one blank; the GDT matches the TIN on the invoice against its registry, and the mismatch is found at filing |
| Currency | On the deal, at the quote | Order, invoice | An order in dollars against a quote in riel; the invoice total is right by accident or wrong by a rate |
| Quoted price | On the deal, at the quote | Order line, invoice line | A price retyped from a chat screenshot; the discount the rep agreed is lost, or applied twice |
| Delivery address | On the deal, at the quote; the account may hold several | Order, delivery note | Goods dispatched to the head office in Phnom Penh instead of the depot in Battambang |
| Rep | On the deal, when it is assigned | Order, commission report | Commission argued over at month end because accounting credited whoever typed the order |
One Cambodian detail belongs here. A quote accepted in a Telegram chat is a contract. Articles 5 and 12 of the Law on E-Commerce (Royal Kram NS/RKM/1119/017) make a quotation accepted by email, chat or a customer portal valid and enforceable, and make the electronic record admissible as evidence. So the acceptance is a dated row on the deal, carrying the message that accepted it, and that row is what the order is raised from. A screenshot on a rep's phone is evidence too. It is just evidence nobody in accounting can find.
What does a quote in dollars become on a riel VAT return?
A riel total, converted on the invoice date. Two rules apply, one at each end. In the pipeline, each deal stores its amount, currency, NBC rate and rate date, and the pipeline converts once at each deal's stored rate, so totals never drift. On the invoice, dollar amounts are converted at the NBC rate on the invoice date, the total payable and the VAT are shown in riel, and the return reports in riel.
The riel rule is narrower than vendors make it. Since GDT Notification 4908 of 18 March 2019, as summarised by DFDL, a tax invoice shows the total payable and the VAT in Khmer riel; the line items may stay in US dollars. The rate is the National Bank of Cambodia daily official rate, or a market rate no lower than it, under GDT Instruction 26118 of 28 October 2022, as summarised by DFDL. That is why the handoff figure carries one annotation on the invoice station and nowhere else: USD converted at the NBC rate on the invoice date. The pipeline never needs that rate, and the invoice never needs the pipeline's.
Take three invented deals on one pipeline, converted at the 2025 average of 4,011 riel per dollar (National Bank of Cambodia, Financial Stability Review 2025). A provincial wholesaler is quoted 12,000,000 riel: 2,992 dollars. An importer is quoted USD 4,500: 4,500 dollars, no rate needed. A second wholesaler is quoted 20,000,000 riel: 4,986 dollars. The pipeline total reads 12,478 dollars, and it reads the same on Monday as it did on Friday, because each deal keeps the rate it was quoted at. When the first deal is won and invoiced on a later date, the invoice does its own arithmetic at that day's rate, and the riel total on the invoice may differ from what the pipeline showed. That is not drift. That is two documents answering two questions.
| Deal | Quoted | Rate stored (NBC, quote date) | In USD | On the invoice |
|---|---|---|---|---|
| A, a provincial wholesaler | 12,000,000 KHR | 4,011 | 2,992 | NBC rate on the invoice date; may differ |
| B, an importer | USD 4,500 | none, quoted in USD | 4,500 | NBC rate on the invoice date; may differ |
| C, a second wholesaler | 20,000,000 KHR | 4,011 | 4,986 | NBC rate on the invoice date; may differ |
| Pipeline total | two currencies | converted once, at each deal's stored rate | 12,478 | no invoice carries this total; each invoice converts on its own invoice date |
Both columns matter because both currencies are still real money here. Inside Bakong, the national payment system, the riel share of transaction volume was 18.2% in 2020, 20.1% in 2021, 21.5% in 2022, 34.2% in 2023, 49.3% in 2024 and 58.2% in 2025 (National Bank of Cambodia, Financial Stability Review 2025). Payment arrives in riel more often every year, and quotes are still written in dollars. A pipeline that shows one currency is guessing about the other. How one till handles riel and dollars in the same sale is the same argument at the counter.
| Year | KHR share | USD share |
|---|---|---|
| 2020 | 18.2% | 81.8% |
| 2021 | 20.1% | 79.9% |
| 2022 | 21.5% | 78.5% |
| 2023 | 34.2% | 65.8% |
| 2024 | 49.3% | 50.7% |
| 2025 | 58.2% | 41.8% |
Where does the order check stock the warehouse can actually promise?
In the inventory ledger, not in the CRM. When a won deal becomes an order in Sales, each order line is checked against available stock: on hand minus what is already allocated to other orders. The CRM sees the answer; it does not compute it. A CRM that shows a stock figure of its own is showing a copy, and a copy is what a rep sells from after the warehouse has already loaded the truck.
This is the one-ledger point, and it is why the handoff is an ERP question rather than a CRM feature. The data spine that purchasing, stock, sales and accounting share is one record: the order a won deal becomes is the order the picker sees and the order the invoice is raised from. Available and on hand are two columns there, and every allocation is the row that moved a case from one to the other. What inventory software changes in a Cambodian business sets out that ledger. The CRM only reads its answer.
For a distributor the check runs the other way too. A rep at a wholesaler in Battambang takes a reorder on the phone. The draft order should tell the rep, before the customer hangs up, whether the depot can deliver this week or whether the goods have to come up from Phnom Penh. That answer lives in the stock ledger. The CRM's job is to ask it at the moment the order is drafted, not at the moment the truck fails to arrive.
What does the CRM never write, and why is that a feature?
A journal line, a tax line, a stock movement. Those three rows are written by Accounting and against the sales order at dispatch, on the ledger the auditor reads, and never by the CRM. The boundary is a feature because every row in the books then has one author, one timestamp and one place to be corrected. A CRM that could post to the ledger would be a second door into the accounts, open to everyone with a pipeline login.
The station table below is the whole article in one grid. Read down the CRM column: it writes the customer record, the quoted price and the currency and rate, and it reads or never touches everything else. Read across the VAT return row: only the ERP writes it, to the GDT, from the invoice. That column is what a finance lead should hold a vendor to in a demo. If the CRM column shows a writes cell anywhere below the currency row, ask who reverses that write when it is wrong.
| Row | Deal (CRM) | Order (Sales) | Invoice (Accounting) | Return (ERP to GDT) |
|---|---|---|---|---|
| Customer record | writes | reads | reads | reads |
| Quoted price | writes | reads | reads | never |
| Currency and rate | writes | reads | writes | reads |
| Order line | never | writes | reads | never |
| Stock movement | never | writes | reads | never |
| Journal line | never | never | writes | reads |
| Tax line | never | never | writes | reads |
| VAT return | never | never | never | writes |
The currency row has two writes cells on purpose. The deal writes the quote rate and its date; the invoice writes a new rate for the invoice date. Neither overwrites the other, which is the whole reason the pipeline and the books can both be right. Retention makes the boundary practical rather than tidy: under the Law on Taxation 2023 (Royal Kram NS/RKM/0523/004), Article 201, accounting records are kept for ten years by medium and large taxpayers and three by small ones, and Article 80 keeps VAT invoices for ten years. A CRM vendor's data export in year four is not the record the auditor asks for. The ledger is. Keep the CRM's memory rich and the ledger's memory long, and never make the second depend on the first.
What breaks when the CRM and the accounting system hold two customer lists?
The invoice. Two lists mean the same buyer exists twice, and the legal name, the TIN, the billing address and the currency of account each get a second chance to disagree. The disagreement is found where it costs most: on an invoice already sent, or in a filing that fails against a TIN that was right in one system and blank in the other.
One customer record has to carry four things exactly once. A second list breaks each of them in its own way:
- Legal name. The name on the invoice has to match the registered name behind the TIN. A second list holds the trading name the rep uses, or a different Khmer spelling, and the invoice goes out under a name the GDT registry does not know.
- TIN. The number the GDT matches on every B2B invoice. A second list holds a TIN typed from a photo of a patent certificate, one digit out, or holds nothing at all, and the filing fails on a line nobody in sales can see.
- Billing address. The address the invoice carries, which may differ from where the goods go. A second list holds the depot's address as the billing address, and the customer's finance team rejects the invoice for a month.
- Currency of account. Whether this buyer is invoiced in riel or in dollars, decided once. A second list decides it per document, so one buyer receives dollar invoices from accounting against riel quotes from sales, and the reconciliation is done by phone.
The fix is not a sync. A sync between two lists is a third list with a timer. The fix is one account record that the CRM writes and the accounting system reads, on books built for the auditors here, so a rep who corrects a TIN in the pipeline has corrected the next invoice. Where two systems have to stay two, because one of them is a bank or a customer's own portal, the API integration work is the honest version of that bridge: one direction, one owner per field, and a log of every write.
How is the handoff different on Odoo versus a purpose-built CRM?
On Odoo the handoff is a configured flow between modules that already share one database. On a purpose-built CRM it is a flow designed against your ledger. Both end in the same place: the CRM stops at the won deal, Sales raises the order, Accounting raises the invoice, and the ERP files the return. The difference is what arrives by default and what has to be built.
Built on Odoo CRM, a won opportunity becomes a quotation in Odoo Sales and a customer invoice in Odoo Accounting on the same partner record, so the customer, the TIN and the quoted price carry across without a connector. Two Cambodian gaps remain. An opportunity carries the company currency; a second currency on a deal, with its own rate and rate date, is a third-party module or custom work (Odoo documentation, checked 14 September 2026). And whatever Odoo ships for the Cambodian chart of accounts, it ships nothing for a Cambodian CRM: Khmer labels, riel quotes and the account-level currency decision are scope, not settings. How Odoo compares with SAP Business One and Acumatica here sets out the platform choice.
Purpose-built, the account record, the deal and the order are designed together, so the fields in the handoff table above are the schema rather than a mapping onto someone else's. That is the right route where the way you sell is the way you compete: a distributor whose deal is the account and whose order is a reorder, or a project seller whose milestones are invoiced one at a time. Either way the filing sits in the accounting system, inside the ERP build, and never in the CRM. Which route fits is decided in discovery, not on this page.
Frequently asked questions
- Can a CRM issue VAT invoices in Cambodia?
- No. A tax invoice is a document of the accounting ledger: a sequence number, a TIN on both sides, a riel total at the NBC rate on the invoice date and a tax line that reaches the monthly return. Those are written in Accounting. The rules for the document are set by Ministry of Economy and Finance Prakas 723 of 14 August 2019, in effect since 1 January 2020. A CRM that prints something called an invoice is printing a quote under a different heading, and the ledger does not know it exists.
- How does a CRM connect to accounting and to GDT e-VAT filing?
- To accounting, through the order: a won deal becomes an order in Sales, and the order becomes an invoice in Accounting on the same customer record. To the GDT, it does not connect at all. The monthly return is filed from the accounting ledger, electronically by the 25th of the following month, as the GDT e-VAT explainer sets out. Everything from the order onward belongs to the ERP.
- We want to keep a packaged SaaS CRM and run Odoo Accounting. Does that work?
- It can, and it is the two-list case above, so it works under one rule: the accounting system owns the customer record and the CRM reads it, never the reverse. Every field in the handoff table then has one owner. Eight CRM tools compared on seven questions records what each vendor says about handing a won deal to an accounting system. None of the eight files to the GDT.
- Does CamInvoice change any of this?
- No. E-invoicing is mandatory only for suppliers to the ministries named in MEF Circulars 003 and 012 of 2025; between businesses it remains voluntary. Where it applies, the invoice is submitted from the accounting system, the station that raised it, and the CRM's handoff is unchanged. The CamInvoice integration guide covers the submission itself.
- What does the rep need to see after the deal is won?
- Three things, read from the ledger rather than copied into the CRM: whether the order shipped, whether the invoice was paid, and whether the customer has an overdue balance before the next quote goes out. Those are reads in the station table's sense. The rep's screen shows them; the rep cannot change them. A reorder from a wholesaler with an unpaid invoice is a conversation, and the CRM's job is to start it before the truck is loaded.
- Who fixes a wrong price after the invoice has gone out?
- Accounting, with a credit note, never the CRM. The deal keeps its history, including the price the rep quoted and the message that accepted it. The invoice is corrected by a dated document with a name on it, which is what the ten-year retention rule is for. A CRM that let a rep edit an issued invoice would be editing the books from the sales floor.
Where to go next
What a CRM records, and when Excel stops working is the page before this one: the deal as dated rows, and the migration off the sheet. Field sales apps in Cambodia follows the rep who drafts the order where there is no signal. Eight CRM tools compared records what each vendor says about the handoff. The CRM service page sets out the two routes, built on Odoo CRM or purpose-built, and the Sales page covers the station the CRM hands to.