Validations in System
E-Invoice request JSON data has to be validated as per the e-Invoice JSON Schema given in the notification.
‘Version’ attribute in the Schema is mandatory and should be latest as per the latest notification. Presently it should be passed as ‘1.1’.
IRN should not be passed as part of the request; it is generated by the e-Invoice system and sent as response.
The attributes in the JSON schema have been defined with column length, format and data types. Where-ever the data format is not defined for the attribute having data type as string, then for these attributes, the alphanumeric and special characters are allowed except the special characters “ (double quote) and \ (back slash).
The following fields should have one of the values given in the master codes.
Supply Type of Transaction
Document Type
The category of transaction of "Business to Consumer (B2C)" invoices will not be considered and hence the API interface should not request for IRN for these transactions.
Document number should not be starting with 0, / and -. If so, then request is rejected.
IRN requests with Document Date from 01/10/2020 only will be accepted and processed for IRN generation. IRN requests belonging to previous dates will be rejected.
Supplier should ensure that the unique invoice number is being generated for the financial year for each invoice, in his ERP/manual system. The financial year is derived from the date of invoice. The financial year starts from 1st April and ends on 31st March.
Duplicate IRN requests are not considered. That is, if the IRN is already generated on particular type of document and document number of the supplier for the financial year, then one more IRN cannot be generated on the same combination.
e-invoice(IRN) cannot be re-generated for the cancelled e-invoice(IRN) also.
Request for the IRN/e-Invoice can be made only by the supplier of the goods or services.
In case of e-commerce transactions, the e-Commerce Operator can request for the IRN/e-invoice on behalf of the supplier. In this case, the e-Commerce Operator should have been registered on the GST portal as e-Commerce Operator and pass eCom_GSTIN accordingly.
In case the supplier is SEZ unit, then he cannot generate e-Invoice.
"Reverse Charges" can be set as "Y" in case of B2B and SEZ invoices only and tax is being paid in reverse manner as per rule. Even in case of Reverse Charged invoices, the Supplier has to generate the IRN.
Recipient GSTIN should be registered and active, on the date of preparation of the document by the supplier.
In case of transaction of direct export, recipient GSTIN has to be URP and state code has to be 96, PIN code should be 999999, POS should be 96.
In case of GSTIN of supplier or recipient belonging to state of ‘OTHER TERRITORY’ (with state code as 97), then PIN code can be 999999.
First two digits of the Supplier / Recipient GSTIN should match with the state code passed in the Supplier / Recipient details accordingly except if supply type is exports wherein Recipient state code will be 96.
PIN Codes are validated against the States, they belong by matching the complete pincode against state master. If the PIN Code does not exist in the master database of the e-invoicing system, and the first 3 digits of the PIN code is matched with the State as per the pattern of PIN code-to-State mapping defined by postal department, then IRN gets generated.
If "Shipping party" is provided, then the transaction is considered as "Bill To-Ship To".
If "Dispatching party" is provided, then the transaction is considered as "Bill From " Dispatch From".
If both Shipping and Dispatching parties are provided, then the transaction is considered as "Combination of Both" (Bill From - Dispatch From and Bill To- Ship To).
In case of export transactions for goods, if e-way bill is required along with IRN, then the 'Ship-To' address should be of the place/port in India from where the goods are being exported. Otherwise E-way bill can be generated later based on IRN, by passing the 'Ship-To' address as the place/port address of India from where the goods are being exported .
In case IGST on intrastate supply, tax rates and tax values related to IGST should be passed, and Supplier state code and POS state code should be same.
The state code of the Supplier GSTIN and POS will decide whether the supply type is Interstate or Intrastate. That is, if the State code of Supplier and POS is same, then it is intra-state, otherwise it is inter-state. However, IGST on intrastate supply attribute will overrule this condition.
In case of Exports and SEZ, the supply is always Interstate
JSON payload size cannot exceed 2MB.
Validations on Items:
Serial number of the item can be only numeric & is verified for duplicate values.
Each item needs to have valid HSN code with at least 4 digits. HSN Code should be valid as per the GST master.
If Is_Service is selected, then the HSN codes must belong to services.
Each item should have valid Unit Quantity Code (UQC) as per the master codes, in case of goods.
Quantity and Unit Quantity Code are mandatory for Goods and optional for Services.
Tax rates are being validated. Only the allowed tax rates will be accepted for all types of document including Credit Note and Debit Note. In case of intra-state transaction, the sum of SGST and CGST tax rates should be entered as GST Rate.
In case of inter-state transaction, the IGST tax rate and value has to be passed.
In case of export transaction, IGST tax rate and value has to be passed.
In case the Recipient is SEZ unit, then IGST tax rate and value has to be passed irrespective of state of the Recipient.
Maximum number of items in each invoice should not exceed more than 1000 items and a minimum of 1 item should be available.
Calculation of Values:
The following summation validations are to be done for items
Taxable Value of Item = Gross Amount of Item - Discount
SGST Value of Item = Taxable Value of Item X GST Rate / 2, if intra-state CGST Value of Item = Taxable Value of Item X GST Rate / 2, if intra-state
IGST Value of Item = Taxable Value of Item X GST Rate, if inter-state
Cess Value of Item = Taxable Value of Item X Cess Rate
State Cess Value of Item = Taxable Value of Item X State Cess Rate
Total Value of Item = Taxable Value of Item + SGST Value of Item + CGST Value of Item + IGST Value of Item + Cess Value of Item + State Cess Value of Item + Non-Advol Cess Value of Item + State Cess Non-advol value of Item + Other charges.
However, in 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 item can include or exclude the tax values as per the business requirements.
(Note: Temporarily, the validation of 'Gross Amount of Item with Quantity and Selling Unit Price' has been withdrawn.
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.)
The following summation validations are to be done on Invoice total
Total Taxable Value = Taxable Value of all Items
Total SGST Value = SGST Value of all Items
Total CGST Value = CGST Value of all Items
Total IGST Value = IGST Value of all Items
Total Cess Value = Cess Value of all Items + Non-Advol Cess Value of all Items
Total State Cess Value = State Cess Value of all Items + State Cess Non-advol Value of all Items
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.
Tolerance limit for points 1 and 2 above: The passed value should be between minimum and maximum values as explained here. Minimum value is considered as the rupee part of the calculated value minus one rupee and maximum value is taken as the rounded up to next rupee value of the calculated value plus one rupee.
Example 1: In Point 1 and 2, if calculated value for IGST of item A is 2345.04 then tolerance limit for passed value of that item is between 2344.00 and 2347.00.
Example 2: In Point 1 and 2, if calculated value of IGST of all items is 10241.00 then tolerance limit for passed value of IGST of all items is between 10240.00and 10242.00
The round-off value for 'Round_off_amount' attribute is to adjust final 'Total_Invoice_Value_INR' attribute and can be between -99.99 and +99.99
The following summation validation is to be done on Invoice total
Total Invoice Value = Sum of All Total Value of Items - Invoice Discount + Invoice Other charges + Round-off amount
Tolerance limit for point 5 above: The passed value should be between minimum and maximum values as explained here. Minimum value is considered as the rupee part of the calculated value minus one rupee and maximum value is taken as the rounded up to next rupee value of the calculated value plus one rupee.
Example : If ‘calculated total invoice value’ is 10241.61 then tolerance limit for ‘passed total invoice value’ is between 10240.00 and 10243.00
Validations on e-waybill:
E-waybill can be generated only if E-way Bill related details are passed where distance is mandatory.
E-way Bill is not generated for document types of Debit Note and Credit Note and Services.
E Way Bill can be generated provided at least HSN of one item belongs to goods.
If only Transporter Id is provided, then only Part-A is generated. Transport Mode, Vehicle Type, Vehicle No, Transportation document number and date should be null or attributes should not have been passed.
If mode of transportation is "Road", then the Vehicle number and vehicle type should be passed. If mode of transportation is Ship, Air, Rail, then the transport document number and date should be passed. Vehicle type and vehicle number should be null or attributes should not have been passed.
The Vehicle no. should match with specified format and exist in Vahan database.
E-Waybill will not be generated if the Supplier or Recipient GSTIN is blocked due to non-filing of Returns.
Pincode of Recipient GSTIN is mandatory if Ship-To details are not entered.
The distance of transportation is validated against the auto-calculated PIN-PIN distance stored in the system. The allowed distance for transportation should be between +/- 10 % of auto-calculated PIN-PIN distance. If the auto-calculated distance is less than 100 KMs, then The allowed distance for transportation should be between 1 and +10 % of auto-calculated PIN-PIN distance.
If the distance of transportation is passed as 0 (zero), then the system will consider it as request made by the tax payer, to consider the auto-calculated PIN-PIN distance for the generation of e-way bill and generate the e-way bill along with IRN. The actual distance is passed in “Info. Message” column for reference.
If the PIN-PIN distance is not available in the system, the passed value of distance will be taken for generation of e-way bill and distance value can not be more than 4000.
The actual distance has to be passed in case the source and destination PIN codes are same and the allowed range of value is from 1 to 100.
In case of export of goods, if e-way bill has to be generated, then the address of port should have been passed as shipping address during generation of IRN.
In case incomplete information has been passed for generation of E Way Bill, then IRN will be generated and returned but not E Way Bill number. However subsequently, based on IRN, E Way Bill can be generated.
Comments