No way to fix a rejected invoice

[BOTSolutions8686]

Hi. One of the invoices got rejected with error , because the vat catagory was not mentioned on the invoice. Now the document is in submitted state. We can not directly edit the invoice. On cancelation it says that the document is linked to sales invoice additional fields. And there is no option to delete the linked additional fields . Please advise on how to proceed.

[mhaggag]

Hello,

Are you referring to the tax_category field on the invoice? We have a validation that prevents submitting invoices if it's missing and ZATCA phase 2 integration is enabled. Or did you mean the tax category was missing the ZATCA Category?

The app disables invoice cancellation in general per ZATCA regulations, so even if the link didn't exist, the invoice wouldn't be cancellable.

Once we figure out the problem, we should be able to fix it and fix the rejection from the Sales Invoice Additional Fields.

[BOTSolutions8686]

If the invoice is not cancelable and is not accepted by ZATCA That means the only way is to generate a new invoice . as by default in ERPNext, you can not amend without cancellation . So if we generate a new invoice . and submit to zatca , that means our accounting entries will be duplicated.

[BOTSolutions8686]

In version 0.37.1 The tax for line item one is somehow getting extra values . Although we do not have any extra vat applied on the invoice. Can you please indicate on what could be the cause of this .

[mhaggag]

If the invoice is not cancelable and is not accepted by ZATCA That means the only way is to generate a new invoice . as by default in ERPNext, you can not amend without cancellation . So if we generate a new invoice . and submit to zatca , that means our accounting entries will be duplicated.

If erroneous invoices are issued, they can be reversed (returned) to correct the accounting situation on ERPNext before issuing new corrected invoices.

In version 0.37.1 The tax for line item one is somehow getting extra values . Although we do not have any extra vat applied on the invoice.

Is the item repeated on multiple lines? We're currently tracking this in #125 and working on a fix.

[BOTSolutions8686]

Yes . Thank you . When can we expect a fix ? Is there a possibility of getting a timeline ?

[mhaggag]

I'm currently working on it, and I'm expecting to pass it on to the test team tomorrow, which means it'll likely go in early next week if no major issues come up (work week is Sunday to Thursday). Please keep in mind this is an estimate and unexpected issues may delay things a bit. However, this is the current highest priority issue for us.

For new invoices, you can either split the repeated lines into different invoices (not great, I know) or carry on as usual until the fix is released then fix the rejection from sales invoice additional fields.

[BOTSolutions8686]

We have managed to fix the issue . By changing a few variables .

https://drive.google.com/file/d/1Fea7rv-361cHvm-VvCj9s6y3phevAysg/view?usp=sharing

This is the link for e-invoice.xml file . This is as per version 0.35.0 Invoice is now getting accepted without warnings or errors. You can use this as reference if needed.

[mhaggag]

Thanks, I took a look at it.

The fix for the line-level tax calculation looks good; it computes the tax for that line. It might run into issues if rounded total is enabled or if ERPNext computes things with a different precision/rounding, but it should work for most cases. We're doing something similar for the fix, we're just getting the value from ERPNext's tax calculation logic to avoid issues with different precision/rounding.

The change to tax amount in tax categories looks like it will produce invalid amounts if a single invoice includes multiple tax categories (e.g. from different items) since it uses the invoice total tax amount for every category. It will work fine for one category, though, if that's your business use case.

[BOTSolutions8686]

Yes I understand . That why we did not go with a pull request. It only will solve our problem. As we know our client . so it is kind of like a hot fix for a specific use case. Where our client always uses VAT 15% (Standard Rate) For all items . No exceptions.

[BOTSolutions8686]

As per ZATCA Guidelines the invoice cannot be edited or cancelled or deleted. If an invoice gets rejected, the only fix can be done for configurations of the module and not the invoice data itself. So proper procedure is to actually generate a credit note for the invoice and generate a new one . Although the invoice was never submitted to zatca if a credit note is issued and finalized to avoid duplicate entries in the accounting - "The credit note will be submitted to ZATCA" as the "Send to ZATCA" trigger is placed on submit document button .

The predicament still exists.

[mhaggag]

As per ZATCA Guidelines the invoice cannot be edited or cancelled or deleted. If an invoice gets rejected, the only fix can be done for configurations of the module and not the invoice data itself. So proper procedure is to actually generate a credit note for the invoice and generate a new one . Although the invoice was never submitted to zatca if a credit note is issued and finalized to avoid duplicate entries in the accounting - "The credit note will be submitted to ZATCA" as the "Send to ZATCA" trigger is placed on submit document button .

The predicament still exists.

Issuing a credit note fixes the accounting situation on ERPNext. ZATCA may accept or reject the credit note (depending on its configuration), but from the ERP perspective the situation is fine. There are two cases:

1) ZATCA rejected the credit note (e.g. because it triggers the same bug in the original invoice with one item on multiple lines). In this case, you are still safe from an audit by ZATCA because a rejection is proof of submission (you have proof you submitted the invoices to ZATCA and that they were rejected and that one undoes the other on the ERP system, which you can show to auditors)

2) ZATCA accepted the credit note (let's say, ERPNext joined the repeated item in one line or something). You're still fine because upon an audit, you can prove that you did the return to undo a rejected invoice to generate a clean/accepted one.

In all cases, since we didn't modify or delete any submitted invoices, and kept records of all operations, we should be good to go.

[meaziz]

In all cases, since we didn't modify or delete any submitted invoices, and kept records of all operations, we should be good to go.

Thanks for the clarification .. Is there any official response from the authorities that having the "Rejected" issued invoice and credit note relying only on proof of submission will work our in an audit.

Also another concern - Relying on this model will yes keep the Accounting Data intact in terms of an audit. But will create an unreal (intermediate transactions) which will mess up the sales, reporting etc...

[omarashrafsarhan]

Hello, @meaziz In the KSA Compliance app, we have taken all necessary measures to fully adhere to the regulations and system requirements set forth by ZATCA. Below are some of the key requirements outlined by the authority that our solution complies with:

• The system must prevent any tampering or modification of invoices or the system itself. Additionally, it should be capable of recording and detecting any tampering attempts.
• Users are restricted from directly modifying the system or altering invoice generation functionalities.
• Deletion or modification of E-Invoices or associated XML documents (including Notes) by users is not permitted once stored in the system. The solution also ensures that adequate storage capacity is available for these documents.

Regarding the deletion of business settings, these settings are linked to the certificate generated from the Fatoorah platform during the onboarding process. Deleting this certificate is not allowed as it is integral to the invoice signing process. Furthermore, as per the system requirements, the solution is mandated to archive all generated invoices, which necessitates the retention of this certificate.

References:

1. https://zatca.gov.sa/en/E-Invoicing/Introduction/LawsAndRegulations/Documents/20210602_ZATCA_Electronic_Invoice_Resolution_English_Vshared.pdf
2. https://zatca.gov.sa/en/E-Invoicing/Introduction/Guidelines/Documents/E-Invoicing_Detailed__Guideline.pdf
3. https://zatca.gov.sa/en/E-Invoicing/Introduction/LawsAndRegulations/Documents/E-invoicing%20Regulation%20EN.pdf
4. https://zatca.gov.sa/en/E-Invoicing/SystemsDevelopers/ComplianceEnablementToolbox/Pages/SupportingDocument.aspx
5. https://zatca.gov.sa/en/E-Invoicing/SystemsDevelopers/ComplianceEnablementToolbox/Pages/SupportingDocument.aspx
6. https://zatca.gov.sa/en/E-Invoicing/SystemsDevelopers/ComplianceEnablementToolbox/Pages/SupportingDocument.aspx