Validation Rules for E-invoicing That You Must Take Care to Avoid Errors

• Mandatory Fields: If a field is mandatory or conditional mandatory it is defined in the schema itself and if such field is missing then error will come. For example: “The Document Number field is required.” Out of total 132 data fields, there are 28 mandatory and 18 conditional mandatory fields
• Field Specification Error: All fields have a data type (string/decimal/number/date) &a length (minimum/maximum/actual length) defined in the schema and if the value provided does not pass the validation, then this type of error comes. For example: “The field Document Number must be a string with a minimum length of 1 and a maximum length of 16”
• Json Schema invalid: If there are certain issues in the json schema itself i.e., either a comma or inverted comma or bracket etc. is missing from above example then you may get an error as “Application Error. Please contact helpdesk”. Also, if you use an inverted comma (“) or a back slash () in any value then also this error will come.
• Specific Values only allowed: For some fields in schema itself there are specific values that are mentioned as allowable values against those data points. For e.g. For Document Type only three values are allowed INV (i.e., invoice) CRN (i.e., Credit Note) and DBN (i.e., Debit Note).

• HSN Code: Presently, the custom set of HSN masters has been shared by GSTN based on customs database. The HSN code should be as per the provided master code list. If still the HSN is not present on the list, then you can recheck and if you feel it's valid then you can send the details to the GSTN helpdesk for verification at government system end. Moreover, as per notification no.78/2020 - Central Tax dated 15th Oct 2020, taxpayers with turnover more than Rs. 5 Crores are supposed to mention 6 -digit HSN Codes on their sales invoices. Recently GSTN has announced that soon there will be validation with regards to this while generating IRN as well. Another important thing to note here is the “Is Service” field – This field should be mentioned as ‘N’ if HSN belongs to ‘Goods’ and it should be mentioned as ‘Y’ if HSN belongs to ‘services. All HSN codes belonging to chapter 99 are of services.
• Pin Codes and Pin code State Mapping Pattern: State-wise pin codes can be downloaded in an excel sheet from IRIS IRP. If the Pin code is not present in the respective state list, then at least the first three digits should match as per “Pin code State Mapping Pattern” list. Thus, you can download both lists and update your masters.
• State Codes, UQC and Tax Rate: The state code, UQC code and Tax rate master list is similar to the master list present on GSTN portal while reporting details in GSTR1.So, you may not be required to make any changes or in fact not even face issue for these fields as they may have already been taken care of.
• Other codes: There is a master list for other data points also which are not mandatory data points like Country Code, Port Code, Currency Code. If you are sending these fields ensure its as per master.
• GSTIN of counterparty : The GSTIN of counterparty is validated against the taxpayer database maintained by each IRPs including IRIS IRP. Each IRP is given APIs to keep their database in sync with the GSTN database. However there could be cases where you get an error message “GSTIN – {0} is invalid.” or “GSTIN – {0} is inactive or cancelled” on IRIS IRP. This happens when either the GSTIN is not found on the IRP portal or the status on portal for that GSTIN is cancelled. In such a case recheck the GSTIN on the GSTN portal. If status on GSTN portal for the GSTIN is valid and active, then you need to update it on the IRIS IRP portal using “Update from GST Common Portal” option on IRIS IRP portal. If it’s not valid or cancelled, then you will have to check it with your counterparty. Kindly note this error can come on any IRP including NIC and This update from GST Common portal should be done on that specific IRP where you are facing this error while IRN generation.
• Distance: Distance field reflects the actual distance between the source and destination between which the movement of goods will happen. This field actually decides the validity period of your E-way bill. If you pass a value in this field and if its more than or less than the distance available in NIC database by 10%, then NIC will send an error as “The distance between the pin-codes given is too high or low.” NIC has also given an option to users if they want to use the auto-calculated distance of NIC, then they can send “0” in this field. So, if your source and destination pin codes are different then the distance can be passed as 0. In such a case, NIC will use the distance available in their systems. But if your source and destination pin code are the same then NIC will give an error if you pass “0”. Error will be “Valid distance to be sent in case of same pin codes, you cannot send 0 as distance in this case.”. You have to pass it as per the actual distance (The number can be between 0 to 100). Similarly, for some pin codes distance between codes is not available on the NIC system and hence one more error may also come as “The distance between the pin codes {0} and {1} is not available in the system, you need to pass the actual distance.” So, taxpayers need to ensure proper distance is being computed and sent in such cases.
  Please note that the distance is validated only in case there is an EWB generation along with E-invoice generation and this validation is done by NIC E-way bill system.

