Inside the Oman Tax Data Document (TDD): Engineering Walkthrough

The TDD in one paragraph

The Tax Data Document (TDD) is Oman's CTC artefact. It is a structured XML document, generated from the underlying PINT OM invoice, that the Oman Tax Authority (OTA) receives in real time alongside the invoice flow on Peppol. It is not the invoice. The invoice itself reaches the buyer through the Peppol four-corner network using the PINT OM customisation. The TDD reaches the OTA through a direct submission channel.

If you are scoping Fawtara, the TDD is the part of the project where most engineering hours land. This post is the deep-dive companion to our Oman Fawtara readiness guide.

CustomizationID and ProfileID

CustomizationID = urn:peppol:taxdata:om-1
ProfileID       = urn:peppol:bis:taxdata

These two values disambiguate the TDD from any other PINT or BIS document. They drive the validator selection, the routing, and the OTA-side ingestion.

Structural sketch

A TDD lives under a single root element in the pxs: namespace. The major blocks:

1. Document identification — pxs:ID, pxs:IssueDate, pxs:DocumentTypeCode, pxs:DocumentCurrencyCode, pxs:TaxCurrencyCode.
2. Source-document reference — link back to the originating PINT OM invoice (its ID and IssueDate).
3. Parties — supplier (issuer of the invoice) and customer (buyer), each with endpoint ID, party name, party tax scheme.
4. Tax breakdown — pxs:TaxLine per tax category and rate, with taxable amount and tax amount.
5. Monetary totals — line extension amount, tax exclusive amount, tax inclusive amount, tax amount.

The TDD does not carry:

• Line-level descriptions or quantities.
• Allowances or charges at line level (allowed only at header where they impact tax totals).
• Payment instructions, terms, or means.
• Notes and attachments not relevant to tax.

The intent is a tight, tax-authority-relevant document — small, fast to validate, and fast to ingest at scale.

The mapping from PINT OM invoice

A working transform reuses these fields directly:

Where the invoice carries multiple tax subtotals at different rates, the TDD aggregates them into one pxs:TaxLine per (category, rate) pair. The transform must therefore group and sum, not blindly map.

Why a deterministic, pure transform

Treat the TDD generator as a pure function:

TDD = transform(PINT_OM_Invoice)

No database lookups inside the transform. No date-based calculations not already in the invoice. No external HTTP calls. Why:

• Exhaustive testing. Every published OpenPeppol PINT OM sample becomes a unit test. A failure means a gap in the transform, not a debate about interpretation.
• Idempotency. The same input always yields the same output. If you regenerate, the TDD is bit-identical, which is critical for retries.
• Auditability. A pure transform is reviewable in a single PR.

This is how the GoRoute tdd_generator service is built. It runs in-process behind the validator and emits the TDD in milliseconds.

Validation

The TDD goes through a layered validation just like the source invoice:

1. XSD — pxs / cac / cbc namespaces.
2. Schematron — TDD-OM-peppol-om-tdd.xslt, run on Saxon-HE 12.4.
3. Code-list checks — currency code, country code, tax category code, unit code.
4. Cross-document consistency — same ID referenced as the source invoice; same supplier and customer parties.

A error blocks the submission to OTA. A warning is recorded for audit. The same discipline applies as in invoice validation errors you can prevent.

Submission flow

PINT OM invoice ──► validate ──► transmit on Peppol ──► persist receipt
                              │
                              └─► TDD transform ──► validate ──► submit to OTA ──► persist OTA correlation ID

Two persistence points matter:

• The Peppol receipt (MLR) for the invoice exchange between supplier and buyer.
• The OTA acknowledgement for the TDD submission.

Both are evidence of compliance. Lose either and the audit trail is incomplete.

Common engineering pitfalls

1. Hand-written TDD. Some implementers try to author the TDD alongside the invoice in the ERP. Don't. Generate it from the invoice.
2. Floating-point sums. Use decimal arithmetic with explicit rounding rules; the Schematron checks totals to the cent.
3. Skipping the Schematron warning. Warnings are not blockers but they are flags for the OTA's downstream analytics. Investigate them.
4. Tying TDD submission to invoice send synchronously. Decouple them. If OTA is briefly unreachable, the invoice still leaves; the TDD is queued and submitted on retry.

What we ship at GoRoute

GoRoute (POP000991) operates the TDD generator and the OTA submission path in production, with PINT OM compiled at Docker build time and a regression suite of 66 PINT-OM tests running on every release. See the higher-level Oman Fawtara readiness guide for the programmatic context, the PINT OM CustomizationID reference for the document-type table, and the e-invoicing mandates 2026 tracker for the global picture.

Book a demo to see TDD generation live against your sample invoices.

Sources: OpenPeppol PINT framework and PINT OM artefacts; Oman Tax Authority Fawtara public documentation; Saxon-HE 12.4 Schematron processor.