Developer GuideAPI ReferenceDocumentationContactSystem Status

Global eInvoicing

Comply eInvoicing requirements across the globe with single API.

E-invoicing regulations vary by country, requiring businesses to comply with different models such as digital stamping, clearance, structured invoice exchange, and reporting. This unified APIs ensures seamless compliance across these models around the globe.

eInvoicing ModelsCopied!

To simplify understanding and integration, we categorise e-invoicing models into four main types:

  1. Stamping (Archive-Only) Model

  2. Clearance[Reporting]-Only Model

  3. Exchange-Only Model

  4. Hybrid Model (Clearance + Exchange)

1. Stamping (Archive-Only) ModelCopied!

In this model, businesses generate invoices that meet specific compliance requirements and receive a stamp (digital seal, QR code, or approval reference). However, there is no mandatory clearance or structured exchange—businesses must store invoices for future audits.

Key Characteristics:

  • Invoice must be stamped before/during issuance.

  • No real-time clearance or structured exchange required.

  • Traditional invoice exchange methods (PDF, email, EDI) are still used.

  • Tax authorities may verify invoices later.

Examples:

  • Saudi Arabia (ZATCA Phase 1) → QR codes required, but no reporting.

  • Spain (Non-Veri*factu method) → Optional stamping & archiving.

2. Clearance[Reporting]-Only ModelCopied!

This model ensures tax compliance through Continuous Transaction Controls (CTC) or similar methods. Businesses must report invoices to tax authorities before, during, or after issuance, but there is no structured invoice exchange requirement between buyers and sellers.

Key Characteristics:

  • Invoices must be reported to tax authorities (real-time, near real-time, or periodic).

  • No mandatory exchange network between suppliers and buyers.

  • In some countries, tax authorities act as the central hub for invoice delivery.

Examples:

  • India (GST E-Invoicing - IRN Generation) → Invoices are reported but exchanged traditionally.

  • Italy (FatturaPA) → Invoices are reported via a government platform.

  • Saudi Arabia (ZATCA Phase 2) → B2B invoices must be cleared before sending; B2C invoices reported within 24 hours.

  • Spain (TicketBAI) → Invoices must be digitally signed, stamped with a QR code, and reported.

3. Exchange-Only ModelCopied!

This model requires structured electronic invoice exchange between businesses via approved networks (e.g., Peppol, DBNAlliance), but there is no mandatory tax clearance before transactions. Governments audit tax records later, if needed.

Key Characteristics:

  • Invoices must be exchanged via an approved network.

  • No real-time clearance or stamping required.

  • Standardised formats used (XML, UBL, etc.).

Examples:

  • Singapore (Peppol E-Invoicing: pre-InvoiceNOW era) → Peppol 4-corner model; no clearance.

  • Australia (Peppol 4-Corner Model) → Secure exchange via Peppol without government intervention.

  • Many EU Countries (B2G e-Invoicing) → Peppol-based invoice exchange.

4. Hybrid Model (Clearance[Reporting] + Exchange)Copied!

Governments worldwide are increasingly adopting the hybrid e-invoicing model as it provides a balance between regulatory compliance and efficient business processes. This model helps prevent tax fraud by ensuring invoices are reported in real-time or periodically to tax authorities. At the same time, it mandates structured electronic exchange, reducing errors and streamlining workflows. Standardising invoice formats across businesses and industries allows for smoother transactions while integrating tax and financial systems ensures automated compliance, making tax reporting more transparent and efficient. As digital transformation accelerates, hybrid models are becoming the preferred choice for many countries looking to modernize their tax and invoicing frameworks.

Key Characteristics:

  • Invoice Generation – Businesses create invoices in a structured format (e.g., XML, UBL, Peppol BIS).

  • Real-Time Reporting/Clearance – The invoice is reported or cleared with tax authorities before or immediately after issuance.

  • Structured Exchange – The invoice is then electronically exchanged between suppliers and buyers via an approved network (e.g., Peppol, DBNAlliance).

  • Validation & Compliance – Tax authorities and businesses have real-time access to invoice data for audits and reconciliation.

Examples:

  • ViDA (VAT in the Digital Age) – The EU is planning a unified digital reporting system, requiring real-time invoice clearance while promoting structured e-invoice exchange across member states. ViDA aims to replace fragmented national models with a consistent pan-European system.

  • UAE (Peppol 5-Corner Model for 2026) – Businesses must report invoices to the Federal Tax Authority (FTA) and exchange them digitally via Peppol.

  • Malaysia (LHDN Validation + Peppol Exchange) – Invoices must be validated by LHDN (tax authority), and structured exchange is encouraged via Peppol.

  • Mexico (CFDI + Exchange) – A well-established hybrid model where invoices are cleared with the tax authority (SAT) and electronically exchanged.

  • Colombia (DIAN + Exchange) – Invoices are validated by DIAN (tax authority) before structured digital exchange between businesses.

API DesignCopied!

This API is designed to facilitate structured reporting, seamless data exchange, and document processing across multiple countries and regulatory frameworks. It consists of three main sections: reporting_schema, exchange_schema, and documents.

1. Reporting SchemaCopied!

The reporting_schema section defines compliance and regulatory reporting requirements based on the country of origin.

  • origin: The country where the reporting is required (e.g., "SA" for Saudi Arabia, "MY" for Malaysia, "AE" for UAE, "ES" for Spain).

  • scheme_id: The specific reporting framework or tax compliance scheme applicable in that country. Examples:

    • "MY:LHDNM" → Malaysia’s LHDNM e-invoicing system

    • "SA:PHASE2" → Saudi Arabia’s ZATCA Phase 2 e-invoicing mandate

    • "ES:TBAI" → Spain’s TicketBAI tax compliance framework

This structure ensures that reports are categorized correctly based on country-specific regulations.

2. Exchange SchemaCopied!

The exchange_schema section manages how data is exchanged between different networks and recipients.

  • origin: The country from which the data originates (e.g., "SA", "MY").

  • network: The platform or protocol used for exchanging documents. Examples:

    • "PEPPOL" → A global e-invoicing network for B2B transactions by OpenPeppol

    • "DBNA" → A collaborative effort between the United States government and the private sector to standardise the e-invoicing system in the country.

  • recipient_id: A unique identifier for the recipient entity receiving the exchanged data.

This setup ensures a standardised and traceable data exchange process across different countries and networks.

3. DocumentsCopied!

The documents section contains the actual transactional or compliance-related documents being processed. Each document follows its own structure, depending on the regulatory and business requirements.

LocalisationsCopied!

The API supports multiple localisations to ensure compliance with country-specific regulations, tax schemes, and document exchange standards. Localisation primarily impacts reporting, document structure, currency, and language formats.

We will go through each aspect of localisation in detail, explaining how reporting requirements, document structures, currency formats, and language adaptations are handled for different countries. This will include specific compliance rules, supported tax schemes, exchange networks, and any country-specific variations that impact API usage.

1. MalaysiaCopied!

Reporting Schemas that we support:

  • MY:LHDNM

Exchange Schemas that we support:

  • PEPPPOL

Team Flick © 2025