Thailand
B2B, B2C, Ausgang, Steuerberichterstattung
2026-08-28
Ein belastbares Thailand-Konzept darf nicht annehmen, dass die Kundendatei und die Behördennachricht identisch sind.
So nutzen Sie diesen Leitfaden
Ein gutes Projektergebnis wiederholt nicht nur die Vorschrift. Es schafft ein nachvollziehbares Entscheidungsmodell, das Regeln mit Gesellschaften, Transaktionsszenarien, Quelldaten, Systemverhalten, Betriebsverantwortung und Nachweisen verbindet.
End-to-End-Betriebsablauf
Der Plattformaufruf ist nur eine Stufe des Geschäftslebenszyklus.
- Qualifizieren
Umfang, Kanal und Dokumentweg vor der Erzeugung bestimmen. - Validieren
Fehlende Identitäten, Steuern, Beträge und Bezüge blockieren. - Erzeugen
Darstellung mit nachvollziehbarer Mapping-Version erstellen. - Senden
Duplikate durch Idempotenz und Korrelation verhindern. - Interpretieren
Antwort in Finance-Status und Aktion übersetzen. - Liefern und abstimmen
Kundenzustellung, Ergebnis und Buchung koordinieren. - Aufbewahren
Quelle, Payload, Antwort, Darstellung und Ereignisse zusammen archivieren.
Länderspezifische Entscheidungen
01
Kundenzustellung
ETDA erläutert, dass elektronische Rechnungen oder Belege bei Erfüllung der Anforderungen etwa als digital signiertes PDF oder PDF/A-3 zugestellt werden können.
02
Übermittlung an die Steuerbehörde
Für die Revenue Department müssen die Daten im vorgeschriebenen XML-Standard erstellt werden. XML-Upload, Host-to-Host und Provider sind getrennte Übermittlungsoptionen.
03
Beide Darstellungen kontrollieren
Geschäftsrechnung, signierte Kundendarstellung und übermitteltes XML teilen eine nachvollziehbare Identität, Beträge und Status, bleiben aber getrennte Archivobjekte.
Jedes Artefakt als eigenes Kontrollobjekt behandeln
Handelsrechnung, Payload, Plattformantwort und Kundendokument hängen zusammen, sind aber nicht austauschbar. Ihre getrennte Identität muss in Monitoring, Abstimmung und Auditabruf sichtbar bleiben.
| Entscheidungsbereich | Zu klärende Entscheidung | Aufzubewahrender Nachweis |
|---|---|---|
| Quelltransaktion | Autoritatives ERP-Dokument und auslösendes Ereignis festlegen. | Dokumentschlüssel, Version, Gesellschaft, Zeit, Status. |
| Strukturierter Payload | Nationale Darstellung aus validierten Fakten erzeugen. | Payload-/Mapping-Version, Prüfsumme, Korrelations-ID. |
| Plattformantwort | Technische und fachliche Antworten nicht in einem Erfolgsflag verdichten. | Originalantwort, normierter Status, Grund, Aktion. |
| Kundendarstellung | Geeignetes lesbares Dokument über den vereinbarten Kanal liefern. | Dokument, Empfänger, Kanal, Zeitpunkt. |
| Änderungskette | Ersatz, Storno und Folgebelege mit dem Original verbinden. | Originalbezug, Ereignisse, Endstatus. |
Erforderliche Fehlerszenarien
- Ablehnung nach ERP-Buchung.
- Timeout bei möglicher Annahme.
- Duplikat mit anderer technischer ID.
- Annahme ohne Kundenzustellung oder Abstimmung.
- Korrektur ohne stabilen Originalbezug.
Amtliche Quellen
- 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