The process of generating e-invoices is not a smooth ride for many. There have been several roadblocks and hurdles in generating IRN successfully – be it through the portal or via GSPs. The reason can be many, however, one which is under your control is taking care of certain reporting aspects at the business level and at the ERP system level for correct e-invoice generation. The data that is to be sent to Invoice Registration portal (like IRIS IRP) is in a JSON (JavaScript Object Notation) format.

In layman terms, in JSON file the data is structured in such a way that each data point has a parameter name and a value for that data point is reported against such parameter name. Two data points are separated with a comma. For E.g.: a simple JSON for your understanding:{“DocDtls”: {“DocNo”: “1090”, “DocType”: “INV”}}

The actual e-invoicing JSON is more detailed than this and can have multiple structures. Each parameter can have a different type of validation rules. The validations are categorized into 4 major buckets for better understanding.

(1) Schema Errors:

A e-invoice schema is usually defined to take care of basic errors in the Json as below:

• 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).

If you are using IRIS GST then these validations are run at IRIS end and even before being sent to IRIS IRP and you can get these validated.

(2) Master Code Errors:

IRIS IRP has a list of master codes for various data points. In order to avoid these errors, you need to clean your masters in the ERP too so that while IRN generation no such error comes.

• HSN Code: Presently, custom set of HSN masters has been updated on the NIC Portal based on custom 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 its valid then you can send the details to the helpdesk for verification at government system end. 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: The pin code should again be as per the master code list and should match with the state code. These Pin code and State code fields are present for the seller, buyer, dispatch from party and ship to party. 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 /Transporter: There is no master list provided for this. However, the GSTIN of counterparty and transporter are validated against the taxpayer and transporter data base maintained by NIC. There could be cases where you get an error message “GSTIN – {0} is invalid.” or “GSTIN – {0} is inactive or cancelled” 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 NIC portal using “Update from GST Common Portal” option on NIC portal. If it’s not valid or its cancelled then you will have to check it with your counterparty/transporter.
• 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 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.

(3) Validations with respect to Values reported:

In the e-invoicing schema as notified by the government, there are many values that are to be reported and for some of those values there are validations added.

Notes:

1. 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.
2. 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.
3. 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.
4. Invoice Discount is different from Item level Discount and not equal to the total of all item level discounts. Similarly Invoice Other Charges is 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

(4) Other Specific Errors:

There are various other validations too, however based on our go-live experience we would like to focus on few of them which were coming very frequently

• 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 no.s.
• 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. In this error IRN no, Acknowledgement no. and date is sent back. 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. So, in such case 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.

You can find the full list of errors on https://einv-apisandbox.nic.in/api-error-codes-list.html

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 to forget 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 case, 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. In our next blog, we will also cover some of these industry specific scenarios.

IRIS ONYX – A Smart E-invoicing Solution!

It is a cloud-based advanced e-invoicing solution that can integrate with your billing systems in multiple ways and help you generate IRN seamlessly without disrupting your current business processes.