JoFotara Solution Provider Responsibility vs the Taxpayer

When your business links its accounting software to the National Invoicing System (JoFotara), a third party enters the relationship between you and the Income and Sales Tax Department (ISTD). That party is the system’s programmer or the technical solutions provider who completes the link. This raises the practical question of JoFotara solution provider responsibility and how it sits next to the taxpayer’s own. Who answers for the linking credentials if someone uses them without permission? Who answers for an invoice that does not match the sale? And does the wording ISTD’s guides use for that provider mean that ISTD keeps its own list of providers?

This article answers from three official texts that ISTD publishes. The first is the note on the linking path in the procedures guide for joining the Jordanian National Electronic Invoicing System, 2026 edition. The second is guideline 7 in the technical guide for integrating with the National Invoicing System through the API, version 1.5. The third is Article 10 of Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended. The article separates what these texts say from what they do not say, and it ends with practical steps for a taxpayer who relies on a provider for the link. For a wider view of the system and how to connect your business to it, read our article Jordan’s National E-Invoicing System.

JoFotara solution provider responsibility: three texts that divide it

The answer does not come from one text. It comes from three places, and each one has its own subject.

• The linking-path note in the joining guide (p. 13). It asks the taxpayer to coordinate with the system’s programmer or the technical solutions provider it works with to complete the technical requirements. Its subject is who completes the technical work of the link.
• Guideline 7, Security, in the technical guide (p. 104). It places the confidentiality of the Client ID and the Secret Key on the taxpayer and makes the taxpayer fully responsible for any unauthorized use. Its subject is the linking credentials.
• Article 10 of Regulation No. 34 of 2019. It places responsibility for the invoice data matching what actually took place on the seller and the buyer. Its subject is the content of the invoice itself.

What the three texts have in common is that the solution provider appears in only one of them, and only in its technical role. The other two place responsibility on the parties to the transaction. The taxpayer answers for the linking credentials, and the seller and the buyer answer for the content of the invoice. The sections below take each text in turn.

Linking credentials: full responsibility on the taxpayer

The linking credentials are two values that the system generates, the Client ID and the Secret Key. The main user creates them from the device linking option (ربط الأجهزة) on the home screen. The main user enters a username and selects the income-source sequence, and the system then generates the two values. The steps are in our article JoFotara Client ID and Secret Key: Device Linking Steps.

The text that decides who carries responsibility for these two values is guideline 7 of the ten guidelines that close the technical guide. Its title is Security. Here is its text as it appears in the guide.

«حماية بيانات الربط مثل Client_ID و Secret_Key وعدم تخزينها بشكل مكشوف داخل الكود البرمجي. تقع مسؤولية الحفاظ على سرية رقم المستخدم (Client ID) والمفتاح السري (Secret Key) وعدم مشاركتهما على عاتق المكلف، ويتحمّل كامل المسؤولية عن أي استخدام غير مصرح به».

In English, the guideline asks for the linking credentials, such as Client_ID and Secret_Key, to be protected and not stored exposed inside the program code. It then says that keeping the Client ID and the Secret Key confidential, and not sharing them, is the taxpayer’s responsibility, and that the taxpayer bears full responsibility for any unauthorized use. The English here is our rendering, and the Arabic text is the authority.

Three points in this text deserve attention.

1. The responsible party in the second sentence is the taxpayer. The guideline names neither the system’s programmer nor the solution provider, and it does not split responsibility between two parties.
2. The responsibility is full, and it covers any unauthorized use. On the face of the text, the word “any” does not limit the responsibility by where the use came from. It makes no distinction between use from inside the business and use from outside it.
3. The first sentence is a technical measure. Not storing the two values exposed inside the program code is work done inside the linked software, and this line does not say who carries it out. The guide, however, presents all ten guidelines as guidelines that the taxpayer must follow. Responsibility for confidentiality, in the second sentence, is stated outright as the taxpayer’s.

The joining guide says the same thing. It closes the points on the linking path by telling you to keep the linking credentials in a safe place and not to share them with anyone. The two official sources therefore agree that keeping the two values safe is the taxpayer’s task.

Our reading of the two texts together is that involving a solution provider in completing the link does not move responsibility for the two values to the provider, because the guideline makes the taxpayer responsible for any unauthorized use without exception. This is our reading of the text, not a statement by ISTD. One question remains that the texts do not answer. The joining guide asks you to use the linking credentials inside your accounting software to integrate with the system, and in the next point it asks you not to share them with anyone. The joining guide does not say how the two fit together when someone else carries out the technical setup.

What ISTD means by the provider the taxpayer works with

This is the full text of the note as it appears in the joining guide, on the same slide that shows the points on the linking path.

«يتوجب على المكلف التنسيق مع مبرمج النظام أو مزود الحلول التقنية المعتمد لديه لاستكمال المتطلبات الفنية اللازمة لربط نظامه مع نظام الفوترة الوطني الإلكتروني».

In English, the note says that the taxpayer must coordinate with the system’s programmer or the technical solutions provider it works with to complete the technical requirements needed to link its system with the National Electronic Invoicing System. The English here is our rendering, and the Arabic text is the authority.

