Handling ICV and Invoice Previous Hash When Clearance Fails

Hello everyone,

I would like to raise a discussion regarding the behavior of Invoice Counter Value (ICV) and Invoice Previous Hash (IPH) in scenarios where an invoice fails during Clearance or Reporting.

Scenario:

  • An invoice is successfully generated in the internal system.

  • The corresponding XML file is created.

  • When the XML is submitted to ZATCA, the Clearance process fails due to a calculation or validation error.

Based on this scenario, I would like to understand the following:

  • What is the expected handling of Invoice Counter Value (ICV)?

  • What happens to the Invoice Previous Hash (IPH)?

  • Does a failed invoice become part of the invoice chain?

  • Should the failed invoice be counted in the ICV sequence and affect the IPH?

  • Or should it be completely excluded, with the invoice being corrected and resent using the same ICV and IPH?

In other words:
Does an invoice that fails Clearance impact the invoice chain, or is it ignored until successfully cleared?

I would appreciate insights from anyone who has practical experience or official clarification from ZATCA regarding this case.

Thank you in advance for your support and valuable input.

1 Like

In my experience, the most important aspect to monitor is the reportingStatus returned by the server: REPORTED/CLEARED and NOT_REPORTED/NOT_CLEARED.

  • When we receive either of these statuses, the current ICV and Invoice Hash must be properly recorded, as they will be required for the next submission.

  • If the status is NOT_REPORTED/NOT_CLEARED, review the error details. This is usually caused by an XML issue. We’ll need to fix the XML and resend it with a new UUID, while incrementing the ICV by +1 and using the PIH from the invoice hash that we recorded Previously.

  • For any other response, continue resubmitting until the server provides one of the valid reportingStatus mentioned above.

Than you for your time and sharing your experience.
That’s so clear.