ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Pakistan — FBR digital invoicing and the PRAL API

In 2025 Pakistan moved to a real-time clearance model run by the Federal Board of Revenue (FBR): every sales-tax invoice on goods from a notified taxpayer must be transmitted in JSON, in real time, to the digital invoicing platform — through a licensed integrator or through PRAL (Pakistan Revenue Automation Ltd) — which returns an enforceable FBR Invoice Number before the invoice is valid. A paper copy of a notified supply no longer carries legal value.

Regulatory timeline

  • December 2023 — first FMCG notification. The FBR notifies that importers, manufacturers, wholesalers and distributors of fast-moving consumer goods (FMCG) must issue electronic invoices through an approved system.
  • 1 February 2024 — first FMCG go-live. The first selected FMCG taxpayers start issuing e-invoices through the central platform.
  • SRO 709(I)/2025 — 22 April 2025. Framework notification under Rule 150Q (Sales Tax Rules 2006) generalising digital invoicing: mandatory integration of corporate registered persons, then non-corporate, via a licensed integrator or PRAL.
  • DI API v1.12 — 7 April 2025. PRAL publishes the technical specification of the data-sharing API (JSON, endpoints, error codes, sandbox test scenarios).
  • SRO 1413(I)/2025 — 1 August 2025. Turnover-based staggered schedule: public companies / turnover > PKR 1bn / importers from 1 Sep.; turnover PKR 100m–1bn from 1 Oct.; turnover < PKR 100m from 1 Nov.; all remaining taxpayers from 1 Dec. 2025.
  • SRO 1852(I)/2025 — autumn 2025. Deferral and re-staggering: registration from 15 October, phased go-live from 1 November to 31 December 2025 by category. The FBR states that no further extension will be granted.
  • Since late 2025 — regime in force. All waves have elapsed; enforcement and penalties (s. 33 Sales Tax Act 1990) are active. Scope remains centred on goods; a formal B2C extension and the inclusion of services are to confirm.

Technical schema

The required format is a proprietary FBR/PRAL JSON described by the DI API v1.12 specification (April 2025). It is neither UBL nor EN 16931: the semantics are those of Pakistani sales tax (HS codes, SRO codes and schedules, sale type, NTN/CNIC, provinces).

Minimal payload posted to the gateway:

{
  "invoiceType": "Sale Invoice",
  "invoiceDate": "2025-04-21",
  "sellerNTNCNIC": "0786909",
  "sellerBusinessName": "Ediverse Demo (Pvt) Ltd",
  "sellerProvince": "Sindh",
  "sellerAddress": "Karachi",
  "buyerNTNCNIC": "1000000000000",
  "buyerBusinessName": "Fertilizer Manufac IRS New",
  "buyerProvince": "Sindh",
  "buyerRegistrationType": "Unregistered",
  "invoiceRefNo": "",
  "items": [{
    "hsCode": "0101.2100",
    "productDescription": "Product description",
    "rate": "18%",
    "uoM": "Numbers, pieces, units",
    "quantity": 1.0000,
    "valueSalesExcludingST": 1000.00,
    "salesTaxApplicable": 180.00,
    "furtherTax": 120.00,
    "saleType": "Goods at standard rate (default)",
    "sroScheduleNo": "SRO123"
  }]
}

On validation, the platform returns:

  • An FBR Invoice Number (e.g. 7000007DI1747119701593) = seller prefix + DI + epoch timestamp — the functional equivalent of the Indian IRN, fiscally enforceable.
  • A validation status (statusCode "00" = Valid) with line-by-line status (invoiceStatuses).
  • A QR code (Version 2.0, 25×25 matrix, 1.0×1.0 inch) and the Digital Invoicing logo, both mandatory on every printed invoice.

The scenarioId (e.g. SN001) is required for sandbox only; hsCode follows the customs Harmonized System nomenclature in NNNN.NNNN format.

Submission flow

The model is real-time clearance: the invoice must be registered by the FBR before it is issued to the customer. Two transmission channels:

  • Licensed integrator — a provider holding an FBR licence that configures the taxpayer's software (POS/ERP) and relays invoices. Several integrators were approved from the outset.
  • PRAL — Pakistan Revenue Automation Ltd, the FBR's technology arm, acts as a licensed integrator and provides integration free of charge on demand (Rule 150XF).

Technically, the ERP/POS calls the gw.fbr.gov.pk gateway with a Bearer token (the token determines sandbox vs production routing):

  • POST /di_data/v1/di/postinvoicedata — production submission (..._sb in sandbox).
  • POST /di_data/v1/di/validateinvoicedata — pre-validation of an invoice without persisting it.
  • Reference APIs (/pdi/v1/provinces, /pdi/v1/uom, /pdi/v2/SaleTypeToRate, /pdi/v2/HS_UOM…) to align provinces, units, rates and HS/UoM pairs.
+------------+   JSON    +--------------------+   +------------+
| Seller PK  |---------> | Integrator / PRAL  |-> | FBR (DI)   |
| (ERP/POS)  |  Bearer   |  gw.fbr.gov.pk     |   |  + IRIS    |
+------------+           +---------+----------+   +-----+------+
                                   |                    |
              FBR Invoice Number + QR + status "00" <---+
              (synchronous return, before delivery to buyer)

The synchronous response carries the FBR Invoice Number and the status. That number, together with the QR code and the Digital Invoicing logo, is what makes the invoice enforceable; without it, a notified supply is deemed un-invoiced.

Validation

Common pitfalls

  1. Clearance, not post-audit. The FBR Invoice Number must be obtained before handing the invoice to the customer. A nightly batch or deferred send is not enough: without a returned number, a notified supply is not validly invoiced and falls under s. 33 of the Sales Tax Act 1990.
  2. Moving schedule — check the latest SRO. Three SROs followed one another in 2025 (709, 1413, 1852) with reshuffled turnover thresholds and dates. Anchoring an integration on a superseded SRO leads to a late start. Confirm the applicable category (corporate / non-corporate, turnover band) and go-live date.
  3. NTN/CNIC and buyer registration type. sellerNTNCNIC and buyerNTNCNIC expect 7 digits (NTN) or 13 (CNIC); buyerRegistrationType (Registered/Unregistered) drives which fields are mandatory. A mismatch (unregistered buyer but "registered" fields populated) triggers a rejection.
  4. HS codes, rates and HS/UoM pairs. The hsCode (NNNN.NNNN format), rate and uoM must come from the reference APIs (5.6–5.8) and be consistent: an invalid HS/UoM pair or a rate not aligned with that day's SaleTypeToRate is refused.
  5. scenarioId is sandbox-only. scenarioId (SN001…) is mandatory in the test environment but must not be carried over verbatim to production — many integrations fail in production by reusing the sandbox payload without switching routing (token) and stripping test fields.
  6. QR code and logo mandatory in print. The materialised invoice must bear the QR Code Version 2.0 (25×25, 1.0×1.0 inch) and the Digital Invoicing logo. Omitting either makes the invoice non-compliant even if the JSON was accepted.