Jordan Personal Data Protection Law and Invoices

This article on the Jordan personal data protection law and invoices puts two sets of facts on one page. The first is what a reader needs to know about Personal Data Protection Law No. 24 of 2023 (PDPL), meaning its dates, the body that oversees it and the main obligations it places on anyone who processes data. The second is the buyer data an invoice in Jordan carries under Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs and under the technical guide for the National Invoicing System (JoFotara).

The aim is to let an accountant or a business owner see the two texts side by side and know what each one requires and what it does not. The legal relationship between them, that is whether one governs the other or exempts from it, is not addressed in the official documents this article relies on. This article therefore does not answer that question, and it gives no legal opinion on compliance with the data protection law. Anyone who needs a ruling on a specific case should turn to the competent authority or to a legal adviser.

What is Jordan’s Personal Data Protection Law?

Personal Data Protection Law No. 24 of 2023 is Jordan’s first data protection law. The Ministry of Digital Economy and Entrepreneurship (MoDEE) publishes the text of the law on its website as a single file that sets the Arabic text beside an English text, which MoDEE labels an unofficial translation. Three dates mark the law’s path to full application, and they are worth keeping in mind.

Since March 17, 2025, the one-year grace period no longer applies, and the law is in force in full for the bodies that were processing data before it took effect. These dates are the only timeline this article relies on. It gives no other dates for instructions or regulations issued under the law.

The law also differs from the invoicing rules in its subject and in the body that applies it. Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs is tax legislation issued under the Income Tax Law, and the Income and Sales Tax Department (ISTD) applies it. The data protection law is overseen by a different body, which is the subject of the next section.

The oversight body: the Personal Data Protection Council

The Personal Data Protection Council oversees the application of the law, and the Minister of Digital Economy and Entrepreneurship chairs it. Inside the ministry, a Data Protection Unit carries out three tasks.

• Complaints. The unit receives complaints about the processing of personal data.
• Compliance checks. The unit checks whether bodies are meeting the provisions of the law.
• The registry. The unit keeps the registry of data controllers and data processors.

This division of roles makes one practical point clear. Everything about the invoice itself, its data, its format and its submission, goes to ISTD and JoFotara. Everything about applying the data protection law goes to the council and its unit at MoDEE. Neither source says that either body rules on matters that belong to the other. How responsibility is split on the invoicing side between a taxpayer and the provider of a linked system is covered in our article JoFotara Solution Provider Responsibility vs the Taxpayer.

Main obligations under Jordan’s Personal Data Protection Law

The law places a set of obligations on anyone who processes personal data. The table below gathers the main ones as the source this article relies on summarizes them, without going into the text of each article or its detailed exceptions.

Note that the table describes what the law requires in general terms. It does not say which of these obligations applies to a particular business. Appointing a data protection officer, for example, is tied to certain cases such as large-scale processing or the processing of sensitive data, and it is not an obligation on everyone who processes data. Working out where your business stands against these obligations is a legal question that falls outside the scope of this article.

Data transfer outside Jordan and hosting

One question that comes up with cloud accounting software is where the data is hosted. The answer, according to the source this article relies on, is that the law imposes no explicit requirement to host cloud accounting data or general financial data inside Jordan. What the law sets is conditions for transferring personal data outside Jordan, not an outright ban on such transfers.

The rule is that personal data may not be transferred to a recipient outside Jordan whose level of protection is lower than the level the law sets, unless an exception applies. The exceptions the source names include the following.

• Explicit, informed consent from the data subject.
• Judicial or international cooperation.
• Data exchange for medical purposes or purposes related to public health.
• A transfer needed for the movement of funds.

There is an important caveat to this answer. Sector regulators can impose their own rules on outsourcing or on cloud services, for example the Central Bank of Jordan (CBJ) for licensed financial institutions. So it is not correct to say that Jordan has no rules at all on data, and a business that works in a regulated sector should refer to the instructions of the body that oversees its sector.

Jordan Personal Data Protection Law and Invoices Side by Side

We now turn to the second side, the buyer data that an invoice in Jordan carries. It comes from two official texts published by ISTD, Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs and version 1.5 of the technical guide for integrating with the National Invoicing System through the API.

What the invoicing regulation requires: the buyer’s name in specific cases

