What Mutabiq reports
One entry for each way this rule can be reported.
- Reported as
- What kind of value was found — empty, not_15_digits and the like — never the value itself.
A file inside the ZIP is itself a ZIP
Reported asentry.nested_zipa ZIP inside the ZIP
What is wrong
One member of the uploaded archive is another ZIP archive rather than an invoice. Mutabiq does not open an archive inside an archive, so this member was never read and none of the checks were run on it. This is a statement about that member of the upload, not about any invoice inside it: nothing in it has been checked.
What to check in your ERP
Build the upload as one flat ZIP holding the XML files themselves, with no inner archive and no folder structure that carries one. The usual cause is an export that zips one archive per day or per branch and then zips those together for transfer; take the XML files out of the inner archives and put them in a single ZIP.
A file inside the ZIP has an unsafe path
Reported asentry.unsafe_pathan unsafe file path
What is wrong
One member of the uploaded archive carries a name that is an absolute path, or one that climbs out of the archive with "..", or one that is otherwise not a plain name inside the archive. Mutabiq refuses such a member without reading it, because a name of that shape is how an archive tries to write outside the place it is unpacked into. The member was never read and none of the checks were run on it.
What to check in your ERP
Check how the archive is assembled. Members should be named for the invoice - an ordinary file name, optionally inside a plain folder - and nothing else. A leading slash or drive letter usually means the archive was built from a list of full paths on disk rather than from names chosen for the archive; a ".." segment usually means it was built by walking upwards from a subfolder.
A file inside the ZIP is too large to check
Reported asentry.entry_too_largetoo large to check
What is wrong
One member of the uploaded archive declares a size larger than the 5 MB limit Mutabiq accepts for a single document, so it was never extracted and none of the checks were run on it. This is a limit of the checker applied to that member, not a finding about the invoice inside it.
What to check in your ERP
The limit is per member, so the archive as a whole is not the problem. A UBL invoice on its own is normally a few hundred kilobytes; a member well past that usually holds several invoices in one file, or an attachment, logo or PDF copy embedded in the XML. Export one invoice per file with embedded attachments turned off.
A file inside the ZIP is larger than the archive says it is
Reported asentry.declared_size_exceededlarger than the archive declares
What is wrong
One member of the uploaded archive expands to more bytes than the archive's own directory declares for it. Mutabiq stops at the declared size rather than following the data, because a member that expands past what it declared is how an archive tries to exhaust the memory of whatever opens it. Extraction was stopped and none of the checks were run on that member.
What to check in your ERP
The archive is internally inconsistent, which is a fault of whatever wrote it rather than of the invoice inside. Rebuild the ZIP with the archiving tool your system normally uses, or with the operating system's own, and upload it again. If the same tool keeps producing it, the file was probably edited or truncated after it was written - transferred over a link that altered it, or repacked by a mail gateway.
A file inside the ZIP could not be decompressed
Reported asentry.inflate_failedcould not be decompressed
What is wrong
The compressed data of one member of the uploaded archive could not be decompressed. The bytes are not a stream the decompressor can read to the end, so the member was never extracted and none of the checks were run on it. Nothing is known about the invoice inside it.
What to check in your ERP
This is damage to the archive rather than anything in the invoice. Rebuild the ZIP from the exported XML files and upload it again. If the rebuilt archive fails in the same way, check the step that moves the file: an upload interrupted part way, a transfer that treated the archive as text, or a scanner that rewrote it in passing will each leave a stream that ends where it should not.
A file inside the ZIP uses a compression method Mutabiq does not read
Reported asentry.unsupported_compressiona compression method Mutabiq does not read
What is wrong
One member of the uploaded archive is compressed with a method other than the two Mutabiq reads - stored, meaning not compressed at all, and deflate, which is what an ordinary ZIP uses. The member was never extracted and none of the checks were run on it.
What to check in your ERP
Rebuild the archive with the default settings of your archiving tool, which produce deflate. Methods such as bzip2, LZMA, XZ or zstd appear when a tool is configured for maximum compression, or when the archive was written by a general-purpose backup utility rather than by a plain ZIP writer. The saving is a few kilobytes on a file this size and costs the upload.
A file inside the ZIP is incomplete
Reported asentry.truncated_entrythe file is incomplete
What is wrong
The archive's directory lists one member, but the data that member points at is not there - it starts past the end of the file, ends past the end of it, or does not begin with the header a member must begin with. The member was never read and none of the checks were run on it.
What to check in your ERP
The archive is cut short or its directory disagrees with its contents, which is a fault of the file rather than of the invoice inside. Rebuild the ZIP and upload it again. A member that is consistently missing this way usually means the archive was assembled while a file in it was still being written, so check that the export finishes before the archiving step begins.
A file inside the ZIP is not UTF-8 text
Reported asentry.not_utf8not UTF-8 text
What is wrong
One member of the uploaded archive holds bytes that are not valid UTF-8. Mutabiq decodes every upload strictly as UTF-8 and does not guess at any other encoding, so the member could not be turned into text and none of the checks were run on it.
What to check in your ERP
ZATCA e-invoices are UTF-8, and Arabic text is where this shows up: a seller or customer name written in Windows-1256 or ISO-8859-6 is bytes that UTF-8 cannot read. Check the encoding the export step writes with - it should be UTF-8 - rather than the data itself, which is usually fine. A file that opens correctly in one editor and shows damaged Arabic in another is the same symptom.
A file inside the ZIP declares an encoding other than UTF-8
Reported asentry.declared_encoding_not_utf8declares an encoding other than UTF-8
What is wrong
One member of the uploaded archive carries an XML declaration naming an encoding that is not UTF-8. Mutabiq accepts UTF-8 only and never trusts a declared encoding over the bytes, so the member was refused without being read and none of the checks were run on it. The bytes themselves may well be UTF-8; it is the declaration that was refused.
What to check in your ERP
Look at the first line of the exported XML: it should read encoding="UTF-8", or carry no encoding attribute at all, which means UTF-8. A declaration of windows-1256, ISO-8859-6 or UTF-16 usually comes from a template or an XML writer configured once and never revisited, while the data being written is already UTF-8. Correct the declaration in the export template inside your e-invoicing module rather than in the exported file.
A PDF inside the ZIP is too large to check
Reported asentry.pdf_too_largethe PDF is too large to check
What is wrong
One member of the uploaded archive is a PDF that declares a size larger than the 10 MB limit Mutabiq accepts for a PDF, so it was never extracted and none of the checks were run on it. It was not counted towards your checks. This is a limit of the checker applied to that member, not a finding about the invoice inside it.
What to check in your ERP
A PDF/A-3 invoice is normally well under a megabyte; one past 10 MB usually carries scanned pages or large images. Put the invoice's .xml file in the ZIP instead, or export the PDF again with its images compressed.
A PDF inside the ZIP could not be read
Reported asentry.pdf_malformedthe PDF could not be read
What is wrong
One member of the uploaded archive begins as a PDF, but its structure is not what it claims to be: the cross-reference table points to the wrong places, an object is cut short, or a structural limit was exceeded. Mutabiq does not repair a damaged PDF, so no embedded invoice could be found and none of the checks were run on it. It was not counted towards your checks.
What to check in your ERP
If you issued the invoice, export the PDF again from your system and rebuild the ZIP. If you received it, ask the supplier for a new copy, or for the invoice's .xml file, which is the file ZATCA itself receives. A file that only starts like a PDF - a renamed text file, or a download cut short - is refused the same way.
A PDF inside the ZIP is password-protected
Reported asentry.pdf_encryptedthe PDF is password-protected
What is wrong
One member of the uploaded archive is a PDF protected by a password or by document encryption, so nothing in it can be read. No embedded invoice could be found and none of the checks were run on it. It was not counted towards your checks.
What to check in your ERP
If you issued it, export the PDF without a password or document protection and rebuild the ZIP. If you received it, ask the supplier for an unprotected copy, or for the invoice's .xml file. Protection that only restricts printing or copying still encrypts the file, so it is refused as well.
A PDF inside the ZIP stores its contents in a form Mutabiq does not read
Reported asentry.pdf_unsupported_filterthe PDF's contents are stored in a form Mutabiq does not read
What is wrong
One member of the uploaded archive is a PDF that compresses the parts Mutabiq must read with a method other than ordinary Flate compression or none at all, the only two Mutabiq reads. No embedded invoice could be found and none of the checks were run on it. It was not counted towards your checks.
What to check in your ERP
PDF/A-3 writers use Flate by default; another method usually means the PDF was reprocessed by an optimiser or a print driver after it was produced. Put the invoice's .xml file in the ZIP instead, or export the PDF again straight from the e-invoicing module.
A PDF inside the ZIP carries no invoice XML
Reported asentry.pdf_no_embedded_xmlthe PDF carries no invoice XML
What is wrong
One member of the uploaded archive is a PDF with no XML invoice attached: either nothing is embedded in it, or the XML files it carries are not a UBL invoice. A PDF/A-3 invoice carries its XML as an attachment and this one does not, so there was nothing to check. It was not counted towards your checks. A simplified invoice may lawfully reach the buyer as a printed or PDF copy with a QR code and no XML; only a standard invoice is shared with the XML embedded.
What to check in your ERP
A PDF exported as a printable copy of the invoice is not the e-invoice: ZATCA receives the XML. Put the invoice's .xml file in the ZIP, or export a PDF/A-3 with the XML embedded if your system offers one. If the PDF was only there beside the XML as a copy to read, it can be left out of the upload. Mutabiq's ERP guides say, for each system, where the vendor's own documentation puts the XML download.
A PDF inside the ZIP holds more than one possible invoice
Reported asentry.pdf_multiple_embedded_xmlthe PDF holds more than one possible invoice
What is wrong
One member of the uploaded archive is a PDF with several XML attachments, and which of them is the invoice is not clear: more than one is a UBL invoice, or one of them cannot be read, so whether it is the invoice is unknown. Mutabiq does not guess, so none of the checks were run on it. It was not counted towards your checks.
What to check in your ERP
Put the invoice's .xml file in the ZIP instead of the PDF. A delivery note or an order attached beside the invoice is not a problem on its own; a PDF is refused this way only when it carries two invoices, or an attachment that is not readable UTF-8 XML.
The XML inside a PDF in the ZIP is too large to check
Reported asentry.pdf_embedded_too_largethe embedded XML is too large to check
What is wrong
One member of the uploaded archive is a PDF whose embedded XML is larger than the 5 MB Mutabiq accepts for a single document, or whose XML attachments together are larger than twice that. The XML was not extracted and none of the checks were run on it. It was not counted towards your checks.
What to check in your ERP
A UBL invoice on its own is normally a few hundred kilobytes; one far past that usually holds several invoices, or an attachment embedded in the XML itself. Export one invoice per document with embedded attachments turned off.
© 2026 Hayatiq AI Solutions F.Z.E. All rights reserved.