Previous invoice hash does not match the invoice before it in this ZIP
Reported aschain.pih_not_previous_member_hashdoes not match the hash of the invoice before it
What is wrong
This document's previous invoice hash (KSA-13) is not the hash of the document that comes before it in the same seller's counter series inside this archive: the member whose invoice counter value (KSA-16) is one less carries a different hash in tag 6 of its own QR code, which is the hash its issuing solution wrote for it. ZATCA's XML Implementation Standard requires every document to carry the base64-encoded SHA-256 hash of the invoice issued before it, computed the same way as the hash under the cryptographic stamp; the QR code carries the same hash of the XML invoice in tag 6. Read together, the two values chain the documents so that the sequence cannot be altered without breaking a link. Mutabiq computes no hash itself: it compares the two values the two documents already carry, after reducing each to the digest it stands for, so a difference of encoding alone - raw bytes against base64, or base64 of the bytes against base64 of their hexadecimal text - is not a mismatch. This is reported as a risk rather than as a rejection: no assertion in ZATCA's published rule set reads two documents together, and what the Fatoora platform does with a broken link is not something Mutabiq can measure. If these files come from different devices, this is expected: in Mutabiq's reading of ZATCA's E-Invoicing Detailed Guideline the counter and the chain belong to the e-invoicing solution that issues the documents, so two solutions of one seller exported together will interleave.
What to check in your ERP
First check that the two files come from the same device or system; if they do not, nothing is wrong. If they do, the hash step of your e-invoicing module is reading the wrong document. The usual causes are a previous invoice hash taken from the last document cleared or reported rather than the last one issued, two processes sharing one counter while each keeps its own last hash, and a document regenerated after the one following it had already been issued. Compare tag 6 of the earlier document with the previous invoice hash of this one in your own system, then check which document the module reads the previous hash from. The link is checked here only where both values decode to a SHA-256 digest; a value that is not one is reported separately by the previous invoice hash and QR code rules.