Paragraph (a) of Article 5 of Regulation No. 34 of 2019 sets five mandatory items on every invoice. They relate to the invoice itself, the seller and the goods or service, and they include the seller’s national number if the seller is not registered for sales tax. That paragraph says nothing about the buyer. The buyer is covered by paragraph (b) of the same article, which reads as follows.

«يجب أن تحتوي الفاتورة على اسم المشتري بشكل واضح في حال بيع السلعة أو الخدمة الآجل أو البيع بالتقسيط أو على دفعات».

In English, Article 5(b) of Regulation No. 34 of 2019 requires the buyer’s name to be stated clearly in a deferred sale, an installment sale or a sale paid in stages. No official English translation of this regulation was found; the English here is our rendering, and the Arabic text is the authority.

So of all the buyer’s details, the regulation requires only the name, and only in three kinds of sale, a deferred sale, an installment sale and a sale paid in stages. Elsewhere, the regulation adds rules that concern the buyer without adding to the buyer data itself.

• Handing over a copy. Article 5(c)(1) of Regulation No. 34 of 2019 provides that a copy of the invoice is given to the buyer in line with the method used to organize and issue invoices, and that the seller keeps the other copies.
• Proof of receipt. Article 5(c)(2) of Regulation No. 34 of 2019 requires the seller, when an invoice is worth more than JOD 10,000, to prove that the buyer received it.
• Sales invoice register. Article 6 of Regulation No. 34 of 2019 requires a paper or computerized register of sales invoices, and the buyer’s name is one of its entries.
• Transfer of data to ISTD. Article 9 of Regulation No. 34 of 2019 requires every seller to enable ISTD to transfer all data and information on invoices and their contents electronically. The opening of its wording is quoted below.

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

In English, Article 9 of Regulation No. 34 of 2019 places on every seller the duty to enable ISTD to transfer, electronically, all the data and information relating to invoices and their contents. No official English translation of this regulation was found; the English here is our rendering, and the Arabic text is the authority.

What the technical guide sets: the buyer block in the invoice file

When an invoice is issued electronically through JoFotara, the buyer’s details go into a block of the XML file named cac:AccountingCustomerParty. The technical guide shades mandatory elements in yellow and optional elements in green. Its color key says that the yellow elements are to be filled in, as mandatory, by the seller’s system, and it says the green elements are to be filled in while describing them as optional. The key’s wording for the two colors reads as follows.

«مطلوب تعبئتها (إجبارية) من خلال نظام البائع» · «مطلوب تعبئتها (إختيارية) من خلال نظام البائع»

ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.

The table below lists the elements of the block as the guide documents them. We cover them one by one in our article JoFotara Buyer Identification: NIN, PN and TN.

The table shows that only two elements are shaded yellow, the identifier type and the buyer’s name. Even then, the name’s content is required in two cases only, a receivable invoice of any value, and a cash invoice worth more than JOD 10,000 or its equivalent in foreign currency. If the name is missing in either case, the invoice is rejected with the message Bayer name is missing, spelled as the guide prints it.

On the JoFotara portal, the invoice form shows the same fields under Arabic labels. They are the name, the buyer additional-ID type (نوع المعرفات الإضافية للمشتري), the buyer number (رقم المشتري), the phone number, the city and the postal code.

When the invoice reaches the buyer

The response returns the invoice status, and if the invoice is accepted a QR code comes back with it, which the guide requires to be shown on the seller’s invoice. For a return invoice, the technical guide sets a rule on the buyer’s details.

«يجب أن تتوافق بيانات المشتري في فاتورة الإرجاع مع بياناته في فاتورة البيع الأصلية المرتبطة بها».

In English, the guide requires the buyer details on the return invoice to match those on the original sales invoice it is linked to. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority. So the buyer details written on the original invoice are repeated unchanged on any return against it.

What each text says and what it does not

With both sides laid out, the table below sets out the subject of each text, the body behind it and the limits of what this article takes from it.

So here is what this article does not say about the Jordan personal data protection law and invoices, and what should not be read into it.

