ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Thailand — RD, e-Tax Invoice and e-Receipt

Thailand has been operating an e-Tax Invoice & e-Receipt programme driven by the Revenue Department (RD) since 2017, with technical specifications published by ETDA. The system remains voluntary for most businesses but has become a de-facto prerequisite for suppliers of major buyers and for cross-border VAT deduction.

Regulatory timeline

  • 1985 — Revenue Code (ประมวลรัษฎากร) Section 86. General framework for Tax Invoice (ใบกำกับภาษี) obligations in Thailand.
  • 22 November 2010 — Amended Electronic Transactions Act B.E. 2544 (2001). Legal recognition of electronic documents and signatures in commercial acts.
  • 1 January 2012 — Voluntary e-Tax Invoice launch. RD pilot for the digitisation of Tax Invoices with digital signature, based on ETDA v1 specifications.
  • 1 January 2017 — e-Tax Invoice & e-Receipt programme. Programme overhaul with two variants: e-Tax Invoice & e-Receipt (full) for large volumes, and e-Tax Invoice by Email for very small businesses and SMEs (simplified signature via RD email).
  • 2018-2020 — Royal Decree TIA (Tax Incentive Act). Tax incentives for adoption (200 % deduction on implementation costs of RD-certified solutions).
  • 2021 — ETDA Standard Invoice v2.0. Publication of CII and UBL 2.1 XML schemas, aligned with international standards.
  • 2023 — TSP Framework. RD certifies a list of Trusted Service Providers (TSP) that can issue and store e-Tax Invoices on behalf of enterprises.
  • 2025-2027 — Mandatory roadmap. RD is preparing a progressive B2B mandatory mandate, schedule announced by turnover tier, with a planned go-live yet to be confirmed in 2026.

Technical schema

The format is defined by ETDA Recommendation TH-ER-007 and offers two profiles:

  • UN/CEFACT CII 16B — Cross Industry Invoice, namespace urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Preferred format for large issuers and international interoperability.
  • OASIS UBL 2.1 — alternative for vendors already familiar with UBL.

Both profiles share:

  • GuidelineID urn:etda:invoice:2.0 in document context.
  • TIN schemeID TH:RD:TIN: 13 digits (in fact composed of provincial code + identifier + check digit per the official RD formula).
  • Currency: THB by default, mandatory conversion for international transactions (Bank of Thailand rate).
  • VAT: 7 % standard (the 10 % statutory rate has been suspended at 7 % by successive Royal Decrees since 1999), exemption for exports.
  • Thai characters: mandatory UTF-8 encoding, the Royal Thai Script (ไทย) must round-trip without degradation.

Minimal example of an e-Tax Invoice CII (ETDA profile):

xmletax-invoice-th-cii.xml
<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
                          xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
                          xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:etda:invoice:2.0</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>TH-2026-00000142</ram:ID>
    <ram:TypeCode>388</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260516</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Ediverse Demo Thailand Co. Ltd.</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="TH:RD:TIN">0105549123456</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Customer Demo Thailand Co. Ltd.</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="TH:RD:TIN">0105540098765</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Submission flow

Two submission modes:

  • e-Tax Invoice & e-Receipt (full): the issuer signs the XML, sends it to the buyer through chosen channels (email, portal), then transmits a copy to RD via a dedicated endpoint (etax.rd.go.th SFTP or REST API). Monthly aggregated reporting to RD.
  • e-Tax Invoice by Email: a simplified variant for very small businesses and SMEs — the issuer emails the PDF + signed XML to an alias etax-receipt@rd.go.th, which signs with the RD certificate and forwards it to the recipient. Ideal for low volume.
textrd-etax-flow.txt
┌──────────────┐    ┌──────────────────┐    ┌──────────────┐
│ TH supplier  │───>│ RD via Service   │───>│ TH customer  │
│ (ERP, XML)   │    │ Provider (TSP)   │    │ (XML + PDF)  │
│ + NRCA cert  │    │ or direct RD     │    │              │
└──────────────┘    └────────┬─────────┘    └──────────────┘
                             │
                             ▼
                  ┌─────────────────────┐
                  │ Monthly RD reporting│  ← consolidated
                  │ (PP30/PP36)         │     VAT data
                  └─────────────────────┘

Validation

  • RD e-Tax Invoice portal: etax.rd.go.th — registration, submission and lookup.
  • ETDA — Electronic Transactions Development Agency: etda.or.th — XML specifications and list of certified TSPs.
  • NRCA Thailand: nrca.go.th — root authority and list of CAs certified for e-Tax signatures.
  • ETDA validator — web and CLI tool to check conformance to the TH-ER-007 schema (available to registered TSPs).

Common pitfalls

  1. 13-digit TIN and provincial structure. The Thai TIN has a structure (provincial code + sequence + check digit); truncating or zero-padding invalidates the invoice. Always validate via the RD.TIN.Validate API before issuance, especially for new buyers.
  2. Thai encoding and combining glyphs. Thai uses combining vowels (สระอำ) and tones in combination. Incorrect Unicode normalisation (NFC vs NFD) can truncate names on the buyer's display. Test with a complete Thai Glyph set.
  3. TSP vs direct issuance — structuring choice. Issuing directly to RD requires infrastructure investment (HSM, certificate, SLA monitoring); going through a TSP simplifies but locks you into their data format. Decide early based on volume and security profile.
  4. e-Tax Invoice by Email and PDF/A-3. The email mode requires a PDF/A-3 carrying the embedded XML, otherwise the RD filter rejects the mail. The most common error is sending a standard PDF with XML as a separate attachment.
  5. PP30 reconciliation. Issued Tax Invoices must reconcile with the RD monthly PP30 return. A timing offset (invoice issued on the 31st but transmitted on the 2nd of the next month) creates variances to be documented in the return.