Agenda 1. Next Steps for Integration 2. Road map for Integration 3. Queries Received 4. Q&A Challenge: Law/Rules/Formats (rules) are still evolving. GST System keep on getting feeds on proposed changes and based on that, we keep on changing our internal API structure. Publication of changed rules to public takes sometime. So GST System always remain public version+. Though on final release everything will be in sync but before that how to start integration

1. GSP Workshop

2. Agenda
1. Next Steps for Integration
2. Roadmap for Integration
3. Queries Received
4. Q&A

3. Next Step For Integration
Challenge:
• Law/Rules/Formats (rules) are still evolving.
• GST System keep on getting feeds on proposed changes and
based on that, we keep on changing our internal API structure.
• Publication of changed rules to public takes sometime. So GST
System always remain public version+.
• Though on final release everything will be in sync but before
that how to start integration

4. Next Step For Integration
Approach for Integration:
We can divide integration in three steps:
1. Technical Integration:
• GST System will publish API specs based on our internal
version, which we are working on.
• API specs will have some difference in forms attributes and
tables from the published forms.
• GSP/ASP will prepare request JSON based on these
attributes, ignore or fill some dummy data in extra attributes.
• Integrate with our live APIs, which we will publish on
sandbox.
• GSP will established its Architecture and framework for
supporting ASP.
This step will ensure end to end technical integration.

5. Next Step For Integration
2. End to End Integration on Sandbox:
• Once next version of rules are published in public , GST System
will update API specs as per latest rules (As per our current
understanding there should not be big variance with already
published spec)
• GSPs and ASPs can then map its business data with API
attributes and update request JSON structure as per latest API
specs.
• They can test end to end with all business condition
• There may be more changes after next release. We can follow
same cycle till final release of APIs
This step will make ASP/GSP system production ready.

6. Next Step For Integration
3. Integration on Staging/Production:
• GSP will setup MPLS connectivity with GST System.
• Perform Security Audit of application
• Perform Sanity Testing on Staging environment
• Go Live

7. Next Step For Integration
GSP Support Mechanism:
Integration Phase:
1. Queries and clarification through google group (Technical as
well as Business queries)
2. Defects/issues can also be raised through it.
3. Internal defects will be raised and notified to user.
4. New releases on the sandbox will notified through google group
and release notes having id of fixed defects will be released
through developer portal.

8. Next Step For Integration
Go live and Post Go live Phase:
1. Helpdesk
2. Beta releases will keep on happening on Sandbox before
production release and it support mechanism will remain the
same as for integration phase.

9. Roadmap For Integration
• Release of other return API Specification – will publish later.
API Name Specification
Release Date
Sandbox Release
Date
GSTR1 17 Feb 20 Feb
GSTR 2/2A 24 Feb 27 Feb
GSTR3 20 Feb 27 Feb
GSTR 1A 8 March 23 March
Cash Ledger 17 Feb 27 Feb
ITC Ledger 17 Feb 27 Feb
Liability Ledger 17 Feb 27 Feb
Utilize Cash/ITC 8 March 23 March

10. Queries Received
Authentication of ASP:
1. GST System will provide a facility to GSP for creating client-id and secret
for ASP. This will help GSP and GST System to handle ASP better. Same ASP
coming through different GSP will have different client-id and secret. This
client-id and secret will help in first level of authentication.
2. But GSP should do second level of authentication as above attributes are in
header and can be compromised. So they should ideally register an ASP,
provide some credentials/certificate to ensure origin of request and do billing
and other SLA management through it.

11. Queries Received
Cygnet:
1. How many times cycle of filing GSTR 1, downloading of GSTR 2A, uploading
of GSTR 2 and GSTR 1A can be repeated? Is it allowed only once?
•Downloading and Uploading is allowed multiple times for all returns but
filing only once
2. Will GSTR 2 include all the line items including rejected line items and hold
or only accepted items?
•Acceptance/ Rejection and Modification is allowed at invoice level, not on line
item level and GSTR2 will have accepted/rejected and Modified invoices.
3. GSTR 1A would include which all items? Only accepted or modified, added
and rejected items also?
•It will have modified, added and rejected.
4. Does GSP require to provide facility for reconciliation between GSTR 1 and
1A?
•In 1A if GSTR2 is filed first then seller has to accept/reject/modify auto
populated invoices first, so reconciliation will be needed. In case of normal
scenario also for modified and added invoices , one may need reconciliation.
5. What would be time line for release of rest of GSTR and rest modules?

