The Govt of India has made it mandatory for companies which have an annual turnover of greater than 500Cr. to implement E-invoicing system, where every invoice you create in your ERP system has to be reported to the government. In additional to E-invoicing the E-Way bill is also clubbed in this process, which requires the deliveries to be associated with a valid electronic document
The IRP(s) (Invoice Registration Portal) provides the API in two ways
Through Internet
Through GSP(s) (GST Suvidha Providers), who are connected right now through Internet, but in future proposals for MPLS connections are in place.
The API provided by the IRP(s), is the same and it involves multiple security mechanisms, like Token Generation, RSA / AES Encryptions.
Authentication Flow
The following depicts the Authentication flow from the Tax Payer to IRP.
-> Request Header:
client_id : client id to be provided by E-Invoice System
client_secret: client secret to be provided by E-Invoice System
-> Request Payload:
Username: Username of Tax payer as created on E-Invoice portal for API Integration
Password: Encrypted Password with Public Key(RSA) provided by Einvoice
AppKey: Randomly Generate 32 character random unique id encrypted with Public Key (RSA) provided by Einvoice
ForceRefreshAccessToken: true / false . Mostly set to false in our case
-> Response Payload: (Listing the important ones)
Status: Status of the authentication request(values 1-Success and 0- Failure)
AuthToken: Authorization token
Sek: Session Encryption Key generated using AES 256(AES/ECB/PKCS7Padding) algorithm. Encrypted () with AppKey
(Needs to be decrypted for further use)
If there are errors they are reported, in simple text.
Service Flow
The following API services are available for consumption
-> Generate IRN (POST Service)
-> Generate EWB (POST Service)
-> Cancel EWB (POST Service)
-> Cancel IRN (POST Service)
-> IRN Info (GET Service)
-> GSTN Info (GET Service)
All the services though follow the same data flow
-> Request Header:
client_id : client id to be provided by E-Invoice System
client_secret: client secret to be provided by E-Invoice System
Gstin: GSTIN of the authenticated user
user_name: User name of the authenticated user
AuthToken: Authentication token returned by the E-Invoice system
-> Request Payload: Data:
Encrypted JSON using SEK generated during Authentication
-> Response Payload: Data:
Encrypted JSON . Needs to be decrypted using SEK
The Problem Statement Since the data flow provided by the Government involves lot of encryption, decryption it is required for your ERP system to provide the same. Most of the modern ERP systems might not have all the functionality of the encryption / decryption mechanisms, for example SAP uses either CPI or PI/PO to get the functionality of Authentication Token, RSA and AES Encryption to be processed.
Some of the GSP(s) provide the same API provided by the government, and might simplify things by requesting for text based JSON(s) and makes things simple. The GSP(s) also store the data on their systems , which can be used for further reporting. This can be both advantageous and dis-advantageous because now that the data is being stored by a third party (Other than you and the government), you need to worry about another point of your Enterprise data being leaked.
The E-invoice Bridge is a Docker Container based image, which provides a REST based service to bridge the services provided by the government. The input to the service is provided as JSON with the same schema provided by the government. The handling of the Authentication Token, the encryption, decryption is all handled by the bridge and provides a simple API interface to the ERP.
No Data is stored on the system, which means the data is stored in your ERP system and then at the Govt. Since the call is a HTTPs based synchronous call, there is not need of maintaining the data in a queue.The data provided by the ERP is validated with a JSON schema, and then forwarded to the service. We have also simplified the services, so that authentication and calling of the services are merged in one single call.
The Bridge is available in Docker fomat, and can be established within your SAP Application Server, and also can be maintained automatically (Updates to the Container), with a pull from the Docker HUB. (https://hub.docker.com/r/cosmo83/sateinvapi)