JoFotara Invoice Numbering: Serial Number and cbc:ID

JoFotara invoice numbering starts with a legal text before it ever reaches the XML file. The first item that Article 5(a) of Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs requires on an invoice is the invoice serial number. In the invoice file sent to the National Invoicing System (JoFotara), the cbc:ID element in the invoice header carries the invoice’s number. Between the legal text and the file there are other numbers with similar names, chiefly the invoice counter (ICV) and the EINV_NUM value that comes back in the system’s response.

Two of our earlier articles cover parts of this topic. Our article on the JoFotara UUID explains the primary key made of the invoice number and its unique identifier, and our article on the JoFotara ICV explains the counter on its own. This article follows the invoice number itself from the legal text to the file and then to the response. It also gathers in one table what the texts do not document about a series of invoice numbers, such as gaps, the format of the number and the number of series.

The short answer is that the regulation requires a serial number on every invoice without defining it or setting its format, and that the technical guide makes the invoice number a mandatory field that forms, together with the unique identifier, a key that stops an invoice from being duplicated, without setting any rule for its sequence. Every other numbering rule is an internal decision in your business, not a requirement that can be attributed to the Income and Sales Tax Department (ISTD).

JoFotara Invoice Numbering: Four Numbers, Each With Its Own Job

When an accountant is asked for the invoice number, the question can mean one of four numbers. One appears in the legal text, two are written by your system into the invoice file, and one comes back in the system’s response. The table below puts them side by side.

The line item number is not in this table. It carries the same element name, cbc:ID, but it orders the lines of a single invoice and must be unique within that invoice.

The Serial Number in Article 5(a): The First of Five Items

Article 5(a) of Regulation No. 34 of 2019 sets out the invoice duty in two steps. First it requires the seller of any goods or service worth at least one dinar to organize and issue an invoice in at least two copies. Then it lists five items the invoice must contain, and the first of them is the invoice serial number. The exact wording is below.

«على بائع أي سلعة أو خدمة لا تقل قيمتها عن دينار واحد تنظيم وإصدار فاتورة من نسختين على الأقل تحتوي على البيانات التالية»

«الرقم المتسلسل للفاتورة»

In English, Article 5(a) of Regulation No. 34 of 2019 requires the seller of any goods or service worth at least one dinar to organize and issue an invoice in at least two copies containing the listed items, the first of which is the invoice serial number. No official English translation of this regulation was found; the English here is our rendering, and the Arabic text is the authority.

Three observations in this text matter to anyone writing a numbering policy for a business.

• The number is required on every invoice the text covers. The first item appears in the same paragraph that sets the one-dinar minimum, and the paragraph exempts no type of invoice from the serial number.
• The text does not define the phrase. The phrase serial number is not among the definitions in Article 2 of Regulation No. 34 of 2019, and Article 5 of the same regulation does not set the format of the number, where it starts or how it proceeds.
• The number appears a second time under another name. Article 6 of Regulation No. 34 of 2019 requires every person obliged to organize and issue invoices to keep a paper or computerized register of sales invoices headed with the seller’s name, and one of its items is the invoice number. The text does not say outright that the invoice number in the register is the serial number in Article 5, although the context suggests it.

Article 3 of Instructions No. 1 of 2019 on Invoicing Affairs and Their Control restates the items of a cash sales invoice.

Article 4(a) of Regulation No. 34 of 2019 provides that, for the purposes of the regulation, the electronic invoice that is recognized is the one issued by the National Invoicing System or by a program linked to it. If your invoice is issued from software linked to the system, its number is written into the XML file that this software builds, which is the subject of the next section.

The Invoice Number in the XML File: The cbc:ID Element in the Invoice Header

ISTD’s technical guide (version 1.5, p. 12) describes the cbc:ID element in the invoice header in a single phrase, the invoice number, and shades its value in yellow in the template. The guide’s color key says that elements shaded yellow mark variables that must be filled in (mandatory) through the seller’s system. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.

In its description of the next element, cbc:UUID, the guide adds that the unique identifier is created by the taxpayer’s system so that the ID and the UUID together form a primary key that stops an invoice sent to the system from being duplicated. Two points about numbering follow from this description.

• The invoice number alone does not identify the invoice on the system. The identification is made by the full pair, the number together with the unique identifier.
• The guide describes cbc:ID as nothing more than the invoice number. It gives no length, no prefix and no list of permitted characters for it, and it does not say that it starts from 1, as it does for the counter.

