Report of the Joint Committee on Business Processes for GST- Payment

INTRODUCTION

During the Empowered Committee meeting held on 10th March, 2014, it was decided that a Joint Committee under the co-convenership of the Additional Secretary (Revenue), Government of India and the Member Secretary, Empowered Committee should be constituted to look into the Report of the Sub-Group-I on Business Processes for GST and make suitable recommendations for Payment and Return to the Empowered Committee. Accordingly, a Joint Committee, in consultation with the Government of India, was constituted on 7th April, 2014 (Annexure-I). The Committee held its deliberations on 28th October, 2014, 12th November, 2014, 25th November, 2014, 22nd December, 2014, 2nd and 3rd February, 2015, 19th and 20th February, 2015 and 16th and 17th April, 2015.

2. The Joint Committee on Business Processes for GST held on 2nd February, 2015, it was decided to constitute a sub-committee on GST Payment Process. Pursuant to that decision, the Member Secretary, Empowered Committee constituted the Sub-Committee vide his memorandum letter dated 3rd February, 2015 (Annexure-II). Shri V Rajendaran, DG (Government Accounts), CAG, Mrs. Krishna Tyagi, CCA, CBEC, Government of India, Shri Madan Mohan, Jt. CGA, Government of India and Shri G Sreekumar, CGM, RBI were co-opted as members of the Sub-Committee. Shri Ravneet S. Khurana, Deputy Commissioner GST Cell, CBEC also participated in the deliberations of the Sub-Committee. The Sub-Committee met in Bengaluru on 14th and 15th February, 2015 and on 06th and 7th April, 2015. The Sub-Committee also exchanged drafts on emails during the interregnum period. The Sub-Committee submitted its final report on 10th April, 2015.

3. The report of the Sub-Committee was discussed in the meeting of the Joint Committee of Business Processes held in Delhi on 16th and 17th April 2015 and was accepted with certain modifications. The meeting of the Joint Committee was attended by the officers as listed in Annexure III.

4. In modern day taxation regime, every transaction of the tax payer with the tax administration should be transparent, responsive and simple. It has been experience of tax administrations that more the system and procedures are made electronic more is the efficiency of tax administration and greater is the satisfaction of taxpayer. In this context, payment system of GST should also be based on Information Technology which can handle both the receipt and payment processes.

b) Need for a uniform system of banking arrangements for collection, remittance and reporting of GST to both Central and State Governments;

c) Proper accounting and bank reconciliation of taxes derived from basic data of payments made by taxpayers to banks, with the required classification of heads of accounts indicated on the Challan;

d) Designing the format of a new Challan for use by the taxpayers paying GST;

e) Developing a detailed accounting procedure common to both Central and State Governments for GST, covering all relevant aspects of payments, accounting and related banking arrangements.

6. It is noted that under GST regime, some taxes and duties may remain outside the purview of GST and will continue to be collected in the manner prescribed under existing accounting procedures/rules/manuals, etc. This means that two types of challans (one for GST and other for non-GST) will be used and accounted for by the respective Pay and Accounts Offices (PAOs)/State AGs.

7. The payment processes under proposed GST regime should have the following features:

a) Electronically generated challan from GSTN Common Portal in all modes of payment and no use of manually prepared challan;

b) Facilitation for the taxpayer by providing hassle free, anytime, anywhere mode of payment of tax;

c) Convenience of making payment online;

d) Logical tax collection data in electronic format;

e) Faster remittance of tax revenue to the Government Account;

f) Paperless transactions;

g) Speedy Accounting and reporting;

h) Electronic reconciliation of all receipts;

i) Simplified procedure for banks;

j) Warehousing of Digital Challan.

8. With the above features in mind the following three modes of payment are proposed:

a) Payment by taxpayers through Internet Banking through authorized banks and through credit card/debit card;

(Section 45 of RBI Act, 1934 permit banks other than RBI to be appointed as agency banks for carrying out government business. Agency banks are permitted to both receive and make payments on behalf of the Government and therefore act as Banker to respective governments. However, authorized banks are only permitted to receive payment of GST on behalf of the Government, and keeping this distinction in view, the expression ‘authorized bank’ is used throughout this Document.)

b) Over the Counter payment (OTC) through authorized banks;

c) Payment through NEFT/RTGS from any bank (including other than authorized banks).

9. Mode of payment described at b) above will be available for payments up to ₹ 10,000/- per challan only. Model GST law may have suitable provisions in relation to this. However, there should not be any IT system constraints for this i.e. the systems should be able to receive payments through all three modes irrespective of the amount. Other means of payment, such as payment by book adjustment as is presently being allowed by Government of India to some departments / State governments or payment by debit to export scrips, while paying tax would not be allowed. It is also noted that all taxpayers under Centre are paying taxes electronically and possibly the same situation exists in some State Tax administrations. It is desirable that under the GST regime, all taxpayers should gradually move to internet payment over an indicative time frame.

10. The Committee recommends that RBI should play the role of an aggregator through its e-Kuber system. Such role will facilitate participation of larger number of banks in GST receipts enhancing convenience for the tax payers and provide single source of information for credit of the receipts to Government accounts and thereby simplifying accounting and reconciliation tasks. In case of any discrepancy found during the reconciliation by the Accounting Authorities, they would directly interact with RBI. Joint CGA suggested that as per the provisions of Section 20 of the RBI Act, 1934 in the proposed scenario, RBI would be the sole banker to the Governments. RBI, on the other hand, has indicated that Section 20 and Section 45 of the RBI Act, 1934 are not mutually exclusive and therefore there would not be any conflict in the role envisaged for the RBI in the proposed model.

11. Each of the above modes is discussed separately along with the role of stakeholders involved, process of reporting, accounting and reconciliation of data. As already mentioned above, it is envisaged that for each mode of payment, the challan will be generated electronically at the GSTN and no manual challan will be used under any mode of payment.

I. PAYMENT BY TAXPAYERS THROUGH INTERNET BANKING THROUGH AUTHORIZED BANKS AND THROUGH CREDIT CARD/ DEBIT CARD:

12. With increasing spread of internet and electronic communication, this mode has emerged as one of the preferred modes of tax payment for both the taxpayers and administrators. As the name suggests, this mode of payment involves payments by the taxpayers that utilize the electronic network, right from the generation of the challan by the taxpayer to the ultimate reconciliation of the data by the Accounting authorities. Before understanding the process involved in e-payments, it is important to list the stakeholders involved in this mode of payment. The following stakeholders will pay a key role in establishing an effective e-payment network in the proposed GST scenario:

13. Every tax payer who wants to avail the facility of e-payment will access GSTN for generation of the Challan through which payment is to be made. The following methods for creation of draft challan for GST payments are recommended:

a) By Registered tax payer or his authorized person by logging on to GSTN Common Portal where basic details (such as name, address, email, mobile no. and GSTIN) of the tax payer will be auto populated in the challan;

b) By authorized representatives of tax payers by logging on to the GSTN Common Portal whereafter the list of registered taxpayers represented by him will be displayed. He can select any tax payer on whose behalf he proposes to pay GST and challan details for such tax payer will be auto populated;

c) By grant of temporary Registration number by any one Tax authority on GSTN Common Portal which can be used by both the tax authorities for facilitating tax payments on behalf of an unregistered person. Such a situation can arise during enforcement action by a tax authority and this temporary registration can be later converted into a regular registration number (GSTIN) if the tax payer has a regular GST liability to discharge after the enforcement action (detailed procedure described in Para 78 below);

d) By creation of a challan without requirement of USER ID and Password, for enabling payment of GST by a registered or an unregistered person on behalf of a taxpayer as per the directions of the tax authority using the GSTIN (like the present provision under Service tax). In this method, GSTN would provide for a validation check (like CAPTCHA) so that challan can be created by a person and not by machine.

14. The issue whether challans should have provision for entering jurisdictional location ( e.g. Commissionerate, division and range) was discussed in detail and it was decided that the same will not be mentioned in the challan. Instead, the Tax authorities would send the Taxpayers updated master data to GSTN as well as to Accounting Authorities. The incremental changes in the said master would also be sent on real time basis by the Tax authorities to GSTN and Accounting authorities. As challan would not have a jurisdictional location code, the Accounting Authorities would use the TAXPAYER Master received from Tax authorities for mapping the challans with the Jurisdictional PAOs / tax authorities’ offices by having a suitable mapping mechanism.

15. Upon creation of the draft challan, the taxpayer will fill in the details of the taxes that are to be paid. The challan page will have sets of mandatory fields, which the user has to provide. The tax payer will have the option to pay CGST, IGST, Additional Tax and SGST concurrently. The tax payers can partially fill in the challan form and temporarily “save” the challan for completion at a later stage. A saved challan can be “edited” before finalization. After the tax payer has finalized the challan, he will generate the challan, for use of payment of taxes. The remitter will have option of printing the challan for his record. The challan so generated will have a 14-digit (yymm followed by 10-digit) Unique Common Portal Identification Number (CPIN), assigned only when the challan is finally generated, this will help the portal and other authorities in identifying the challan. The CPIN would be a running serial number to be initialized every calendar month. After the challan is generated, it will be frozen and will not be allowed to be modified. The CPIN/challan so generated would be valid for a period of seven days. In case of payment through Mode III, CPINs would remain live with RBI for a period of 30 days. GSTN would purge all unused CPINs on the day immediately after the date on which the validity period is over (i.e. 7 days if Mode I or II is selected and 30 days if Mode III is selected for payment). At the end of each day (EOD), GSTN would send all the CPINs generated on that day to the Accounting authority of the Centre and to those accounting authorities of the states that so desire. The suggested format of the challan is appended at Annexure – IV which is a common format for all three modes of payment. Since the challan would be prepared electronically, chances of errors will be minimal. However to deal with challan correction in exceptional circumstances, a challan correction mechanism, prepared in consultation with the office of Pr. CCA, CBEC is detailed in paras 123 and 124 below.

16. Since there are three modes of payment, the tax payer has to choose the e-payment mode. This mode will also cover payment by Credit/Debit Card which can be used only after log in on the GSTN.

17. Once e-payment mode is selected, options will be shown to taxpayer to choose between Internet Banking and Credit / Debit Cards for making payment. In case Internet Banking mode is selected, a field with drop down box detailing names of various authorized banks, registered with GSTN for Internet Banking, would be displayed. The taxpayer will have option of choosing his preferred bank for Internet Banking. Credit and Debit Cards of all banks shall be accepted. However, the payment gateway services should be obtained by GSTN from the authorised banks or their payment gateway SPVs only. To encourage competition, preferably more than one such gateway should be provided on the GSTN portal, with display of their respective charge rate and service performance level. The taxpayer can choose any of the gateways available on the portal for making the payment. The exact charge should be calculated separately by the gateway service provider. The gateway provider should collect this amount separately over and above the challan amount. The challan amount should be fully credited to respective Government accounts maintained with the authorised bank (acquiring bank for CC/DC payments), while the gateway charges should be retained back by the gateway provider. The Government/GSTN should procure the payment gateway services from the authorised banks (or their SPVs) through an appropriate competitive process to keep the charge rates low. The Committee also deliberated the issue of charge back claims in case of credit card based payment, and felt that the possibility of such claims on payments to the government is minimal and manageable, especially in view of implementation of two-step authentication norm by the banks. In addition, the taxpayer would be required to pre-register his credit card, from which the tax payment is intended, with the GSTN system. GSTN may also attempt to put in a system with banks in getting the credit card verified by taking a confirmation from the credit card service provider. The payments using credit cards can therefore be allowed without any monetary limit to facilitate ease of doing business. In the event of such claims, recommended standard operating procedure, prepared in consultation with RBI, is enclosed as Annexure-V.

