Postal code length is incorrect in JoFotara: Fix

The Postal code length is incorrect message appears when your accounting software sends an invoice to the National Invoicing System (JoFotara) and the invoice comes back rejected with code 400. Postal code length is incorrect means that the value sent in the cbc:PostalZone element of the buyer details is longer than the limit the technical guide sets for this element, which is a maximum of 5 characters.

The element itself is optional in the guide’s templates. So the message is about the length of a value that was actually sent, not about a missing field. That leaves two ways to fix it. You either correct the value so that it falls within the limit, or you leave the field without a value if you have no correct value for the buyer.

This article explains the text of the message as it appears in the technical guide issued by the Income and Sales Tax Department (ISTD), version 1.5. It shows where the element sits in the buyer block, and what the guide says about the length limit and what it leaves unsaid. It then moves on to the steps for fixing the error, a worked check and a checklist to go through before you send.

What the Postal code length is incorrect message means

The technical guide describes code 400 (Bad Request) as an error in the values sent inside the XML file. The detail of the error is written in the EINV_MESSAGE field of the response file. One of the messages the guide lists under this code is Postal code length is incorrect, and on p. 102 it explains it in these words.

«يدل على أن رقم صندوق البريد في ملف ال XML طوله غير صحيح حيث أن الحد الأعلى له 5».

In English, the guide says the message indicates that the postal box number in the XML file has an incorrect length, since its maximum is 5. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.

Notice that the guide uses two different names in two places. In the explanation of the message it calls the value the postal box number (رقم صندوق البريد). In the buyer details table it calls it the buyer’s postal code (الرمز البريدي للمشتري) and places it in the cbc:PostalZone element. The guide pairs the message with a maximum of 5, which is the same limit it sets for this element. So if you get the message, start your check from cbc:PostalZone in the buyer block.

The message is one of the rejection messages collected, together with the other codes, in our article JoFotara Error Codes: Why an Invoice Is Rejected and How to Fix It, and our article on JoFotara error 400 indexes it with the other messages of that code. This article deals with this one message alone, its limit, its place in the file and how to fix it.

Where the message appears in the response file

JoFotara returns the result of its checks inside the EINV_RESULTS element. It holds three arrays, INFO, WARNINGS and ERRORS. Each entry in these arrays carries five fields, type, status, EINV_CODE, EINV_CATEGORY and EINV_MESSAGE. The text Postal code length is incorrect comes in the last of them.

Version 1.5 of ISTD’s technical guide does not state the EINV_CODE value that accompanies this message. So rely on the text of the message in EINV_MESSAGE when you search for it in your logs or build an alert on it in your software, and copy the text exactly as it comes back to you.

If the invoice is rejected, its status in EINV_STATUS carries the value NOT_SUBMITTED, and the QR code, the unique identifier, the invoice number and the signed invoice come back as null. So do not judge the invoice by the HTTP code alone. Read EINV_STATUS first, as the guide requires in its guidelines.

Where cbc:PostalZone sits in the buyer details

The buyer details template in the guide starts with the cac:AccountingCustomerParty element. In this block the guide documents six variables. Two are shaded yellow, which means mandatory, and four are shaded green, which means optional. cbc:PostalZone is one of only two variables in the template that concern the buyer’s address. The other is the governorate code, cbc:CountrySubentityCode.

The table below brings the six variables together with their shading and their documented rule, so you can see where the element sits among its neighbors.

So the element the message points to sits in the buyer block, and its documented rule is its length. Each of its neighbors has a rule of its own. The phone number is digits only, between 9 and 14 digits, and the governorate code is one of twelve codes, listed in our article JoFotara Governorate Codes: The Full List. The buyer identifier and its types are covered in our article JoFotara Buyer Identification: NIN, PN and TN.

The 5-character limit: what the guide sets and what it leaves open

The buyer details table on p. 17 states that the buyer’s postal code has a maximum of 5 characters only, and the explanation of the message on p. 102 repeats the same limit. A value longer than 5 characters is what the message points to, and a value of 5 characters or fewer meets this rule.

