Indian E-invoicing

[cosmo83]

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 Solution

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)