Every Thai company that crosses the Revenue Department's e-Tax invoice threshold asks the same question: can Odoo handle this, or do we bolt on a separate portal? We have set up Odoo e-Tax invoice and e-Receipt workflows for enough Thai businesses now to say the answer is yes, but the details matter more than most vendors let on. Get the numbering scheme or the provider handshake wrong and you end up with rejected batches at month-end close, which is the worst time to discover a configuration gap.
This post walks through how we actually configure Odoo e-Tax invoice and e-Receipt for Thai clients, what the Revenue Department expects on the data side, and where the real friction shows up during go-live.
What the Revenue Department actually requires for Odoo e-Tax invoice
The e-Tax Invoice & e-Receipt system requires a digitally signed document sent to the Revenue Department, either directly or through a certified service provider. The signed XML must carry the correct tax ID, sequential document numbering, VAT breakdown and a timestamp tied to your certificate or time-stamping service.
Two paths exist, depending on company size and transaction volume:
- e-Tax Invoice by Time Stamp — lower volume, uses the Electronic Transactions Development Agency (ETDA) time-stamping service for authentication, rather than a Certification Authority digital certificate.
- e-Tax Invoice & e-Receipt (full scheme) — requires a digital certificate, typically routed through a licensed service provider. This suits companies issuing a higher volume of invoices and receipts.
Which path you fall into is not an Odoo decision. It is a registration decision you make with the Revenue Department first, and Odoo configuration follows from that choice.
How e-Tax invoice requirements map into Odoo
Odoo does not sign or transmit documents to the Revenue Department itself. It generates the invoice or receipt in the correct structure, holds the sequential numbering correctly, and hands off to a connector or provider module that performs the signing and submission. We have worked with a few different providers, and the Odoo-side setup follows a similar shape each time:
- Company data: tax ID, branch code, registered address, all validated against what is on file with the Revenue Department.
- Document sequences: separate, non-repeating numbering per document type (tax invoice, credit note, receipt) and, in some cases, per branch.
- Journal configuration: dedicated sales journals tied to the e-Tax workflow so ordinary internal documents are not accidentally sent for signing.
- Provider connector: API credentials, certificate or time-stamp service reference, and a sandbox mode before anything goes live.
- PDF/XML template mapping: making sure the printed invoice matches what was actually signed and submitted, since Thai auditors will compare them.
None of this requires touching Odoo's core invoicing logic. We handle it through configuration and a thin integration layer, which keeps the setup upgrade-safe when you move between Odoo 16 through 19. Our Odoo API integration services team builds exactly this kind of connector work.
Document numbering: where most setups go wrong
Thai regulations expect the tax invoice number sequence to be continuous. No gaps, no reused numbers, even across branches if you have multiple. This clashes with how many companies previously ran numbering in spreadsheets or legacy systems, where gaps from voided invoices were skipped over informally.
In Odoo, we set this up so that:
- Each legal document type gets its own sequence object, scoped correctly to company and branch.
- Cancelled or voided documents are handled by credit note, not by deleting or renumbering, which keeps the sequence intact.
- Draft invoices do not consume a number until validated, so testing and re-editing in draft state never breaks the chain.
The most common failure we see in companies migrating from other software is a numbering scheme baked into invoice templates rather than a proper sequence. That breaks the moment two users create invoices at the same time. Odoo's built-in sequence mechanism handles concurrency correctly, but only if configured before go-live, not patched in afterward.
Choosing a service provider for e-Tax submission
Odoo does not include a bundled connection to every Thai e-Tax provider. You select and contract with a licensed provider, or use the ETDA time-stamp path directly for smaller filers, and then connect that provider to Odoo via API or a purpose-built module.
A few things worth knowing before you commit:
| Consideration | Why it matters |
|---|---|
| API vs. file-based submission | API integration lets the approval flow run inside Odoo; file-based means manual export/import steps each cycle |
| Certificate custody | Some providers hold your signing certificate on your behalf, others require you to manage it, affecting renewal responsibility |
| Volume-based pricing | Providers often price per document; high-volume retailers should model this cost before choosing |
| Response and retry handling | Rejected submissions need a clear retry path back into Odoo, not a manual side process |
We are vendor-agnostic here, and our job is making sure whichever provider you pick integrates cleanly with your Odoo invoicing and accounting flow. Failure and retry paths need to be visible to your accounting team, not hidden in provider logs no one checks. Our Odoo consultancy services team can walk you through the trade-offs before you sign a contract.
The approval flow inside Odoo
The part that actually changes daily behavior for your finance team is the approval flow. In a typical setup:
- Sales order is confirmed and delivery is completed.
- Invoice is created in draft state as usual.
- On validation, Odoo triggers the e-Tax submission, either automatically or via a manual send action, depending on how much control the client wants.
- The provider signs and forwards to the Revenue Department, returning a status.
- Odoo records that status on the invoice, and the finance team sees accepted, pending or rejected states directly from the invoice list view.
- Rejected documents route back for correction, typically a data issue like a mismatched tax ID or wrong document type, then get resubmitted.
We usually configure this so a rejected document does not block downstream accounting entries, since companies still need their books to move forward while a correction is investigated. That is a design choice, not an Odoo default, and it is worth discussing with your accountant before go-live.
Withholding tax and PromptPay alongside e-Tax invoice setup
Most of our Thai clients need e-Tax invoicing working alongside withholding tax certificates (PND 3 / PND 53) and PromptPay reconciliation on the receivables side. These are separate configurations in Odoo, but they touch the same journals and the same month-end close process. We set them up together rather than in isolation. Getting the chart of accounts and tax mapping right once, at the start, avoids a second round of rework when the e-Tax layer goes live a few weeks later. If your Odoo instance also connects to Shopee, Lazada or TikTok Shop, our Odoo API integration services work usually starts here, before the provider conversation.
One limitation worth knowing upfront
Odoo's e-Tax integration depends entirely on your chosen provider's uptime and API stability. If the provider has an outage or slows down during peak submission periods, invoices can back up in a pending state inside Odoo until the provider recovers. We build a manual fallback path for this, holding invoices in a queue rather than blocking sales, but there is no way to make the submission itself instantaneous or provider-independent. Companies with very high daily invoice volumes should factor this into which provider and plan they choose.
Getting your Odoo e-Tax invoice setup right the first time
We approach e-Tax and e-Receipt setup the same way we approach any Thai localization work. Configure first, verify against a real batch of invoices before go-live, and stay through the first month-end close to catch edge cases that only show up once real transactions run through the system. If you are planning a rollout, our Odoo implementation services page outlines how we scope and sequence this kind of work. Our Odoo ERP support services team can pick up ongoing provider and compliance changes after go-live.
If your company is registering for e-Tax invoicing for the first time, start the Revenue Department registration and provider selection in parallel with the Odoo configuration, not after. The two timelines rarely align on their own. Leaving the provider conversation until the end is the single most common cause of delayed go-lives we have seen.