18. In case of Payment Gateway, the first choice for a taxpayer would be to select the card type to be used for making the payment. Upon choosing the card type, the taxpayer would be displayed available gateway service providers servicing the card type. Once a taxpayer chooses a gateway, the interface of the gateway would be invoked. Alongside, GSTN will forward the same electronic string as was passed for Internet Banking (details in para 19 below). The service provider will capture and verify the card details and debit the challan amount and additional gateway charges from the card holder. The Payment Gateway service providers are expected to build their interface with GSTN common portal to capture challan amount breakup in terms of CGST, IGST, Additional Tax and SGST. Along with the interface, associated accounts for CGST, IGST, Additional Tax and state-wise accounts for SGST should be created by the Authorized banks associated with the gateway service providers. The breakup received from GSTN common portal will be used to credit the amounts received under respective accounts created for the purpose. The Committee noted that in respect of credit card payments, presently the acquiring bank is permitted to transfer the amount to the merchant on T+3 basis. Thus there may arise some situations where the taxpayers account has been debited on T+0 basis whereas Government’s account in authorised bank would be credited on T+3 basis. It was informed by RBI that this time could be reduced to T+1 basis by suitable negotiations with the payment gateways. It is recommended that suitable negotiations may be carried out by the Accounting authorities and RBI with payment gateways to credit the amount on T+1 basis.

19. In case of payment through Internet Banking, once the taxpayer chooses a particular bank for payment of taxes, GSTN will direct him to the website of the selected bank. Alongside, GSTN will forward an electronic string to the selected bank carrying the following details for each challan on real time basis:

a) GSTIN;

b) CPIN;

c) Challan Amount;

d) Break Up of the Amount into CGST, IGST, Additional Tax and SGST ;

e) State/UT Government to which SGST remittance pertains.

GSTN in consultation with banks would decide about the requirement of merchant code as a GSTN identifier.

20. Taxpayer will make the payment using the USER ID and Password provided by the bank to enter into the secured e- banking area of his bank. He will select an account for debiting the total tax amount and authorize the payment. While making the payment, the bank will display the breakup of total amount payable into CGST, IGST, Additional Tax and SGST and seek confirmation from the user. No change in the break up as well as the total amount would be allowed on the Bank’s portal. In case the user wants to change the break up or the total amount, he should abort the transaction and go back to GSTN portal from the bank’s portal and reinitiate the process.

21. After the successful completion of a transaction, e-FPB of the concerned bank will create a unique Challan Identification Number (CIN) against the CPIN. This will be a unique 17-digit number containing 14-digit CPIN generated by GSTN for a particular challan and unique 3-digit Bank code (MICR based which will be communicated by RBI to GSTN). The incorporation of the date of payment in the CIN may be examined from the IT’s perspective. This CIN, as a combination of CPIN and Bank Code, will be reported by the banks along with its own Unique Bank reference number (BRN). Such CIN is an indicator of successful transaction and will be used as a key field for accounting, reconciliation etc. by taxpayers, accounting authorities and tax authorities. After every successful e-payment transaction, there will be an instantaneous reverse flow of information through an electronic data string from the collecting bank to the GSTN containing the following details:

a) CIN;

b) GSTIN;

c) Bank Reference number (BRN);

[Since there could be maximum of four credits against one debit, banking practice may be ascertained by GSTN. If such transactions (i.e. four credits against one debit require multiple BRNs i.e. one for each credit entry), all BRNs should be reported.]

d) Challan amount;

e) Date of Payment;

f) Time of Payment

22. If the transaction cycle is not completed because of failure of credential verification, there would be no response from the bank to portal informing about the same. If a response (positive or negative) is not received by GSTN within the stipulated period (few minutes), there would be a feature in GSTN to re-ping the bank system and seek a response against CPIN. There may be a scenario in which the internet banking transaction is successful, but the connection drops before the control comes back to GSTN portal, and the re-ping facility will help in finding the status of such transactions.

23. Upon receipt of confirmation from the bank regarding successful completion of the transaction, GSTN will inform the relevant tax authorities about payment of taxes. A copy of the paid challan (downloadable/printable) with auto-populated CIN, date and time of payment and a statement confirming receipt of the amount by the bank will be provided to the taxpayer by GSTN.

24. Thereafter the tax paid challan (CIN) will be credited to the tax ledger account of the taxpayer. It was discussed and agreed by the Committee that there would be 20 ledger accounts (one for each Major heads i.e. CGST, IGST, Additional Tax & SGST and 4 Minor heads for each Major Head i.e. Interest, Penalty, Fees & Others).

Role to be played by each Stakeholder:

GSTN:

25. In the framework of GST administration, GSTN is envisaged to be a “pass through portal” that works as a common interface between taxpayers, tax authorities, authorized banks, RBI and accounting authorities. So GSTN will play the following role in this mode of payment:

a) Generation of challan along with CPIN;

b) Facilitating e-payments by providing a linkage to Internet Banking interfaces of authorized banks and payment gateways of authorised banks for CC/DC based payments;

c) Receipt of real time data from IT system (e-FPBs) of each authorized bank regarding successful completion of payment transaction by the taxpayer (CIN);

d) Generating receipt containing BRN No. of collecting bank for taxpayer acknowledging receipt of payment by the bank. A further facility of generating receipt containing RBI’s scroll number for taxpayer would also be provided;

e) Information to the respective Tax Authorities on real time basis for each successful transaction reported by banks. The communication at this stage may contain a minimal set consisting of GSTIN, CIN (i.e. CPIN + Bank Code), BRN(s), Challan amount, break-up of the amount into CGST, IGST, Additional Tax and SGST and date of payment;

f) At EOD, GSTN will also send the details of CPIN generated for the particular day to the Accounting Authority of the Centre (to facilitate estimation of revenue and fund management) and to such State accounting authorities that may so desire;

g) On T+1 morning, GSTN will generate a consolidated file containing a summary as well as entire details of the challans for which successful transactions were reported by the banks on real time basis for the date value of T=0 (for this purpose, daily transactions would include transactions from 20:01 hrs on previous day to 20:00 hrs in the current day). The file will be sent to the respective accounting authorities. At this stage, the challan data will also include CIN (i.e. CPIN + Bank Code) and BRN reported by the banks. GSTN would generate this file on all working days including the days on which no transaction took place;

h) GSTN will receive 39 consolidated e-scrolls from RBI (one each for CGST, IGST and Additional Tax and one each for SGST for each State/UT Govt, see para 26(a) below) on T+1 basis. The contents of the scrolls are mentioned in para 28 below;

i) On receipt of consolidated transaction level e-scrolls from RBI during latter part of the day, GSTN will carry out preliminary system based reconciliation with reference to the successful transactions already reported real time by the banks and consolidated by GSTN as per step (g) above. GSTN will append the RBI scroll Number on each challan and thereafter forward its reconciliation results to the respective accounting authorities;

j) Once the amount reflected in the CIN, received by GSTN from Bank on real time basis, is credited in the cash ledger of the taxpayer, GSTN will lock that CIN to prevent its further usage;

k) Purge all unused CPINs after the expiry of seven days in case of Mode I & II / 30 days in case of Mode III;

l) Receive TAXPAYER master as well as updates thereto from the respective Tax Authorities on real time basis.

e- FPBs (ELECTRONIC FOCAL POINT BRANCHES) OF AUTHORIZED BANKS:

26. There would be a single e-FPB for each Authorized bank for the entire country. It will perform the following role:

a) Each e-FPB will open a major head wise (CGST, IGST, Additional Tax and SGST) account of each government (total 39 accounts) to which the remittances received by it would be credited. Currently, the Constitutional Amendment Bill states that the Additional Tax will be collected by Centre and assigned to States. If this arrangement is continued, the e-FPB will maintain one account for Additional Tax for Centre. A Committee has been constituted by the EC to examine the operational issue of Additional Tax and if it is decided that this tax will be collected by the respective State Government and retained by them, separate accounts for every State will have to maintained for Additional Tax also, on the lines of SGST;

c) At the end of each day (T+1), each e-FPB will be responsible for preparing daily luggage files Major Head wise (CGST, IGST, Additional Tax and SGST) for each government detailing receipts from all modes of payments on a particular day (including nil payment days) and forwarding it to RBI in the morning. Each luggage file will have a Unique Serial Number which will be a running serial number extending through a financial year which will facilitate identification of missing files. This luggage file number will become part of the electronic file. For operational purposes such as size of the file, it may be broken up into different parts with each part being numbered uniquely and also mentioning the total number of parts of that file;

d) In the morning of each day (T+1), each e-FPB will also forward the daily luggage file mentioned above to accounting authorities of the Centre and the respective State, in case their accounting authorities so desire, so that they can independently monitor delayed remittances, if any, from the banks to the Government account in RBI;

e) On the first day of every month, e-FPB will provide Datewise Monthly Statements (DMS) for each tax and government separately to RBI for the preceding month with following details:

i) Name of Tax;

ii) Government Name;

iii) Datewise number of successful transactions and total credit reported to RBI; and

iv) List of discrepancies remaining unresolved at the end of the report month (MOE UIN, CIN, BRN, Amount, Nature of discrepancy).

These statements will be simultaneously communicated to the respective Accounting Authorities, if they desire so.

27. Each authorised bank should have one or more service branch in each State to serve as GST help desk and to receive queries / e mails to resolve the issues from Taxpayers, Tax Authorities and Accounting Authorities.

e-Kuber (Core Banking System) of RBI:

28. The following functions will be performed by RBI (e-Kuber):

a) RBI will consolidate luggage files received from all authorized banks, debit their accounts and correspondingly credit the CGST, IGST and Additional Tax accounts of Government of India and SGST accounts of each State/UT Government maintained in RBI(39 accounts);

b) RBI would send consolidated, digitally signed e-scrolls, along with all the challan details, for each type of Tax (one each for CGST, IGST and Additional Tax for Government of India, and separate e-scrolls of SGST for each State/UT Governments) per day (including NIL payment day) after including the amount collected by it in Mode – III to Accounting Authority of Centre (e-PAO) / each State (e-Treasury) and GSTN simultaneously. Daily Major head account-wise scroll from RBI will consist of following information:-

(i) Merchant Code given to GSTN;

(ii) Scroll Number and Date;

(iii) Name of Government to which the scroll pertains;

(iv) CIN;

(v) GSTIN;

(vi) BRN;

(vii) RBI Transaction Number;

(viii) Mode of payment;

(ix) Tax amount;

(x) Control parameters like total transaction, Total Amount in the scroll, etc.

c) If any discrepancy is reported by Accounting Authority or GSTN, it would carry out the correction mechanism with the authorized bank and thereafter report the corrected data to respective Accounting Authority and GSTN.

d) RBI will consolidate Datewise Monthly Statements (DMS) received from the banks for each tax and government, validate the consolidated statements (39) with reference to its own data of e-scrolls reported during the report month, have a systemic review of unresolved discrepancies and communicate the statements to the respective accounting authorities within 3 days from end of the report month.

Central Accounts Section (CAS) of Reserve Bank of India, Nagpur:

29. CAS, Nagpur reports daily consolidated credits and debits to each Government and Accounting Authorities. Such daily statements cover all receipts and payments for the respective governments including inter-government transactions. GST credits will be one of the items reported by CAS, Nagpur in its daily statements. The scroll number mentioned in para 28 (b) (ii) above should be the credit identifier in the daily statements.

e-PAOs (Electronic Pay and Account Offices ) of Centre and e-Treasuries of State Governments:

30. In the case of Central government, the existing e-PAO (Central Excise) and e-PAO (Service Tax) can work as e-PAO (IGST), e-PAO (CGST) in the GST regime. Another e-PAO (Additional Tax) can be operated till the time that the Additional Tax remains in force. All these e-PAOs can be located at Delhi itself. The State governments will need to establish their e-PAOs / e-Treasuries (proposed Central Accounting Unit in the RBI Report of 2014). The following functions will be performed by e-PAOs/e-Treasuries:

a) At EOD, the Central Accounting Authority and those State accounting authorities that so desire will receive details of CPIN generated by GSTN for the particular day. (Centre’s accounting authorities require this to facilitate estimation of revenue and fund management);

b) Each morning (T+1), e-PAOs / e-Treasuries will receive from GSTN a consolidated file of entire details of the challans (including CIN) for which successful transactions were reported by the banks to GSTN on real time basis for the previous day;

c) Each morning (T+1), e-PAOs for CGST, IGST & Additional Tax and e-Treasuries of the State Government will get consolidated transaction level digitally signed daily e-scrolls from RBI (along with all the challan details) pertaining to the successful transactions of the previous day (date value T=0);

d) E-FPB of authorized banks would also send such scrolls on T+1 basis to central accounting authorities and to those e-Treasuries that may so desire;

e) They will also receive from GSTN, later in the day, results of reconciliation by GSTN with the bank’s and its own data;

f) The e-PAO and e-Treasuries of the States would reconcile the challan details [received in step b) above] with the e-Scroll information [received from RBI in step c) and from GSTN in step e) above], and do the detailed revenue accounting based on the information provided in the e-scroll provided by RBI to the accounting authorities;

g) They will receive TAXPAYER master from the respective Tax Authorities (backend module) and the same would be required to be kept updated on real time basis by the respective Tax Authorities. The said TAXPAYER master would be used by the Accounting Authorities for mapping the challan details with the Jurisdictional PAOs by having a suitable mapping mechanism. This is a requirement of the Government of India for determining revenue from each formation. States may also follow a similar procedure, if they so desire;

h) They will also provide CIN wise payment / challan details to the respective Tax Authorities daily or periodically as per requirements / norms of their governments for departmental reconciliation and for updating Tax Authorities database that the tax amount has been accounted in the government’s books. Accounting Authorities should provide their accounting reference number (in Government of India, CIN is used for this purpose; some State Governments seem to be generating their own accounting reference number) for each challan accounted by them along with the tax amount as per the credit accounted by them to the jurisdictional Tax Authorities for reconciling their records.

i) They will provide verified Datewise Monthly Statement (DMS) to Pr. CCA, CBEC (Principal Chief Controller of Accounts) and Accountant General of the states:

Pr. CCA, CBEC (PRINCIPAL CHIEF CONTROLLER OF ACCOUNTS) AND ACCOUNTANT GENERAL OF THE STATES:

31. The following functions will be performed by them:

a) They will receive daily and monthly Put Through Statements from CAS, RBI;

b) They will also receive verified Datewise Monthly Statement (DMS) from e-PAOs and e-Treasuries of the States respectively;

c) The reconciliation of both the data will be carried out by them;

d) Office of Pr. CCA CBEC will also consolidate the total collection and forward the same to the Office of CGA for further consolidation.

II. OVER THE COUNTER PAYMENT THROUGH AUTHORIZED BANKS:

32. Another mode of payment that will be employed in the proposed GST regime will be Over the Counter (OTC) payments which will enable the taxpayers to make payment of the taxes at the Authorized Bank’s counter. This will be beneficial for smaller taxpayers that do not have access to internet banking facilities. CCA raised an issue that the authorized banks might be asked as to whether they would be able to scroll these OTC payments through e-FPBs. This was discussed and RBI’s representative assured that the scrolling by e-FPBs of OTC payments in one scroll would be ensured. The authorized banks will be required to establish / upgrade their IT software for accepting GST receipts.

33. The following stakeholders will play a key role in establishing an effective OTC payment system in the proposed GST scenario:

a) GSTN;

b) Branches of Authorized Banks;

c) e-FPBs of Authorized banks;

d) e-Kuber of RBI;

e) e- PAOs of Centre / e-Treasuries of State Governments;

f) Pr. CCA, CBEC / Accountant General of the States;

g) Tax authorities of Centre and States.

Process involved in Over the Counter payment of GST through authorized banks:

34. Every tax payer who wants to avail the facility of OTC payment (only for paying tax upto ₹ 10,000/- per challan), will access GSTN for generation of a challan through which payment is to be made.

35. Upon creation of the draft challan, the taxpayer will fill in the details of the taxes that are to be paid. From the available payment options, the taxpayer would select option of cheque, DD or cash based payment. The name of the authorized bank and its location (city/town/village) where the instrument/cash is to be presented is required to be filled in necessarily. No outstation cheques are to be accepted except those which are payable at par at all branches of bank having presence at that location. In case cheque or DD is selected as the mode of payment, entry of Instrument details is recommended, but not mandatory, as the taxpayer may not have the instrument ready at the time of challan generation. The tax payers can partially fill in the challan form and temporarily “save” the challan for completion at a later stage. A saved challan can be “edited” before finalization. After the tax payer has finalized the challan, he will generate the challan, for use of payment of taxes. The challan so generated will have a Unique Common Portal Identification Number (CPIN), assigned only when the challan is finally generated, that will help the portal and other authorities in identifying the challan. After the challan is generated, it will be frozen and will not be allowed to be modified. The CPIN / challan so generated would be valid for a period of seven days within which payment is to be tendered. GSTN will inform the challan details including validity period to the CBS (Core Banking System) of the selected bank on a real time basis.

36. Upon successful saving of the challan details, the challan will be available on the dashboard of the taxpayer in downloadable/printable form. So the taxpayer can either download the challan form and print it offline or can print the challan directly from GSTN. If the payment is made by cheque or DD, the challan itself would have a disclaimer that the payment is subject to realization of cheque or DD.

37. Thereafter taxpayer will approach the branch of the authorized bank for payment of taxes along with the instrument or cash. Since the tax payer is required to pay four types of taxes and the amount is required to be credited in the accounts maintained by bank for each type of tax, one option for the tax payer is to submit four instruments for crediting to the respective accounts. Four instruments may not be required if pooled account for realization of instrument is maintained. The matter was discussed in detail and it was recommended, that in the interest of facilitating the payment, each e-FPB should maintain a GST pool account so that the tax payer can issue only one instrument which will be written in the name of the GST pool account of the concerned bank. The bank’s IT system upon realization of the instrument, will immediately first credit that amount to the GST pool account and then immediately transfer that amount to the respective tax accounts [CGST, IGST, Additional Tax or SGST(39 accounts) as per details in challan (CPIN Data)]. However RBI representatives observed that since there would be real-time sharing of data between GSTN and Agency Banks, the details would be available to the bank official before submission of the challan by the customer. In such a situation, GSTN would have already shared the break-up of the total amount to the bank and the bank needs to credit the same in the appropriate head. The internal Accounting mechanism of bank may be left to the bank to design, as the requirement here is the proper booking and reporting of the transaction which banks would have to ensure. It was decided that those banks need not operate a GST pool account which can credit the amount in the respective tax accounts ‘on the fly’.

38. There should be a linkage between the GSTN and the Core Banking System (CBS) of the authorized banks whereby the details of challan are shared with the Authorized bank selected by the tax payer on real time basis so that they can be stored in the database of banks and also to facilitate the cashier / Teller to verify the details of the challan submitted by the remitter. This will eliminate the need for manual feeding of the challan details by the cashier / Teller in the banking system and thereby reduce the errors in data processing.

39. The taxpayer should preferably carry two copies of the challan, one for the bank’s record and another for himself to get acknowledgement. In the alternative, he can use a normal pay-in-slip and mention CPIN and challan amount in it. On approaching the bank, he should provide the challan itself or at least CPIN number on normal pay-in-slip to enable the cashier / teller to fetch the challan details in his system. There should be a customized IT application (software) in the bank’s system to accept GST receipts on OTC basis. While each branch can accept GST receipts, the credits should always be to the GST accounts maintained and operated by e-FPB . The banks not having such system should not be allowed to accept OTC payments. The minimum requirements to be met by the banks for being authorized to accept GST receipts for all modes including OTC mode are detailed in para 85 below.

40. The cashier / teller will verify the details of challan, payment instrument and amount provided by the taxpayer with those displayed in his system and should accept the receipt only when no discrepancy is found. If the challan has crossed its validity period of seven days, the bank’s system itself should bar acceptance of the payment. In any case, the challan would also not be available in the GSTN and consequently in the bank’s system because it would have been purged from the System by GSTN upon the expiry of the 7 day validity period.

41. The tax payer may make payment by cash or instruments drawn on the same bank or on some other bank in the same city. In case of cash payments or same bank instruments, the payment would be realized immediately and a transaction number (BTR/BRN) and CIN will be generated immediately at the authorized bank’s system which will be unique for each and every transaction. Such successful transactions shall be intimated to GSTN on real-time basis with details similar to those mentioned in para 21 above. This message will convey to the common portal that the payment has been successfully received at the bank’s counter.

42. After generation of BRN, the bank cashier may give a printed receipt from his system including the Bank’s transaction number (BTR/BRN) and CIN. However, if it not found feasible to print a separate receipt, the cashier should record the BRN and CIN generated from the system, on the tax payer’s copy of the challan or pay-in-slip as acknowledgment.

43. In case an instrument drawn on another bank in the same city is presented, the payment would not be realized immediately. In such case, CIN will not be generated immediately, and cashier should write only the system generated acknowledgment number on the challan / pay-in-slip and a stamp to the effect that the acknowledgment by the bank is subject to realization of the cheque / DD. The tax-payer need not visit the bank again to get CIN as the same will be communicated to him from GSTN as per the process detailed in para 47 & 48 below. However, if he does not receive any communication from GSTN within 3 days, he should visit the bank to ascertain the status of his payment.

44. Where the instrument is drawn on another bank, there should be a validation in the bank’s system to prevent out station cheques (except those payable at par across cities), and to also prevent deduction of commission charges for instruments drawn on another bank in the same city.

45. The Authorized Bank would send the instrument for collection and the transaction would be treated as complete and successful only after the actual receipt of the amount by the said bank.

46. The bank will inform GSTN on real time basis in two stages. First when an instrument is given OTC. At this stage the Authorized bank will forward an electronic string to GSTN which will contain the following details:

a) CPIN;

b) GSTIN;

c) Challan Amount;

d) Bank’s acknowledgement number.

On receipt of the above first message, GSTN should send a SMS to the tax payer, in addition to showing the status of the payment on its portal as subject to realization.

47. The bank’s system would send a second message to GSTN once the cheque is realized, the total amount is credited first to GST pool account and thereafter the funds are credited to the respective tax accounts as per CPIN data (as stated in para 34 above, GST pool accounts are not required to be maintained by those banks who can credit the amount in the respective tax accounts ‘on the fly’). On the day of realization, it will become a successful transaction to be reported to RBI on T+1 (T = 0 being day of realization). After the successful completion of transaction, the second acknowledgement will have the same details as mentioned in para 46 above with three additional details:

a) CIN;

b) Date of Realization of Cheque;

c) Time of realization of cheque;

d) Bank Transaction Number (BRN/BTN).

On receipt of the second message, GSTN would send a SMS to the tax payer, in addition to updating the status of the payment on its portal.

48. This 2 stage intimation by authorized banks is recommended for the following reasons:

a) Keep a watch on delays on the part of authorized banks in realization;

b) Maintaining a system based control as all branches of authorized banks will be allowed for OTC.

49. On receipt of the real time information for a successful transaction as per para 41 above (cash, cheque on same bank or DD) or receipt of the second message from Bank as per para 47 above (cheque drawn on another bank), the tax paid challan will be credited to the tax ledger account of the taxpayer. If the OTC payment was subject to realization (para 46), the initial status on the dashboard will state so. If the cheque is dishonoured, the presenting bank should inform GSTN about the fact of dishonour and same will be informed by GSTN to taxpayer and reflected on his dashboard.

Role to be played by each stakeholder:

50. The role played by each stakeholder in this mode of payment will be the same as mentioned in Mode I. There is an additional stakeholder in this mode, namely Branch of Authorized bank that receives the remittances and its role is discussed below.