In the Arabic, the phrase that describes the provider ends with a pronoun that refers back to the taxpayer. The provider meant is the one the taxpayer itself relies on for its software, not a provider chosen or vetted by ISTD. The rest of ISTD’s guides support this reading. Across its four guides, ISTD publishes no program for vetting software and no list of vetted providers.

Three practical points follow from this.

• Describing any provider as backed by ISTD finds no support in ISTD’s guides. If you read such a description in a sales offer, ask for the document it relies on, and compare that document with what ISTD publishes on its website.
• Choosing the provider is the taxpayer’s decision alone.
• Coordination is the taxpayer’s duty. The note is worded as an obligation on the taxpayer, so the initiative to complete the link stays with the taxpayer even when someone else does the technical work.

What the solution provider handles, according to ISTD’s guides

The note defines the provider’s role in a single phrase, completing the technical requirements needed to link the taxpayer’s system. The technical guide sets out those requirements in detail and ends with ten operating guidelines, which our article JoFotara Guidelines for Linked Systems: All Ten Explained takes one by one. The connection steps themselves are covered in our article on how to connect your system to JoFotara step by step.

These guidelines describe the work of the linked software. They start with building the invoice file to the UBL 2.1 standard. They cover resending after a failure with the same number and the same unique identifier (ID and UUID), without generating new values. They end with storing what the system returns and logging every send and every response. In its introduction to them, the guide addresses the taxpayer. It describes them as a set of operating guidelines that the taxpayer must follow when preparing and sending invoices, and it does not mention the solution provider in them. Guideline 7 alone adds an explicit statement that the taxpayer bears full responsibility for any unauthorized use.

This division of roles shows at the first send. The technical guide ties the error 403 Forbidden to a wrong Client ID or Secret Key. It also ties the linking credentials to a single income-source sequence, so a 400 rejection with the words not authorized can come from a sequence mismatch, not only from the tax number. Both points concern what the taxpayer creates and selects on the device linking screen (ربط الأجهزة).

None of the three texts this article relies on makes the solution provider answerable to ISTD for a linking error. What the taxpayer agrees with its provider lies outside these texts, and this article gives no legal opinion on it.

Article 10 of Regulation No. 34 of 2019: the seller and the buyer answer for the invoice

The third text is in Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended, and it is Article 10. Its wording, as given in the consolidated text that ISTD publishes, is below.

«تقع مسؤولية مطابقة البيانات والمعلومات الواردة في الفاتورة مع الواقع الفعلي لعملية بيع السلعة أو تقديم الخدمة على كل من البائع والمشتري على حد سواء وكل منهما مسؤول عن الفواتير غير المطابقة للواقع الفعلي».

In English, Article 10 of Regulation No. 34 of 2019 places responsibility for the data and information on the invoice matching what actually happened in the sale of the goods or the supply of the service on the seller and the buyer alike, and it makes each of them responsible for invoices that do not match what actually happened. No official English translation of this regulation was found; the English here is our rendering, and the Arabic text is the authority.

The article is about the content of the invoice, not the means by which it was issued. It does not name the system’s programmer or the solution provider among those responsible. It names only the two parties to the sale. Our reading is that an invoice issued from software linked to the system remains the seller’s invoice. Linking changes the route by which the invoice reaches ISTD, and it does not change who owns it.

Another provision of the same regulation completes the picture, Article 9 of Regulation No. 34 of 2019.

«على كل بائع تمكين الدائرة من نقل البيانات والمعلومات كافة المتعلقة بالفواتير ومحتوياتها إلكترونياً وعلى أن تتولى الوحدة المنشأة في الدائرة هذه المسؤولية».

In English, Article 9 of Regulation No. 34 of 2019 requires every seller to enable ISTD to transfer all data and information related to invoices and their contents electronically, with the unit established within ISTD taking on that responsibility. No official English translation of this regulation was found; the English here is our rendering, and the Arabic text is the authority.

Enabling the transfer of invoice data is therefore placed on the seller, and responsibility for the transfer itself rests with a unit within ISTD. Article 9 of Regulation No. 34 of 2019 does not mention the solution provider either.

What Article 10 of Regulation No. 34 of 2019 means for a buyer reviewing a return invoice from its supplier is explained in our article on purchase returns in JoFotara.

Who bears what when you link

The table below brings the points above together in one place and gives, for each topic, the text it rests on.

Where the texts stop

Some of what is said about the relationship between a taxpayer and its provider has no basis in the official sources. We build nothing on the following points.

