Frequently Asked Questions
Presently, IRN can be generated only by the tax payers who have been notified. That is, tax payers whose turnover is more than Rs. 500 Crores.
All APIs have to be tested on the sandbox environment. Each API with at least 50 success cases and 50 failed cases with different errors to be tested.
The asymmetric algorithm (RSA/ECB/PKCS1Padding) and symmetric algorithm
AES256 (AES/ECB/PKCS5Padding) along with SEK is used to encrypt the request
payloads of the POST API methods and to decrypt response payloads. It may be
noted that SEK is generated and passed by the e-invoice system while sending
the authentication token.
- Signing of invoice is required by the rules notified by the Government of India. A placeholder for digital signature has been added in the e-invoice schema and hence if a signed e-invoice is sent to IRP, the same will be accepted.
- The e-invoice will be digitally signed by the IRP after it has been validated. The signed e-invoice along with QR code will be shared with creator of document as well as the recipient.
- Once it is registered, it will not be required to be signed by anyone else.
- There will NOT be a place holder provided in the e-invoice schema for the company logo.
- This is for the software company to provide in the billing/accounting software so that it can be printed on his invoice using his printer. However, the Logo will not be sent to IRP. In other words, it will not be part of JSON file to be uploaded on the IRP.
As of now, there is no change in the generation of e-way bill process. It will exist along with the e-invoice system. There will be additional facility in future to generate the e-way bill based on the IRN.
Yes, there will be one more API, released shortly, to generate the e-way bill based on IRN and Part-B details.
As of now, the criteria for e-Invoice is turnover greater than 500 crore. There will be government notifications on the change in eligibility criteria.
Yes, there will be offline tool and web portal.
There is no need for whitelisting the IPs to test on the Sandbox.
Testing can be done using GSPs virtual GSTINs for different states.
E-invoice system is using the email id and mobile number, registered by the taxpayer on the GST Common Portal, for communication purpose.
If it is old, get is updated with latest on the common portal and communicate to us at 
so that we can cross-verify and update on the sandbox for accessing the credentials.
If you are a GSP, then get it updated with GSTN and request them to communicate to us so that it can be updated.
so that we can cross-verify and update on the sandbox for accessing the credentials.
If you are a GSP, then get it updated with GSTN and request them to communicate to us so that it can be updated.
There are two types of API credentials – Client Id and Client Secret, and Username and Password. Client Id and Client Secret is provided to the notified tax payer and the tax payer can use it for all the business units registered in different states, based on the same PAN.
Whereas the Username and Password is created for each GSTIN. That is, one business, registered in different states, need to create separate username and password for each registered unit/GSTIN.
Make sure you use the email id and mobile number entered by you in the GST portal.
Presently it is activated only for GSTINs with turnover more than 500 crore. In case you come under this category, contact GSTN.
GSP and tax payer can get the API credentials using the online registration option under ‘Login’ system on this portal.
On logging into the testing portal, one can get the end points of APIs for sandbox system.
On logging into the testing portal, one can get the public key of the e-invoice system for sandbox system.
It is not advisable to request for new token before firing each transaction. Once the token is generated it can be re-used any number of times till it get expired.
Even if new request for token is made, the system returns the already generated valid token with an expiry time.
The best practice is, once the token is generated, store in the tax payer system along with SEK and expiry time. Next, whenever the transaction request is made, token can be referred from the system and used. If it has expired, then request for new token and store and use it.
It is not advisable to send the same request or same transaction continuously or multiple times. However, based on the response of the transaction, the tax payer system to act upon rather than firing again. If it happens so, then the e-invoice system will block that user’s requests for one hour and so.
ForceRefreshAccessToken parameter of Authentication API can be used by the tax payer system to generate the new token, just 10 minutes before the expiry of the token. Basically, the tax payer system can use it to avoid failure of the transaction fired after expiry of the token.
Authentication token generated by the e-invoice system is valid for 6 hours on the production system. However, for effective testing by the developer, it has been set for 1 hour in the sandbox.
Appkey is generated by the API consuming application. It is a 32 byte AES key.
In case the tax payer is using the API through GSP, the GSP will provide the ClientId and ClientSecret to the tax payer.
GSP will not have the taxpayer’s user id and password. On the production environment (when made available), if the taxpayer has generated the token using a set of credentials (client Id, GSTIN, user Id, password) using one system, then same token can be used for calling other system API. In Sandbox, the credentials are different for each service.
App key should be byte array (byte[ ]) of 32 bytes length e-invoice API.
Same App Key that was sent in auth request only needs to be used to decrypt the SEK that has come as the response to the API call using Symmetric AES algorithm.
Please log in to https://einv-apisandbox.nic.in/einvapiclient/ using your generated credentials. To the right side, you will get an option to download the public keys.
- The IRN (hash) will be generated by IRP (register) using GSTIN of supplier or document creator, financial year and the unique serial number of the document/ invoice along with the document type.
- The serial number of invoice must be unique for a GSTIN for a Fin Year and the same has to be captured by Supplier’s ERP.
- Supplier has to keep the IRN against each of its invoice, once received by the seller from the IRP. It will be advisable to keep the same in the ERP as invoice without IRN will not be a legal document.
- The mandatory fields are those that MUST be there for an invoice to be valid under e-Invoice Standard.
- The optional ones are those that may be needed for the specific business needs of the seller/business. These have been incorporated in the schema based on current business practices in India.
- The registration of an e-invoice will only be possible once it has ALL the mandatory fields uploaded into the Invoice Registration Portal (IRP).
- An optional field not having any value can be reported with null or can be omitted from the payload.
Please check whether the encryption is happening correctly using the decrypted SEK. You may use the facility in the developer test portal where you can encrypt the same payload using the decrypted SEK and compare the encrypted output from your function with same payload and SEK.Make sure you have decrypted the SEK received using the App key using symmetric algorithm before using the same as key for encryption.
The details are provided in the API documentation along with sample code in C# and Java at https://einv-apisandbox.nic.in/
The response is encrypted using the SEK using symmetric algorithm, so please decrypt using the SEK.
e-Invoice will have 1000 line items, and when the e-way bill generated from it, e-way bill have high value 250 items with total invoice value. This is followed in current e-way bill system also.
Just generation of IRN is not the goal of the e-Invoice system. Registering the invoice with the IRP is the actual requirement (Given the logic of generation of IRN, anybody can generate it, but unless it is registered, it has no authenticity).
As the IRP anyway has to generate the IRN (atleast to check whether tax payer generated IRN is correct), there is no need to generate IRN by tax payer.
- The QR code will be provided to the seller once he uploads the invoice into the Invoice Registration system and the same is registered there.
- Seller must print the QR code on the printed Invoice.
The data is signed using JSON Web Signature, details can be obtained from the web. The signed token has 3 parts, header, data and signature, these three are separated by (dot).
After splitting the 3 parts, you can decode the first 2 parts of content with base64 decode.
There will be provision to validate the QR code off line, as well as there will be facility to upload the signed QR code to the portal and get it verified.
Details will be shared later.
To verify the signed Invoice and the QR code, the public key of the certificate which is used to sign is required.
This public key is same as that has been used for encrypting the password and App key.
The key for sandbox environment is available for download in the e-Invoice sandbox API developer's portal.
Signed QR Code data, passed as the response of IRN generation, has to be
printed along with the signature on the invoice. You can see these QR code on
the web version of e-invoice system that is, going to be released shortly.
As of now, in the trial, there is no version number. In future, version number would be part of the end point for subsequent versions.
For production, access is allowed only through the white listed IP addresses of India.