Every invoice file sent to Jordan’s National Invoicing System (JoFotara) carries a date in its header, and the first thing a developer building that file asks is how the date is written. The JoFotara invoice date format is yyyy-mm-dd, which means the year in four digits, then the month, then the day, separated by hyphens, as in the value 2023-10-30. The value goes in the cbc:IssueDate element of the XML file.
The rule in short is to write the date as yyyy-mm-dd, as in all the XML examples in the technical guide issued by the Income and Sales Tax Department (ISTD). It is also the format given in the description table of the basic invoice information template (p. 12). The guide sets no format for the time or the time zone.
This article sets out what the guide says about the date, where the element sits in the file, what guideline 9 says about a standard time format, and how the element in the XML file differs from the date field in the invoice form on the portal. It then separates out what the guide does not specify, so that your system is not built on a rule that is attributed to ISTD but is not its own.
JoFotara invoice date format in the technical guide
The date is described in the basic invoice information table of the technical guide for integrating with the National Invoicing System through the API, version 1.5 (p. 12). In the template column the table shows the cbc:IssueDate element with the words “invoice date” (تاريخ الفاتورة) shaded yellow inside it, and the description column carries the following text.
«تاريخ الفاتورة ويجب أن يكون حسب الصيغة التالية yyyy-mm-dd».
In English, the description says that this is the invoice date and that it must follow the format yyyy-mm-dd. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.
The format yyyy-mm-dd has three parts, and each part has a fixed number of digits. The table below breaks down the value 2023-10-30, which the guide uses in its basic invoice information example (p. 14).
The guide’s own examples also show something that some developers overlook. A month with one digit is written with two. In one of the guide’s examples the date is 2022-09-27, and the month is written 09, not 9. The order is fixed as well, with the year first, then the month, then the day.
This is also the date format of the ISO 8601 standard, and it is the format the UBL standard uses for dates. That is why it fits the guide’s requirement that the whole invoice file conform to UBL 2.1, the standard explained in our article JoFotara UBL 2.1: What It Is and What It Requires.
Where the IssueDate element sits in the invoice file
The cbc:IssueDate element sits in the invoice header, inside the “basic invoice information” template (p. 12), next to the elements that identify the invoice itself. These include the invoice number cbc:ID, the unique identifier cbc:UUID, the invoice type cbc:InvoiceTypeCode and the invoice currency. The element looks like this in the template.
<cbc:IssueDate>invoice date</cbc:IssueDate>
To read this line you need the color key that the guide places above the template. It says that the elements shaded yellow mark variables that must be filled in (mandatory) by the seller’s system. The words “invoice date” inside the element are shaded yellow, so the date is a mandatory value that your system fills in on every invoice. The element name and its opening and closing tags are fixed text, copied as they are. How to read the shading across the rest of the file is explained in our article JoFotara Mandatory Fields: Reading the Technical Guide.
After the template, the guide shows a filled-in example (p. 14) in which the element carries an actual value.
The value 2023-10-30 in this example is an illustration. Do not hard-code it in your system, because the element carries the date of each invoice individually.
Why every invoice uses yyyy-mm-dd
The pages of the technical guide show the date description as yyyy-mm-dd. But if you copy the description text from the PDF file and paste it into an editor, the order of the date parts may appear different from the examples on some pages (among them pp. 33, 46 and 73). That difference exists only in the copied description text. The XML examples are consistent.
Every XML example in the guide writes the date as yyyy-mm-dd, and the date values in its examples include 2023-10-30, 2023-11-01, 2023-11-20, 2022-09-27 and 2026-02-27. The same format is the one given by the date description in the basic invoice information template (p. 12), and it is the ISO 8601 format that UBL follows.
So the rule we adopt in this article, and in everything we publish about JoFotara, is that the date is written as yyyy-mm-dd, as in all the XML examples in the guide, and that a different order in copied text is not treated as an acceptable alternative format.
The guide does not say what happens if the date is sent in another format, so neither acceptance nor rejection can be attributed to it in that case. This is one of several observations on reading the technical guide that we collect in a separate article in this series, on the guide’s examples and what should not be copied from them word for word.
Guideline 9 and the standard time format
On page 104, the technical guide sets out ten guidelines for systems linked to JoFotara. The ninth is headed time (التوقيت الزمني), and its text is as follows.
«استخدام تنسيق زمني موحد (Standard Time Format) لتجنب اختلافات المعالجة بين الأنظمة».
In English, the guideline says to use a standard time format to avoid processing differences between systems. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.
This text states two things and leaves three things unstated. Separating them keeps the guideline from being made to say more than it does.
- Stated. Your system uses a standard time format, and the purpose is to avoid processing differences between systems.
- Not stated in the guideline. It names no specific format, it sets no time zone, and it sets no format for writing the time.
The practical reading of this guideline is that your system writes the date in one format on every invoice and in every place where it stores or sends the date, and that this format is the yyyy-mm-dd used by the guide’s examples. If your software shows the date to users in another form, for example starting with the day, make the conversion to yyyy-mm-dd a fixed step when the file is built. This is our reading of the text, not a statement by ISTD.
The other nine guidelines, and what each means for linked systems, are explained in our article JoFotara Guidelines for Linked Systems: All Ten Explained.
The date field in the invoice form on the portal
Everything above concerns the XML file that a linked accounting system builds. A business that issues its invoices directly on the portal does not write an XML file. It fills in the new invoice form shown in ISTD’s procedures guide for issuing an invoice in the Jordanian National Electronic Invoicing System, 2026 edition (p. 6). In the invoice details section, the form has three fields, the invoice type, the invoice issue date (تاريخ إصدار الفاتورة) with an asterisk showing that it is mandatory, and the currency.
The table below compares the two places.
So the format yyyy-mm-dd is a concern of whoever builds the XML file. A portal user does not need to know it to issue an invoice, and should not be told to type the date in that form into the field, because ISTD’s guide does not say so. The other fields of the form are explained in our article JoFotara Invoice Form Fields Explained.
The format of the date is a matter of form, while which date is written is a legal matter governed by Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended. Article 3 of that regulation fixes the time and date of a sale as the time and date at which the sale actually takes place, Article 5(d) ties issuing the invoice to that moment, and Article 5(a) of the regulation lists the date of organizing and issuing the invoice among the particulars an invoice contains. There is no published English text of this regulation, so the English here is our rendering, and the Arabic text is the authority.
The date after the invoice is accepted, and the QR code
The role of the date does not end when the file is sent. Once an invoice is accepted, the National Invoicing System returns a QR code, and the code must be shown on the seller’s invoice. The guide (pp. 105 to 107) explains how to verify the code by scanning it in the Sanad app, through the digital document verification option (التحقق من المستندات الرقمية). If the document is valid, the app shows the basic invoice data held inside the code, six items in all, one of which is the invoice date.
So the date you send in your file is one of the basic items that the guide says appear when an invoice is verified. Where the code comes from and when it comes back are covered in a separate article in this series on the QR code that ISTD returns.
What the guide does not specify about date and time
The phrase “standard time format” in guideline 9 raises questions for a developer that go beyond the date. The table below sets each question next to what version 1.5 of the technical guide contains.
Version 1.5 of ISTD’s technical guide does not state a format for the time, a time zone, or what happens when the date arrives in another format. Because none of the ISTD documents cited here states these points, they should not be relied on. While those questions stay open, three habits help.
- Do not invent a time format and attribute it to ISTD. If your system needs to record the invoice time internally, that is a design decision in your system, not a requirement stated in the guide.
- Document your decisions as design. The time zone your server uses, and the way a date is converted from its display form to yyyy-mm-dd, are two decisions you write down in your internal documentation as your own system’s design.
- Ask the responsible body when you need to. The guide (p. 104) directs inquiries to the technical support committee for invoicing affairs at ISTD, through ISTD’s website. If your case depends on this point, confirm it with ISTD before you rely on it.
Invoice date pre-submission checklist
This checklist gathers what the guide says about the date, and keeps apart what is our own practical reading, so that you know the source of each item.
- The element is in its place.
cbc:IssueDateis in the invoice header, within the basic invoice information template (p. 12). - The value is not empty. The date is shaded yellow in the template, so it is a mandatory value (p. 12).
- The order is right. Year, then month, then day, with a hyphen as the separator, as in the format yyyy-mm-dd.
- The digit count is right. Four digits for the year, two for the month and two for the day, as in the example 2022-09-27.
- The example value is not fixed. The value 2023-10-30 in the guide’s example (p. 14) is not copied into every invoice.
- Copied text is not a reference. The date format in your file is the format of the XML examples, not what appears in the description text when it is copied from the PDF file.
- One format across your system. The date is written in the same format on every invoice and in every place, and this is our practical reading of guideline 9.
Checking the date is part of a wider check that guideline 2, verification before sending, asks for. It covers the totals, the taxes, the taxpayer number, the buyer number and the mandatory fields before the invoice is sent to the system.
How Qoyod handles the invoice file
All of the above is work that falls on the taxpayer’s system, meaning the software that builds the invoice file and sends it. Qoyod’s integration with the National Invoicing System works on that layer as follows.
- Building and sending the file. 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.
- A check 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.
- The status of each invoice 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.
The pre-send check is an alert, not a guarantee. For a wider view of the system and how to connect your business to it, read our article Jordan’s National E-Invoicing System. To see what Qoyod offers, visit Qoyod’s JoFotara page.
E-invoicing and full accounting in one system
Qoyod is integrated with the National Invoicing System (JoFotara). You issue your invoice in Jordanian dinars from Qoyod, it is booked to your ledgers automatically and sent to the system, and once it is accepted it comes back with a QR code from the Income and Sales Tax Department.
Frequently asked questions
What is the invoice date format in JoFotara?
The date is written as yyyy-mm-dd, which means the year in four digits, then the month in two digits, then the day in two digits, with a hyphen between each two parts, for example 2023-10-30. It is the format used in all the XML examples in the technical guide of the Income and Sales Tax Department.
In which element of the XML file is the invoice date written?
It is written in the cbc:IssueDate element in the invoice header, within the basic invoice information template of the technical guide (p. 12). Its value is shaded yellow there, which is the color that marks mandatory fields.
Why does the date order look different when I copy text from the technical guide?
The pages of the guide show the date description as yyyy-mm-dd, but the description text, when copied from the PDF file, may appear in a different order on some pages (among them pp. 33, 46 and 73). All the XML examples write the date as yyyy-mm-dd, so the format of the examples is the one to use, and the copied text is not treated as an alternative format.
What does guideline 9 mean by a standard time format?
The guideline says to use a standard time format to avoid processing differences between systems, without naming a specific format. The guide sets no format for the time and no time zone.
Do I write the date as yyyy-mm-dd when I issue an invoice from the portal?
That format concerns the XML file that a linked accounting system builds. The invoice form on the portal has a mandatory invoice issue date field (تاريخ إصدار الفاتورة), and ISTD’s guide does not document how the date is displayed in it.
References
- 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, 14, 33, 46, 73 and 104 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), pp. 6 and 8.
- Regulation No. 34 of 2019 on Organizing and Controlling Invoicing Affairs, as amended, consolidated text (in Arabic), Articles 3 and 5.
