Use case · Jordan e-invoicing

JoFotara integration for your POS, ERP or accounting system

JoFotara is Jordan’s national e-invoicing system, run by the Income and Sales Tax Department (ISTD). We would connect the system you already use, so each completed sale reaches JoFotara without anyone retyping it.

Who can connect my system to JoFotara, and what does it take?

Any business that has to issue invoices can join JoFotara, whatever system it uses today. If your POS, ERP or accounting system can send completed invoices over an API, we would connect it. You link the device on the JoFotara portal to get a Client ID and Secret Key, and each invoice goes as a UBL 2.1 file.

Who this is for

Businesses that sell in Jordan and issue invoices from one of these:

Odoo, whose Jordan localisation has a JoFotara module. Look at that first.
A cloud POS that can send completed sales over an API or a webhook.
An accounting system with an API.
Spreadsheets, or no system. ISTD’s portal lets you issue invoices by hand, and for a small number of invoices that may be all you need. We would tell you if it is.

If your system cannot send completed invoices over an API or a webhook, a connection does not fit as it stands. We would say so in the first conversation, and point you to the portal or to a different system.

What JoFotara asks of a connection

These are ISTD’s own requirements, as we read them in its guides. Each row links to the document it comes from.

What ISTD asks for in an invoice connection to JoFotara, and what it means for the build
Topic	What ISTD says	What it means for the connection
Client ID and Secret Key	There are two paths. With no accounting software you add a sub-user and issue invoices on the portal. With accounting software you link the device, which gives you a Client ID and a Secret Key, finish the technical requirements, and the software sends invoices directly. ISTD joining guide, 2026 edition	We need the Client ID and the Secret Key from your account to send invoices. The Secret Key stays private.
Invoice format	Technical guide version 1.5, approved 14 May 2026: the invoice is a UBL 2.1 XML file, Base64-encoded inside JSON, sent to the JoFotara backend with Client-Id and Secret-Key headers. ISTD technical integration guide, version 1.5	We would build the UBL 2.1 file for each sale, encode it as Base64 inside JSON, and send it with your Client-Id and Secret-Key headers.
Invoice type	There are three invoice families: income invoice (sellers not registered for sales tax), general sales tax invoice and special sales tax invoice. Each has a return invoice. The payment method (cash or receivables) and the type (local, export, development zone, transit, foreign trade, free-zone assignment) are coded in the invoice. ISTD technical integration guide, version 1.5	We would map each sale to the invoice type your registration allows, and send a refund as a return invoice. JoFotara rejects a mismatch, for example an income invoice from a seller registered for sales tax.
The answer, the QR code and the UUID	JoFotara answers with a status, a QR code and an invoice UUID. The QR code JoFotara returns must be printed on the seller’s invoice. Keep the ID, UUID, QR and status. When you resend an invoice, reuse the same ID and UUID. ISTD technical integration guide, version 1.5	We would keep the ID, UUID, QR code and status with each sale, and pass the QR code back so it prints on the invoice. A resend reuses the same ID and UUID.
The buyer’s name	The buyer’s name is mandatory on receivables invoices and on cash invoices above 10,000 JOD (or the equivalent in another currency). ISTD technical integration guide, version 1.5	We would send the buyer’s name when your system has it, and flag the invoices where ISTD requires it and it is missing.

Checked against ISTD documents on 1 November 2026. Technical guide version 1.5.

Four ways to get invoices into JoFotara

Use the simplest one that covers your invoices. A connection built for you is the last on the list, not the first.

Four routes to JoFotara compared: who each suits, what you need and where it stops
Route	Who it suits	What you need	Where it stops
Your system’s own JoFotara module	A system that ships one. Odoo’s Jordan localisation has a JoFotara module.	An Activity Number, a Secret Key and a Client ID, which is what Odoo’s module asks for.	As we read Odoo’s documentation, the module sends the invoices Odoo itself issues. A separate POS that does not post its sales into Odoo needs its own route. Check that your version includes it.
Your POS or ERP vendor’s connector	A system whose vendor says it sends invoices to JoFotara.	The Client ID and Secret Key from your JoFotara account, and the vendor’s setup steps.	Only what the vendor built. We do not keep a list of which systems have one, so ask yours what it supports.
Typing invoices into the JoFotara portal	A business with no accounting software, or very few invoices.	A portal account and a sub-user.	Every invoice is typed by hand. It gets slow at around 1,000 invoices a month. That is our rule of thumb, not an ISTD rule.
A connection built for you	A system with an API but no JoFotara module, invoices coming from more than one system, or rules of your own.	Your Client ID and Secret Key, API access to your system, and a plain description of how you issue invoices.	Your system must send completed invoices over an API or a webhook. It is also software someone has to keep working, and ISTD’s technical guide can change.

The 1,000-invoice figure is our own rule of thumb, not ISTD’s.

If you run Odoo