Branch of Authorized bank:

51. Being the first point of contact for the remittance by the taxpayer, the branch of the Authorized bank receiving the payment will play a key role in the accounting and reconciliation of data with GSTN. It will perform the following functions:

a) Accept the payment only through the customized GST software/screen in its system.

b) Provide an acknowledgement to the tax payer;

c) Send the instrument (if pertaining to another bank) to the clearing house for realization and record the result in the IT system as and when the response is received. Such recording should be system based rather than manual and include realization or dishonouring of the cheque, as the case may be, so that the IT software can take up further action including intimation to GSTN on real time basis;

d) Credit the realized amount into either GST pool account, if so, maintained by the authorized bank (in its e-FPB) and thereafter transfer the said amount into the individual tax head accounts as indicated in the challan (all Authorized banks must develop a suitable GST software for this purpose) or to credit the amount directly to the respective government’s account (39 accounts).

e) In case the instrument is dishonoured, the presenting bank should inform GSTN.

52. It is to be noted that banks will have to develop a mechanism/IT application where all these amounts tendered at individual branches of an authorized bank are only handled through the e-FPB of that authorized bank. This is because the tax accounts will be maintained only by the e-FPB. Individual branches have not been authorized by RBI to operate Government account. It is also important to provide for a mechanism in GST Law to debar those tax payers whose cheques have once bounced from using this mode of payment. The most effective mechanism will be through GSTN which should debar such defaulters from using this mode.

III. PAYMENT THROUGH NEFT/RTGS FROM ANY BANK (INCLUDING OTHER THAN AUTHORIZED BANKS):

53. The third mode of payment envisaged under the GST regime is OTC payment through all banks including other than authorized banks, i.e., a bank where a tax payer may have account but that bank may not be authorized by the Government to accept GST receipts. The payment through this mode will strictly be a matter of normal banking service of NEFT / RTGS provided by that bank to its customer. The chances of error in this mode are similar to that of any remittance done through NEFT / RTGS. However, care needs to be taken to ensure that CPIN number is correctly mentioned in NEFT / RTGS message. The Committee recommends that this mode being a new mode of remittance should be scaled up gradually starting with a pilot run by RBI. It was informed by RBI that a detailed process flow could be worked out with specific provisions for validations. RBI further informed that this concept was being tested in Karnataka and this experience would be further used for developing this mode of payment. NEFT / RTGS mandate would have the same validity period of seven days as the CPIN and the date upto which it would remain valid would be printed on it. The Committee observed that in this mode of payment, it would not be possible to automatically ensure that a CPIN was not used beyond its validity period of 7 days. It was decided that CPIN once generated and intimated by GSTN to RBI in this mode though will have a validity period of 7 days but would remain live with RBI for a period of 30 days. In case the payment is received after the expiry of the said 30 days, RBI would return the amount to the remitter bank. Beside this, it was also decided that there should be a provision in the GST law whereby any taxpayer using this mode beyond the validity period (seven days) of the CPIN more than two times would be barred by GSTN from availing this mode of payment.

54. Although the process under this mode will be more or less similar to the OTC payment discussed earlier in paras 32-52 above, but due to involvement of a new stakeholder i.e. a non-authorized bank, certain modifications are required for this process. This process will be beneficial for those taxpayers who do not have a bank account in any of the authorized banks or find such bank to be far away for OTC payment or want to make the payment directly from their account in their own bank only. In this mode, only payment through National Electronic Funds Transfer (NEFT) / Real Time Gross Settlement (RTGS) is to be allowed as other payment instruments would require the Central and the State Governments to create accounts with non-authorized banks also which will not be desirable.

Process involved in payment through NEFT / RTGS from any Bank (including other than authorised banks):

55. Every tax payer who wants to avail the facility of payment through NEFT/RTGS mode will access GSTN for generation of a challan through which payment is to be made.

56. Upon creation of the draft challan, the taxpayer will fill in the details of the taxes that are to be paid. As agreed by the RBI representative, RBI would itself be the recipient of the amount transferred through NEFT / RTGS, thus eliminating the need for a link-up first with an authorized branch to receive the payment and thereafter its transfer to the RBI. RBI would thus perform the role of Authorized bank and that of e-FPB in this mode of payment. In this view, the name of the authorized bank will be auto populated as RBI. As a part of the challan preparation, a tax payer will have to choose the mode of payment as NEFT / RTGS from any bank. The challan so generated will have a Unique Common Portal Identification Number (CPIN), assigned only when the challan is finally generated. The generated Challan will have a NEFT / RTGS mandate associated with it. This mandate will contain NEFT / RTGS pooling bank account details (i.e. of RBI) along with IFSC for receiving money. After the challan is generated, it will be frozen and will not be allowed to be modified. The CPIN so generated would be valid for a period of seven days within which payment is to be tendered but would remain live with RBI for a period of 30 days. NEFT/RTGS mandate would have the validity period of CPIN printed on it. As mentioned above, there shall be a provision in the GST Law whereby any taxpayer using challan under this mode beyond the validity period of seven days of the CPIN more than two times would be barred from availing this facility by GSTN.

57. Upon successful saving of the challan details, the challan will be available on the dashboard of the taxpayer in downloadable / printable form. So the taxpayer can either download the challan form or print it offline or can print the challan directly from GSTN.

58. Besides the generation of challan, GSTN will also generate NEFT / RTGS mandate form in prescribed format. The CPIN generated at the portal shall be incorporated in NEFT/RTGS mandate form in “Account Name” field. RBI would provide for suitable validations for this field. The “Sender to Receiver” field shall carry the entry “GST Payment”. In case of NEFT / RTGS payments, there shall also be a disclaimer on the challan copy and the mandate form that the payment through NEFT / RTGS is a transaction between the tax payer and his bank and the payment will be deemed to be received by the government only when the amount is credited to the designated account in RBI. The payments in this mode would be permitted only against cheques and no cash payments would be permitted to initiate NEFT / RTGS transaction for the reasons mentioned in Para 67 below.

59. The following details will be available in the NEFT / RTGS mandate form:

b) Beneficiary Account Number : Account Number of RBI’s pooled account for GST;

c) Account Name : CPIN of relevant challan (suitable validation to be provided by RBI);

d) Total Amount;

e) Sender to Receiver Remarks: GST Payment.

The form will have a provision to write the NEFT/RTGS charges manually and then record the total amount to be collected by the bank (sum of challan amount and charges). The entire NEFT/RTGS form will be auto-populated except the part relating to the charges.

60. Thereafter taxpayer can print a copy of NEFT / RTGS mandate form and approach his bank branch (any bank) for payment of taxes (within a period of seven days of the generation of CPIN, so that when the amount is received by RBI, the CPIN is still valid.) The payments in this mode would be permitted only against cheques and no cash payments would be permitted to initiate NEFT / RTGS transaction. NEFT/RTGS mandate would have validity period of CPIN printed on it. As already mentioned above, there should be a provision in GST law whereby any taxpayer using this mode beyond the validity period (seven days) of the CPIN more than twice would be barred from availing this facility by GSTN.

61. GSTN will inform RBI on real time basis the following details:

a) CPIN;

b) GSTIN;

c) Challan Amount;

d) Break Up of the Amount into CGST, IGST, Additional Tax and SGST;

e) State/UT Government to which SGST remittance pertains.

62. The accepting bank should add its charges for doing NEFT / RTGS remittance and collect gross amount from the customer. The amount indicated as GST amount for remittance should be transferred by the remitter bank to the designated account of the government in RBI. For the proper identification of the transaction, there should be a Unique Transaction Reference (UTR) that should be conveyed along with file details to RBI. The remitter bank must also mention the CPIN in the NEFT/RTGS mandate as part of the Account Name. The Remarks field shall mention ‘GST Payment’.

63. Upon successful completion of the transfer at the end of the remitter bank, the remitter will get a receipt detailing Unique Transaction Reference (UTR). Taxpayer should thereafter login back to GSTN portal and update the challan details with Unique Transaction Reference (UTR) provided by the remitter bank for NEFT / RTGS transaction. An alternate SMS based facility for such updating by the tax payer (instead of internet based) may be established by GSTN to facilitate those taxpayers who do not have an internet access. On receipt of the transaction number, GSTN will communicate this Unique Transaction Reference (UTR) (for the corresponding CPIN) also to RBI on real time basis.

64. Once the RBI receives the payment in its account with NEFT/RTGS message, it will link up the payment with the CPIN earlier received from GSTN and report the transaction to GSTN on real time basis through an electronic string which will contain the following details:

a) CIN (CPIN and Bank Code of RBI);

b) GSTIN;

c) Challan Amount;

d) BRN of RBI;

e) Unique Transaction Reference (UTR);

f) Time of Payment;

g) Date of Payment.

65. Upon receipt of the electronic string regarding successful completion of the transaction by GSTN, the tax paid challan will be credited to the cash ledger of the taxpayer. The GSTN will thereafter lock the CIN so that it cannot be used again.

66. As recommended in para 58 above, the Mode III may be implemented with arrangement of CPIN being mentioned as the “Account Name” in NEFT/RTGS message. RBI will provide for a suitable validation for this field. In such arrangement, the chances of error will be only marginal as the remitter banks take care to mention the account name correctly in any NEFT/RTGS message. In case of error, NEFT/RTGS unique transaction number (UTR) intimated by the tax payer can be used as a secondary identifier. The primary matching by RBI should be with reference to CPIN only, i.e., CPIN as contained in NEFT/RTGS message and CPIN data provided by GSTN. On successful matching, the GST pooled account should be debited and the respective 39 tax accounts (CGST, IGST, Additional Tax and SGST) should be credited simultaneously as per the challan details with generation of CIN and BRNs. At this stage, the transaction should be treated as successful and CIN and BRNs should be communicated to GSTN by RBI.

67. As stated in para 15 above, though the CPIN is valid for a period of 7 days, the same would remain live with RBI for a period of 30 days. Thus RBI can accept the payment during the said period of 30 days. In case payment is received after the expiry of 30 days, RBI would refund the said amount to the remitter bank. Keeping in view this requirement, it has been recommended, as mentioned above, that payments in cash would not be accepted for initiating NEFT / RTGS transaction.

68. The Committee deliberated the need for a pooled GST account. Based on inputs provided by RBI, a receiving account is necessary for NEFT/RTGS process. Therefore, a pooled GST account as an operational necessity will have to be opened in RBI. This account may be opened in the name of the Accounting Authority of the Government of India solely for the operational reasons as a transit account. There should be a validation in RBI system that no funds pertaining to the transactions with date value T=0 are left in this account when the scroll is prepared on T+1.

69. If the matching based on CPIN does not succeed, the role of UTR as secondary matching identifier becomes important. However, it is possible that RBI may receive NEFT/RTGS message even before the tax payer updates his challan with UTR number and GSTN informs RBI on real time basis. In case of failure of CPIN based matching and UTR not being available, the funds will remain in the pooled account till the UTR is received or scroll is prepared, whichever is earlier. Such credit in the pooled account should be with a “CPIN mis-match” flag that a secondary level matching needs to be carried out before scroll is generated on T+1 basis. Once UTR is provided by GSTN, the secondary matching of all such transactions remaining in the pooled account should be carried out. If a transaction can now be linked to the correct challan, the respective Tax accounts should be credited with generation of CIN and BRNs. There should be a validation in RBI system that all the transactions with “CPIN mis-match” and date value T=0 in the pooled account are subjected to secondary level matching before generation of scroll for all taxes.

70. If the matching based on CPIN and UTR NEFT / RTGS transaction number UTR both fails, the entire receipt should be credited to CGST account with a “CPIN mis-match” flag so that the Accounting Authorities of Government of India can account such amount under a separate suspense sub-head (possibly receipts awaiting transfer i.e. RAT).

