TDS or “Tax Deducted at Source” is a form of withholding tax introduced to collect tax from the very source of income in India.
A person or company who has to make payment for a specified service/product to any other person or company has to deduct tax during payment itself based on the rates defined by the government. He also has to remit the same to the government against the vendor/partner.
So the entity who makes the payment is the deductor and the entity who receives the payment is the deductee.
TDS payable is the tax deducted at source that the deductor (person/company who is making the payment) has to pay to the government on behalf of the deductee.
TDS receivable is the tax deducted at source that the deductee (person/company who is offering the service or product) has to ensure he has received from his customers based on the invoices that he has raised against his customers.
TDS Receivables reconciliation is the process of validating the tax paid by a person/company’s customers to the government against the book of accounts maintained internally by them and sometimes with the customers’ statement of accounts. Moreover the tax paid is available in the Form 26AS report available in the Income Tax website that can be downloaded.
Furthermore the datasets corresponding to invoices, credit notes, receipts, settlement of receipts against invoices, customer information and ledgers corresponding to TDS receivables.
When all the above datasets are in harmony with each other, the reconciliation is considered to be complete. When the records do not match 100%, and the cause for the unreconciled records are known and validated, corrective actions are taken in the book of accounts.
Table 1: Data Required for TDS Receivable Reconciliation
Dataset Name | Dataset Description | General Update Frequency |
---|---|---|
Sales & Returns Register | Invoices and credit/debit notes done by the company over a period of time. | Daily |
Receipts | Records which acknowledge that a sum of money has been received against a specific sale | Daily |
Settlement of Receipts / advances against Invoice Report | Records which link the credits in receivable ledger to that of the invoices/debit or credit notes. | Daily |
TDS Ledger | Records which specify the TDS portion for every transaction in the sales and returns register and also for advance receipts. | Daily |
Customer Master | Data on customers. Eg: Customer ID, TAN ID, Legal Entity, TAN Mapping to Customer ID. | Whenever a customer is created. |
Form 26AS | Statements that provide details of any amount deducted as TDS or TCS from various sources of income of a taxpayer. | Monthly |
For the TDS receivable reconciliation to be successful, many of the below issues need to be addressed. This ensures that the reconciliation can be done faster and in a more accurate manner reducing the financial risk involved with taxation.
a. Volume: In enterprises or in today’s Digital economy with sheer volume of transactions, with respect to the sales and receipts can be a nightmare for reconciliation.
b. Velocity: In Retail transactions, part of the sales register comes from offline and part of it comes from online. Further with receipts with so many options available with respect to payment gateways, financing, part payments, subscriptions etc. the data comes from multiple sources and at varying times. Collating all of it and making sense takes its own effort and doing it manually leads to a huge number of issues. With huge volume, the complexity is compounded.
c. Variety: Furthermore just like the above stated example for retail, data comes from different sources. In addition internally there can be multiple applications maintaining a Sales register because of geography, multiple entities etc. Form 26AS is the government’s document which mostly will be in PDF Format. Same goes with TDS ledger and Receipts. Consolidating them into a single standard format is tedious. Again while consolidating, we may miss a set of documents which will affect the veracity of the data.
d. Veracity: Veracity indicates truthfulness of the data.
For example: Let’s say we’ve filed an invoice of Rs.100000 and TDS of 10% for a customer. In an ideal scenario, he should’ve paid Rs.90000 for us and Rs.10000 as TDS to the government .But he might have paid us Rs.80000 only and paid TDS accordingly, taking into account some discount or disallowance which is not captured properly in internal systems or not accounted properly.
There are many other such scenarios when the veracity of the data is susceptible and causes huge reconciliation issues.
Moreover on top of the data issues mentioned above, another big issue is to ensure we are comparing apples to apples and not apples to oranges. So we need to ensure that the data on both sides of the equation are in the same format and in the same structure to even start the reconciliation.
A simple example would be the data formats across the datasets. The date format may be dd-mm-yyyy in the Sales register and yyyy-mm-dd in Form 26AS, so the challenge lies in bringing them all together under one umbrella.
Then, in our recent experiences, we have seen cases where a single TAN ID is matched against either a single or multiple customer ids (in case of multiple locations) which is valid but the reverse where a single customer id is mapped to multiple TAN’s which happens as a result of mergers or acquisitions causes problems.
In simple terms, let us consider TAN ids A and B, a customer account 12345, if 12345 is mapped against both A and B, it is difficult to reconcile because the customer may have paid to either TAN A or B, imagine the scenario with huge volume of transactions.
During the first wave of Covid (May 2020), the government had reduced the TDS rates by 25 percent to improve liquidity. Here the customer who is supposed to pay 10% TDS in case of section 194A, would have paid 7.5% due to the government’s intervention. So reconciling for that financial year and subsequent years, required another subset of guidelines.
Finally, another crucial aspect to be considered while reconciling, is that a customer may have hundreds of transactions in the Sales Register against him, but in Form 26AS, there might not be a one to one mapping against him, as a result of the customer paying in batches.
Also Form 26AS does not have the invoice references which can map it back to the Sales Register/Receipts. So it becomes manually impossible to match them since it involves finding the right set of combinations from the sales register against that of Form 26AS .
All of the above challenges require data engineering after acquisition and there is a complexity involved as well. When we do this manually, processing the data with great accuracy takes a tremendous hit.
Automation is the way to go and it can not only improve your efficiency from a resourcing standpoint but also from a reconciliation success standpoint and reducing your financial risk with respect to taxation.
An application that helps you with automation of this analysis should have powerful data acquisition and engineering capabilities, highly configurable rules engine and adjust easily with low coding effort.
We built the DataTwin TDS Receivable Reconciliation product with all of the above in mind. DataTwin Platform offers a robust platform on which features below have been built.
©2022 DataTwin. All rights reserved
Leave a comment