PIH calculation when a previous invoice fails to reach ZATCA on first attempt and succeeds on retry

@Ankit.K.Tiwari @idaoud
@eCloud
I am seeking clarification on PIH (Previous Invoice Hash) calculation in scenarios involving network timeouts, retries, and bulk invoice submissions.


My understanding

As per my understanding, PIH is calculated using the hash of the previous invoice that has been successfully submitted to ZATCA and processed, meaning it eventually receives a response such as:

  • REPORTED / NOT_REPORTED (for reporting)
  • CLEARED / NOT_CLEARED (for clearance, where applicable)

However, I am unclear how PIH should behave when an invoice fails to reach ZATCA on the first attempt and is only accepted after a retry.


Scenario for clarification

Invoice 1

  • XML generated with:
    • UUID = U1
    • Invoice Hash = H1
    • PIH = H0
  • Invoice 1 is submitted to ZATCA
  • First submission fails due to a network issue
  • The invoice does not reach the ZATCA server, and no response is received
  • At this stage, Invoice 1 is effectively not submitted to ZATCA

Invoice 2

  • XML is generated after the first attempt of Invoice 1
  • Uses:
    • UUID = U2
    • Invoice Hash = H2
    • PIH = H1 (hash of Invoice 1)
  • Invoice 2 is submitted to ZATCA
  • ZATCA responds successfully:
    • Status = REPORTED (or NOT_REPORTED)
    • CLEARED / NOT_CLEARED as applicable

Retry of Invoice 1

  • Invoice 1 is retried with:
    • The same UUID (U1)
    • The same Invoice Hash (H1)
    • The same XML
  • On retry, ZATCA responds:
    • Status = REPORTED
      (this is not a REPORTED status from the first attempt; the first attempt resulted in a network timeout / no response from ZATCA, so the invoice is processed and reported as a new submission on retry)

Questions

  1. In this scenario, is it correct that Invoice 2 used PIH = H1, even though Invoice 1 had not reached ZATCA at the time Invoice 2 was generated?
  2. If PIH must reference the hash of a previously submitted invoice, does an invoice that only succeeds on a later retry still qualify as the correct predecessor in the chain?
  3. Does ZATCA consider PIH chaining to be based on:
  • The issuance order defined by the ERP, or
  • The actual order in which invoices are successfully received by ZATCA?
  1. If the first attempt of Invoice 1 never reached ZATCA, but the invoice is later accepted on retry:
  • Is the PIH used by Invoice 2 still considered valid?
  • Or should Invoice 2 have waited until Invoice 1 was successfully received?

Here are the answers to all your inquiries.