Beyond the maximum, the guide leaves four points undefined. Knowing them keeps you from building a check on a rule that does not exist.

• No minimum length. The guide states the maximum alone and gives no minimum number of characters.
• No digits-only condition. For the buyer’s phone number the guide requires digits only, but it sets no such condition for this element. The documented rule on it is its length alone.
• No format for postal codes in Jordan. The guide sets no format for these codes and no reference to check them against, so this article gives neither a format nor a list.
• No rule for an empty field. The guide does not say whether a green element with no value is left out of the file or sent empty. The next section deals with this point.

The rule for all four points is the same. The guide’s silence on a condition is neither permission to ignore it nor a reason to invent it. If you need a stricter rule, ask ISTD technical support or your software provider.

An optional element with a binding limit: when to correct the value and when to leave it

The guide shades cbc:PostalZone green in all of its templates. The color key on p. 12 explains what green means.

«العناصر المظللة باللون الأخضر تدل على متغيرات مطلوب تعبئتها (إختيارية)».

In English, the key says that elements shaded green indicate variables to be filled in, as optional. ISTD publishes this guide in Arabic only; the English here is our rendering, and the Arabic text is the authority.

So whether you fill in the element is up to you, but any value you put in it is subject to the 5-character limit. That gives you two ways forward when the message appears.

The first way: correct the value

If you have a correct value for the buyer within 5 characters, put it in place of the long value. Start the correction from the customer record in your software, not from the XML file alone. If your software builds the file from the saved customer card, correcting the file alone will not stop the long value from coming back on the next invoice for that customer.

The second way: leave the field without a value

If you have no correct value, the guide does not require one, because the element is optional. But it does not say how a missing value is represented in the file, whether the element is removed or sent empty. Settle how the file is built in this case with your software provider or with ISTD technical support, not by inference. Our article JoFotara Mandatory Fields: Reading the Technical Guide covers this point together with the other green elements.

What being optional does not change

The choice here is about filling the element in, not about its rule. A value sent in cbc:PostalZone is subject to the 5-character limit even though the element is green, and the message itself is the proof. The other green elements in the buyer block have their own rules too. The phone number is optional and still has its digits and length rule, and the governorate code is optional and the guide lists twelve codes for it.

The buyer block also has one case where green becomes a condition. The buyer identifier value is shaded green, but the guide makes the buyer’s tax number mandatory on a development zone invoice. None of this applies to cbc:PostalZone, because the guide does not tie it to an invoice type or a payment method.

How to fix Postal code length is incorrect step by step

The fix happens in the customer details inside your accounting software and then in the file you send. Follow these steps in order.

1. Read the message and the invoice status. Make sure the text in EINV_MESSAGE is Postal code length is incorrect, and that the invoice status in EINV_STATUS is NOT_SUBMITTED.
2. Identify the invoice and the buyer. Take the invoice number, cbc:ID, and its identifier, cbc:UUID, from your send log, and identify the customer the invoice was issued to.
3. Find the element in the file. Look inside the cac:AccountingCustomerParty block for cbc:PostalZone and check the value it holds.
4. Count the characters of the value. If there are more than 5, that is what the guide points to in its explanation of the message.
5. Trace where the value comes from in your software. Check the field in the customer details that your software fills this element from. It may hold text longer than the code itself, or a value meant for another field, such as the address or the phone number.
6. Correct the value or leave the field without a value. Choose one of the two ways in the previous section, and settle how an empty field is represented before you rely on it.
7. Fix the other errors with it. If the ERRORS array carries other messages, fix all of them before you resend, so that the invoice is not rejected a second time for another reason.
8. Resend with the same number and identifier. When a send fails, the guide asks you to resend the invoice with the same number, cbc:ID, and the same identifier, cbc:UUID, not with a new identifier. Then read EINV_STATUS in the new response.

A worked check before you correct

The table below shows how to judge the value in cbc:PostalZone by the length rule alone. The lengths in it are counting examples, not formats of real postal codes.

So the check here is a count of characters and nothing more. Whether the code is actually the buyer’s own code is a data question that you confirm with your customer, because the guide publishes no rule for checking it.

The message in the API path and on the portal form