12. Queries Received
Cygnet:
6. If buyer files GSTR2 before seller's filling GSTR1, then seller GSTR1 will be
auto populated and seller has to accept/reject/modify invoices uploaded by
buyer. He can add new invoices also in this. If supplier accept purchaser changes
in GSTR1 A and files GSTR1A. Then those invoices will be considered matched
and become part of GSTR1 of supplier. So after acceptance flow will complete.
Please confirm process if GSTR 2 is filed before filing of GSTR 1
• Covered in Business Process Presentation.
7. Discussion has been going on in implementing the GSP solution in other
Indian languages.
• You are free to provide solution in any language.
8. For storing transaction logs, agreement is saying that we need persist those
data up to 7 years but in google group discussion we have found that up to 3
months and advisable for 6 months. Please let us know the final duration up to
which we need to store transaction logs.
• GST System is required to keep records by 7 years as per law. So GSP will be
required to keep 7 years logs of transaction also but they can keep 6 months
log in hot storage and rest can be on any cold storage but that should be
retrievable in a reasonable time in case required.

13. Queries Received
Cygnet:
9. For transaction logs, as per agreement we need to store http headers, request
and response time stamp along with status (success / failure / timeout etc.), does
this means that we literally need to store so much data for each GSTN api access?
• Yes it be required for you also to do billing and other compliance purposes.
10. What as audit logs we need to store? Can you please elaborate?
• Information like access log of GSP application, changed history, login
attempts etc. to investigate further in case of dispute.
11. As per 7.8 c section of agreement, do we need to delete all the data of taxpayer
which we have stored into GSP system once the transaction gets completed. For
example, we store data for outward invoices for filing GSTR1. So do we need to
delete all these data once GSTR3 gets filed? If yes, how to maintain trail in case of
error or dispute with customer at later date?
• If GSP is only working as pass through and doing buffering or storing it for
retry then it applies.
12. Can you please share all the types of validations / calculations you are going
to apply at GSTN end?
•Rules will have detail for calculation and certain business rule. We will also
provide details of validation, which we are performing at system level.

14. Queries Received
Cygnet:
13. At what level we need to validate taxpayers data while filing GSTR1, GSTR2 and
GSTR3? For example, if taxpayer submits advance tax paid document number in
GSTR1 then do we really need to check that document number exists on GSTN server
or not? OR this will gets validated at GSTN end?
•GST system will validate but as an ASP if you have data, you should validate it to
avoid later errors. This will be the value add of ASP.
14. For reconciliation flow, right now we are assuming that once we get the Auto
populated data in GSTR2A, we need to reconcile those data with purchase register of
tax payer and if user do Accept | Reject | Modify then we need to download those data
from GSTR2A and again need to submit those data along with status while filing
GSTR2.
•When GSP system is reconciling then it will have downloaded data of invoices
along with its hash. In case of accept/reject only hash need to be sent back along
with ITC detail in GSTR2 save api, in case of modify complete data need to be sent.
15. In above context, we are assuming that there is no api from your need which will
allow us to directly submit status like user have accepted / rejected / kept on hold
against invoices. If not then we are correct as per above as need to manually
download this data and submit this data to GSTR2 along with status like A | R | M
•See answer above.

15. Queries Received
IRIS:
1. Return Summary and E-sgin
a. At the time of using the SAVE API, only the data at invoice level or
as required, get saved with GSTN system. Is the return summary (for
the data available) is to be computed and sent as well?
•No, as per current API spec also, GST System is not asking for any
summary.
b. Are GET Summary APIs to be used only when the return is filed? Or
can also be used when the data is saved but not yet filed?
•Get Summary API can be called anytime after data is saved. It will
generate summary based on saved data.
c. Using the GET Summary APIs, it is possible to fetch data from GSTN.
Would this summary be calculated by GSTN for the data available with
them? Or GSTN will send the summary information which tax payer
had submitted?
See answer above.

16. Queries Received
IRIS:
2. Scope / coverage of the API which will validate HSN and rate of
tax.
HSN details along with tax rate will be made available in public
domain. For now, we are not thinking of providing any API.
3. For entities registered with GST, would their registration details
be made available to GSPs
We will provide an API to search a GSTIN.

17. Queries Received
Tally:
1. GSTIN mapping to corresponding VAT TIN or Excise/Service Tax Registration
No.
During migration to GST, hundreds of Supplier/Customer ledgers need to be updated with
GSTIN and support through API will ease the process.
This is under discussion as GST System is not the source of truth for VAT TIN/Service Tax to
GSTIN mapping data. Tax payer has provided this mapping to us and nobody has verified it yet.
2. Individual and Bulk GSTIN validation
Backend check for validity of GSTIN (of all parties participating in return) before uploading or
saving Return and thereby prevent rejection due to GSTIN error.
First API will provide GSTIN status also. For now we will only take single GSTIN in a request.
3. HSN List with applicable Tax Rates, UQC and history
During migration to GST, users can easily update item masters with applicable tax rates.
System assistance to apply the right tax rate to stock items especially in situations of invoicing /
supply and payment dates are different (Time of Supply rules)
Answered already.

