Way4Tech
๐Ÿ‡ฏ๐Ÿ‡ด E-invoicing in Jordan

Odoo e-invoicing in Jordan: JoFotara

The Jordan e-invoicing picture in full: the scheme, the authority behind it, who it binds, and every requirement we map before a build is quoted.

Scheme

JoFotara, the National Electronic Invoicing System (ู†ุธุงู… ุงู„ููˆุชุฑุฉ ุงู„ูˆุทู†ูŠ)

Authority: Income and Sales Tax Department (ISTD), Ministry of Finance, delivered with the Ministry of Digital Economy and Entrepreneurship

Where it stands

Phase 2 has been live since 1 April 2025 and covers B2B, B2C and B2G. As of August 2026 ISTD is still pulling smaller taxpayers in, and an invoice that did not go through JoFotara is not accepted as a deductible expense.

Who has to comply

Taxpayers issuing invoices in Jordan. No sector or entity-type exemption has been published. The commercial trigger is simpler than the legal one: your customer cannot deduct the cost if the invoice did not clear JoFotara, so they will refuse it.

Every requirement, in full

7 requirements. Each one has to end up as a field, a document layout, a stored response, or an API call in your Odoo build. This is the list an e-invoicing project in Jordan gets costed against.

  1. 1 Invoices are submitted to ISTD through the JoFotara API and the returned status comes back into Odoo. Build it as a clearance flow, not a periodic report file.
  2. 2 UBL 2.1 XML as the invoice payload.
  3. 3 ISTD returns a QR code that must be printed on the document the customer receives.
  4. 4 Per-taxpayer API credentials from the JoFotara portal: Client ID, Secret Key and Activity Number.
  5. 5 Taxpayer type must be set on the company: unregistered, registered under standard sales tax, or registered under special sales tax.
  6. 6 Negative quantities and negative unit prices are rejected. Global or document-level discounts have to be re-expressed as a percentage on each line.
  7. 7 Company name in the ERP must match the ISTD registration, invoice currency must be JOD, and customer country plus Tax ID are mandatory fields.

Checked Localization notes on this page checked on 22 August 2026.

Rates, formats, thresholds and submission windows change. We configure against the rules in force at build time and confirm every figure with your accountant or tax advisor before sign-off. If a rule moves after go-live, it is a support ticket, not a rebuild. Read more on our Odoo localization service.

How we build e-invoicing for Jordan

The delivery method behind the list above. The same four steps on a 10-user rollout and on a multi-company programme, with the depth scaled to the scope.

  1. 1 Requirements first, code second. Each line above becomes a field, a report, or an API call on a written mapping sheet. Anything with no home in Odoo is quoted as a build before the project starts.
  2. 2 Numbering is settled on day one. Invoice sequences are the part that breaks quietly and costs the most to unwind after go-live, so they are signed off before the first test document.
  3. 3 Submission runs from a queue. Retries, idempotency keys, stored responses and an audit trail. A failed send becomes a ticket with evidence, not a missing invoice you find at month end.
  4. 4 Your finance team signs it off. Real documents, in a test database, checked with your accountant or tax advisor before cutover, with a rollback plan in writing.

What we need from you to quote it

Bring these to the first call and you get a scoped, priced e-invoicing plan for Jordan instead of a range.

  • โœ“ Your tax registration details and the entity each one belongs to.
  • โœ“ A sample of every document type you issue: invoice, credit note, debit note, self-billing if you use it.
  • โœ“ Any registration, certificate or portal credential the authority has already issued you.
๐Ÿ‡ฏ๐Ÿ‡ด

Scope e-invoicing for your Jordan rollout.

Send us the list above with your answers against it. We come back with what is configuration, what is a connector, and what is a build, priced before the project starts.