71. In all such cases of CGST credits with “CPIN mis-match”, the tax payer will not get a confirmation SMS from GSTN and his ledger will not reflect the payment. He can be expected to provide UTR at this stage. Once the UTR becomes available, GSTN should carry out the matching with CPIN, and communicate following details to the Accounting Authorities of Government of India and concerned State Government.

a) RBI scroll number and date which carried the credit (CGST scroll);

b) BRN;

c) CIN (of credit to CGST account with “CPIN mis-match” flag);

d) Challan amount;

e) Breakup of total amount in CGST, IGST, Additional Tax and SGST;

f) Name of State Government to whom SGST pertains.

72. Based on the communication from GSTN, CGST Accounting Authorities shall take steps for clearing the suspense sub-head by transferring the credit to CGST, IGST and Additional Tax accounting heads, and for carrying out inter-government transfer to the concerned State Government.

73. The reconciliation between e-Scroll sent by RBI on T+1 and the transaction details available with GSTN (provided earlier by RBI) will be performed using CIN and Unique Transaction Reference (UTR).

Role to be played by each stakeholder:

74. As for the role played by each stakeholder in this mode of payment, it will be same as for their role in OTC payments through authorized banks. The role of Branch of remitter bank that transfers the funds to RBI and the additional role of RBI performing the functions akin to authorized banks is discussed below.

Branch of remitter bank:

75. The branch of the remitter bank would perform the following functions:

a) Remitter bank is required to ensure that the correct CPIN is entered in the NEFT / RTGS message and also inform UTR to the taxpayer;

76. RBI’s role for the Mode III will be akin to that of authorised banks for other modes, i.e, RBI will be the bank which will receive the funds directly from a taxpayer’s account in a pooled account. It should be possible to have a suitable IT system which will carry out CPIN or UTR based matching (as detailed in para 66 above) for each NEFT/RTGS receipt and credit the remittance to a specially created pooled GST account and thereafter transfer it to the respective tax accounts of each government.

77. Once the remittances are received by RBI, it will perform the following functions:

a) RBI will receive and validate the NEFT/RTGS transaction against the Challan details received by it;

b) RBI would communicate the receipt of payment (CIN) to GSTN on real time basis;

c) On first day of every month, RBI as e-FPB will provide Datewise Monthly Statements (DMS) for each tax and government separately to the concerned wing of RBI for the preceding month with following details:

i) Name of Tax;

ii) Government Name;

iii) Date wise number of successful transactions and total credit reported to RBI; and

iv) List of discrepancies remaining unresolved at the end of the report month (MOE UIN, CIN, BRN, Amount, Nature of discrepancy).

These statements will be simultaneously communicated to accounting authorities of the Centre and the respective States in case their accounting authorities so desire.

d) RBI will also be responsible for incorporating these payment details in their daily master scroll generated by them as an aggregator for amounts received through Mode I and II.

PAYMENT ACROSS DEPARTMENTAL COUNTER:

78. The issue was discussed in the Joint Committee on Business Process and it was decided that since the emphasis in GST regime is towards automation and least human interface between the tax administration and the taxpayer, therefore there is no need to provide for this mode i.e. payment across departmental counters. It was also stated that taxpayers have been provided various other modes to facilitate anytime, anywhere payment and this mode would be retrograde especially when e-payment is being declared as the preferred mode of payment. However, the departmental officers will accept the deposit of taxes during the course of enforcement and anti-evasion investigations including by flying squads, etc. While doing so, if the concerned person is not already registered, the departmental officer will create a temporary GSTIN on the GSTN common portal. For this purpose, GSTN will provide a separate module and a GSTIN series for giving temporary GSTIN. The officer will collect the amount in respect of all types of taxes payable by him in cash/cheque/DD from the said person, issue a temporary receipt to him, generate the challan from GSTN, fill up the challan (at a later stage, if not possible at that time) and remit the amount using Mode2. GSTN will provide a facility for linking of the temporary GSTIN to the permanent GSTIN, if taken at a later stage.

PENALTY MECHANISM FOR ERRING BANKS:

79. At present, banks are subjected to penalty for delayed fund remittances only. Current system of remuneration to banks for collection of Central Excise, Service Tax and Customs duties is determined on the basis of challans. New parameters of bank performance could be developed, based on timely remittance and reporting of error- free data to all stakeholders. A system of incentives / penalties to be administered by the respective Accounting Authority (i.e. if defaults arise in remission of CGST/IGST/Additional Tax, by Accounting Authority of Centre and if defaults arise in remission of SGST, by Accounting Authority of the concerned state) can be built-in, based on a transparent evaluation mechanism of the quality of data of collection reported by banks for accounting and reconciliation purposes. The CGA has suggested that penalties for inaccurate reporting and delayed settlement of taxes is already in place in the case of Direct Taxes and the same may be put in place in GST regime. It is further recommended that a framework of desired features and validations at Banks for collection of taxes under GST regime should be devised by RBI in consultation with the Accounting Authorities. Any bank found not having built capabilities to adhere to the framework, should not be allowed to collect GST receipts. Due care should be taken so that discontinuities arising from manual interventions in the banks’ internal processes are removed. The Committee also recommends that, over a long term, Accounting Authority should develop a service quality rating for the participating banks based on identified transparent and quantifiable parameters.

BANKING ARRANGEMENTS UNDER GST:

80. At present Central Government and each State Finance Department prescribes banking arrangements for collection of government taxes. At present, Central and State governments utilize the services of Public Sector Banks/ Other Public Sector Banks (IDBI)/ Private Sector Banks (ICICI Bank, Axis Bank, HDFC Bank) for tax collection. The committee was informed that Non-Scheduled and Cooperative banks operating in State(s) are not permitted to collect taxes.

81. The list of all authorized banks participating in the GSTN should be common across all states. This can be a super set consisting of existing authorized banks of the Central Government and all State Governments and Union Territories. A list of banks that have been presently authorized either by the Centre or State Tax Authorities has been provided by RBI and the same is enclosed as Annexure-VI. It is recommended that all these banks may be considered for authorization in the GST regime in consultation with the Department of Financial Services.

82. Only those banks should be accredited who refine their IT systems to handle GST remittances in a seamless manner obviating need for manual intervention for data entry, funds flow and exchange of data.

83. It is also noted that a participating bank in the current context has limited mandate for tax receipts as compared to that of an authorized bank. The mandate of participating banks, though essentially agents of RBI, is limited to acceptance of tax receipts through internet banking mode only. Whereas, authorized banks have a broader mandate of accepting government receipts through both internet banking mode and physical mode (OTC) of Cash, DD and Cheques, in addition to mandate of making government payments. In order to give a broader choice to the tax payers, and hence to enhance ease of doing business, it is recommended that the participating banks can also be allowed to accept GST receipts through OTC mode envisaged in this report.

84. Out of the superset of existing authorized banks and participating banks only those banks should be authorized to accept GST receipts who meet the minimum requirements suggested below. The objective of these minimum requirements is to ensure that a bank has the capability to handle GST receipts in a seamless manner in a consistent and error free manner underpinned by a robust IT system with no process flow discontinuities.

85. Minimum requirements to be met by a bank for being authorized for GST remittances are recommended to be as follows:

a) A centralized application for handling GST receipts for both modes (internet banking and OTC) in an end-to-end manner should be established.

b) There should not be any process flow discontinuities for any mode of the receipt.

c) The system should not require any post-event data entry at any stage.

d) The data entry at any stage of the process should be limited to the operations performed at the bank’s end.

e) The data received from GSTN portal should not require any fresh data entry and should not be open for modification.

f) There should be functional integration with GSTN portal and banks for both modes.

g) The IT system should have the ability to receive challan data and to communicate successful remittances on real time basis to GSTN portal for both modes.

h) The collation of data and reporting to GSTN portal and to RBI should be system based and not require manual operations.

i) The standards of communication prescribed by RBI (ISO 20022) should be followed.

j) There should be an upfront (before being authorized) as well as periodic audit of the IT system and the centralized application for handling GST receipts. The system audit should cover operational, technical and security aspects as per terms of reference and periodicity set by GSTN in consultation with Accounting Authorities.

k) One branch of the concerned authorized bank in the entire country should be established / designated as the e-FPB (Electronic Focal Point Branches) to handle all backend operations of GST receipts including operation of 39 tax accounts, data collation, reporting and reconciliation with RBI / GSTN / Accounting Authorities.

l) In addition, one or more branch of the concerned authorized bank in each State Capital should serve as GST helpdesk (Refer Para 27 above).

m) Three separate tax accounts for Government of India (one each for CGST, IGST and Additional Tax) and one tax account for each State/UT Government (36 in total) (for SGST) should be set up and operated by e-FPB alone.

n) The credit to respective tax accounts should be simultaneous with debit to the tax-payer’s account in case of internet banking mode, realization of a cheque or submission of DD/cash in case of OTC mode and receipt of NEFT / RTGS remittances from remitter banks into RBI’s pool account and then its transfer to tax accounts.

o) The above mentioned credit to the respective tax accounts should be by the IT system itself as per the mandate contained in the Challan data received from GSTN and not require manual intervention.

p) In addition to tax specific 39 accounts (for CGST, IGST, Additional Tax and SGST account for each State / UT Government), a common pooled account for cheque/Draft and CC/DC payments should be set up and operated by e-FPB ( but not required by those banks who can credit the amount ‘on the fly’).

q) As a part of the daily consolidated but transaction level report of successful receipts in each government account to RBI, there should be an assurance that all transactions credited to respective CGST, IGST, Additional Tax and SGST Accounts are being reported to RBI and no balances are left in these accounts meant for cheque realization. RBI will need to build a similar assurance for NEFT/RTGS remittances.

r) Suitable validations prescribed by GST Law should be inbuilt in the IT system / GST application. Some of such validations will pertain to non-acceptance of outstation cheques and non-deduction of cheque collection charges for OTC receipts, and mark up and collection of CC/DC charges (to be agreed) from tax payers.

86. It was agreed that the minimum standards to be met by the participating banks, as encapsulated above, should be communicated to the banks well in advance in consultation with RBI.

ACCOUNTING SYSTEMS UNDER GST:

87. State governments/UTs accounting system also follows, to a large extent, the general principles and procedures of Central government accounting, with minor variations in respect of classification of tax heads of accounts. While the List of Major and Minor Heads of accounts are common to both Central and State/UT Governments accounts, classification below Minor Heads may vary at the State level.

88. Under the proposed GST regime, it is recommended that a uniform system of banking arrangement for both the Central and State/UTs governments to facilitate fund flow, reporting and accounting may be framed.

PROPOSED ACCOUNTING SYSTEM UNDER GST:

89. Four different Major Heads of accounts would be required to be opened for classifying CGST, IGST, Additional Tax and SGST along with underlying minor heads and sub-heads, wherever required, to account for various taxes.

90. There is a need to standardize these accounting codes for all items covered under GST regime among all the States and UTs, since settlement of IGST would be based on centralized reporting. SGST will be accounted for by the States and credited to individual State Treasuries, through the existing system followed in each State. SGST will not be reflected in accounts of the Central Government.

91. There may be cases of mis-classification and erroneous scrolling under Major Heads of accounts which may lead to less or excess revenue settlements between the Centre and State(s). To deal with such transactions, detailed accounting procedures should be designed. It is recognized that it is IT system issue, and not an accounting issue. The debit from tax-payers account should result in auto-credit to respective accounts of Government of India and the concerned State Government. Except in case of remittance through any authorized bank including a non-agency bank (where the funds have to necessarily come to a designated account in RBI), there should not be any mix-up of the funds belonging to two governments.

92. The CGA has suggested the following in this regard:

a) Codal provisions of the DDO & PAO should be complied with for discharge of PAO’s role. The automation as proposed should conform to this basic requirement.

b) PAO is the sole authority for receipt, payment and reconciliation of accounts book with Bank Reconciliation statement (BRS).

