Validations in e-Invoicing System

← All Topics
  1. E-Invoice request JSON data has to be validated as per the e-Invoice JSON Schema given in the portal.
  2. Version of the Schema is mandatory and should be latest as per the notified in API portal.
  3. IRN should not be passed as part of the request; it is generated by the e-Invoice system and sent as response.
  4. The following fields should have one of the values given in the master codes.
  5. Supply Type of Transaction
  6. Document Type
  7. 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.
  8. Document number should not be starting with 0, / and -. Also, alphabets in document number should not have alphabets in lower cases. If so, then request is rejected.
  9. Supplier should ensure that the unique invoice number is being generated for the financial year for each invoice, in his ERP/manual system. For the purpose of the financial year, the date of invoice is considered. The financial year starts from 1st April and ends on 31st March.
  10. 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.
  11. e-invoice(IRN) cannot be re-generated for the cancelled e-invoice(IRN) also.
  12. IRN cannot be cancelled, if the Valid/Active E-way Bill exists for the same.
  13. Request for the IRN/e-Invoice can be made only by the supplier of the goods or services.
  14. 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.
  15. In case the supplier is SEZ unit, then he cannot generate e-Invoice.
  16. The Document Date can be yesterday or today’s date.
  17. ‘Reverse Charges’ can be set as ‘Y’ in case of B2B invoices only and tax is being paid in reverse manner as per rule. Even in case of Reverse Charged invoices, the seller has to generate the IRN.
  18. Recipient GSTIN should be registered and active. In case of transaction of direct export, recipient GSTIN has to be URP and state code has to be 96.
  19. In case, Buyer is SEZ, the Bill to State code should be 96.
  20. PIN Codes are validated against the States, they belong to.
  21. If ‘Shipping party’ is provided, then the transaction is considered as ‘Bill To-Ship To’.
  22. If ‘Dispatching party’ is provided, then the transaction is considered as ‘Bill From – Dispatch From’.
  23. If Shipping and Dispatching parties are provided, then the transaction is considered as ‘Combination of Both’.
  24. In case of export transactions, the ‘Ship-To’ address should be of the place/port from where the goods are being exported.
  25. In case of Goods, the state code of the Seller GSTIN and state code of the Buyer GSTIN will decide whether the supply type is Interstate or Intrastate. That is, if the State code of Seller and buyer is same, then it is intra-state, otherwise it is inter-state.
  26. In case of Services the state code of the Seller GSTIN and state code of POS will decide whether the supply type is Interstate or Intrastate. That is, if the State code of Seller and state code of POS is same, then it is intra-state, otherwise, it is inter-state.
  27. In case of Exports, the supply is always Interstate whether Goods or Services.