I recently posted a related question about the calculation of the Previous Invoice Hash (PIH):
Clarification on Previous Invoice Hash (PIH) Calculation.
I’m still awaiting a response, but I’d like to highlight a potential issue with the PIH calculation.
The documentation and data dictionary specify that the PIH should be the Base64-encoded SHA256 hash of the previous invoice, resulting in a maximum length of 44 characters (calculated as 4×32/3=44). However, it seems the calculation method has changed. The PIH in the current SDK produces a hash with double the length, suggesting a different process is being used.
From my observations, the new calculation appears to follow these steps:
- Compute the SHA256 hash of the previous invoice, yielding 32 bytes.
- Represent those 32 bytes as a hexadecimal string.
- Encode the UTF-8 representation of the hexadecimal string into a Base64 string, resulting in an 88-character hash.
Despite this, I’m still using the original approach outlined in the documentation (directly encoding the SHA256 hash into a Base64 string). So far, invoices are being reported successfully with this method.
However, clarification from the ZATCA team is essential. Can we continue using the documented approach, or should we switch to the logic implemented in the SDK?