I would like to report a technical issue related to the submission of a credit note, where due to a technical error in the XML file setup, a debit note code was entered for this XML . This issue has been present for several months but was only recently discovered.
Although the credit note appears correctly in our system, it is showing a debit note on the ZATCA platform.
We kindly request your assistance in resolving this issue and would appreciate any guidance on the appropriate steps to correct the error.
Thank you for your cooperation. We look forward to your response and instructions.
To ensure comprehensive support as usual,
Can I kindly ask you to collaborate more in this part (“Although the credit note appears correctly in our system, it is showing a debit note on the ZATCA platform.”)
Actually it is inside the system it is a credit note
but the XML was created and a debit note code was placed in xml for this credit note
(XML was created and document type was set to 383(DN) instead of 381(CN).Only the document type is incorrect)
So just for my understanding, you issued an invoice as CN but the typeCode for the shared XML is DN not CN, However the invoice in your system saved as CN!!
Okay, can you elaborate more on how your system integrates with ZATCA?
The purpose of this question is to ensure that your system correctly calls the appropriate API for each invoice submission. It is essential that the invoice received by ZATCA matches the one stored in your system, as discrepancies between the saved invoice and the submitted invoice indicate a misalignment in processing.
Do you understand what I am trying to say?
Our recommendation is that you need to check it from your side as it seems that it’s an internal issue.
If i create it inside the system, there will be a duplicate credit note (the original CN. The second CN to close the debit notice)
There will be a problem inside the system
Can it be created outside the system to be corrected in Portal only
Thank you @idaoud yes incorrect DN has to be reversed by passing a corresponding CN and then actual CN must be submitted for Reporting or Clearance. As this incorrect DN is generated outside main ERP system, CN may be generated in same manner so as not to impact customer ledger.
Due to this issue, several credit notes were submitted with an incorrect invoice type code.
We would like to ask:
Is it possible to reverse all the incorrect credit notes using a single credit note that covers all the affected documents, instead of issuing a separate reversal for each one?
The affected credit notes belong to a previous tax period, and the VAT return for that period has not yet been submitted. If we issue the correction notes now, will they be counted under the previous tax period or the current period?
Kindly advise on the correct procedure in this case.
@mnuaimi it is difficult to give a general response without understanding the nature of invoices (original credit notes that were sent with incorrect invoice type code) and number of customers involved. You cannot generate one credit note covering different customers.
Please do not keep the VAT return filing on hold, VAT return must be filed within due dates irrespective of issues with e-invoicing data.
The issue occurred because we relied on the sample XML models included in the SDK.
Up until version 3.3.4.0, the SDK samples defined:
Credit Note with code 383
Debit Note with code 381
As a result, our system submitted sales return invoices using code 383, which ZATCA treated as Debit Notes.
This has affected most taxpayers using our e-invoicing solution, and many of them have received emails from ZATCA indicating mismatches between VAT return totals and the aggregated tax amounts from the shared invoices.
The main question is: What can we do now?
Our system has already shared over 150 million invoices for more than 2,000 taxpayers. Most of these invoices are simplified invoices, while the standard invoices represent only around 4% of the total.
We have already corrected the invoice type codes and are working hard to roll out updates to all our clients’ systems — most of which are desktop or POS applications.
We would like to ask:
Can we ignore the previously submitted invoices and focus on ensuring correct submissions moving forward?
Is it possible to arrange a meeting with your technical or compliance team to discuss this issue in more detail?
How can we get assigned a relationship manager from ZATCA to handle ongoing inquiries and coordination?
Your guidance on how to proceed will be greatly appreciated.
We have contacted the Zatka team and clarified to them that the discrepancies stem from the transmission of code 383 alongside the sales return, based on the XML file templates outlined in the development documentation. They have understood this matter.