Comprehensive guide for implementing PINT OM-compliant e-invoicing in Oman. Built on Peppol International standards with Oman-specific requirements for seamless OTA integration and compliance.
PINT OMSpecifications
DCTCEModel
PeppolNetwork
PhasedRollout
Reporting Mandates
OTA Peppol eInvoicing
PINT OM Framework
Exchange Networks
Peppol Network
Accredited Service Providers
Supported Documents
Commercial Invoices (380)
Self-Billed Invoices (389)
Credit Notes (381)
Debit Notes (383)
Self-Billed Credit Notes (261)
Introduction to Oman E-Invoicing
The Sultanate of Oman is a country located on the southeastern coast of the Arabian Peninsula. As part of its vision for digital transformation and economic modernization, the Oman government is implementing electronic invoicing systems to enhance tax compliance, transparency, and operational efficiency across the business sector.
Key Authorities
Authority
Role
Responsibilities
Ministry of Commerce, Industry and Investment Promotion
Primary regulatory body for e-invoicing
• Developing and publishing e-invoicing standards and specifications • Setting compliance requirements for businesses • Managing the implementation timeline and phased rollout • Providing official guidance and documentation • Coordinating with other government entities
• Collecting and processing Tax Data Documents (TDD) from e-invoicing transactions • Monitoring VAT compliance through e-invoicing data • Conducting tax audits and enforcement • Providing tax-related guidance to businesses
The e-invoicing program is part of Oman's broader "Oman Vision 2040" strategy:
Objective
Description
Digitization
Transform government services and business processes to digital platforms
Economic Transparency
Enhance transparency and competitiveness in the business environment
Tax Compliance
Combat tax evasion and eliminate the shadow economy
Ease of Business
Improve and streamline business operations and processes
Data-Driven Policy
Enable informed government decision-making through real-time data
E-Invoicing Overview
Oman has adopted an e-invoicing framework based on international standards, specifically the Peppol network, adapted to local requirements through the PINT OM (Peppol International Oman) specifications. This system enables businesses to exchange electronic invoices in a standardized format while ensuring tax compliance through automated reporting to the Tax Authority of Oman.
For official updates and detailed information, please refer to the Ministry of Commerce, Industry and Investment Promotion and Tax Authority of Oman websites.
Oman E-Invoicing and Fiscalization Mandates
The Sultanate of Oman has introduced e-invoicing mandates as part of its digital transformation strategy. This section outlines the key mandate affecting businesses operating in Oman.
OTA eInvoicing with Peppol
The Ministry of Commerce, Industry and Investment Promotion has implemented a mandatory e-invoicing system based on the international Peppol network, adapted for local requirements through the PINT OM (Peppol International Oman) specifications.
What is Peppol?
Peppol (Pan-European Public Procurement Online) is an international network that enables businesses to exchange electronic documents, including invoices, in a standardized format. Oman has adopted this proven framework and customized it to meet local tax and business requirements.
Regulatory Framework
Component
Details
Issuing Authority
Ministry of Commerce, Industry and Investment Promotion
Tax Authority
Tax Authority of Oman (OTA)
Standard
PINT OM (Oman Peppol International Specifications)
Network
Peppol Network
Model
Decentralized Continuous Transaction Control and Exchange (DCTCE)
Who Must Comply?
Category
Scope
Business Type
All businesses operating in Oman
VAT Status
Both VAT-registered and non-VAT registered entities
Transaction Types
B2B (Business-to-Business) and B2G (Business-to-Government)
How It Works
The Oman e-invoicing system operates through a five-corner model:
Corner
Participant
Role
C1
Supplier
Issues the invoice
C2
Supplier's Service Provider
Validates and transmits the invoice, reports tax data to OTA
C3
Buyer's Service Provider
Receives and validates the invoice, reports tax data to OTA
C4
Buyer
Receives the invoice
C5
Tax Authority of Oman (OTA)
Collects tax data from both service providers
This decentralized approach means businesses must work with Accredited Service Providers (ASPs) to exchange invoices and report tax information automatically to the OTA.
Document Types
The mandate covers several types of electronic documents:
Code
Document Type
Description
380
Invoice
Standard business invoices for regular transactions
381
Credit Note
For returns, adjustments, and corrections
383
Debit Note
For additional charges and adjustments to previously issued invoices
389
Self-Billing Invoice
Buyer-issued invoices (in specific scenarios)
261
Self-Billing Credit Note
Buyer-issued credit notes to adjust self-billing invoices
Key Requirements
To comply with the OTA eInvoicing mandate, businesses must:
#
Requirement
Description
1
PINT OM Compliant Systems
Invoice format must follow Oman specifications
2
Accredited Service Provider
Use authorized providers to exchange invoices
3
Peppol Network Exchange
All invoices transmitted through the Peppol infrastructure
4
Automatic Tax Reporting
Service providers report Tax Data Documents (TDD) to the OTA
5
Record Maintenance
Keep proper audit trails and documentation
Benefits
The e-invoicing system provides the following benefits:
Benefit
Impact
Improved VAT Compliance
Reduces tax evasion and increases compliance rates
Enhanced Transparency
Increases visibility in business transactions
Reduced Manual Work
Minimizes manual processing and human errors
Faster Processing
Enables quicker invoice exchange and approval
Streamlined Audits
Simplifies tax audit processes and documentation
Real-Time Data
Supports government decision-making with live transaction data
Implementation
The e-invoicing mandate is being rolled out in phases. Businesses should take the following steps:
Step
Action
Purpose
1. Stay Informed
Monitor official Ministry of Commerce announcements
The Tax Authority of Oman (OTA) e-invoicing system is built on the PINT OM (Peppol International Oman) specifications, establishing a comprehensive framework for electronic invoice exchange and tax reporting.
What is Oman E-Invoicing?
The Oman e-invoicing program requires businesses to exchange electronic invoices in a standardized format through the Peppol network. This system enables real-time invoice validation, automated tax reporting, and seamless business-to-business document exchange while ensuring compliance with Oman tax regulations.
The framework is based on the international Peppol BIS Billing 3.0 standard, customized for Oman requirements through the PINT OM (Peppol International Oman) specifications.
The Five-Corner Model
Oman has adopted a Decentralized Continuous Transaction Control and Exchange (DCTCE) model, which operates through five key participants:
Corner
Participant
Role & Responsibilities
C1
Supplier
• Issues the invoice • Submits invoice data to their Service Provider • Receives confirmation and status messages
C2
Supplier's Accredited Service Provider
• Validates invoice data from supplier • Converts invoice to standard XML format (if needed) • Transmits invoice to buyer's Service Provider • Reports Tax Data Document (TDD) to OTA • Forwards status messages to supplier
C3
Buyer's Accredited Service Provider
• Receives and validates the invoice • Delivers invoice to buyer • Reports Tax Data Document (TDD) to OTA • Sends validation status messages • Forwards OTA status to buyer
C4
Buyer
• Receives the validated invoice • Reviews and processes the invoice • Receives status confirmations
C5
Tax Authority of Oman (OTA)
• Collects Tax Data Documents from both Service Providers • Monitors VAT compliance • Provides reporting confirmation messages
How It Works
The invoice flow follows these steps:
Supplier creates invoice and submits it to their Accredited Service Provider (C2)
C2 validates the invoice data and converts it to Oman standard XML format
C2 transmits the invoice to the Buyer's Service Provider (C3) via Peppol network
C2 reports the Tax Data Document (TDD) to the OTA (C5)
C3 validates the received invoice and sends status message to C2
C3 delivers the invoice to the Buyer (C4)
C3 reports the Tax Data Document (TDD) to the OTA (C5)
OTA confirms receipt of TDD to both C2 and C3
Status messages flow back through the chain to inform both parties
Key Components
PINT OM Data Dictionary
The Data Dictionary defines all required and optional fields for invoices, including:
Invoice identification and dates
Party information (supplier, buyer, payee)
Line items with pricing and quantities
Tax breakdowns by category
Payment terms and methods
Allowances and charges
Tax Data Document (TDD)
A subset of the invoice data that is automatically reported to the OTA by both Service Providers, containing:
Essential tax-related fields
Party identifiers
Tax calculations
Transaction amounts
Message Level Status (MLS)
Real-time status messages that confirm each stage of the process:
Validation success or failure
Transmission confirmation
Receipt acknowledgment
TDD reporting confirmation
Business Use Cases
The Oman e-invoicing framework defines 16 business use cases (matching the 20-bit transaction type identifier) that cover common invoice, credit note, and debit note scenarios. These use cases ensure standardized handling of various transaction types while maintaining compliance with Oman VAT regulations.
The 5 Mandatory Use Cases
These use cases establish the fundamental requirements for any e-invoicing implementation in Oman. All businesses must support these scenarios:
#
Use Case
Description
Data Requirements
1
Standard Tax Invoice
Basic e-invoice for taxable supplies
50 mandatory data points, including 15 new fields not previously required by Oman VAT law
2
Standard Tax Credit Note
Corrects or adjusts previously issued e-invoices
Mandatory and frequently used optional fields as per Data Dictionary
3
Debit Note
Additional charges or adjustments to previously issued invoices
Mandatory fields as per Data Dictionary
4
Self-Billing Invoice
Created by the buyer on behalf of the supplier
Standard invoicing data elements as specified
5
Self-Billing Credit Note
Corrects or adjusts a self-billing invoice
Mandatory fields as per Data Dictionary
The 11 Additional (Conditional) Use Cases
These use cases handle specific business scenarios with additional data requirements beyond standard invoice fields:
#
Use Case
Purpose
Additional Data Required
6
Third Party Invoice
Invoice issued by a third party on behalf of the supplier
Third party identifiers and authorization details
7
Summary Invoice
Consolidated invoice for multiple transactions over a period
Transaction grouping data and summary period information
8
Continuous Supply
Subscription or recurring services
Service period details and recurrence patterns
9
Export
Cross-border sales outside Oman
Export documentation references and destination details
10
Deemed Supply
Non-monetary transfers treated as taxable supplies
Specific deemed supply identifiers and valuation data
11
Import (Reverse Charge)
Special tax mechanism where buyer accounts for VAT on imports
Reverse-charge transaction indicators and reason codes
12
Profit Margin
Special VAT scheme for used goods, art, antiques
Margin calculation data and scheme identifiers
13
E-Commerce
Digital marketplace or online platform sales
Platform identifiers and digital commerce metadata
14
Import of Goods
Importation of goods into Oman
Import documentation, customs references, and duty data
15
Special Zone
Transactions involving special economic or free zone entities
Zone identifiers and customs-related data
16
Prepayment
Advance payments before delivery of goods or services
Prepayment reference, linked invoice details, and settlement terms
Field Complexity by Scenario
The data requirements vary significantly based on the use case:
Mandatory use cases: 49-50 mandatory data fields
Conditional use cases: Up to 120 data fields per invoice (mandatory, conditional, and optional)
Total coverage: Over 135 business terms across all scenarios in the PINT OM Data Dictionary
Implementation Requirements
Businesses must:
Identify applicable use cases for their business operations
Support all 5 mandatory use cases at minimum
Implement conditional use cases relevant to their transaction types
Ensure data completeness for all required fields per use case
Validate against PINT OM specifications before transmission
Test scenarios with their Accredited Service Provider
The time when the invoice was issued. PINT OM requires the issue time on all invoices.
Regional API
JSON
{ "issue_time": "14:30:00"}
Unified API
JSON
{ "issue_time": "14:30:00"}
Rules:
[IBT-168]: Invoice issue time is mandatory for all PINT OM invoices
Must be in ISO 8601 format: HH:MM:SS
Represents the local time of invoice issuance
due_date
UBL Tag: cbc:DueDate Requirement: Conditional Type: Date (YYYY-MM-DD)
The date by which payment is due.
Rules:
[IBT-009]: Payment due date
[ibr-127-om]: Payment due date MUST be present when the amount due for payment (IBT-115) is greater than 0, except when invoice type code (IBT-003) is Credit Note (381) or Self-Billing Credit Note (261), or when the transaction type code (BTOM-001) indicates Deemed supply
A 20-character binary string indicating the nature of the invoice transaction. Each bit position corresponds to a specific transaction characteristic. If applicable, set to 1; if not, set to 0.
[ibr-160-om]: When Frequency of billing (BTOM-006) value is 'Others', then value should be provided in Invoice note (IBT-022)
Multiple notes can be included
Each note can have an optional subject code (IBT-021)
tax_point_date
UBL Tag: cbc:TaxPointDate Requirement: Conditional Type: Date (YYYY-MM-DD)
The date when VAT becomes accountable (delivery date or tax point).
Regional API
JSON
{ "tax_point_date": "2025-06-14"}
Unified API
JSON
{ "tax_point_date": "2025-06-14"}
Rules:
[IBT-007]: Value added tax point date
[ibr-124-om]: VAT point date MUST NOT be present when invoice type code (IBT-003) is Credit Note (381) or Self-Billing Credit Note (261)
[ibr-141-om]: When VAT point date is present, it should be before the Invoice issue date (IBT-002)
Must be in ISO 8601 format: YYYY-MM-DD
Typically the delivery date or date of supply
document_currency
UBL Tag: cbc:DocumentCurrencyCode Requirement: Mandatory
Type: Code (ISO 4217)
The currency in which all invoice amounts are expressed.
Regional API
JSON
{ "document_currency": "OMR"}
Unified API
JSON
{ "document_currency": "OMR"}
Rules:
[ibr-005]: Invoice MUST contain invoice currency code (IBT-005)
[ibr-cl-03]: Currency ID MUST be coded using ISO 4217 alpha-3
[ibr-126]: All currency ID attributes must match document currency code
[ibr-159-om]: Currency exchange rate (BTOM-004) is MUST when the Invoice currency code (IBT-005) is different from 'OMR'
[ibr-175-om]: When Invoice currency code (IBT-005) is other than 'OMR' and Tax accounting currency (IBT-006) is 'OMR', then the value in Invoice total VAT amount in tax accounting currency (IBT-111) and Invoice total amount with VAT in OMR (BTOM-020) MUST be present
For Oman transactions, typically "OMR" (Omani Rial)
The exchange rate for converting document currency to OMR.
Regional API
JSON
{ "currency_exchange_rate": 0.384615}
Unified API
JSON
{ "currency_exchange_rate": 0.384615}
Rules:
[ibr-002-om]: Currency exchange rate (BTOM-004) should contain the values to a maximum of 6 decimal places
[ibr-159-om]: Currency exchange rate (BTOM-004) is MUST when the Invoice currency code (IBT-005) is different from 'OMR'
[ibr-153-om]: When the Tax accounting currency (IBT-006) is set to OMR and the invoice currency code (IBT-005) differs from OMR, the source currency must be designated as the invoice currency code (IBT-005), and the target currency must be specified as the Tax accounting currency (IBT-006), provided that the currency exchange rate (BTOM-004) is available
[ibr-055-om]: Preceding invoice reference (IBG-03) is mandatory when invoice type code (IBT-003) is 381 (Credit Note), 383 (Debit Note), or 261 (Self-Billing Credit Note)
The reason code for issuing a credit note. Required when document_type is 381 (Credit Note) or 261 (Self-Billing Credit Note).
Regional API
JSON
{ "credit_note_reason_code": "CAN"}
Unified API
JSON
{ "credit_note_reason_code": "CAN"}
Allowed Values:
Code
Description
CAN
Cancellation of the original invoice
VAT
VAT treatment change
VAL
Value/consideration adjustment
QTY
Quantity adjustment (goods returned in full or part)
OTH
Other reason
Rules:
[ibr-001-om]: Credit note reason code (BTOM-003) value should be from the Reasons for credit note code list
[ibr-158-om]: Where the Invoice type code (IBT-003) is Credit Note (381) or Self-Billing Credit Note (261), Credit note reason code (BTOM-003) MUST be present
[ibr-008]: Postal address (IBG-08) MUST contain country code (IBT-055)
[ibr-011]: Electronic address (IBT-049) MUST have scheme identifier
[ibr-CL-11]: Electronic address scheme MUST be from code list
[ibr-144-om]: In postal address (IBG-08), Address line 1 (IBT-050), City (IBT-052) and country subdivision (IBT-054) must be provided
[ibr-135-om]: Either identifier (IBT-046) or VAT identifier (IBT-048) MUST be present when the transaction type code (BTOM-001) does not indicate an Export (position 7) and scheme identifier (IBT-049-1) is '0248'
[ibr-179-om]: VAT identifier (IBT-048) MUST occur maximum once
VAT Exemption Reason Codes (IBT-186) — required when vat_category is E:
Code
Description
VATEX-OM-01
Financial services (specified)
VATEX-OM-02
Supply of residential property (first sale/lease)
VATEX-OM-03
Bare land
VATEX-OM-04
Local passenger transport
VATEX-OM-05
Healthcare services
VATEX-OM-06
Educational services
VATEX-OM-07
Supply of medicines and medical equipment (specified list)
VATEX-OM-08
Supply of food items (specified list)
VATEX-OM-09
Rental of residential property
VATEX-OM-10
Charitable and humanitarian activities
VATEX-OM-11
Government services
VATEX-OM-12
Other exempt supply (as specified by regulation)
Zero-Rating Reason Codes — required when vat_category is Z:
Code
Description
VATZR-OM-01
Export of goods
VATZR-OM-02
Export of services
VATZR-OM-03
International transport of goods
VATZR-OM-04
International transport of passengers
VATZR-OM-05
Supply of means of transport for international use
VATZR-OM-06
Supply related to international transport
VATZR-OM-07
Supply of precious metals (investment grade)
VATZR-OM-08
Supply to designated/special zones
VATZR-OM-09
First supply of residential property within 3 years
VATZR-OM-10
Supply of crude oil and natural gas
VATZR-OM-11
Supply of food items (zero-rated list)
VATZR-OM-12
Supply of medicines and medical equipment (zero-rated list)
VATZR-OM-13
Diplomatic and international organization supply
VATZR-OM-14
Supply under customs suspension
VATZR-OM-15
Transfer of going concern
VATZR-OM-16
Other zero-rated supply (as specified by regulation)
Rules:
[ibr-021]: Each invoice line MUST have unique identifier (IBT-126)
[ibr-022]: Each invoice line MUST contain invoiced quantity (IBT-129)
[ibr-023]: Each invoice line MUST contain unit of measure code (IBT-130)
[ibr-024]: Each invoice line MUST contain line net amount (IBT-131)
[ibr-025]: Unit of measure code MUST be from UN/ECE Recommendation 20
[ibr-026]: Each invoice line MUST contain item net price (IBT-146)
[ibr-027]: Item net price MUST NOT be negative
[ibr-CL-23]: Unit code MUST be coded according to UN/ECE Rec 20 with Rec 21 extension
[ibr-SR-50]: Item description (IBT-154) MUST occur maximum once
[ibr-SR-58]: Invoiced item VAT category code (IBT-151) MUST be present
[ibr-125-om]: In Item Information (IBG-31), Item description (IBT-154) MUST be there
[ibr-145-om]: Each Invoice line (IBG-25) MUST be categorized with an Invoiced item VAT category code (IBT-151)
[ibr-147-om]: Invoice line net amount (IBT-131) MUST equal (Invoiced quantity (IBT-129) × (Item net price (IBT-146) / Item price base quantity (IBT-149)) + Sum of invoice line charge amount (IBT-141) − Sum of invoice line allowance amount (IBT-136))
[BTOM-013]: Item type MUST be either "GS" (goods) or "SV" (services)
[BTOM-017]: Line total including VAT MUST be provided
[ibr-167-om]: Line VAT Information (IBG-30) with Invoiced item VAT category code (IBT-151) as 'Exempt from VAT' MUST have a VAT exemption reason code (IBT-186)
[ibr-163-om]: In Line VAT Information (IBG-30) where Invoiced item VAT category code (IBT-151) is 'Exempt', VAT Line amount shall not be present
[ibr-165-om]: In Line VAT Information (IBG-30) where Invoiced item VAT category code (IBT-151) is 'Zero Rated', VAT Line amount MUST be zero
[ibr-om-zero]: When VAT category code (IBT-151) is 'Z' (Zero-rated), a zero_rating_reason_code MUST be provided
[ibr-194-om]: Invoice line amount payable (BTOM-010) must be provided
[ibr-126-om]: In Price Details (IBG-29), Item price base quantity (IBT-149) and Item Gross Price (IBT-148) MUST be there
Import Details
import_details
Requirement: Conditional Type: Object
Import-related details. Required when transaction type code (BTOM-001) position 13 is set (ImportGoods).
[ibr-036]: Document level allowance amount MUST NOT be negative
[ibr-037]: Document level allowance base amount MUST be provided if percentage is provided
[ibr-038]: Document level charge amount MUST NOT be negative
[ibr-039]: Document level charge base amount MUST be provided if percentage is provided
[ibr-041]: Document level allowance MUST have VAT category code (IBT-095)
[ibr-042]: Document level charge MUST have VAT category code (IBT-102)
[ibr-CO-04]: Allowance amount = Base amount × Multiplier factor
[ibr-CO-05]: Charge amount = Base amount × Multiplier factor
[ibr-131-om]: Allowance amount (IBT-092, IBT-136) must equal base amount (IBT-093, IBT-137) × percentage (IBT-094, IBT-138) ÷ 100 if base amount and percentage exist
[ibr-146-om]: Charge amount (IBT-099, IBT-141) must equal base amount (IBT-100, IBT-142) × percentage (IBT-101, IBT-143) ÷ 100 if base amount and percentage exist
[ibr-168-om]: Document level allowances (IBG-20) with Document level allowance VAT category code (IBT-095) as 'Exempt from VAT' MUST have a Document level allowance VAT exemption reason code (IBT-196)
[ibr-169-om]: Document level charges (IBG-21) with Document level charge VAT category code (IBT-102) as 'Exempt from VAT' MUST have a Document level charge VAT exemption reason code (IBT-198)
[ibr-049]: Payment means type code (IBT-081) MUST be from UN/ECE code list 4461
[ibr-061]: If payment means is credit transfer, account identifier (IBT-084) MUST be provided
[ibr-CL-16]: Payment means code MUST be from approved subset
[ibr-191-om]: Payment means type code (IBT-081) must be provided except when the invoice type code (IBT-003) is Credit Note (381), Self-Billing Credit Note (261), or when the transaction type code (BTOM-001) indicates Deemed supply (position 8)
[ibr-192-om]: When Payment means type code (IBT-081) is 'credit transfer' then Payment account identifier (IBT-084) must be provided
[ibr-196-om]: The Incoterms (BTOM-022) must be provided when applicable (e.g., for export and import transactions)
Oman eInvoicing Lifecycle
This guide covers the complete lifecycle of e-invoicing in Oman, from onboarding to the Peppol network through sending and receiving invoices.
Onboarding to Network
Before you can send or receive e-invoices through the Oman Peppol network, you must complete the onboarding process:
1. Register with an Accredited Service Provider (ASP)
The Oman e-invoicing system operates through Accredited Service Providers. You must:
Select an ASP approved by the Tax Authority of Oman (OTA)
Complete registration with your chosen ASP
Provide your business registration details (Commercial Registration, VAT TIN)
Obtain your Peppol participant identifier
2. Obtain Peppol Credentials
Your ASP will provide you with:
Credential
Description
Format
Peppol ID
Your unique participant identifier
0248:OM1234567890 (scheme 0248 + OM prefix + 10-digit TIN Number)
Participant ID
Your internal UUID for API calls
UUID format
API Credentials
Access keys for programmatic integration
API Key (static) or OAuth2 client credentials
3. Configure Your System
Set up your integration:
Configure API authentication
Map your internal data models to PINT OM format
Set up webhook endpoints (for receiving invoices)
Test your connection in sandbox environment
4. Go Live
Once testing is complete:
Activate your production account
Begin exchanging invoices with registered Peppol participants
Monitor compliance through your ASP dashboard
Sending an Invoice
Sending an invoice through Peppol involves four key steps: preparing the invoice data, verifying the recipient, sending the document, and handling responses.
Preparing the Invoice Data
Create your invoice following the PINT OM specification. Here's the basic structure:
{ "status": "success", "message": "Document validated.", "data": { "result": "invalid", "error_count": 2, "errors": [ { "field_name": "receiving_party.legal_name", "rule_code": "ibr-001", "error_message": "An Invoice MUST have a Buyer name (IBT-044).", "error_level": "fatal" } ] }}
Sending the Document
Once the invoice data is prepared and the recipient is verified, send the invoice through the Peppol network.
Single Document Submission
Send a single invoice to the Peppol network.
Endpoint: POST /v1/{participant_id}/documents
The endpoint accepts two content types:
Content-Type
Format
Description
application/json
JSON
PINT OM data model (see examples below)
application/xml / text/xml
UBL 2.1 XML
Raw PINT OM-compliant UBL XML document
When submitting XML, the document is parsed, mapped to the internal PINT OM data model, and run through the same validation pipeline as the JSON path. The response is always application/json.
Additional endpoints for retrieving document content:
GET /v1/{participant_id}/documents/{document_id}/xml — Raw UBL XML
GET /v1/{participant_id}/documents/{document_id}/pdf — Rendered PDF
GET /v1/{participant_id}/documents/{document_id}/xml-base64 — Base64-encoded XML
GET /v1/{participant_id}/documents/{document_id}/pdf-base64 — Base64-encoded PDF
Mark Document as Read
After processing a received invoice, mark it as read.
Endpoint: PUT /v1/{participant_id}/documents/{document_id}/read
No request body required.
Response:
JSON
{ "status": "success", "message": "Document marked as read.", "data": null}
Benefits of Marking as Read:
Track which invoices have been processed
Filter by is_unread=true to find unprocessed invoices
Maintain audit trails
Improve document management workflow
Pull System Best Practices
When using the Pull System:
Polling Frequency: Check for new documents every 5-15 minutes
Batch Processing: Retrieve multiple unread documents in one request
Status Tracking: Always mark documents as read after processing
Error Handling: Implement retry logic for failed retrievals
Filtering: Use query parameters to filter by date range or status
Example Polling Flow:
Text
1. GET /v1/{participant_id}/documents?is_unread=true&direction=incoming&limit=502. Process each document3. PUT /v1/{participant_id}/documents/{id}/read4. Wait 5-15 minutes5. Repeat
Simulating Incoming Documents (Sandbox Only)
When developing and testing your integration in the sandbox environment, you won't have real external parties sending you documents. The Simulate Incoming Document endpoint lets you create realistic incoming documents so you can test your receiving flow — webhooks, polling, document retrieval, and read-marking — without needing a live counterparty.
Sandbox only — This endpoint is only available in the sandbox environment. It will return an error in production.
Simulate an Incoming Document
Endpoint: POST /v1/{participant_id}/simulate/incoming
The endpoint creates a completed incoming document with direction: "incoming" and read_at: null (unread). If you have webhooks configured, it also fires the document.received event — so you can test your full webhook flow end-to-end.
Request Body:
All fields are optional. If omitted, the API generates realistic mock data automatically.
The simulated document is immediately available through all the standard document endpoints — you can retrieve it, download its XML/PDF, and mark it as read just like a real incoming document.
Testing Your Receiving Flow
Use simulate to verify each part of your integration:
1. Test Webhook Delivery
Text
1. Register a webhook subscription POST /v1/webhooks/subscriptions ↓2. Simulate an incoming document POST /v1/{participant_id}/simulate/incoming ↓3. Verify your webhook endpoint receives the document.received event ↓4. Confirm signature verification works with your stored secret
2. Test Polling Flow
Text
1. Simulate an incoming document POST /v1/{participant_id}/simulate/incoming ↓2. Poll for unread incoming documents GET /v1/{participant_id}/documents?is_unread=true&direction=incoming ↓3. Retrieve the full document GET /v1/{participant_id}/documents/{document_id} ↓4. Mark as read PUT /v1/{participant_id}/documents/{document_id}/read
3. Test Different Document Types
Simulate various document types to ensure your system handles them all:
JSON
{"type": "380"}
JSON
{"type": "381"}
JSON
{"type": "389"}
Complete Lifecycle Example
Here's a complete example showing both sending and receiving:
Sending Flow
Text
1. Verify recipient exists in Peppol network GET /v1/peppol/lookup/{peppol_id} (or GET /v1/peppol/lookup/{peppol_id}/{document_type} for type-specific check) ↓2. Prepare invoice data with all required datapoints (optionally validate first via POST /v1/{participant_id}/documents/validate) ↓3. Send invoice via POST /v1/{participant_id}/documents (or POST /v1/{participant_id}/documents/bulk for multiple documents) ↓4. Receive confirmation with document_id (UUID) ↓5. Track status via: a. Polling — GET /v1/{participant_id}/documents/{document_id} Monitor: exchange_status → delivered, reporting_status → reported b. Webhooks — listen for document.exchange.delivered, document.reporting.reported, document.completed events ↓6. OTA reporting handled automatically — check reporting_status and reporting_reference
Receiving Flow (Webhook)
Text
1. Register webhook subscription POST /v1/webhooks/subscriptions (save returned secret for signature verification) ↓2. Webhook triggered when invoice arrives ↓3. Receive document.received event ↓4. Acknowledge webhook immediately (200 OK) ↓5. Verify X-Flick-Signature header ↓6. Retrieve full document via GET /v1/{participant_id}/documents/{document_id} ↓7. Import into accounting system ↓8. Mark document as read PUT /v1/{participant_id}/documents/{document_id}/read
Receiving Flow (Polling)
Text
1. Poll GET /v1/{participant_id}/documents?is_unread=true&direction=incoming ↓2. Retrieve unread documents ↓3. For each document: - Get full details via GET /v1/{participant_id}/documents/{id} - Validate and process - Mark as read via PUT /v1/{participant_id}/documents/{id}/read ↓4. Wait 5-15 minutes ↓5. Repeat
Complete collection of PINT OM compliant invoice examples covering standard invoices, credit notes, debit notes, self-billing, and special transaction scenarios.
Standard Invoices
Standard Tax Invoice (380)
A typical commercial invoice with standard 5% VAT rate, including allowances and charges.
Key Features:
Invoice Type Code: 380 (Commercial invoice)
Standard VAT rate: 5% (category S)
uuid and issue_time fields (mandatory in PINT OM)
country_subdivision_code for governorate identification
Debit note for additional charges or corrections that increase the amount owed. Unique to PINT OM — used when the supplier needs to charge additional amounts after the original invoice.
Key Features:
Document Type Code: 383 (Debit note)
References original invoice via document_references
Invoice issued by the buyer on behalf of the supplier (type code 389). Used in scenarios where the buyer has an agreement to self-bill — common in oil & gas procurement contracts in Oman.
Invoice for goods exported outside Oman with zero VAT rate and foreign currency support. Transaction type bit 7 is set to indicate an export transaction.