c) Any compromise on this fundamental work flow may lead to legal complications in preparation of Finance Accounts / Appropriation Accounts which is constitutional mandate.

d) Each challan detail must be linked with one DDO and PAO and bank account.

e) As part of standard operating process, accounts classification should be done by the PAO in his books and no one else. Bank is not involved in classification of accounts.

93. The challan will reflect only the net tax paid amount along with related bifurcations of nature of tax liability, such as, Interest, Penalty, Fees, other charges, etc. Presently, the Tax Payment Challan information forms the basis of accounting and reconciliation between the banks, RBI, Tax authorities and Accounting authorities of the Centre/States/UTs. A list of sample tax accounting codes under GST is proposed in the table below:-

S. No.

Type of Tax Liability

Sample Accounting Code

1

CGST – Tax

00010001

2

CGST – Interest

00010002

3

CGST – Penalty

00010003

4

CGST – Fees

00010004

5

CGST – Other

00010005

6

IGST – Tax

00020001

7

IGST – Interest

00020002

8

IGST – Penalty

00020003

9

IGST – Fees

00020004

10

IGST – Other

00020005

11

SGST- Tax

00030001

12

SGST – Interest

00030002

13

SGST – Penalty

00030003

14

SGST – Fees

00030004

15

SGST – Other

00030005

16

Additional Tax – Tax

00040001

17

Additional Tax – Interest

00040002

18

Additional Tax – Penalty

00040003

19

Additional Tax – Fees

00040004

20

Additional Tax – Others

00040005

The actual accounting codes have to be finalized by CGA in consultation with CAG on the basis of proposals from Tax Authorities.

94. CGST, IGST and Additional Tax components will be accounted for under Consolidated Fund of India (CFI). Transfers of due IGST amount and Additional Tax to the States can thereafter be made there from as per the existing procedure.

95. The interest, penalty, fees or other charges, if any, under GST will need to be accounted for separately. Hence, they would be reflected under separate heads in the Tax Payment Challan.

96. The IT audit of the process flows and settlement of funds by the FPBs / Link cells with RBI will be conducted periodically by a CERT-IN empanelled agency selected by the office of Pr. CCA, CBEC, or by a designated authority of States/UTs so as to ensure correctness of revenue collections.

RECONCILIATION OF RECEIPTS:

97. Well-developed and stabilized IT systems without manual process discontinuities in banks, RBI and common portal should eliminate/reduce possibilities of errors. However, there may still be reconciliation challenges arising due to errors encountered during the stabilization phase of the IT systems of the stakeholders and their mutual functional integration. Even in the post stabilization phase, some errors may be seen due to problems external to the IT systems, e.g., in the public network used for sharing the data. A process and standard operating procedure for handling the errors, if they arise, will have to be established, as multiple agencies would be handling funds and related information pertaining to different governments.

98. The proposed GST payment process envisages a paradigm shift from the processes and validations currently being used for payment of taxes to the Government. This shift is aimed at establishing a convenient, consistent and efficient payment process for the tax payers as well as for the 37 governments simultaneously. This shift is possible in view of current IT capabilities in the eco-system and the experience gained in various systems for payments to the governments.

99. Following are the fundamental changes from the existing systems:

a) Tax payer will generate the electronic challan, and therefore that challan data can be trusted for its correctness for its contents, as filled in by the taxpayer.

b) The challan thus generated on GSTN portal will provide a unique Id (CPIN) which would be used uptill the time payment has been received by the bank and CIN (CPIN plus Bank Code) has been generated. The said CIN would be used thereafter for accounting, reconciliation, etc.

c) All modes of payment will use the system generated electronic challan and there would not be re-digitization of the challan data, as recorded by the taxpayer, by any agency in their part of the workflow.

d) Any agency handling the payment process will merely add its unique Id and parameter to the basic data received by it from another agency earlier in the work-flow chain, and thereafter pass on the data to the agency next in the chain.

e) RBI will play the role of the aggregator for flow of funds as well as information from the banks.

f) GSTN will have the primary anchor position in the payment process with responsibility for information flow to various agencies whereas RBI will have the primary anchor’s role in relation to funds flow, information flow about receipts and correction of discrepancies noticed during reconciliation process.

g) e-Scroll from RBI will be the basis for accounting, reconciliation and other incidental activities to be carried out by the accounting authorities of both Centre and States.

100. In view of these fundamental changes, the key Id for information exchange with banks and RBI should use the unique Id generated by GSTN, i.e., CPIN. Once the payment has been made by the taxpayer and CIN is generated and reported by the recipient bank along with its transaction number (BRN), CIN which has CPIN embedded there in, would be used as key Id in subsequent stages. CIN is recommended to be used as a key Id as it is the sole indicator of the receipt of actual payment. Similarly, the transaction reported by RBI for the funds flow (credit) to government accounts through the e-scrolls should form the basis for accounting as it reflects the actual credit in the Government Accounts.

Reconciliation by GSTN:

101. GSTN through its IT system should carry out reconciliation in following two stages:

a) When the banks report each successful transaction on real time basis, the IT system should validate the bank’s message with reference to CPIN and total amount of the challan, and communicate the discrepancy, if any, immediately. This validation and real time response by GSTN is particularly relevant for Mode II and III for which the entire payment is not in a single workflow.

b) When consolidated e-scrolls are received from RBI on T+1 basis, GSTN should carry out the reconciliation between those scrolls and the consolidated challan files communicated to the Accounting Authorities earlier in the day. The discrepancies should be communicated by GSTN to the Accounting Authorities and RBI simultaneously on the same day. The purpose of this reconciliation is to assist those Accounting Authorities who may not have IT systems to carry out transaction level reconciliation in an automated manner, and to identify systemic and service level issues for taking up with the authorized banks and RBI.

102. The role of GSTN in the reconciliation process should be limited to the above set of activities. GSTN should not be expected to take up MOE process for any error type as that is fairly resource intensive, requires manual appreciation of facts and is time consuming. The transaction level resolution of discrepancies through the Memorandum of Error (MOE) process with RBI and banks should be the responsibility of the respective Accounting Authorities.

Reconciliation by Accounting Authorities:

103. The Accounting Authorities through their IT systems are expected to carry out the reconciliation at their level de novo based on communication by GSTN of challan data for successful transaction received on T+1 basis (State AG authorities to be assisted for setting up accounting interface with GSTN) or through Tax Authorities system (based on the integration capabilities at Central / State level) and e-scrolls received from RBI for each day on T+1 basis. The reconciliation results communicated by GSTN would act as additional validation in the reconciliation process. The reconciliation would be performed on the basis of CIN, which will be the unique identifier across all databases.

Resolution of Reconciliation Outcomes (discrepancies noted during the reconciliation process):

104. There would be to and fro data transmission between GSTN, e-FPB of Authorized Banks, banks other than authorized Banks, RBI, Accounting Authorities and Tax Authorities. There is a scope of error occurring at each leg of communication. The process for reconciliation of such errors in each leg of communication is discussed in succeeding paras.

First leg of communication of data (CPIN linked to a GSTIN) starts from GSTN to Authorized banks:

105. If the data forwarded by GSTN (CPIN linked to a GSTIN) itself has an error then this error will be reflected in all the later transactions. So significance of accuracy of this data cannot be overemphasized. It would be important for GSTN to maintain a robust system for maintaining data integrity and keeping the data error free by having suitable validations at the time of creation of CPIN. Key elements here are CPIN and GSTIN.

Second leg of communication of data (CIN with embedded CPIN) starts from Authorized banks / RBI to GSTN (T=0):

106. This communication is not meant to be the basis for accounting, but act as an enabler to reduce errors in the overall process and to facilitate fleet-footed monitoring by the Tax Authorities. The IT system of the authorized banks should have the following validations to reduce possibility of discrepancies in this leg:-

a) In any reporting of successful transactions by the banks to GSTN, CPIN field is never a blank;

b) The response sent back to GSTN is always against a CPIN received from GSTN;

c) Sum total of all credits to Tax accounts for a particular CPIN adds up to the challan amount.

d) CIN reported by the authorized banks/RBI should always have a CPIN embedded in it.

107. In spite of the above mentioned validations, if a discrepancy is found in a bank’s response, the discrepancy will get noticed in the real time validation of the response by the GSTN. The response sent by e-FPB of authorized bank (in Mode I & II) / RBI (in Mode III) should be validated with the data sent earlier by GSTN to Authorized bank / RBI. Key elements are CPIN, GSTIN, CIN & Challan amount in case of authorized banks and CPIN, GSTIN, CIN, NEFT/RTGS UTR and Challan amount in case of RBI. This validation between CPIN available with GSTN and CIN received from e-FPB of authorized banks / RBI should be done on real time basis and the discrepancies, if found should be communicated to the concerned banks immediately by GSTN’s IT system so as to enable time to the banks for correction, if possible, before communicating the receipts to RBI on T+1 basis.

108. The validation by GSTN may throw up following discrepancies in the transaction being reported (with CIN added by the bank) by e-FPB of authorized bank / RBI:

a) without CPIN;

b) with incorrect CPIN;

c) with challan amount mismatch.

109. In all these cases, the resolution at e-FPB may require manual intervention. The bank may resend the data to GSTN after correction. If the bank is unable to resolve by T+1 reporting time to RBI, the bank should include the transaction in the luggage file with whatever CPIN data it may have for that transaction. It will be type (c) error in the third leg.

Third leg of communication of data (luggage file) starts from Authorized banks to RBI (T+1):

110. In this leg, the data is being collated and transferred by authorized banks to RBI in daily luggage files for each type of tax of Government of India (CGST, IGST & Additional Tax) and SGST (state wise; for 29 states and 7 UTs) separately [there will be total thirty nine luggage files (3+29+7)]. The key element here is CIN. So the accurate reporting of the same by the authorized bank to RBI has to be underlined. As RBI would prepare e-scrolls based on this data, correctness and cleanliness of this data is crucial. RBI collates daily luggage files ( thirty nine) received from all the authorized banks, includes payments received directly by it in Mode III, adds RBI Transaction Id for all modes, prepares and sends daily e-scroll (one for each major head for Centre and each State) to GSTN and Accounting Authorities. Reconciliation by GSTN and Accounting Authorities (of the Centre and the States) will be initiated after they receive their respective files (Government of India authorities will receive three files while State Authorities will receive a file each). Errors in this leg of communication would be detected at this stage. Various situations that can be envisaged in this leg are as follows:

a) Transaction reported to GSTN by authorized banks but not to RBI (CIN reported to GSTN but not included in luggage file):

111. To prevent/minimize this type of error, the bank’s IT system should have a validation that all credits to the Tax accounts for the date value being the previous day should get reported to RBI in the luggage file. This discrepancy will be detected at the stage when GSTN and Accounting Authorities compare the challan data (CIN ) of the day received from authorized banks with the e-scroll of the corresponding date received from RBI on T+1 basis. If GSTN detects such a discrepancy, it will communicate the same to the relevant Accounting Authority and RBI. On the basis of this information or on the result of their own reconciliation with reference to CINs reported earlier by GSTN, the Accounting Authority will generate a Memorandum of Error (MOE) with a Unique Identification Number (UIN) and communicate the same to the RBI and copy the same to the concerned authorized bank and GSTN. GSTN being only a pass through portal, should not be entrusted the work of MOE and its resolution. Moreover, MOE process requires manual appreciation of facts, accounting expertise and decision making on behalf of each Government, which will be beyond GSTN’s mandate/capacity. The steps involved in the correction mechanism in the aforesaid situation are as follows:

i) GSTN to report the error to the relevant Accounting Authority (and Tax Authority, if GOI or concerned State so wants) and RBI, if the discrepancy is detected by GSTN;