Odoo’s Jordan localisation includes a module for JoFotara. It needs an Activity Number, a JoFotara Secret Key and a Client ID, and it produces UBL 2.1. Look at that module first.

Check that your Odoo version has it. The documentation we read is for version 19.0.

We would come in when the module does not cover your case. As we read Odoo’s documentation, the module sends the invoices Odoo itself issues. A separate POS that does not post its sales into Odoo needs its own route, and we would connect that system to JoFotara.

Odoo documentation: Jordan

Receipts and invoices

ISTD’s 2019 Instructions say that anyone selling goods or services issues an invoice, unless the Instructions list them as an exception. We could not confirm that the exceptions are unchanged in 2026. The readiness checker tells you whether you may be exempt.

The QR code JoFotara returns must be printed on the seller’s invoice. Whether the invoice at your counter is the receipt itself or a separate document is a question for ISTD or your accountant. We would not guess. We would build to their answer.

A refund is a return invoice. JoFotara has one for each invoice type, and we would send it the same way.

How a connection would work

This is the order we would work in. The format and the handling of JoFotara’s answer are ISTD’s. The steps are ours.

You link your system on the JoFotara portal and get a Client ID and a Secret Key. We would keep the Secret Key in protected settings, never in the code.
We would read each completed sale from your system, over an API or a webhook, only once the sale is complete.
We would map the sale to a JoFotara invoice: the invoice type for your tax registration, the payment method, the type of sale and the buyer’s name where it is required.
We would build the UBL 2.1 file, encode it as Base64 inside JSON, and send it with your Client-Id and Secret-Key headers.
We would store JoFotara’s answer with the sale: the status, the QR code and the UUID. The QR code would go back to your system so it prints on the invoice.
When JoFotara rejects an invoice, we would show you the message and the cause, and fix the cause first. When we resend, we would reuse the same ID and UUID. When a request fails before JoFotara answers, we would retry it and alert you if it keeps failing.
We would compare what your system issued with what JoFotara has answered, and alert you to any sale that has no answer.

What we need from you

A JoFotara account linked to your system, and the Client ID and Secret Key it gives you.
Which system issues your invoices today, and an admin who can give us API access to it.
Your tax registration, so we use the right invoice type: income, general sales tax or special sales tax.
How you handle refunds, and which of your sales are cash and which are on credit.
A way to show the QR code on the invoice your customer gets.
Your accountant’s answer on what counts as the invoice at the counter: a receipt or a separate document.

Check your readiness first

Twelve questions at most, no email, and each next step links to the ISTD document it comes from.

Open the JoFotara readiness checker

Common questions

We would, if it can send completed invoices over an API or a webhook. Tell us what you use and we say whether it fits, whether or not you hire us. If your system cannot send invoices that way, the options are ISTD’s portal or a different system, and we would tell you so at the start.

An account on the National E-Invoicing system. You log in to ISTD’s e-services, open National E-Invoicing and create an account, and your tax number is filled in for you. Then you link the device on the JoFotara portal, which gives you a Client ID and a Secret Key.

The invoice is a UBL 2.1 XML file, Base64-encoded inside JSON, sent with Client-Id and Secret-Key headers. ISTD’s technical guide is at version 1.5.

Odoo’s Jordan localisation has a module for JoFotara. It needs an Activity Number, a JoFotara Secret Key and a Client ID, and it produces UBL 2.1. Check that your Odoo version includes it. As we read Odoo’s documentation, the module sends the invoices Odoo itself issues, so a separate POS that does not post its sales into Odoo needs its own route. That is where we would step in.

JoFotara answers each invoice with a status, a QR code and a UUID. One rejection in ISTD’s guide reads “This user is not authorized to submit this type of invoice”. It means the invoice type does not match the seller’s tax registration. We would show you the message, fix the mapping and resend with the same ID and UUID.

With no accounting software, you add a sub-user and issue invoices on the JoFotara portal. With a POS or accounting system, you link the device and the software sends the invoices. Typing invoices into the portal gets slow at around 1,000 a month. That is our rule of thumb, not an ISTD rule.

It depends on your system and on how many invoice types you issue. For a defined scope, about six weeks to a first working system is a fair expectation, and bigger scopes take longer. We give you a scope and a quote after the free 30-minute audit.

Sources

Everything above about JoFotara comes from ISTD’s own documents and from Odoo’s documentation, as published when we last checked. ISTD can change its rules, so confirm with ISTD before you rely on this. The steps and the 1,000-invoice figure are ours, not ISTD’s.

Checked against ISTD documents on 1 November 2026. Technical guide version 1.5.

Before you rely on this

This page is general information from ISTD’s published documents. It is not tax or legal advice and not an ISTD service. Confirm with ISTD or your accountant before you act. BottleTech is not affiliated with ISTD.

Want your POS or accounting system sending invoices to JoFotara?

Tell us what you use. We would map the connection and tell you whether it is a fit, whether or not you hire us.

Tell us what you use