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

Jordan — JoFotara, ISTD e-invoicing

JoFotara (الفوترة الوطنية, "the national invoicing") is Jordan's national e-invoicing system, operated by the Income and Sales Tax Department (ISTD — دائرة ضريبة الدخل والمبيعات) alongside the Ministry of Digital Economy and Entrepreneurship (MDEE). It follows a clearance model: each invoice is submitted to and validated by the ISTD, which returns a UUID and a QR code, before being delivered to the buyer. Launched in December 2022 on a voluntary basis, it became mandatory in waves across 2024 and 2025.

Regulatory timeline

  • 2018-2019 — legal foundation. Income Tax Law No. 38 of 2018 (Art. 23) mandates issuance of an original invoice; Invoicing Regulation No. 34 of 2019 frames billing and retention duties.
  • 2021 — design. The ISTD develops the National Billing System (NBS / JoFotara) together with the MDEE.
  • December 2022 — voluntary launch. JoFotara goes live; pilot opened first to large taxpayers, on a voluntary basis.
  • 2023-2024 — Phase 1, mandatory enrolment of large taxpayers. The ISTD notifies targeted taxpayers and requires integration. Mandatory switch-over for the first segments lands during 2024.
  • October 2024 — compliance reminders. The ISTD issues notices urging taxpayers to finalise registration and integration.
  • 1 April 2025 — Phase 2, generalisation. E-invoicing via JoFotara (or an approved integrated system) becomes mandatory for nearly all taxable persons; the Amended Billing & Control Regulation No. 2 of 2025 takes effect. Only invoices issued through JoFotara are tax-deductible.
  • 2025-2026 — gradual SME/micro onboarding. Stepwise extension; the exact schedule for the last segments is to confirm with the ISTD.

Technical schema

JoFotara is built on a UBL 2.1-compliant XML document (OASIS Universal Business Language — the same foundation as PEPPOL BIS). The Jordanian profile restricts and adapts UBL to the local tax document types.

  • Document types: income invoices, general sales invoices, special sales invoices, simplified invoices and credit notes.
  • Transport: the UBL XML is sent to the ISTD API encapsulated/encoded (base64) inside a JSON envelope. Vendor copy often says "XML encrypted into JSON" — this refers to the transport encoding, not end-to-end encryption.
  • Identifiers: each invoice carries a UUID; supplier and buyer are identified by their ISTD tax number. A JOD 10,000 threshold governs whether detailed buyer details must be carried on certain invoice types.
  • QR code: returned by the ISTD after validation, it must appear on the invoice handed to the buyer and enables public verification of registration.
  • Authentication: each taxpayer receives a client ID and a secret key from the ISTD to authenticate against the direct API.

Submission flow

JoFotara is a clearance model (CTC, Continuous Transaction Control): the invoice is legally valid only after ISTD validation, unlike a mere post-audit reporting.

  1. Generation. The supplier's ERP/software produces the invoice as UBL 2.1 XML.
  2. Submission. The document is sent to the JoFotara API, authenticated with client ID + secret key.
  3. Real-time validation. The ISTD checks structure, identifiers and tax consistency.
  4. Stamp returned. If compliant, the ISTD returns the validated UUID and the QR code.
  5. Delivery. The invoice (with QR code) is handed to the buyer; only invoices validated this way are tax-deductible.

Taxpayers without an integrated ERP can enter/issue invoices manually through the web portal at portal.jofotara.gov.jo.

Validation

Common pitfalls

  1. Treating JoFotara as mere reporting. It is a clearance model: without the UUID and QR code returned by the ISTD, the invoice is not tax-valid and grants no deduction right.
  2. Confusing "JSON encoding" with encryption. The document is still UBL 2.1 XML; the JSON/base64 envelope is only transport. Build a genuinely compliant UBL, not an ad-hoc JSON.
  3. Omitting the QR code on the issued invoice. The ISTD-returned QR must appear on the buyer copy; an invoice without a validated QR is rejected on audit.
  4. Mishandling the JOD 10,000 threshold. Above it, detailed buyer details become mandatory on certain invoice types.
  5. Underestimating the enrolment schedule. The 2024-2025 waves target specific segments; check your mandatory date with the ISTD rather than assuming a deferral. The exact final SME tiers remain to confirm.
  6. Assuming a sector is exempt. The ISTD has stated that no sector or entity type is ultimately exempt.