You may notice in the image that the template puts the phrase serial number where the value of cbc:UUID goes. Do not confuse it with the serial number in Article 5(a). The guide describes what sits in that position as a distinctive number, the UUID, and describes what sits in cbc:ID as the invoice number.

Linking the serial number in the regulation to the invoice number in the guide is our reading, not an explicit text. Article 5(a) requires a serial number for the invoice, and cbc:ID is the element that the guide describes in the invoice header as its number, so the closest reading is that this element carries that number. This is our reading of the text, not a statement by ISTD.

cbc:ID Elements in the File: Which One Carries the Invoice Number

The element name cbc:ID appears in many places in the invoice file, and each place holds a different value. Anyone searching the file for the invoice number has to tell the right place from the others. The table below lists the places that the technical guide explains.

The invoice number is therefore the element that sits directly in the file header, not inside another block. It can be confused with the element inside cac:SellerSupplierParty, because the income-source sequence also carries the word sequence. It is explained in our article on the JoFotara income-source sequence.

Invoice Number and the ICV Counter: Two Sequences With Different Descriptions

The counter is the only value in the file header that the guide’s description column explicitly calls sequential. The guide says (p. 13) that it is a counter created by the taxpayer for electronic invoices, starting sequentially from 1 to infinity according to the global definition.

The similar wording is where readers of the legal text and the guide get confused. The regulation requires a serial number, and the guide describes the counter, not the invoice number, as sequential. But the guide does not say that the counter is the serial number Article 5(a) means, and it does not say that the invoice number must equal the counter’s value. The difference between the two, as the guide’s text puts it, is as follows.

It follows that if you make the invoice number equal to the counter’s value in your system, that is a design choice in your business, not a condition in the guide. The same is true if you keep them separate. Our article on the JoFotara ICV, mentioned at the start, explains the counter in full, including what the guide says about its sequence and what it does not say.

EINV_NUM: The Invoice Number as the System Returns It

After sending, the National Invoicing System returns a response whose elements the guide explains in a table (p. 97). Among them is EINV_NUM, described as the number of the sent invoice, and next to it EINV_INV_UUID, described as the invoice’s global unique number (UUID).

By that description, the value in EINV_NUM is the invoice number that you sent in cbc:ID. The guide describes no other number that the system generates for the invoice. The response has four uses for numbering.

• Matching the response to the invoice. Compare EINV_NUM and EINV_INV_UUID with the number and identifier you sent, since together they are the key that identifies the invoice.
• Status before number. The guide asks you to decide the invoice’s status from the EINV_STATUS value, not from the technical response code. In the NOT_SUBMITTED state the EINV_NUM value comes back empty, together with the QR code, the unique identifier and the signed invoice.
• Resending an invoice that was already accepted. If you send an accepted invoice again with the same number and identifier, the system returns the status ALREADY_SUBMITTED together with the original QR code.
• Storing. Guideline 5 in the guide (p. 104), titled storing core data, asks you to store the invoice number, the unique identifier, the QR code and the status, for tracking and retrieval.

The invoice number also shows up when the QR code is verified. The guide (pp. 105 to 107) states that verification is done by scanning the code with the Sanad app only, through its digital document verification option (التحقق من المستندات الرقمية). If the document is valid, the app displays basic data held inside the code, including the invoice number, together with the invoice total, the total tax, the date, and the seller’s tax number and name.

The Invoice Number When You Resend and in a Return Invoice

Two rules in the technical guide settle when the number stays as it is and when a new one appears.

On a resend, the number and the identifier stay the same

Guideline 3 in the guide, resend management, asks you to resend with the same invoice number and the same unique identifier when a send fails. Guideline 8, outage handling, asks you to retry without generating a new identifier when a request times out or the connection fails. The guide warns that generating a new identifier on a retry causes duplicate invoices. The number you reserved for the invoice on the first attempt therefore stays with it on every later attempt.

A return invoice is a separate document that points to the original number

A return invoice in the National Invoicing System is a new document with the type code 381. Its header carries its own number and identifier, and it points to the original invoice inside the cac:BillingReference block. In that block the guide asks for three values from the original invoice, its number in cbc:ID, its identifier in cbc:UUID, and its total in cbc:DocumentDescription.

Three practical consequences for numbering follow.

• You need the original invoice’s number after it is accepted, so it is not enough for it to appear in the response and then be left. The guide provides no way to change an invoice after acceptance, and any correction is made with a return invoice that points to it.
• The guide allows more than one partial return invoice against the same original invoice until its quantities are used up, and each of them points to the original’s number and identifier.
• Return lines are matched against the line item numbers in the original invoice, so the guide recommends storing each line’s number in the item element cbc:ID together with the invoice number.