The message is documented in the technical guide for integrating with the National Invoicing System through the API, which covers the path where accounting software sends an XML file to the system. The invoice form on the portal has, in its Buyer details section (بيانات المشتري), a field named Postal code (الرمز البريدي). It sits alongside the name, the buyer additional-ID type (نوع المعرفات الإضافية للمشتري), the buyer number (رقم المشتري), the phone number (رقم الهاتف) and the city (المدينة).

ISTD’s procedures guide for issuing an invoice in the Jordanian National Electronic Invoicing System does not say how the portal handles the length of this field, or whether it shows the same message. So this article is limited to the integration path, and it does not carry the 5-character limit over to the portal form by inference.

Pre-submission checklist

Go through these points in the buyer details before the invoice leaves your software.

• The value of cbc:PostalZone, if one is sent, is no longer than 5 characters.
• The field that fills this element on the customer card holds the code alone, not the address or the phone number.
• How an empty field is represented in your file is settled with your software provider or with ISTD technical support.
• The buyer’s phone number, if one is sent, is digits only, between 9 and 14 digits.
• The governorate code, if one is sent, is one of the twelve codes the guide lists.
• The invoice number cbc:ID and the identifier cbc:UUID are stored, so that you can resend with them if the invoice is rejected.

In its guidelines, the technical guide recommends checking the totals, the taxes, the tax number, the buyer’s number and the mandatory fields before sending, to reduce errors with code 400. This element is not named among those points, but its limit applies to any value sent in it.

How Qoyod helps

When you issue your invoice from accounting software, you do not write the XML file by hand. Qoyod is integrated with the National Invoicing System (JoFotara). 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’s integration with the National Invoicing System works on this layer as follows.

• 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.
• 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. It covers only the fields named above, and the postal code is not one of them. So the accuracy of the buyer details on your customer cards remains your responsibility, and acceptance of the invoice rests with the National Invoicing System alone. To see the full integration, visit our National Invoicing System page.

Where to go next

• The other rejection codes and messages. They are in our article JoFotara Error Codes: Why an Invoice Is Rejected and How to Fix It.
• The full picture of the system. How it works and how to connect your business to it, in our article Jordan’s National E-Invoicing System.
• Another message from the buyer block. When the buyer’s name is missing, see our article on the Bayer name is missing message.
• The buyer’s tax number in development zones. See our article on the BuyerTaxNumber error on development zone invoices.

Frequently asked questions

What does the Postal code length is incorrect message mean?

It means that the value sent in the cbc:PostalZone element of the buyer details is longer than the maximum the technical guide sets, which is 5 characters. The guide lists it among the code 400 errors, whose detail comes in the EINV_MESSAGE field.

Is the buyer’s postal code mandatory on a JoFotara invoice?

It is not mandatory, because the technical guide shades the cbc:PostalZone element green, the color of optional variables. Any value sent in it, however, is subject to the 5-character limit.

Should I remove the element from the file if I have no correct value?

The guide leaves this point undefined, since it does not say whether a green element with no value is removed or sent empty. Settle it with your software provider or with ISTD technical support before you build your file on it.

Does the guide require the value to be digits only?

The technical guide sets only a length rule for this element, a maximum of 5 characters. It gives no digits-only condition for it, as it does for the buyer’s phone number, and it sets no format for postal codes in Jordan.

Is the postal box number in the message explanation a different element?

The guide uses the two terms in two different places, the buyer’s postal code in the buyer details table and the postal box number in the explanation of the message. It pairs the message with a maximum of 5, which is the limit it sets for the cbc:PostalZone element, so start your check there.

Do I generate a new unique identifier when I resend after the correction?

Do not generate a new identifier. The technical guide asks you to resend with the same number, cbc:ID, and the same identifier, cbc:UUID, and then to read EINV_STATUS in the new response to learn the status of the invoice.

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, 17, 101 and 102.
• Income and Sales Tax Department (ISTD), procedures guide for issuing an invoice in the Jordanian National Electronic Invoicing System, 2026 edition (in Arabic).
• ISTD’s National Invoicing System guides (in Arabic)