Every Thai company we have worked with treats e-Tax Invoice & e-Receipt as a compliance checkbox at first. Halfway through the project, they discover it touches numbering sequences, PDF templates, digital signatures and a third-party submission service all at once. Setting up Odoo e-Tax invoice correctly means getting all four pieces to agree with each other. It is not just installing a module and hoping the Revenue Department accepts whatever comes out.
This is the setup sequence we actually follow on client projects. It includes the parts that go wrong the first time.
Odoo e-Tax invoice: what the Revenue Department actually requires
Thailand runs two separate schemes. Mixing them up is the single most common planning mistake we see. The first is e-Tax Invoice by Email, aimed at small businesses with annual revenue up to THB 30 million. It is verified through an ETDA time stamp rather than a digital signature. The second is e-Tax Invoice & e-Receipt, open to businesses of any size. This route requires a digital signature on every document.
Both schemes require qualifying sales documents to be transmitted electronically. Submission goes directly or through an authorized service provider, within the filing period. The document itself needs a fixed structure: taxpayer ID, branch code, a sequential running number per document series, and a VAT breakdown. Depending on the scheme, it also carries a time stamp or a digital signature tied to the submitting entity.
We tell clients early: confirm which scheme you qualify for and want to register under before touching Odoo configuration. The two paths configure differently downstream. Switching later means redoing numbering and signing setup.
Odoo e-Tax invoice numbering: the part everyone underestimates
Thai e-Tax invoices need a numbering scheme that is sequential, gapless within its series, and traceable back to the issuing branch. Odoo's native sequence engine handles sequential numbering fine. Thai companies usually run multiple document series in parallel, though, one per branch and sometimes one per point of sale. The moment someone manually resets a sequence, or two branches share a prefix by accident, the export file gets rejected. That rejection happens at the provider's validation step, not inside Odoo itself.
Our checklist before go-live:
- One dedicated sequence per legal branch, matching the branch code registered with the Revenue Department, not an internal Odoo naming convention
- No gaps allowed. Cancelled invoices get a credit note, never a deleted or renumbered document
- Prefix and reset rules locked down in access rights, because a single incorrect edit here contaminates the whole month's submission file
- A test run against the provider's sandbox before the first live batch, always
Choosing a service provider for e-Tax invoice filing
Odoo itself does not submit anything to the Revenue Department. It builds the correctly formatted document. Then it either signs the document directly or hands it to a certified service provider for signing and transmission. Which route to take depends mostly on volume and existing relationships. Some Thai accounting teams already work with a provider for other filings. They often prefer to keep that vendor for e-Tax as well.
When we scope this with a client through our Odoo implementation services, we compare providers on three practical points. First, turnaround time for the daily or monthly submission batch. Second, how their API or file-drop interface integrates with Odoo's export. Third, what happens when a batch is rejected. Some providers give a clear per-line error. Others return an opaque failure that takes a support ticket to decode. That third point matters more than most feature comparisons once you are three months into live filing.
The approval flow inside Odoo
The workflow we implement typically looks like this. An invoice is validated by the accounting team as usual. That validation triggers generation of the e-Tax XML or PDF/A-3 document in the background. The document sits in a pending state until a designated approver reviews it. Usually that is the finance manager, and sometimes a second person for segregation of duties. Only after the provider confirms successful transmission does Odoo mark the document as filed.
We keep this approval step manual rather than fully automatic, even where the technology allows straight-through processing. The reason is simple. The first few months of any e-Tax rollout surface edge cases: a customer with an outdated tax ID, a credit note issued against a document from before go-live, a branch code typo. These are far cheaper to catch before submission than after.
Where Odoo e-Tax invoice work connects to other Thai localization
e-Tax invoicing rarely lives on its own. Most of the Thai companies we support through our ERP development services are also managing VAT reporting, withholding tax certificates for PND 3 and PND 53, and PromptPay reconciliation in the same close cycle. If the e-Tax document numbering is wrong, it usually shows up first as a VAT return that will not tie out. It rarely shows up first as a rejected filing. That is why we treat this as one connected piece of ongoing support rather than a standalone module install.
Companies selling through Shopee, Lazada or TikTok Shop add another layer. Marketplace payouts need to map back to individual e-Tax documents per order. That mapping is where a lot of generic Odoo setups fall apart, usually because the marketplace integration and the e-Tax module were configured by different people at different times. This is where our Odoo API integration services usually get pulled in mid-project.
A realistic project timeline
For a single-entity company with one or two branches, we typically plan the phases below.
| Phase | Duration | What happens |
|---|---|---|
| Requirements and provider selection | 1-2 weeks | Confirm filing scheme, pick provider, get sandbox access |
| Configuration | 1-2 weeks | Sequences, templates, approval routing, signing setup |
| Parallel testing | 2-4 weeks | Run e-Tax alongside existing paper/manual process |
| Cutover | 1 filing cycle | First live batch, close monitoring |
Multi-branch or multi-company setups take longer. Branch-level access rights and numbering need sign-off from each branch's accounting lead before anything goes live.
The trade-off worth naming
Here is the honest limitation. e-Tax Invoice & e-Receipt adds a real approval step and a real dependency on a third-party provider's uptime and turnaround. It is not a fully hands-off background process. Companies that expect same-day, zero-touch filing from day one are usually disappointed by month one. That is when the first rejected batch teaches everyone what the edge cases actually are. Budget for that learning period rather than assuming the first configuration will be the last one.
If your company is approaching the mandatory threshold, or already filing manually and looking to automate, start with a short scoping call before committing to a provider. The numbering and approval decisions are much cheaper to get right before the first invoice than to unwind after three months of live filing. Our team at Odoo ERP customization services has rebuilt this setup more than once, after other providers got the numbering wrong the first time. It always costs more the second time. Our Odoo ERP support services team then stays on to watch the first few filing cycles.