Thailand
B2B, B2C, Outbound, Tax Reporting
2026-08-28
A robust Thailand design should not assume that the file delivered to the customer is identical to the tax-authority submission payload.
How to use this guide
A useful project outcome is not a document that merely repeats the rule. It is a traceable decision model that connects the rule to legal entities, transaction scenarios, source data, system behaviour, operating ownership and evidence.
End-to-end operating flow
A platform call is one stage inside a longer business lifecycle.
- Qualify
Determine scope, channel and document path before building the payload. - Validate
Block incomplete identities, tax facts, amounts and references before transmission. - Generate
Create the platform-specific representation with a traceable mapping version. - Submit
Use idempotency and a correlation key so retries do not silently duplicate documents. - Interpret
Convert every response into a finance-readable status and responsible action. - Deliver and reconcile
Coordinate customer delivery with the validated or reported result and ledger posting. - Retain
Archive source, payload, response, representation and later events as one evidence chain.
Country-specific decisions
01
Customer delivery
ETDA explains that an electronic invoice or receipt may be delivered in an electronic format such as PDF or PDF/A-3 with a digital signature, provided required information and legal conditions are met.
02
Revenue Department submission
For submission to the Revenue Department, the data must be prepared as XML following the required standard. Upload XML, host-to-host and service-provider paths are separate delivery choices.
03
Control both representations
The business invoice, its signed customer representation and the submitted XML should share a traceable document identity, totals and lifecycle status while remaining distinct stored artifacts.
Treat every artifact as a separate controlled object
The commercial invoice, transmitted payload, authority response and customer document may be related, but they are not interchangeable. Their distinct identities must remain visible in monitoring, reconciliation and audit retrieval.
| Decision area | What must be decided | Evidence to retain |
|---|---|---|
| Source transaction | Identify the authoritative ERP document and the event that makes it eligible for processing. | Document key, version, company, timestamps and source status. |
| Structured payload | Generate the required national or platform representation from validated facts. | Payload version, mapping version, checksum and submission correlation ID. |
| Platform response | Interpret technical and business responses without collapsing them into one success flag. | Raw response, normalized status, reason and next action. |
| Customer representation | Deliver the legally and commercially appropriate readable document through the agreed channel. | Delivered document, recipient, channel and delivery time. |
| Adjustment chain | Link replacement, cancellation, credit/debit or other follow-on documents to the original identity. | Original reference, event history and final reconciled status. |
Failure scenarios the design must handle
- Validation rejection after the ERP invoice has already been posted.
- Network timeout where the platform may have accepted the document but the sender did not receive the response.
- Duplicate submission with a different technical message ID but the same business invoice.
- Authority acceptance without successful customer delivery or finance reconciliation.
- A later correction that breaks the link to the original submitted and delivered artifacts.
Official sources
- Thai Revenue Department e-Tax Invoice & e-Receipt portal
- Thai Revenue Department ICT standards for electronic tax transactions
- ETDA e-Tax Invoice & e-Receipt FAQ
- Revenue Department system overview