What the Texts Do Not Document About a Series of Invoice Numbers

These are the questions an accountant or a developer asks when designing numbering, and next to each is what you find in Regulation No. 34 of 2019, the technical guide and ISTD’s 2026 guides.

This silence does not mean that every arrangement is accepted, or that a particular arrangement is rejected. It means the rule is not published in the texts available. For questions, the technical guide (p. 104) refers you to the invoicing technical support committee at ISTD through the ISTD website. If your case depends on this point, confirm it with ISTD before you rely on it.

Practical Steps to Set Up Your Invoice Numbering

What follows are organizational practices that build on what the guide documents. Where a step is not from the guide’s text, we describe it as an internal decision.

1. Keep the numbers separate in your system. Give the invoice number, the unique identifier and the counter a field each, so that the value of one does not travel into the position of another in the file.
2. Write the numbering policy internally. Set in it the format of the number, whether return invoices get a series of their own, and what you do with the number of an invoice that was rejected. Describe the policy as your business’s own, and do not attribute any item of it to ISTD.
3. Do not change the number or the identifier on a resend. This is what guidelines 3 and 8 in the guide say.
4. Store the number with what goes with it. The invoice number, the unique identifier, the QR code and the status, as guideline 5 asks, and with them the line item numbers for any later return.
5. Match the response. Compare EINV_NUM with what you sent, and judge the invoice by the EINV_STATUS value.
6. Record the number in the invoice register. Article 6 of Regulation No. 34 of 2019 asks for a register that includes the register page number, the buyer’s name, the invoice number and the invoice total.
7. Keep an audit log. Guideline 10 in the guide asks for a complete log of sends, responses and resends, and it is what shows later what happened to each number.

How Qoyod Handles the Invoice Number and Its UUID

Everything above is work for the software that builds the invoice file and sends it. Qoyod’s integration with the National Invoicing System works on this layer as follows.

• Building the file and sending it. 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.
• An alert before sending. 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.
• Every invoice’s status in view. ISTD returns the invoice status and any error message, and Qoyod shows them in its status panel, with states that include sent (مرسلة), previously sent (مرسلة مسبقًا) and not sent (لم تُرسل) together with the error message.
• Resending with the same identifier. The status panel lists invoices that were not sent and need to be resent, and when you resend one it keeps the same UUID.

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 what Qoyod offers on our National Invoicing System page.

Frequently asked questions

What is the serial number of an invoice in Jordan?

It is the first of the five items that Article 5(a) of Regulation No. 34 of 2019 requires in every invoice worth at least one dinar. The regulation does not define the phrase, and it does not set the format of the number or where it starts.

Is the invoice number in cbc:ID the same as the invoice counter ICV?

The two differ in position and in description. The invoice number sits in the file header and forms a primary key together with the unique identifier, while the counter sits inside the AdditionalDocumentReference block and the guide describes it as starting sequentially from 1. The guide does not require their values to be equal.

Must invoice numbers be consecutive, with no gaps?

The texts available do not say so. Article 5(a) of Regulation No. 34 of 2019 requires a serial number without defining it, and the technical guide states no rule on gaps in the invoice number. It would therefore be wrong to attribute acceptance or rejection in this case to ISTD.

Does the National Invoicing System give my invoice a new number?

The system returns the EINV_NUM element in its response, which the guide describes as the number of the sent invoice. The number that comes back is the one you sent in cbc:ID, and the guide describes no other number that the system generates.

Do I change the invoice number if a send fails and I retry?

You do not change it. The technical guide asks you to resend with the same invoice number and the same unique identifier when a send fails, and it warns that generating a new identifier on a retry causes duplicate invoices.

Does a return invoice have a number of its own?

Yes, a return invoice carries its own number and identifier in its header, and it points to the original invoice inside the BillingReference block with that invoice’s number, unique identifier and total. The guide does not say whether return invoices follow a separate number series.

References

• Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended, consolidated text (in Arabic), Articles 2, 4, 5 and 6.
• Instructions No. 1 of 2019 on Invoicing Affairs and Their Control, as amended (in Arabic), Article 3.
• 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, 13 and 97 to 107.
• Income and Sales Tax Department (ISTD), procedures guide for issuing an invoice in the Jordanian National Electronic Invoicing System, 2026 edition (in Arabic).