I am currently working on generating compliant QR codes for Saudi Arabian e-invoices as per ZATCA specifications.
During our tests, we observed that when the value of Tag 1 (the company name) in the TLV-encoded data exceeds 127 characters, the QR code is rejected, with the error “Invalid QR code format, Please follow the ZATCA QR code specifications”. The error message simply states that the QR code format is invalid, even though the TLV structure is well-formed and Base64 encoding is correctly applied.
We have confirmed that the same invoice passes validation when we shorten the company name so that the length of Tag 1’s value is 127 characters or less.
Could you please confirm whether there is a hard limit of 127 characters for the company name (Tag 1) in the QR code, and if so, whether this is officially documented?
If this is an undocumented limitation, would ZATCA consider updating the documentation or supporting longer names?
@loug overall limit of QR Code is 1000 characters (increased from 500 characters specified in documentation). There is no character limit on each individual tag of QR Code.
After implementing the truncation of the seller name on QR code, we start getting this error:
{
"validationResults": {
"infoMessages": [
{
"type": "INFO",
"code": "XSD_ZATCA_VALID",
"category": "XSD validation",
"message": "Complied with UBL 2.1 standards in line with ZATCA specifications",
"status": "PASS"
}
],
"warningMessages": [],
"errorMessages": [
{
"type": "ERROR",
"code": "sellerName_QRCODE_INVALID",
"category": "QRCODE_VALIDATION",
"message": "seller name does not match with qr code seller name",
"status": "ERROR"
}
],
"status": "ERROR"
},
"reportingStatus": "NOT_REPORTED"
}
What we should do in such case? Should we also truncate the seller name in the XML?
This is so confusing and no official documentation for such edge cases… It looks like when developing specification nobody was thinking about these boundary cases at all.
@sergei.shishov let me check with concerned team about this scenario.
Regarding your comment, please note that the specifications for QR Code were published in May 2021 and taxpayers are allowed ample time to test all their edge cases. Various channels including this forum, weekly Q&A workshops, dedicated support emails are provided to address any challenges that taxpayers or solution providers face. It is impractical for any tax authority to cover all edge cases across all industries of the country and address them in documentation. Hence there is a role /need of solution providers to bridge the gap.
While your posts and contribution to the community are appreciated, condescending tone is not.
We have removed the trailing precision and now our timestamp looks like 10-09-2025T16:32:15Z. But as I was saying before it did not help.
Then we started investigating the same way how @loug was doing, removing character by character from the name and submitting until it is passed. And the result was exactly the same, when the character length was 127, the submission went successful.
For example this name will not work: أبجدية عربية جميلة تحتوي على العديد من الحروف والكلمات المميزة والرائعة حقا as it has 139 characters in binary representation. But almost similar one without some words: أبجدية عربية جميلة تحتوي على العديد الحروف والكلمات المميزة والرائعة will work as binary representation of this string is 127 length.
Could you please double check on your side, guys, about this hard limit and recommend us what we should do in such case? Should we just truncate the name (not UX friendly as it will be truncated on scanned QR code), or you can properly fix it and support more characters as you promised?
We will remove there precision microseconds, but I can assure you that 2 years we are reporting SINV with this time format and do not have any issues. We have tons of document reported with such QR code and never were rejected. But the simplified invoices rejected for this particular customer. Based on this and on investigation of QR code I can see the difference only in company name (length).
Do you have an ability to give this QR code to your dev and run through the “verification” process and see what it will spit out. Then Try without precision and check the outcome. I still think that something is wrong with length. I hope you guys have UnitTests covering the QR code 1000 (mentioned above) limit otherwise providing such info without even checking is not reliable.
@sergei.shishov team is unable to replicate the error with the name أبجدية عربية جميلة تحتوي على العديد من الحروف والكلمات المميزة والرائعة حقا . Can you please share the XML for which you received error “SellerName_QRCODE_INVALID” on sp_support@zatca.gov.sa ?
The issue is appeared on our side. We were generating incorrect TLV and therefore the QR code was not valid as the parsing of that TLV was impossible.
NOTE: Just to anyone else experiencing similar issue: the problem was that our code assumed that the maximum length of the value is 1 byte and therefore when the value was bigger than 127, we were not properly convert it to TLV value.
In the internet there are some examples of TLV conversion and we were using one of them. And in that solution it was assumed (hardcoded) that the length of the value fits into 1 byte.
If you have the same issue, double check your implementation.
