Peppol in Oman: A Practical Fawtara Readiness Guide

Why this guide

The Oman Tax Authority's Fawtara mandate brings continuous transaction controls (CTC) to a market that, until recently, exchanged invoices exclusively bilaterally. Fawtara is one of the first national CTC programmes to ride on the Peppol network using the PINT specialisation — which means suppliers, buyers, and service providers have to get three layers right at once:

1. Peppol transport — AS4 over Peppol with a certified Access Point and a registered SMP entry.
2. Document semantics — PINT OM for invoices and credit notes, both in billing and self-billing flavours.
3. Tax reporting — a compliant Tax Data Document (TDD) submitted to the OTA alongside the invoice flow.

This post walks through what "ready" actually looks like from an engineering standpoint, and gives you a concrete checklist to work through.

The document landscape

Five PINT OM document types make up the Fawtara picture. Each has a distinct Peppol CustomizationID and its own set of Schematron validation rules.

The TDD is the part that trips up new implementers. It is not an invoice — it is a tax-oriented projection of an invoice, with its own schema, its own Schematron (TDD-OM-peppol-om-tdd.xslt), and its own submission endpoint. If your pipeline only produces invoices, you are not Fawtara-ready.

Validation stack

Oman PINT documents go through a layered validation pipeline before anything leaves your access point:

1. UBL 2.1 XSD — structural validation.
2. Business rules — totals and calculation checks.
3. eDEC code lists — participant schemes, process IDs, unit codes.
4. CEN EN16931 + Peppol BIS 3.0 Schematron — baseline.
5. PINT OM Schematron — pint-om jurisdiction rules, per document type.

A Schematron error means reject. Only warning level issues may pass through. PINT documents skip the CEN + BIS baseline and run only their PINT Schematrons — this is a deliberate design choice in the PINT programme to avoid double-enforcement of the same rule family.

GoRoute compiles all nine PINT OM Schematrons at Docker build time using Saxon-HE 12.4 and runs them in-process on every submission. That keeps validation cost measured in milliseconds per document instead of a network round-trip.

The TDD generator

The TDD is produced from the PINT OM source invoice using a deterministic mapping — you should never hand-author it. A reliable generator needs to:

• Pick the right CustomizationID (urn:peppol:taxdata:om-1) and ProfileID.
• Reuse the invoice ID, IssueDate, DocumentCurrencyCode, and TaxCurrencyCode.
• Map every line's tax category, rate, and taxable amount into pxs:TaxLine.
• Carry the supplier and customer endpoint IDs in the format Fawtara expects.
• Produce a document that passes the TDD-OM-peppol-om-tdd.xslt Schematron.

Building this once and testing it exhaustively against the official PINT OM sample set is the single highest-leverage investment in an Oman readiness project.

The infrastructure checklist

To send and receive in production:

• [ ] G3 production certificate issued and installed (keystore format PKCS12).
• [ ] Peppol Access Point registered with OpenPeppol under your certification type.
• [ ] SMP entry published for each participant, referencing your AP endpoint.
• [ ] TLS certificate on your public endpoints (ap.yourdomain and smp.yourdomain).
• [ ] SML registration (production vs. test) matches your environment.
• [ ] Monitoring on every AS4 receive — delivery receipts persisted, duplicates detected.
• [ ] Retry policy on outbound send that respects idempotency.

The compliance checklist

• [ ] All five PINT OM document types producing valid XML.
• [ ] TDD generator tested against the full OpenPeppol PINT OM sample set.
• [ ] SLA tracking for TDD submission to the OTA.
• [ ] Error classification — what gets retried automatically vs. surfaced to the finance team.
• [ ] Audit trail on every submitted document (who, when, correlation IDs).
• [ ] Dated evidence of validation pass for every document that leaves your AP.

What you can do next

If you're scoping a Fawtara programme, the two most useful moves this week are:

1. Run the official PINT OM sample set through your validator — any failure against a sample means a gap in your implementation, not a question of interpretation.
2. Write the TDD generator as a pure transform — take a valid PINT OM invoice in, produce a valid TDD out, with zero external dependencies. That turns a compliance problem into a testing problem, which is a much better place to be.

GoRoute operates a certified Peppol Access Point and SMP, and ships PINT OM validation + TDD generation as first-class capabilities. If that would shortcut your roadmap, book a demo or read the technical factsheets.

Sources: OpenPeppol PINT OM artefacts (official), Oman Tax Authority Fawtara public documentation.