ii) The relevant Accounting Authority to generate a MOE with a UIN and communicate the same to RBI with a copy to concerned authorized bank for resolution (Accounting Authorities of the Centre and States will have to initiate MOE in respect of their respective taxes) (This may be on the basis of discrepancy detected and communicated by GSTN or by the Accounting Authorities themselves);

iii) RBI to ascertain from e-FPB of the concerned authorized bank / RBI and get the discrepancy corrected. E-FPB of the concerned Authorized bank / RBI must rectify this discrepancy within a period of two days from the date of receipt of MOE from the Accounting Authority;

iv) Rectification by the concerned e- FPB / RBI will be by way of identifying the missing transaction, putting it in a separate luggage file containing the UIN of the relevant MOE and then transmitting the same to RBI;

v) RBI will send a separate e-scroll relating to MOE to the concerned Accounting Authority containing the missing transaction;

Points at iv) and v) are design issues, which can be decided by GSTN in consultation with RBI. The reporting by e-FPB and thereafter by RBI can be through separate files as mentioned above, or the normal luggage file from banks and scroll from RBI can contain the now resolved transaction with a MOE resolution flag and UIN as additional field for the relevant record.

vi) Accounting Authority to note the correction of MOE and report the same to GSTN and the concerned Tax authority thereby completing the transaction cycle;

vii) RBI to take steps to penalize the e-FPB of the concerned Authorized bank.

b) Transaction reported by Bank to RBI but not to GSTN (CIN included in luggage file but CIN not reported to GSTN):

112. In case of payment through internet banking (Mode I), this seems to be an unlikely scenario, as all payments will be processed at the Core Banking Solution (CBS) of the concerned e-FPB of authorized bank and therefore the compiled data that it reports to RBI on T+1 basis will be nothing but the compilation of data (CIN) already reported by e-FPB of authorized bank on real time basis to GSTN. This discrepancy may however arise due to communication failure even after the prescribed rounds of pinging.

113. This discrepancy can arise in other modes of payment (Mode II and III), because the payment cycle is not a single workflow, is spread over a longer period of minimum two days and requires participation of various banking officials even though the entire cycle is supposed to be done on the IT system customized for GST payments.

Such a discrepancy will be detected by GSTN when it undertakes a reconciliation of the challan details (CIN) of a day available with it with the e-scroll of the same day received from RBI on T+1 basis. In such cases, the correction mechanism will involve the following steps:

i) If CPIN and associated data reported in the scrolls received from RBI matches with GSTN’s CPIN data, GSTN can forward the entire challan details of that CPIN to the concerned Accounting Authorities with a copy to Tax Authorities. There will not be any need for MOE in such case. The Accounting Authorities will carry out the accounting based on scroll data received from RBI and tally it with the challan data (CIN) now received from GSTN. GSTN would also update the taxpayer’s cash ledger after confirming the payment from the authorized bank / RBI;

ii) If e-FPB of an authorized bank has reported a transaction to RBI in GST luggage file, without it being a GST transaction or without realization of the amount, it should take up such cases for refund outside the MOE process as a more comprehensive verification will be needed before allowing the refund. For minimizing this kind of error, the bank’s IT system should have validations/controls mentioned in para 85 above;

iii) Only if the CPIN and associated data in the scroll does not match with GSTN’s data there will be a need for MOE. That will be type c) error, discussed in the paragraph below. In those cases, the Accounting Authority should create MOE with a UIN and communicate it to RBI with a copy to e-FPB of the concerned authorized bank. (The Accounting Authorities will identify the concerned bank on the basis of bank code contained in the CIN reported against the successful CPIN in the e-scroll received from RBI).

114. This kind of error can be minimized through suitable validations in the bank’s IT system. If the error still occurs, it will be noted when the scroll data is processed by GSTN / Accounting Authorities. Even if the error gets noticed earlier as mentioned in para 109 above but remains unresolved till the time of reporting to RBI on T+1 basis, the bank should report the transaction to RBI with whatever CIN data it has received from the e-FPB of authorized bank. The bank should not hold back any balance in the tax accounts beyond the reporting time to RBI in respect of transactions of the previous day. When such unresolved transaction is reported to RBI, it should carry a flag indicating type of discrepancy. RBI should credit the amount to the account of the respective government as mentioned in the luggage file. As the scroll from RBI will have an unresolved CPIN discrepancy, the Accounting Authorities may credit the amount to a separate sub-head under the relevant major head and simultaneously take up MOE process. If the discrepancy pertains to the total challan amount, its impact on individual taxes will get known during reconciliation of the scroll data with the challan data, and the Accounting Authorities of the affected government should take up MOE process.

d) Money transferred to wrong government accounts though CIN matches with data in e-scroll received from RBI (major head level):

115. It may so happen that while sending the luggage file to RBI, the e-FPB of the authorized bank / RBI reflects the amount received in a tax head different from the one specified in the challan (major head level) (CPIN).

116. In such a situation, Accounting Authorities will play a crucial role as they are statutorily responsible not only for proper accounting of money but also for its credit into the correct government account. This discrepancy will be ascertained by the Accounting Authorities while carrying out reconciliation between the challan data obtained from GSTN on T+1 basis (detailing major heads) and e-scroll (for each major head separately) received from RBI. Steps involved in the correction mechanism are as follows:

i) The relevant Accounting authority would generate MOE with UIN and communicate the same to RBI. Accounting Authorities of the Centre and States will have to initiate MOE in respect of their respective taxes;

ii) RBI to ascertain from e-FPB of the concerned Authorized bank / RBI (in case of Mode III) and get the discrepancy corrected within a time period of 2 days from the receipt of MOE from the Accounting Authorities;

iii) E- FPB of the concerned Authorized bank / RBI would verify the details in the CIN transmitted to GSTN with the details transmitted to RBI in the daily luggage file. Thereafter correction entry would be transmitted to RBI in a separate luggage file with UIN of MOE;

iv) On the basis of information transmitted by e-FPB of the concerned Authorized bank, RBI would carry out the corrective Debit/Credit entries in the accounts of the concerned governments;

v) Thereafter RBI would send a separate e-scroll relating to MOE to the relevant Accounting authority about the corrective entry carried out resulting in reconciliation and correction;

vi) Relevant Accounting Authority to account for the corrective entry in its records and report correction of MOE to GSTN and relevant Tax authority thereby completing the transaction cycle;

vii) RBI to take steps to penalize e-FPB.

e) CIN neither transmitted to GSTN nor conveyed in luggage file from authorized bank to RBI and therefore not included in e-scroll received from RBI:

117. This scenario will reflect the failure of the system at two ends. In this scenario the taxpayer has properly paid taxes into the government account through authorized / non-authorized banks but the same has neither been reported to GSTN nor to RBI thereby in effect eliminating the transaction from the system itself. So it is crucial that suitable protocol should be developed for dealing with this kind of errors. It has to be kept in mind here that CPIN generated at GSTN has a validity period of only 7 days within which the payment is to be tendered. This error cannot be ascertained on the basis of any reconciliation as there will not be any flow of information from authorized banks / RBI. The error will be noticed only when the taxpayer on not receiving a credit confirmation SMS from GSTN or not finding the credit in his ledger inform GSTN. Steps involved in correction are:

i) In case of OTC payment through authorized banks in cash or by instruments drawn on the same bank, taxpayer will be provided with an instantaneous acknowledgement by the bank containing CIN. As CIN is available with the taxpayer, he should inform GSTN about the transaction (CIN, bank branch where OTC payment was made and date of payment). On the basis of this information, GSTN should ascertain from e-FPB of the concerned authorized bank regarding receipt of payment. Once the confirmation is received through an electronic string, GSTN will validate the same against CPIN and thereafter the tax paid challan (CIN) will be credited to the taxpayer’s ledger. e-FPB of the Authorized bank is now expected to include this receipt in the luggage file for the day for transmission to RBI.

ii) In case of OTC payment through authorized banks by instruments drawn on another bank in the same city, the process of giving acknowledgement would be in two steps. In case CIN is not reported to GSTN by the e-FPB of the authorized bank, the taxpayer may follow the procedure detailed in sub-para i) above. E-FPB of the authorized bank is now expected to include this receipt in the luggage file for the day for transmission to RBI.

iii) In case of OTC payment through banks via NEFT/RTGS, upon successful completion of the transfer at the end of the bank, the taxpayer will get a receipt detailing Unique Transaction Reference (UTR). Taxpayer can thereafter login into GSTN and update the details of UTR provided by the bank for NEFT/RTGS transaction in the challan. GSTN is expected to communicate the UTR to RBI. In case the CIN is not communicated by RBI, GSTN will now take up the matter with RBI (instead of with authorized bank) in the manner detailed in sub para i) above. RBI is now expected to include this receipt in the e-scroll for the day, if NEFT/RTGS remittance was received. If the remittance was not received, RBI will inform GSTN accordingly. In turn, the tax payer will be intimated by GSTN for taking up the matter with his bank (through which NEFT / RTGS was effected by him) for deficiency of service.

f) Sum total of amount for a CIN reported in e-scroll by RBI is lesser / greater than that reported by e-FPB of authorized bank / RBI to GSTN:

118. This error relating to the shortfall can occur if a bank has deducted collection charges in Mode II and a bank has collected remittance charges for NEFT / RTGS transaction from the challan amount Mode III . Such errors in Mode II can be minimized through suitable validations in the bank’s IT system. In such case, one of the tax amounts will be less than the amount indicated in the challan. The relevant Accounting Authority (for whom the amount received is less than the amount mentioned in challan) will have to take up MOE process with RBI with a copy to the concerned bank as detailed in para 116 above for getting the shortfall amount.

119. In case the amount in the scroll is more than the challan amount for any tax, the bank will have to raise the MOE with the concerned Accounting Authority for the refund. Without approval of the Accounting Authority, the banks should not be allowed to adjust the excess amount against future receipts.

Fourth leg of communication of data is between RBI and GSTN & Accounting Authorities:

120. RBI is collating luggage files from e-FPBs of various authorized banks, including amount received by it in Mode III and thereafter generating and transmitting e-scrolls Major head wise to Government of India and SGST (state wise). During collation of the data, an error can creep into e-scroll resulting in missing / additional transaction. Since there is simultaneous flow of information to two different agencies i.e. GSTN and Accounting Authorities, following situations may arise:

a) Transaction reported to GSTN by e-FPB of authorized banks but not by RBI in its e-scroll (CIN level);

b) Transaction reported by RBI in its e-scroll but not by e-FPB of authorized bank / RBI to GSTN (CIN level);

c) Transaction reported by RBI but with incorrect details of CIN (CIN level);

d) Sum total of the amount for CIN reported to RBI is lesser/greater than that received by GSTN/Accounting Authority.

e) There is mismatch between tax wise amounts while the total challan amount matches.

121. In all the situations mentioned above, the reconciliation and error correction mechanism would be similar to that in the third leg of communication (para 110 to 119 above) as the source of discrepancy cannot be identified. It can be at the bank level or at RBI level. Therefore, the concerned Accounting Authorities should take up MOE with RBI with a copy to concerned authorized bank. RBI should first verify the data at its own end for corrective measure, if the error had arisen from its actions, if the source of error is found by RBI to be the one of the authorized bank, it should facilitate/ensure corrective measure by the identified bank in a time bound manner.

Recording by Tax Authorities:

122. After reconciliation and successful accounting of each payment, the transaction level data with unique accounting number, if required by a State Government (some governments have that practice) should be communicated by the Accounting Authorities to the Tax Department’s system for updating the records, which would finally contain following unique Ids for each receipt:

a) CIN;

b) GSTIN;

c) Bank Transaction Number (BRN);

d) RBI Transaction Number;

e) Accounting Entry ID Number/confirmation flag.

The presence of all the above mentioned five fields would constitute the assurance for credit to the government account with RBI, and the reconciliation and accounting in the government books.

Challan Correction Mechanism:

123. In view of the presumptions listed above, the requirement of providing for a challan correction mechanism would be minimal though not completely ruled out. The Committee recommends for providing the correction mechanism in following situations:-

a) ERROR IN GSTIN: This may happen in situations where the payment of tax is being made by either authorized representative such as CA or any other person on behalf of the taxpayer. Such kind of error will have no impact on the transfer of the funds to the account of the concerned governments as the money will be correctly transferred on the basis of the CIN. Further once the payment confirmation is received by GSTN from the concerned bank then the amount will be credited to the ledger of the taxpayer whose GSTIN is mentioned in the electronic string that is relayed by the bank to GSTN (earlier the same GSTIN was communicated by GSTN to bank). Therefore taking into account both the above factors as well as the fact that Challan has been generated either by the taxpayer himself or through his authorized representative and the mistake being committed has no impact on the funds with tax administration, there is no need for providing an error correction mechanism for the same. The authorized representative, acting as an agent for the taxpayer should be responsible to the principal for any error committed while performing authorized acts and tax administration should have no role to play in this matter.

b) ERROR IN MAJOR HEAD: In such a scenario, the bank though has collected the correct amount but has credited the wrong head of tax account. This would impact the transfer of funds to the account of the respective governments as bank has transferred the funds on the basis of the data not detailed in CPIN. Thus bank would be required to withdraw funds from one account and credit the other account(s). It is proposed to permit banks to rectify such error before the end of the day during which the amount has been received by the bank as at the end of the day, the amount would have been credited in respective government accounts and thereafter the same would also have been accounted by Accounting Authorities of the Centre and State. No correction in the challan data is required even in this case. If the error is noted after reporting of the credit on T+1 basis, the normal MOE process should be used.

c) ERROR IN TOTAL AMOUNT: If the amount paid is in excess then there is provision for either claim of refund by the taxpayer or the amount can be carried forward to the next period and therefore there is no need to provide for correction mechanism.

124. In view of recommended maintenance of cash ledger, the fields relating to ‘Tax period’ and ‘purpose’ will not be captured in the challan as being done presently and therefore correction mechanism for correcting these two fields has not been provided for.

CHALLAN FORMAT:

125. e-Challan will remain the source document for the purpose of accounting and reconciliation by the accounting authorities of the Centre/States/UTs. The Office of C & AG has stressed upon the need for ensuring the availability of e-Challan for accounting and reconciliation purposes. A proper Challan format (Annexure -IV) that covers all the details required for accounting and reconciliation is essential to be prescribed, that will be treated as proof of payment to the government.

126. In the GST regime, the existing practice of entry of challan data at the bank branch level will be dispensed with as the challan would be shared on real time basis from the GSTN portal to the CBS of the authorized bank / RBI indicated in the challan.

127. Central Government Accounts (Receipt and Payment) Rules, 1983 provides for submission of Challan in form GAR 7 along with the payments to facilitate the Pay and Accounts Officer to classify the receipts accurately in his accounts. The form will need to be suitably modified for use in the electronic systems envisaged for GST payments. Almost all the information currently required in GAR 7 has been provided in proposed GST challan form. However, as discussed in para 14 above, the jurisdictional location code will not be available in the challan and the same would need to be mapped with the help of the backend system of each tax administration.

(Satish Chandra)

Member Secretary

Empowered Committee of State Finance Ministers

(Rashmi Verma)

Additional Secretary

Department of Revenue

Government of India

Annexure-I

EMPOWERED COMMITTEE OF STATE FINANCE MINISTERS

DELHI SECRETARIAT, IP ESTATE, NEW DELHI – 110002

Tel. No. 2339 2431, Fax: 2339 2432 e-mail: vatcouncil@yahoo.com

No.15/45/EC/GST/2014/32

Date: 7th April, 2014

JOINT COMMITTEE ON BUSINESS PROCESSES FOR GST

During the last Empowered Committee meeting held on 10th March, 2014, it was decided that a Joint Committee under the co-convenership of the Additional Secretary (Revenue), Government of India and the Member Secretary, Empowered Committee should be constituted to look into the Report of the Sub-Group-I on Business Processes for GST and make suitable recommendations for Registration and Return to the Empowered Committee. It was also decided that the Joint Committee should also keep in view the Registration and Return requirements necessary for IGST Model. Accordingly, a Joint Committee, in consultation with the Government of India, is constituted with the following members:

Government of India

(1) Smt. Rashmi Verma, Additional Secretary (Revenue) — Co-convener

(2) Shri P.K. Mohanty, Joint Secretary (TRU-I)

(3) Shri M. Vinod Kumar, Joint Secretary (TRU-II)

(4) Shri J.M. Kennedy, Director (TRU-II)

(5) Director/Deputy Secretary holding the charge of State Taxes Section

States Government

(1) Dr. J.B. Ekka, Commissioner of Taxes, Assam

(2) Shri Prashant Goyal, Commissioner, Trade & Taxes, Delhi

(3) Shri H.V. Patel, Commissioner, Commercial Tax, Gujarat

(4) Shri Sudhir Rajpal, Commissioner, Excise & Taxation, Haryana

(5) Shri Kifayat Hussain Rizvi, Commissioner, Commercial Tax, J&K

(6) Shri Ajay Seth, Commissioner, Commercial Tax, Karnataka

(7) Shri Shyam Jagannathan, Commissioner, Commercial Tax, Kerala

(8) Shri Amit Rathore, Commissioner, Commercial Tax, Madhya Pradesh

(9) Dr. Nitin Kareer, Commissioner, Sales Tax, Maharashtra

(10) Shri Abhishek Bhagotia, Commissioner, Commercial Tax, Meghalaya

(11) Shri Manoj Ahuja, Commissioner, Commercial Tax, Odisha

(12) Shri Sanjay Malhotra, Commissioner, Commercial Tax, Rajasthan

(13) Shri K. Rajaraman, Commissioner, Commercial Tax, Tamil Nadu

(14) Shri M.K. Narayan, Commissioner, Commercial Tax, Uttar Pradesh

(15) Shri Dilip Jawalkar, Commissioner, Commercial Tax, Uttarakhand

(16) Shri Binod Kumar, Commissioner, Commercial Tax, West Bengal

Empowered Committee of State Finance Ministers

(1) Shri Satish Chandra, Member Secretary — Co-convener

2. The Committee will submit its report to the Empowered Committee in two months time.

Sd/-

(Satish Chandra)

Member Secretary

Empowered Committee of State Finance Ministers

Copy to: All the Members of the Joint Committee

Copy also to:

(1) PS to Chairman, Empowered Committee of State Finance Ministers

(2) Adviser to Chairman, Empowered Committee of State Finance Ministers

During the meeting of the Joint Committee on Business Processes for GST held on 2nd February, 2015, it was decided that a Sub-Committee should be constituted to consider the Report of the Committee for Finalizing Payment Processes under GST and to give its recommendations for the consideration of the Joint Committee on Business Process for GST. Accordingly, a Sub-Committee consisting of the following officers was constituted:

Government of India

1.

Shri Shashank Priya, Commissioner, GST Cell, CBEC,Government of India

Co-convener

2.

Shri Upender Gupta, Additional Commissioner, CBEC Government of India

Member

3.

Shri Manish Saxena, Additional Director, Directorate General of Systems, Government of India

2. It was also decided to request RBI, Principal Chief Controller of Accounts, CBEC and Controller General of Accounts to nominate senior officers to attend the meetings of the Sub-Committee/Committee.

3. It was further decided that the first meeting of the Sub-Committee will be held at 10.00 am on 14th February, 2015 at Hotel Le Meridien, Bangalore. All the members of the Sub-Committee are requested to kindly make it convenient to attend the meeting of the Sub-Committee. They are also requested to intimate their travel programme to Shri Ritvik Ranjanam Pandey, Commissioner Commercial Tax, Karnataka (Tel: 080-22264495, Fax: 080-22263595 and e-mail: ritvik@gov.in) so that necessary arrangements for their boarding, lodging and transport could be made under intimation to the Empowered Committee.

Sd/-

(Satish Chandra)

Member Secretary

Empowered Committee of

State Finance Ministers

Copy to:

Additional Secretary (Revenue), Government of India with the request to kindly request RBI, Principal Chief Controller of Accounts, CBEC and Controller General of Accounts to nominate suitable officers to attend the meeting in Bangalore and subsequent meeting of the Joint Committee on Business Process for GST, when the Business Process for payment is considered by the Committee.

1. Under the charge back claim, a taxpayer after making payment through credit card may seek refund of the money till 60 days of the transaction. Usually such refunds can be sought under three scenarios:

(i) Payment was made fraudulently by someone using the card of others;

(ii) Extra payment was made because of some technical error during payment;

(iii) Some service was not delivered for the payment made.

2. During the past few years, there have been significant changes in the security systems surrounding a transaction done through credit cards. The nature of such transactions has undergone changes because of introduction of two factor authentication and OTP (one time password) as per RBI’s regulations. Under such circumstances it has become more improbable to have fraudulent transactions. Banks also have stopped entertaining claims caused by fraudulent transactions. As such scenario (i), i.e., payment through fraudulent use can be practically ruled out.

3. In scenario (ii) arising from technical errors, the errors can be detected even before any transaction is reported to RBI on T+ 1 basis. The acquiring banks should have a validation in their IT system that no double payment is reported for a tax against the same CPIN. If a credit card has been charged twice for the same challan total amount, the additional collection may be refunded by the acquiring bank.

4. In case the technical error of charging the card twice is noticed after the transaction has been reported to GSTN on real time basis but before the reporting to RBI on T+ 1 basis, the acquiring bank can refund the amount under real time intimation to GSTN. Thereafter, such double payment should not be reported to RBI.

5. In case the technical error is detected after reporting to RBI on T+ 1, the acquiring bank should send the claim to GSTN with full details. GSTN should verify its database, and confirm to the bank regarding double payment received against the same CPIN.

6. There should be a validation in GSTN’s system that such double payments (para 4 and 5 above) are either not reflected in the tax payer’s ledger or the second payment against the same CPIN is barred from utilization. Based on the confirmation from GSTN, the acquiring bank can refund the extra payment.

7. For scenario (iii) arising from claim of non-delivery of service, the acquiring bank should send the claims to GSTN with full details. GSTN can rebut the claim by providing a copy of the Challan (pdf file generated from its system) used for making the payment and details of the tax-payer’s ledger account in which credit was made to show that the service was provided. The bank can use the above details /document as a sufficient basis to repudiate any charge back claim for non-delivery of service. Such evidences have to be provided to banks within 48 hours of the claim.

8. Even if the charge back request for scenario (iii) is received by the acquiring bank before reporting of the transaction to RBI on T+ 1, the bank should send the claim to GSTN for a response. GSTN should verify its record, and rebut the claim as mentioned in para 7 above. GSTN will have 48 hrs to send its response. In the meantime at T+1 event, the acquiring bank should report the transaction to RBI in normal course. The bank should not hold back the funds. Subsequently when the response is received from GSTN, the bank may either decide to reject the claim (most likely as it is fairly easy to establish that the tax was actually paid to the Government and there was no denial of service) or accept the claim. If the claim is accepted, the process suggested in para 9 below may be followed.

9. In case the charge back is accepted after reporting to RBI (either in case of scenario (ii) or in case of scenario (iii) when GSTN’s rebuttal is not accepted) and refund is made by the acquiring bank to the issuing bank, such refund should be reported as a new transaction to RBI. The report to RBI as well as the entry in RBI’s scroll should be as a debit entry identified using the original CPIN. On receipt of such information, GSTN should debit the taxpayer’s ledger and inform the Tax Authorities who should recover the amount from the said taxpayer.

Updation of TaxHeal on daily basis takes lot of time and effort .Donations help me to continue support and development of this free website.If you like TaxHeal and you gained something, isn’t that worth a coffee or two? Please consider donating via PayPal