• There is no published list of vetted providers. The joining guide speaks of the provider the taxpayer works with, and the four guides publish no program for vetting software and no list of providers.
• There is no documented procedure for revoking leaked linking credentials. In the list of linked devices, the technical guide shows a User status column (حالة المستخدم) with an on/off toggle, but it does not explain what the toggle does, so we do not describe its effect. The guide does not say what to do if you suspect that the linking credentials have leaked. The general contact it points to for inquiries is the technical support committee for invoicing affairs at ISTD, through its website istd.gov.jo.
• Unlinking devices is not a self-service setting. ISTD’s questions and answers guide describes it as an internal request submitted to ISTD under the name invoicing-system support request (طلب دعم فني لنظام الفوترة), and ISTD limits it to a business that has no accounting system and linked by mistake. ISTD’s written position in the same guide is that a business with an accounting system must link that system with the invoicing system. Whether linking is required at all is covered in our article Is Linking Accounting Software to JoFotara Mandatory?
• Personal data lies outside these texts. The three texts do not deal with the buyers’ data on invoices that the provider can see. That is the subject of the Personal Data Protection Law No. 24 of 2023 (PDPL).

Practical steps for a taxpayer who relies on a solution provider

These steps add no new obligation. They put what the texts above say into an order that suits a business working with an outside provider.

1. Create the linking credentials from your business’s account. Device linking (ربط الأجهزة) is one of the options on the main user’s home screen, and the two values are generated from the business’s own account, not from the provider’s account.
2. Select the right income-source sequence. The linking credentials are tied to one sequence, and a mistake in it can show up at sending as a rejection with the words not authorized.
3. Keep the two values in a safe place. Agree with your provider on who enters them into the software and when, because under guideline 7 of the technical guide the responsibility for any unauthorized use stays with you.
4. Ask your provider how the two values are stored. The first part of guideline 7 of the technical guide asks that they not be stored exposed inside the program code.
5. Review the invoice data before you issue the invoice. Under Article 10 of Regulation No. 34 of 2019, the invoice matching what actually took place is the responsibility of the seller and the buyer, and the article does not list the provider among those responsible.
6. Know where to turn. The technical guide refers technical inquiries to the technical support committee for invoicing affairs, and administrative requests such as unlinking go through the internal services (الخدمات الداخلية) on ISTD’s website.

If an accounting firm handles the link for several businesses, each business’s linking credentials are generated from that business’s own account and remain its own secret.

If your solution provider is Qoyod

Qoyod is integrated with the National Invoicing System (JoFotara). The accurate word for its relationship with the system is integration, not vetting by ISTD, because ISTD publishes no program for vetting software in its guides. To send your invoices, Qoyod needs the Client ID and the Secret Key that you create from device linking (ربط الأجهزة). The taxpayer needs no digital certificate or signature of their own to send invoices through Qoyod.

Qoyod builds the invoice file in UBL 2.1 format with its unique identifier (UUID) and sends it to the National Invoicing System without any manual intervention. Qoyod checks each invoice at field level as it is created, covering the tax number, the document type and payment method, the General Sales Tax rate and whether the lines are complete, and alerts you to any error before the invoice is sent, to reduce rejections. ISTD returns the invoice status and any error message, and Qoyod shows them in its status panel. What the texts set stays as it is. Keeping the two values confidential is your responsibility under guideline 7 of the technical guide, and the invoice matching what actually took place is the responsibility of the seller and the buyer under Article 10 of Regulation No. 34 of 2019.

Frequently asked questions

Who is responsible if the Client ID and Secret Key are used without permission?

Guideline 7 of ISTD’s technical guide places responsibility for keeping the Client ID and the Secret Key confidential, and for not sharing them, on the taxpayer. It states that the taxpayer bears full responsibility for any unauthorized use, and it does not mention the solution provider at this point.

What does the joining guide mean by the solutions provider the taxpayer works with?

The phrase means the provider that the taxpayer itself relies on for its software, because the pronoun in the Arabic phrase refers back to the taxpayer. In its four guides, the Income and Sales Tax Department publishes no program for vetting software and no list of vetted providers.

Is the solution provider responsible for an invoice that does not match the sale?

Article 10 of Regulation No. 34 of 2019 places responsibility for the invoice matching what actually took place on the seller and the buyer alike, and it does not mention the solution provider. What the taxpayer agrees with its provider lies outside this text.

Should I hand the Client ID and Secret Key to my solution provider?

The joining guide asks you to use the linking credentials inside your accounting software, and it also asks you to keep them in a safe place and not to share them with anyone. It does not say how the two fit together when the provider carries out the setup. What guideline 7 of the technical guide does establish is that responsibility for any unauthorized use stays with the taxpayer.

Can I unlink devices if I stop working with my provider?

ISTD’s questions and answers guide describes unlinking devices as an invoicing-system support request submitted to ISTD, and ISTD limits it to a business that has no accounting system and linked by mistake. For a business that has an accounting system, ISTD’s written position is that it must link its system with the invoicing system.

References

• Income and Sales Tax Department (ISTD), procedures guide for joining the Jordanian National Electronic Invoicing System, 2026 edition (in Arabic), p. 13.
• Income and Sales Tax Department (ISTD), technical guide for integrating with the National Invoicing System through the API, version 1.5 (in Arabic), p. 104.
• Income and Sales Tax Department (ISTD), questions and answers guide for the National Invoicing System, 2026 (in Arabic).
• Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended, consolidated text (in Arabic), Articles 9 and 10.