18. Queries Received
Tally:
4. Last Modified Time stamp or Running sequence for uploaded transactions
To identify incremental changes and thereby optimize Download bandwidth. An API for ‘last data change for a
GSTIN’. This would allow an application to know when the last ‘change’ was processed by GSTN for GSTR-1 or 2 etc.
for a given GSTIN. Ex: Whenever new GSTR-1 uploads take place, this timestamp would be updated, and a person
can query ‘Last Update Time for GSTR-1 for GSTIN.
We will only provide an API, which will provide list of invoices, which get changed (Auto Populated) by supplier
during a time period.
5. Additional Filter for retrieving Data
Invoice number / Invoice Date based filter to obtain only desired set of filtered data. Obtain filtered set of invoice
data that needs to be actioned (Ex: Original invoice details for a Debit/Credit note, Specific Export invoice for
updating Shipping Bill, Specific invoice details for making amendments). Ex: API to get filtered set of transactions
‘from a time stamp’.
ASP or GSP system will have all such details in their system already. If they want to double check they can call
specific table getAPI for that invoice period and get the data.
6. Checksum Algorithm
Ability to reconcile at summary/section/invoice level and thereby minimize data download and achieve quick
reconciliation. This will allow applications to simply get the ‘summary GSTR-1’ (for example), and compare with the
hundreds/thousands of invoices on the taxpayer system by recomputing the checksum to see if they are ‘the same’,
and only seeking the ‘detailed data’ for specific concern areas.Full details of rules and logic for generation of the
same.
Checksum algorithm will be provide with next release of API.

19. Queries Received
Tally:
7. GSTIN User ID
To have a common user ID and password across multiple GSTIN for a given legal entity
for ease of operations. Ex: A firm in Service industry with pan-India presence will be
required to have 30 User ID and corresponding password.
For now one GSTIN-One Userid.
8. Purchase Invoice visibility.
API support for download of auto drafted purchase invoices on an ongoing basis, even
before 11th of subsequent month so as to reconcile and follow up with suppliers.
Current API also support it.

20. Queries Received
Tally:
9.GSTR Summary
All GSTRs to be summarized at table / section level for easy Checksum
based reconciliation (as against clubbing 3-4 sections into one block)
along with invoice count.
Summary APIs are section/table wise only and invoice count will be
provided.
10. Out of band notifications
E-mail and SMS notifications on success and failures of upload/filing for
effective return experience.
On filing, one will get e-Mail/SMS but not on every save request. ASP can
built it if they want.
11. Electronic Invoice Reference Number
API required for generation and fetching of electronic invoice reference
number (as per Form GST INV-1) from the GST common portal.
Still under discussion.

21. Queries Received
Tally:
12. APIs related: Following information are Critical for closure of design
List of error codes and Field level validations
Error codes will be provided along with some validation.
List of Drop down options (Ex: Reasons for ITC Reversal, Reason for issue of Credit Note,
Return Liability types etc.)
Master will be provided along with API.
Release of pending APIs (GSTR-4 to 11 and Challan, ITC-1 report, TRP registration etc.)
Roadmap will be provided.
Better user experience can be ensured if following changes are incorporated:
• Modify the response of Get APIs to include the ‘Transaction ID’ against a given piece of
data.
We will include transaction id provided by requester in response, so that response can be
co-related by GSP easily. But we are not going to provide Transaction details (which
transaction updated this value last) against each record of a get response.
• Modify the details provided in Get Transaction Status against a given Transaction ID:
Include meta-data with the Transaction ID. Ex: GSP through whom this transaction ID
was received, the date/time when it was submitted.
Same response as above.

22. Queries Received
Cams:
1. OTP message - Is Customization of message allowed?
Not Clear
2.TRP Enrollment - Is there an API planned to return TRP details including validity?
Not Now but can be considered in later releases.
3.Is validations (business rules) in-built in all API exposed by GSTN?
Yes
4.Is ASP authorised to store data pulled from GSTN?
Additionally, GSP is not authorised to store data? How do GSPs handle queries /
questions that may arise.
Please see Agreement clause for it.
5.Is there an API planned for setting session (token) expiry?
No
6.GSTR 1A - Post submission of GSTR2 by (Buyer/Purchaser), will it always reflect as
GSTR 1A irrespective of Modifications/deletions or accepted as it is?
Question not very clear

23. Queries Received
Mind:
1. How GSP will do load balancing while dealing with multiple ASP(s)? Our assumption is
that GSP has no knowledge of data size as far as ASPs are concerned.
Load Balancing can be done without knowledge of data size also. Did not get the
complete context of this question?
2. In case of API calling by ASP for data pushing to GSTN, what will be the encryption
approach. Will it be direct pass thru or some further encryption need to apply? If all
encrypted by ASP, then how GSP will keep track of number of transactions.
3. How throttling need to manage?

24. Q&A