Thailand's e-Tax Invoice & Receipt regime pushes work that finance teams used to do informally into a signed, machine-readable, archivable process. A posted account.move has to become a document carrying a correct 13-digit Tax ID, a branch code, Thai and English party names, a VAT breakdown that reconciles to the ledger, and a digital signature a recipient or auditor can verify years later. Odoo core models none of that. account.move has no branch code, no Thai legal-name field separate from the display name, nowhere to keep a signature or a provider document reference, and no state that distinguishes "posted in the ledger" from "accepted as an e-Tax document". Teams end up exporting to spreadsheets, re-keying into a portal, and reconciling two sets of numbers at month end — which is exactly where the errors and the audit exposure live.

What we build is a Thai localisation layer that sits on top of your existing accounting flow rather than beside it. A new model — typically l10n_th.etax.document — is created from the posted move and carries its own lifecycle: draft, signed, submitted, accepted, rejected, cancelled. Company and partner records gain the fields the format actually requires (Tax ID with checksum validation, branch code defaulting to 00000 for head office, Thai legal name, address decomposed into the sub-district / district / province structure the schema expects), enforced with @api.constrains so a bad master-data record fails at save time instead of at submission time. Tax mapping is configuration, not code: each account.tax maps to its Thai tax category (7% VAT, zero-rated, exempt, out-of-scope), so the XML is generated from what you actually posted and totals always tie back to the journal entry.

One posting produces both outputs. The machine format comes from a serializer that reads the mapped master data and tax lines and validates the result against the schema before anything is signed, with field-level errors surfaced on the record. The human-readable copy is a QWeb report designed for Thai typography and the required legal wording, rendering the document reference and a verification QR code on the PDF. Signing runs through a pluggable adapter — your certificate in a configured keystore, or your chosen service provider / e-Tax agent called over its API — so the signing route is a configuration choice, not a rewrite. Delivery to the buyer is queued through the standard mail layer with the signed artefacts attached, and every attempt, response payload and error is written to the chatter of the source invoice, where an accountant would actually look for it.

Rejections are treated as a normal path, not an exception. A rejected document returns to the operator queue with the provider's reason code and message on the record; the correction workflow either re-issues once the underlying data is fixed or produces the appropriate credit/debit document linked back to the original, so the chain of references stays intact for audit reconstruction. Signed XML, the rendered PDF and the raw signing response are stored as immutable attachments with a retention policy and a scheduled action that flags anything approaching the end of its statutory retention window. Access is controlled with ir.model.access.csv plus record rules — issuers create and submit, auditors get read-only across companies, and the archive is never editable from the UI. Dashboards and filtered list views show what is pending, signed, rejected or overdue, and everything is reachable over XML-RPC/JSON-RPC if issuance is driven from an upstream POS or billing system.

This is build-to-order, not a download. We start with a scoping call to confirm your Odoo version and edition, whether you sign in-house or through a service provider, your branch structure, and how invoices reach buyers today. From confirmed scope, typical delivery is 2–4 weeks: we build against your series, install on a staging database restored from your production data, run UAT with your finance team on real documents, then go live with a rollback plan in hand. You receive the source code and the git repository, so nothing here is a black box you cannot maintain.