Notes -

• In case of EXPWOP and SEZWOP, Passed IGST Value of Item will not be validated even if actual tax rate is passed, if the passed value of IGST for that is ZERO.
• In case of CREDIT NOTE AND DEBIT NOTE, the ‘IGST/CGST/SGST/CESS value of item’ is not validated with corresponding tax rates and taxable values.
• In the case of Reverse charge and Export transactions (EXPWP), Total value of Item can match with either with tax values or without tax values. That is, the total value of an item can include or exclude the tax values as per the business requirements.
• Invoice Discount is different from Item level Discount and not equal to the total of all item level discounts. Similarly Invoice Other Charges are different than the item level other charges and will never be equivalent to total of Item level other charges.

For all above validations, some tolerance is also allowed as there could be different ways in which different businesses round off each value. Tolerance is defined in such a way that the actual value sent by taxpayer should be between a range determined based on the calculated value as mentioned in below examples:

• Example 1: If the calculated value is any value from 2345.01 till 2345.99, then the actual value allowed is between 2344.00 and 2347.00.
• Example 2: If the calculated value is 2345.00 then the actual value allowed is between 2344.00 and 2346.00

• Duplicate SI numbers are not allowed in line items: There is a field Serial no for each line item that you are required to provide. So, in case you have multiple line items, you have to ensure that all line items have unique Serial nos.
• SHIP TO – state code is not valid to state code for B2B, SEZ and Deemed Export transactions: This error comes when SHIP to state code for supply type B2B/SEZWP/SEZWOP/DE is passed as 96-Other Country. This state code 96 is allowed only in the case of exports.
• IGST on intrastate supply is not applicable to export/SEZ transactions: The field IGST on intrastate supply is added in order to cover those transactions where even though the pos and supplier state code are the same state, IGST is applicable. However, as SEZ and exports are already inter-state, IGST is only applicable, so this flag is not to be sent in such cases.
• Duplicate Request sent: This error comes when you send the same invoice for IRN generation more than once at the same time.
• Duplicate IRN: This error comes when you send an already IRN generated invoice for IRN generation again. Ideally, once you get an IRN you should not be sending the same invoice again. However, it sometimes does happen that IRN gets generated, but you do not get a proper response and hence you resend. When you get a Duplicate IRN and if your IRN is generated today or two days prior then you can fetch the IRN details by doing a GET by IRN. As there are multiple IRPs now, in both below cases while registering IRN for second time Duplicate IRN error will come
  When IRN is generated from IRP 1 and again sent to IRP 1 for IRN generation.
  When IRN is generated from IRP 1 and again sent to IRP 2 for IRN generation

Apart from the above, recently GSTN has also released an advisory which mentions that for the taxpayers having turnover of above 100 Cr., IRN has to be generated within 7 days from the document date. So, if an invoice or a debit note or a credit note is raised today, it should be registered on the IRP portal within 7 days from today. This validation is proposed to be implemented from 1st May 2023.

If the same invoice is being sent repeatedly without solving the error, then it may block the taxpayers from generating IRNs. Hence ensure that you test each scenario and submit error-free data only to IRP. Among all these validations, not forgetting that GSTR1 will also be auto-populated from e-invoices. So, if some validations are present at GSTN but not present in e-invoicing then those too you need to take care or else your invoices may not be auto-populated. Also, it may happen that you have some different business cases, where you are required to send values in a particular manner, however the validations do not allow you to do the same. In such case do write to GSTN/IRP/NIC self-service portal with a proper explanation of the scenario.