1. Sometimes IRPs may fail to check duplicate IRN from de-dup system for technical reasons. Under this circumstance, it is possible for tax payers to register the same document/invoice at different IRPs. Whenever the de-duplication system comes back to live, only one of the IRP will be able to successfully register the IRN. All other IRPS will fail to register on de-duplication system the IRNs generated with them for the same document. In such cases, the status of these IRNs will be updated as 'REJ' by these IRPs. This will be reflected in the 'Get IRN Details' API when the tax payers pull the IRNs.

New API to get the list of such IRNs which are marked as 'REJ' has been provided. The supplier can send the date of rejection and if any IRNs are marked as rejected (REJ), the list of IRNs will be provided through this API. The details of the API are available here

2. The new validation has been added in IRN generation – Providing the country code has been made mandatory under category 'EXPWP and EXPWOP export details ("ExpDtls"."CntCode") for the export transactions.

3. It is being observed that many tax payers' applications generate large number of erroneous hits to the GST E Way Bill and GST eInvoice Systems. In case of any error due to validation or data of data type or format or otherwise, appropriate error codes and error messages are provided in response to such requests by GST system. The tax payer application has to capture these error codes and facilitate to take action in correcting the issue and only then re-send the requests. Distinct error codes with detailed descriptions are provided in response for various types of failures, so that the tax payer application can take appropriate measures to correct the request payload. But many tax payer applications are ignoring the response error codes but continue to send the same erroneous request payloads multiple times, sometimes, lakhs of times.

To handle the large number of errors which would affect the overall performance of the system, measures are being to block the access to such users and added with two new error codes. The details and process of blocking and unblocking are provided in the document.

NIC – GST Systems

Process of blocking of E-way Bill and E-invoice generation to tax payers due to large number of erroneous hits

To facilitate seamless integration with the existing ERPs or financial accounting applications, the GST E Way Bill and GST eInvoice systems of NIC are providing the services through Application Programming Interfaces (API). Using these facilities, many businesses have integrated their systems directly or through GSPs or ERPs.

NIC has also facilitated the tax payers to test the integration of their ERP systems with NIC – GST systems on testing environment, SANDBOX. It has been informed to all the tax payers to test the integration on sandbox with all types of APIs before going for the production.

In spite of following of all these measures, it is being observed that many tax payers' applications generate large number of erroneous hits to the GST E Way Bill and GST eInvoice Systems. In case of any error due to validation of data or data type or format or otherwise, appropriate error codes and error messages are provided in response to such requests by GST system. The tax payer application has to capture these error codes and facilitate to take action in correcting the issue, either in software or data and only then re-send the requests. Distinct error codes with detailed descriptions are provided in response for various types of failures, so that the tax payer application can take appropriate measures to correct the request payload. But many tax payer applications are ignoring the response error codes but continue to send the same erroneous request payloads multiple times, sometimes, lakhs of times.

For example, when the request payload has issue with total taxable value, the following error code and description is responded with. Unless the values are corrected and sent, even if the same payload is sent lakhs of number of times, the same error is responded with. This is due to not handling or testing of these cases in the tax payer application.

These large number of unproductive hits consume the network and server resources not only of the business entities but largely affect the GST infrastructure hosting these API services. This will directly impact the performance of the GST system and hence causes inconveniences to other users of the system across the country. It may result in Denial of Service (DoS) attack also.

To bring awareness to the users on large erroneous API calls, NIC has taken several measures such as providing detailed description of the errors, the relevant help on the causes and resolutions for the errors etc. NIC has been sending the summary of errors through mails every day to the users as well.

In spite of best of efforts by NIC, the issue of large number of errors exceeds unacceptable range at times and affects the performance of the whole system. The same could have been controlled through technology but there will be chances of genuine hits getting affected.

Hence the following process or measures are being taken to control these erroneous hits.

1. The automated mails will continue to be sent to the authorized signatory's mail id. This can be treated as the first notice.

2. To start with, if the number of errors is more than 20,000 per GSTIN or more than 1 lakh for a client Id, a mail will be sent from the support / help desk team to the same mail, id intimating about the errors and 2 days' time will be provided to correct the issue and report back.

3. If the issue repeats more than 2-3 days continuously, the automated mail itself may be treated as the prior intimation and the access to all the API of e-way bill and e-invoice will be blocked.

4. If the GSTIN or the client id are blocked, following error messages will be responded with,

5. It is the responsibility of the end user (GSTIN) as well as the service provider like GSP/ASP/ERP etc. (client id) to take care of the number of error generated on the system to avoid any inconvenience.

6. Once the tax payer resolves the issue, he will communicate the same to the helpdesk, then blocking will be revoked and tax payers will be allowed to continue. If it repeats, the blocking will not be revoked till the tax payers does the thorough testing of integration on the sandbox for 2-3 days.

7. Gradually, the limit on the number of errors for GSTIN and Client Id will be reduced.