We have a scenario where an invoice with the same invoice number was mistakenly submitted three times to ZATCA, and all three instances were cleared successfully. After five months, upon reviewing our records, we noticed these three duplicate entries with the identical invoice number.
Could you please advise on the correct procedure to rectify this duplication? if we raise a credit note referencing the original invoice number, how will ZATCA treat these entries—will all three be nullified, or only two, with the latest one remaining active in the portal?
Your guidance on this matter would be greatly appreciated to ensure compliance.
Just a heads-up, we have similar issue as due to NetworkConnectivity issues we submitted document multiple times with different hash but exactly same payload and invoice number. I am not anyhow connected to zatca, but this is how we are handling such cases. For every double-submitted document we are creating counter-party and submit it… What is happening on ZATCA:
you reported 5 documents with same NUMBER but different hash and “recorded” the same tax 5 times.
you need to issue 4 more counter-documents (NUMBER can be random or NUMBER-<suffix> and inside the reference of the document, you specify either NUMBER or UUID. I am not sure if ZATCA can properly handle UUID inside, but this is the most obvious way to find the duplicate. Otherwise just submit 4 documents with NUMBER as reference for CreditNote.
This will end-up with 5 times tax recording and 4 times tax reduction and at the end you will “record” only 1 tax for this document.
@sergei.shishov in case of network connectivity issue you must retry the same payload without changing hash.
Regarding credit notes, please note UUID cannot be made mandatory as taxpayer may issue credit notes related to the period prior to integration.
As an example, the field KSA-27 “Prepayment UUID” is added to schema in case taxpayer wants to link prepayment invoice using UUID instead of IRN but that had to be kept optional for the reason that prepaid invoice could have been issue prior to integration in which case there will be no UUID available.
@sameer yes you have to issue Credit Notes to reverse duplicate invoices submitted with different hashes. You have to make sure to keep all the content of such credit notes (to reverse duplicate invoices) exactly same as per the corresponding invoice except for technical identifiers such as UUID, PIH, ICV and hash. So the parties, dates, values etc all business fields must remain same on credit notes for effective reversal in corresponding tax period.
According to my case ,where the same invoice number, was submitted three times and all three instances were cleared by ZATCA. However, upon reviewing the details in the cleared tax invoices, I noticed that the hash and Invoice Counter Value (ICV) differ across all three submissions.
To resolve this duplication while maintaining compliance, we plan to issue a credit note. Could you please clarify the correct approach for linking the credit note to these original invoices? Specifically, if we reference the common invoice number in the credit note’s BillingReferenceID (BT-25) tag or related fields, will all three cleared invoices be nullified, or will only two be reversed while the latest one remains valid in ZATCA’s system?
But what original values needed to be provided in the Credit note ? Invoice number of the tax invoice if I have provided means ,then does all three instances in the ZATCA will be nullified or only 2 will be nullified and valid only last submitted invoice in ZATCA portal ?
@sameer Billing Reference ID (BT-25) is a free-text field which allows up to 5,000 characters. Apart from IRN, you can also include UUID and ICV if you prefer.