It could be difficult for large businesses to analyse invoices on a day-to-day basis and determine their eligibility for credit, specifically where the quantum is large.
The GST laws that took effect on July 1, 2017 required a taxpayer to file three returns: GSTR-1 (outward supplies), GSTR-2 (inward supplies) and GSTR-3 (a summary of outward and inward supplies and reporting on tax payments). However, owing to various technical challenges with GSTN, GSTR-2 and GSTR-3 never got activated, requiring the introduction of GSTR 3B. Considering various issues raised around the multiplicity of returns to be filed and also the complexity of information required to be reported, the GST Council in its 25th meeting agreed to introduce a simplified return filing mechanism. The format of the simplified return was approved in the 28th GST Council meeting.
New return filing mechanism
In the proposed new system for GST return filing, a taxpayer with a turnover above Rs 5 crore would have to file Form GST RET-1 on a monthly basis. Taxpayers with a turnover of up to Rs 5 crore have the option to file quarterly returns in Form GST RET-2 (Sahaj – business making only B2C supplies) or Form GST RET-3 (Sugam – business making B2B and B2C supplies). All the outward supplies will be reported in ANX-1 and the inward supplies will be reported in ANX-2, both of which would form a part of the above returns. The taxpayers will also be allowed to file revised return by filing an amendment return.
The new return mechanism provides an option for the supplier to upload its invoices continuously, which can then be viewed and locked by the recipient/buyer. The credit can be availed by the recipient/buyer only after the locking of the invoice. Once an invoice is locked, no amendment can be made by the supplier and any amendment has to be carried out only by issuance of a debit note or a credit note, as the case may be or after unlocking of invoice by the recipient, subject to reversal of credit. Such pending invoices will not be available for amendment by the supplier unless rejected by the recipient/buyer. If the recipient/ buyer does not take any action on the invoices appearing in ANX-2 (accepted, pending, rejected), they shall be deemed to be accepted upon filing of the return.
Separate functionality will also be provided to the recipient to search and reject an invoice that has already been accepted and credit availed. This will entail reversal of credit and interest on it, in accordance with the provisions of the GST law. The documents uploaded in FORM GST ANX-1, for any particular month by a supplier who did not file their return for the previous two consecutive tax periods, shall be made available to the recipient in FORM GST ANX-2 with an indication that the credit shall not be available on these documents.
Is the new return filing mechanism helpful?
Let us assess this by looking at the current compliance requirements under the GST law. The first and foremost was filing of the GST returns, GSTR-1 and GSTR 3B. Logically, the output supply value and the tax liability reported in GSTR-1 had to match GSTR 3B reporting. However, in the initial months, numerous mismatches were identified, resulting in the issuance of notices, either alleging short payment or excess credits. The primary reason was allowing the taxpayer to report the value of outward supplies and tax payable thereon in two different returns, whereas, ideally, GSTR-3B output side should have been auto-populated by GSTR-1 filed by the taxpayers. In fact, in the initial months, the filing sequence was reversed, i.e. GSTR 3B preceded GSTR-1. Hence, in many cases, GSTR 3B was an ad hoc reporting that was later rectified by filing GSTR-1. The new mechanism of filing returns ensures that reporting is done at a transaction level, i.e. invoice level (by way of GSTR ANX-1), which forms the basis of reporting outward supplies and tax liability thereon. The possibility of committing any error is substantially reduced, unless a particular invoice is either not reported or wrong particulars are reported. In other words, all a taxpayer has to do is upload his invoice details to generate reporting for output supplies and tax thereon.
Another aspect of complexity is the GSTR 2-2A reconciliation. The GSTR 2-2A reconciliation process has been complicated for most corporates and in many situations has resulted in a credit loss or a risk of a potential demand. It is important that the approach on reconciliation of credits is proactive and not reactive. There was always a need for introducing automated processes, which could ensure that the invoice is reconciled on a real-time basis and any errors are resolved immediately. The issue gets addressed by the new process of invoice upload and locking, whereby credit is available only once the invoice is uploaded by the supplier in GST ANX-1 and the GST RET-1 (or GST RET-3) is filed by the supplier and the said invoice (as appearing in GST ANX-2) locked by the recipient. If the supplier fails to report the invoice or do not file the returns, the recipient will not get credit, thereby requiring it to take immediate action. Whereas, under the current mechanism on credit reconciliation (2-2A reconciliation) the entire action could have been postponed until the September of the next financial year (March for 2017-18), until which time, the supplier might not be traceable.
While the above is a welcome change, it also puts the entire onus of compliance by the suppliers on the recipient. Also, the process of accepting and locking every invoice to take credit could be cumbersome if volumes are large and would take up a lot of human bandwidth, unless an automated process of matching is implemented. The process will get more complex if discrepancies are identified in the invoices uploaded by the supplier and there is a need to get the invoice amended. All of this will lead to a delay in taking credit and could lead to cashflow issues. The recipient (if he has not locked the invoice) will have to review it on a real-time basis while making the payment, considering the flexibility available to the vendor to amend the invoice any time before locking. The recipient may also keep the invoice as pending if there is a lack of clarity around taking credit, thereby restricting the vendor to amend. However, credit will be postponed until acceptance. Situations could exist where the payment of GST may have to be made in cash by the recipient on its output in a particular month. However, although credits are visible online, they can be utilised only at a later point in time. This could be onerous for businesses where the difference between tax liability and tax credit is not substantial, leading to non-utilisation of credit in the future or for a considerable length of time.
Also, recipients will have to be cautious while accepting invoices as rejection of the same at a later stage (e.g. credit is not eligible) would result in interest implications. As mentioned above, if there is unclarity on eligibility to take credit, the invoice should be kept pending, as it would otherwise result in deemed credit while filing returns.
Also, it appears that if the supplier ultimately does not file his returns or pay GST, the recipient will have to bear the loss. It is unclear as to whether, and if the answer is yes, as to how the recipient will get credit if at a later stage GST is recovered from the supplier by the tax authorities. Needless to say, the recipient will also have to take steps to ensure that there is no GST loss on account of credit. E.g. the recipient can put the GST amount on hold or the payables team not making payment to the vendor/supplier until the invoice is reported. This would lead to additional work/business disruption.
The facility to allow amendment in returns is a welcome step. However, the impact of the same on the credit flows will have to be evaluated.
Need for automation
As mentioned above, it could be difficult for large businesses to analyse invoices on a day-to-day basis and determine their acceptance/eligibility of credit, specifically where the quantum is large. This could be further complicated by the timing difference that could arise as a result of processes being followed by corporations, e.g. the prompt issuance of the invoice by the supplier, sending of the invoice copy to the recipient, prompt reporting of the invoice by the supplier, receipt and prompt recording of the invoice it its books by the recipient.
In addition to the above changes which necessitates looking at automation, we have seen additional data necessity arising out of the requirement to file GSTR 9 and GSTR 9C. This is the first year of filing these forms and most corporations are going through the struggle of gathering the data that is required to be reported. The complications increase when this data is required to be filed state-wise. Also, certain additional information required, such as HSN-wise summary, bifurcation of expenses into capital goods, input, input services, reconciliation of expenses with P&L and disclosing details of ineligible ITC, is onerous to generate and the systems may not be geared up to do so.
Considering the above, it is imperative that the process, whether it be of taking credit, or of uploading invoices or for filing returns or of preparing GSTR 9 and 9C, is entirely automated. The data should flow in a seamless uninterrupted manner, beginning from the generation of transaction documents (i.e. the invoice) until its reporting. All the relevant fields should be identified and captured, and the ERP systems should either be suitably amended to provide relevant reports, or an external tool should be used to ensure that filings lead to automated generation of required reports. Adequate checks and balances should be built while massaging the data and validation rules should be incorporated to ensure that the GST requirements are met e.g. validation rules to ensure correct HSN, consistent rate in relation to the HSN selected across invoices, type of tax – CGST and SGST or IGST, correct customer GSTN number, etc. This is assuming that the data entered is correct and no rectification is required, and if not, then there is also a need to set up automated processes for vouching the data as well; e.g. Optical Character Recognition (OCR) scanning of invoices, comparison with PO etc. OCR is a process by which the invoice data can be captured in a soft copy form from digital/scanned copies of invoices.
Another critical step on automation is reconciling the transaction level data that is being reported with the financial books (ideally to be conducted before filing of the returns for a month). Such a reconciliation may not be possible at the GL-code level and may have to be done at a line item level, which depending upon the transaction volume could be onerous. As we have seen, the differences in reporting could arise on account of multiple reasons including (a) transactions reported in the returns but not appearing in financial books (e.g. stock transfers between distinct persons) or (b) transactions reported in financial books but not in returns (e.g. non-GST supplies, accrual entries where there is no GST impact, reporting differences arising out of revenue recognition or Ind-As, deferred revenue giving rise to differences in value being reported etc.).
Also, the department audits have not yet commenced. The requirement from authorities will only increase during the coming months, based on the annual report, audit reports, returns filed (both under GST and income tax) for the company, as well as data generated by the vendors and suppliers. We have already seen government instructions to look into the mismatch between the reporting under income tax (in the returns) vs. that under GST. We have also seen instructions regarding sharing of data between the customs and transfer pricing authorities. As stated above, there could be multiple reasons for differences in the reporting under various laws, and it is necessary to work around a mechanism to generate a report on this as and when required.
This apart, we will also now see authorities getting into substantive issues relating to the eligibility of credit, credit reversals, distribution of credits, cross charge and deemed value where full credit is available and interpretation around what is full credit, and it is only prudent that the verification and reversal (for non-eligible credit) is completed beforehand. Keyword search/creating a database of keywords (e.g. food, car hire, motor vehicle, construction etc. or GTA, transporter, reverse charge etc.) could help generate a listing of transactions containing the said keywords and help identify instances of non-eligible credit or reverse charge transactions. Modules can be developed for automated reversal or distribution of credits, which can then be verified. AI tools can be used to enable the system to learn and understand transactions where credit is being taken and then highlight exceptions. e.g. a Rule built on Vendor name providing services under a particular HSN where credit has been availed in the past or alternatively, credit has not been availed. The tool can identify deviations and as and when the deviations are identified, the tool can keep learning and improvising. We have all heard about smartphones which are capable of analyzing our daily activities and improvising on this basis, including creating routines etc.
Traditional ERP systems are unlikely to provide such information readily, and even if customised, could be a huge cost issue. Considering that the base data is the same, what is needed is an integrated tax management solution that could churn the same data based upon different sets of rules and would also be able to prepare reconciliation statements, with adequate level of detailing and an audit trail. The solution should be capable of being used for compliance requirements under different laws e.g. transaction data captured for GST should be capable of being used for filing GST returns, as well as analysing TDS compliance or for generating tax audit reports under Income tax. Also, the solution can be configured to highlight some evident exposures arising out of reporting under different laws e.g. withholding tax requirement identified in respect of a transaction under income tax could raise a red flag for reverse charge payment under GST.
The government is far ahead on technology, as is evident from the notices that are being issued arising out of data-analytics being carried out by GSTN, and as their database would expand further, this would only increase. Clearly the corporations need to gear up and be ready.
Ritesh Kanodia is Partner at Dhruva Advisors.
First Published: IST