Oman Tax Data Document explained

The Tax Data Document, or TDD, is one of the easiest parts of Fawtara to misunderstand. It is not the same as the invoice sent to a buyer. It is a separate tax-reporting document that reports invoice data to the tax authority.

For developers, that distinction matters. If a system treats the TDD as just another copy of the buyer-facing invoice XML, it will be harder to validate, debug, archive, and explain failures.

The short answer

The Oman TDD is a regulatory reporting artifact. It belongs beside the invoice flow, but it should be implemented as its own module with its own semantic model, syntax binding, code lists, business rules, and validation artefacts.

Build it as a deterministic output from stored invoice data. Preserve links between the source invoice, PINT-OM invoice XML, TDD instance, validation result, and archive record.

Invoice XML and TDD are different jobs

The PINT-OM invoice represents the commercial invoice or credit note in the e-invoicing process. The TDD reports tax data extracted from source documents for tax reporting and compliance.

That gives each artifact a different engineering job:

Artifact	Primary job	Main risk if misunderstood
PINT-OM invoice XML	Represents the issued invoice or credit note in the e-invoicing process.	The invoice cannot be validated or exchanged correctly.
TDD	Reports tax data to the tax authority.	Tax reporting can fail even when the invoice-side flow looks correct.
Human-readable invoice	Shows the customer a readable invoice.	A PDF or paper copy is mistaken for the compliance record.

The TDD should not be an afterthought bolted onto a PDF generator. It should be a deliberate data product from the invoice system.

What the TDD package includes

The current OpenPeppol Oman TDD documentation includes a process page, business-interoperability specification, semantic model, syntax binding, code lists, business rules, and Schematron artefacts.

For implementation planning, group the package like this:

Layer	What to inspect
Process	When a TDD is created, submitted, updated, withdrawn, or checked.
Semantic model	Business terms and structure of the tax-reporting document.
Syntax binding	How the semantic model is expressed in XML.
Code lists	Allowed values that must match the published artefacts.
Business rules	Cross-field and tax-reporting conditions.
Schematron	Machine-readable validation rules.
Release notes	Status, publication date, and breaking or notable changes.

Use the release notes as part of change control. A mapper written against one release should not quietly run against another release without test evidence.

TDD data model: what to preserve

Keep enough source data to regenerate, explain, and audit the TDD later.

At minimum, preserve:

• source invoice identifier;
• source invoice issue date;
• document type;
• seller and buyer identifiers;
• tax registration identifiers;
• invoice totals and tax totals;
• line or summary tax categories required by the final model;
• source-document references;
• validation artefact version;
• TDD creation timestamp;
• submission or status timestamp if applicable;
• correction, update, or withdrawal history where relevant.

Do not store only the generated XML string. Store the source data, the generated artifact, the validation result, and the relationship between them.

Recommended module boundary

Keep the TDD implementation separate from invoice rendering and customer delivery.

A clean architecture has these pieces:

Module	Responsibility
Source invoice model	Owns the canonical invoice data used by accounting, invoice XML, TDD, and archive.
PINT-OM mapper	Generates the buyer-facing invoice or credit-note XML.
TDD mapper	Generates the tax-reporting document from source data.
Validator	Runs XSD, code-list, business-rule, and Schematron checks.
Submission/status adapter	Handles provider or authority-facing submission/status calls when applicable.
Archive	Stores source data, generated artifacts, validation results, timestamps, and correction links.

This separation makes it possible to fix a TDD issue without rewriting the invoice PDF, and to fix an invoice-mapping issue without hiding a tax-reporting failure.

Error handling

Do not show raw Schematron failures only to finance users. Keep the raw error, but add a readable explanation and route it to the person who owns the source data.

Good error handling should identify:

• the document affected;
• whether the failure is invoice-side, TDD-side, or source-data-side;
• the source field that needs correction;
• the rule or validation layer that failed;
• whether the document can be regenerated after correction;
• whether a previously submitted document needs an update or withdrawal path.

The error flow should be tested with invalid fixtures before go-live.

Test cases for a TDD implementation

Create fixtures before provider testing starts.

Recommended fixture set:

• simple B2B invoice;
• simple B2C invoice;
• credit note linked to an original invoice;
• debit note or correction case;
• export case;
• import or self-billing case if relevant;
• invoice with multiple VAT rates;
• invoice with allowance or charge;
• Arabic buyer or item text;
• intentionally invalid TDD for each validation layer;
• update or withdrawal scenario if confirmed by the final process.

Each fixture should include source data, expected TDD output, expected validation result, and the reason for the test.

Archive and traceability

The OTA FAQ confirms that archiving remains the taxpayer's responsibility. A TDD implementation should therefore support traceability, not only submission.

For each TDD, be able to answer:

• which source invoice produced it;
• which mapper version generated it;
• which official artefact version validated it;
• when validation passed or failed;
• whether it was submitted, updated, withdrawn, or rejected;
• who corrected the source data;
• where the related invoice XML and human-readable copy are stored.

This is the difference between a working demo and an auditable production process.

What is not safe to claim yet

Do not publish or rely on the following without current primary evidence:

• exact final TDD field names;
• exact final TDD business-rule counts;
• final submission/update/withdrawal behavior beyond the current OpenPeppol process text;
• exact QR/TLV details;
• final penalty amounts;
• claims that a vendor or connector fully supports the Oman TDD.

The safe claim is that TDD is a separate tax-reporting artifact and should be implemented, validated, versioned, and archived separately from the buyer-facing invoice XML.

Next step

Take one real invoice and build a traceability table. Include the source invoice record, generated PINT-OM invoice XML, generated TDD, validation results, artefact versions, and archive location. If that traceability table is hard to fill out, the implementation needs a clearer data model before go-live.