• It does not classify invoice fields. It does not say that the buyer’s name, national number or phone number does or does not fall within the law’s definition of personal data, because the source it relies on does not give the text of that definition.
• It does not say that one text exempts from the other. It does not state that the data protection law exempts invoice data from its provisions, or that the invoicing regulation exempts the seller from the provisions of the data protection law.
• It does not say the two texts conflict. Nor does it say they are consistent. A ruling on the relationship between them needs a text or an official opinion that does not appear in the documents this article relies on.
• It does not cover invoice retention periods. Retention is governed by Article 8 of Regulation No. 34 of 2019 and is outside the scope of this article. What a linked system stores and records on the integration side is covered in our article JoFotara Logging: What to Store and Record.

Checklist for buyer data before you issue the invoice

What you can set with confidence is the side that ISTD documents. The checklist below rests on the invoicing regulation and the technical guide alone, and it helps you see what buyer data each invoice needs.

1. Identify the type of sale. Is it a deferred sale, an installment sale or a sale paid in stages? In these three cases, Article 5(b) of Regulation No. 34 of 2019 requires the buyer’s name to be stated clearly.
2. Identify the payment method in the file. On a receivable invoice the name’s content is required whatever the value, and on a cash invoice it is required when the value is more than JOD 10,000 or its equivalent.
3. Choose the identifier type. The schemeID element is shaded yellow, and its three values are NIN for the national number, PN for the personal number of a non-Jordanian and TN for the tax number.
4. Review the green elements. The buyer’s number, postal code, governorate code and phone number are optional according to the guide’s shading, unless another condition makes one of them mandatory, such as the buyer’s tax number on a development zone invoice.
5. Respect the format constraints. The buyer’s number takes digits only, the postal code takes a maximum of 5 characters, and the phone number takes digits only, from 9 to 14 digits.
6. Match the return data. On a return invoice, the buyer’s details match those on the original invoice.

Data protection questions as such, like consent, the privacy policy and the rights of data subjects, are a matter for the text of the law and the body that oversees it. If you issue your invoices from accounting software, that software needs to be linked to JoFotara. For a wider view of the system and how to connect your business to it, read our article Jordan’s National E-Invoicing System, or see how Qoyod works with JoFotara on our National Invoicing System page.

Frequently asked questions

What is the number and year of Jordan’s Personal Data Protection Law?

It is Law No. 24 of 2023, published in the Official Gazette on September 17, 2023. It entered into force on March 17, 2024, six months after publication, and the one-year grace period for bodies already processing data ended on March 17, 2025.

Which body oversees the application of the law?

The Personal Data Protection Council oversees it, chaired by the Minister of Digital Economy and Entrepreneurship. Inside the ministry, a Data Protection Unit handles complaints, compliance checks and the registry of controllers and processors.

What buyer data does the invoicing regulation in Jordan require?

Regulation No. 34 of 2019 requires the buyer’s name to be stated clearly in a deferred sale, an installment sale or a sale paid in stages, under Article 5(b) of that regulation. The technical guide adds that the name’s content is mandatory on a receivable invoice, and on a cash invoice worth more than JOD 10,000.

Is the buyer’s national number mandatory on an e-invoice?

The technical guide shades the value of the buyer’s number in green, which makes it optional under its color key. The identifier type, by contrast, is shaded yellow. The guide documents one case where the buyer’s tax number becomes mandatory, the development zone invoice.

Does the law require data to be hosted inside Jordan?

According to the source this article relies on, the law contains no explicit requirement to host cloud accounting data or general financial data inside Jordan. It does set conditions for transferring personal data outside Jordan, and sector regulators can impose their own rules on licensed financial institutions.

Does the law exempt invoice data from its provisions?

The official documents this article relies on do not address this question, so the article states neither an exemption nor that the data is covered. Anyone who needs a ruling on a specific case should turn to the body that oversees the law or to a legal adviser.

References

• Personal Data Protection Law No. 24 of 2023 (PDPL), text published by the Ministry of Digital Economy and Entrepreneurship (MoDEE) with the Arabic and an English text that MoDEE labels an unofficial translation.
• Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended, consolidated text (in Arabic), Articles 5, 6, 8 and 9.
• Income and Sales Tax Department (ISTD), technical guide for integrating with the National Invoicing System through the API, version 1.5 (in Arabic), pp. 12, 16, 26, 98 and 101.