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.