e-TDS/TCS Filing Complexities in RPU Ver. 5.9 and Solutions

Complexities of filing of e-TDS/TCS Regular and Correction Statements and Related Compliance Using Return Preparation Utility Ver. 5.9 and Recommended Solutions

Introduction

The landscape of Tax Deducted at Source (TDS) and Tax Collected at Source (TCS) compliance in India demands uncompromising precision, requiring taxpayers, accountants, and tax professionals to bridge a formidable gap between complex legislative provisions and rigid, often unforgiving technological utilities. The Centralised Processing Cell (CPC-TDS), operating primarily through the TRACES portal, has fundamentally transformed the administration of withholding taxes by transitioning from localised, manual oversight to a highly automated, data-driven national ecosystem. While this systemic shift has introduced transparency and tax-credit matching efficiency, it has unleashed technical and operational challenges for the professionals responsible for executing the compliance mandate.

For the modern tax practitioner, the challenge is inherently twofold. First, there is the technical necessity of mastering the peculiar nuances of the Return Preparation Utility (RPU), the File Validation Utility (FVU), digital signature cryptographic configurations, and the complex tangle of validation error codes that dictate the acceptance of electronic returns. Second, there is the operational necessity of managing the chaotic incursion of client data, navigating communication breakdowns, handling vast volumes of unstructured financial records, and maintaining professional sanity against the backdrop of unforgiving statutory deadlines and potentially crippling financial penalties.

The execution of a flawless TDS/TCS return requires far more than mere mechanical data entry. It demands a sophisticated understanding of system dependencies, data sanitation protocols, statutory limitations, and many structured dispute resolution frameworks, which require an exhaustive, granular exploration of the entire e-TDS/TCS lifecycle, identifying every conceivable obstruction from initial software installation to post-filing rectification, and offering tested, professional-grade solutions to ensure seamless, penalty-free compliance.

Phase 1: The Technological Foundation and Pre-Requisite Architecture

The genesis of every TDS/TCS filing cycle begins with the prescribed governmental utilities: the Return Preparation Utility (RPU) and the File Validation Utility (FVU), provided by Protean (formerly NSDL). Although these tools are freely available and theoretically straightforward to deploy, their actual installation is frequently derailed by environmental incompatibilities, operating system constraints, and obscured software dependencies.

Decoding Java Runtime Environment (JRE) Dependencies

Both the RPU and FVU are native Java-based applications. The most common point of total failure during the initialisation of these tools is a missing, outdated, or conflicting Java Runtime Environment (JRE). The utilities typically require JRE versions ranging from 1.6 to at least 1.8 update 60 to function correctly.

When a taxpayer or a practitioner double-clicks the TDS_RPU.jar executable file and faces complete unresponsiveness, a silent failure where no window opens and no error message is generated, the root cause is almost exclusively Java-related. Modern operating systems and endpoint security protocols frequently block or auto-disable Java due to security vulnerabilities, rendering the tax utilities inert. To permanently resolve this, the local machine must host the correct architectural version of Java (32-bit versus 64-bit) that corresponds perfectly to the underlying operating system.

Furthermore, relying on the standard online Java installer often results in timeouts or corrupted installations due to network fluctuations. Utilising the Windows Offline Installer package directly from the official Oracle repository bypasses these network-level interruptions and forces a complete and successful installation. Post-installation, it is frequently necessary for the practitioners or their IT support to manually map the Java installation path within the Windows Environment Variables. This ensures that the operating system natively recognises .jar files and explicitly associates them with the Java platform, preventing the system from treating them as unrecognisable archive files.

Archive Extraction, Cache Conflicts, and Path Configuration Failures

A seemingly trivial yet remarkably persistent operational delay occurs during the initial extraction of the downloaded utility archives from the Protean TIN website. Practitioners frequently encounter baffling “File Corrupted” or “Cannot Extract” system errors. This is rarely a server-side issue. Rather, it is the result of local browser caching conflicts. The browser attempts to open a partially downloaded, interrupted, or historically cached version of the .zip file. The remedy is to perform a hard refresh or deliberately clear the browser cache before initiating the download, and to utilise dedicated, robust extraction software (such as WinRAR or 7-Zip) rather than relying on the occasionally unstable native Windows Explorer extraction tools.

Once successfully extracted, the specific physical location of the utility directory plays a critical role in its stability. The infamous “Error 76 – Path Not Found” is a fatal runtime error that severely disrupts the preparation of returns and the generation of FVU output files. This error is a classic manifestation of operating system constraints clashing with poor data hygiene. It triggers when the directory path contains special characters, excessive spaces, or when the folder hierarchy is so deeply nested (e.g., C:\Users\Name\Desktop\ClientData\Financial Year 2024-25\Quarter 4\TDS Returns\RPU_Version_4.8) that it exceeds the 256-character maximum path length permitted by the Windows API.

Moreover, Error 76 is frequently caused by invisible typographical errors. If a practitioner or a taxpayer inadvertently leaves a trailing space at the end of a Deductor’s Code or a folder name, the software will subsequently look for a directory path that technically does not exist, triggering the crash. The permanent solution is twofold: audit the Deductor Master data to purge any trailing whitespace, and house the RPU and FVU folders as close to the root directory of the hard drive as physically possible (e.g., simply C:\TDS_Utilities\) to ensure the path remains brief and structurally pure and accurate.

Overcoming Outdated Encryption Certificates

Another obscure technical hurdle that frequently baffles even seasoned professionals is the validation error stating: “Encryption certificate present in FVU/RPU folder is old”. The FVU is designed to validate the digital integrity of the generated return against an internal cryptographic certificate. When Protean releases a new FVU version, it inherently contains updated encryption keys and certificates.

Many practitioners utilise third-party TDS software suites rather than the raw RPU. If they update the main interface of their third-party software but the software fails to automatically overwrite the underlying legacy FVU .jar and certificate files located deep within its root directory, the validation process will abruptly halt. Rectifying this requires manual intervention. Practitioners must download the latest standalone FVU zip file from the Protean website, extract contents, navigate to the specific installation directory of the third-party tax software (e.g., C:\Program Files (x86)\Spectrum\Zen TDS\e-TDStcsfvu), and overwrite the legacy files with the newly downloaded versions in a manual manner.

Phase 2: Data Sanitation, Reconciliation, and The Excel Battleground

TDS and TCS compliance are data-intensive. Practitioners frequently find themselves managing tens of thousands of individual deductee records, primarily relying on Microsoft Excel as the universal intermediary staging ground before ultimately importing the data into the RPU or a third-party software engine. While Excel is a powerful analytical tool, it possesses aggressive automated formatting behaviours that routinely corrupt specific types of critical financial and identification data, turning data preparation into a rather herculean task.

The Disappearance of Leading Zeros: Protecting Identifiers

A highly disruptive issue is Excel’s innate tendency to strip leading zeros from numerical sequences. Many critical statutory identifiers, such as postal PIN codes, specific employee identification numbers, and crucially, Challan Serial Numbers, frequently begin with a zero. When a client exports their raw accounting data and provides a CSV file containing a challan serial number like 001234, opening that file normally in Excel automatically converts the value to 1234. If this truncated, incomplete number is imported into the RPU and then validated against the government’s OLTAS (Online Tax Accounting System) database, it triggers a mismatch, causing the tax credit to vanish.

To preserve absolute data integrity, professionals must actively override Excel’s default calculation behaviours. The most robust methods include:

1. The Apostrophe Prefix Method: For manual data entry or quick fixes, entering a single quote or apostrophe (‘) immediately before the number forces Excel to interpret the cell contents strictly as a text string. This retains the leading zeros perfectly without displaying the apostrophe in the final printed output or the exported file.

2. Custom Number Formatting: For large datasets requiring a fixed, statutory character length, applying a custom format mask is highly efficient. By highlighting the column, navigating to Format Cells -> Custom, and entering a mask such as 000000 (for a mandatory six-digit field), the user ensures that any inputted number visually retains its necessary zero padding.

3. PowerQuery Import Transformation: When importing massive raw CSV files provided by enterprise clients, relying on simple double-clicking is dangerous. Utilising Excel’s PowerQuery feature (Get Data -> From Text/CSV) allows practitioners to intercept the data. By defining the specific column’s data type as “Text” during the PowerQuery transformation phase, the software is prevented from ever evaluating the identifiers as mathematical values, perfectly preserving the leading zeros from the source file.

PAN Validation Frameworks and the Cost of Mismatches

The accuracy of the Permanent Account Number (PAN) is the absolute bedrock of the entire TDS and TCS ecosystem. An incorrect PAN is not merely an administrative typo but a critical compliance failure. It denies the deductee their tax credit in their Form 26AS, triggering disputes. More alarmingly for the deductor, quoting an invalid PAN immediately invokes the provisions of Section 206AA of the Income Tax Act, which mandates tax deduction at a rate of 20% (or higher, depending on the specific section).

Relying solely on client-provided vendor master data without independent, systemic verification is an unacceptable operational risk. Professional practice requires the use of bulk PAN verification tools, which are natively integrated into modern, high-tier tax software. These systems perform API calls to the TRACES database, verifying the structural validity, active status, and exact name matching of thousands of PANs simultaneously before a single line of data is ever exported to the FVU.

Challan Reconciliation: Navigating CIN and BIN Complexities

Equally critical is the reconciliation of Challan details against the OLTAS database. The government tracks deposits via the Challan Identification Number (CIN) for non-government deductors, and the Book Identification Number (BIN) for government entities utilising book entry transfers.

A CIN is a composite identifier comprising three strict elements that contains the 7-digit BSR code of the bank branch, the exact date of deposit, and the 5-digit Challan Serial Number. If any of these elements reported in the TDS return differ by even a digit from the data uploaded by the receiving bank to the government portal, the entire return will process with a “Short Payment” default, as the system cannot locate the funds.

To prevent these mismatches, the practitioners must integrate real-time challan mapping into their workflow. By downloading the .csi (Challan Status Inquiry) file directly from the Income Tax e-portal, professionals can cryptographically verify that the challans claimed in their internal software precisely match the government’s ledger before the FVU validation stage is even initiated.

Phase 3: Navigating the File Validation Utility (FVU) Labyrinth

The File Validation Utility (FVU) acts as the uncompromising, unyielding gatekeeper of the Indian TDS ecosystem. It subjects the raw .txt file generated by the RPU or third-party software to an exhaustive battery of structural, logical, and mathematical checks. When validation inevitably fails during the preparation cycle, the FVU generates an HTML error report containing highly specific, alphanumeric codes. Interpreting these cryptic codes accurately and knowing exactly where to apply the fix within the source data is the hallmark of a seasoned tax practitioner.

The FVU categorises errors into hierarchical record types: File Header (Record Type 1), Batch Header (Record Type 2), Challan Details (Record Type 3), and Deductee Details (Record Type 4).

File Header and Structural Errors (1000 Series)

These errors indicate that the fundamental architecture of the generated text file is flawed, preventing the utility from even reading the subsequent data rows.

Batch and Deductor Level Errors (2000 Series)

The 2000 series errors pertain directly to the demographic, geographic, and contact information of the Deductor and the designated Person Responsible for compliance.

Challan Details Errors (3000 Series)

Errors in the 3000 series are highly critical, as they indicate mathematical or structural discrepancies between the reported deposit data and the statutory formats expected by OLTAS.

Deductee and Transaction Errors (4000 & 6000 Series)

The 4000 and the newly introduced 6000 series errors govern the intricacies of individual deductee transactions. They are particularly vital as they respond to recent, complex legislative amendments.

The resolution of FVU errors requires a methodical, almost forensic approach. The professional practitioner must examine the HTML error report, trace the specific line number indicated back to the raw .txt file, identify the corresponding record type, and apply the structural fix within the host software before regenerating and re-validating the file.

Phase 4: The e-Filing Portal, EmSigner, and Digital Signature Complexities

Once a completely error-free. fvu upload file is finally generated, the compliance lifecycle shifts to the Income Tax e-filing portal. For corporate entities, LLPs, and tax audit assessees, the return submission must be authenticated using a physical Class 3 Digital Signature Certificate (DSC). The technological interface between the practitioner’s local machine, the USB cryptographic token, and the government portal is notoriously fragile, governed by a temperamental bridging utility known as emSigner (or the DSC Management Utility).

Overcoming DSC Configuration and Registration Failures

The most frequent barrier encountered at the upload stage is the portal’s outright failure to recognise or communicate with the DSC. This typically manifests as a blank screen when attempting to select the certificate or a sudden validation failure upon clicking submit.

The primary culprit is an outdated DSC utility. The Income Tax portal frequently updates its underlying security architecture, rendering older versions of the local utility incompatible. The practitioner must ensure the absolute latest utility is actively running in the background, often checking system tray icons to verify its operational status.

Furthermore, the DSC must be mapped and registered to the profile of the authorised signatory on the e-filing portal. A common trap occurs when a DSC expires and is renewed. While the name remains the same, the underlying cryptographic thumbprint of the new token is entirely different. The portal will obstinately continue to look for the old certificate, resulting in an immediate rejection. The correct protocol is to log into the portal’s profile settings, actively de-register the expired DSC, and register the fresh token.

Additionally, strict PAN matching is enforced at the cryptographic level. The PAN embedded within the digital certificate by the issuing Certifying Authority (such as eMudhra or Capricorn) must perfectly, character-for-character, match the PAN of the principal contact that is registered on the TAN profile. Any divergence will result in an insurmountable authentication failure.

SSL/TLS Trust Relationship Anomalies

A highly technical error encountered during the final signing process is the system prompt: “Could not establish trust relationship for the SSL/TLS secure channel”.

This software bug, often a cryptographical handshake occurs when the local machine’s operating system does not possess the necessary Intermediate or Root Certificates to verify the complete chain of trust of the DSC, or if there is a severe protocol mismatch (e.g., the government portal mandates TLS 1.2 for security, but the local machine is defaulting to legacy, compromised SSL protocols).

To resolve this, the practitioner must dive into the Microsoft Management Console. Utilising the Windows Certificate Manager (certmgr.msc), they must verify that the overarching Root CA (such as the Controller of Certifying Authorities – CCA India) is actually installed and active in the “Trusted Root Certification Authorities” store. If it is missing, the certificate chain is broken, and the root must be manually downloaded and imported. Additionally, ensuring that the system’s internet properties (via inetcpl.cpl) have TLS 1.2 explicitly enabled, and updating the USB token’s proprietary hardware drivers (such as ePass2003 or WatchData), will re-establish the secure cryptographic channel and allow the signature to be successfully affixed.

Phase 5: Post-Filing Architecture, Token Numbers, and Default Intimations

The successful upload of the TDS return to the portal does not mark the conclusion of the compliance cycle; rather, it merely initiates the assessment phase by the Centralised Processing Cell. Returns are processed algorithmically under Section 200A of the Income Tax Act, 2025, and any mismatch identified triggers an official intimation of default.

A pervasive operational challenge that deeply frustrates both practitioners and their clients is the delayed emergence of these defaults. Months after a seemingly successful, FVU-validated filing, a deductor may be suddenly ambushed by a substantial demand notice. The TRACES portal relies on a massive, asynchronous cross-referencing engine. It must reconcile the deductor’s uploaded data against millions of banking transactions via OLTAS, and subsequently map the resulting credits to the individual deductees’ Form 26AS and Annual Information Statements (AIS). A minor, previously undetected typographical error in a PAN, or a micro-mismatch in the deposit date of a challan, causes the credit to hang in suspense, generating an automatic default.

Decoding the Financial Impact of Defaults

These system-generated defaults typically manifest in three primary, aggressively enforced financial penalties:

1. Late Filing Fees (Section 234E): A rigid, statutory levy of Rs. 200 per day for every single day the return is delayed beyond the prescribed due date, capped only at the total amount of tax deductible. This is entirely system-generated and non-negotiable.

2. Interest on Late Deduction (Section 201(1A)): If the system detects a chronological lag between the date a transaction was credited to a vendor’s account in the books and the date the tax was actually deducted, interest is automatically applied at 1% per month (or part of a month).

3. Interest on Late Payment: Once tax is deducted, the law mandates that it must be remitted to the government by the 7th of the following month. Failure to do so attracts a severe interest penalty of 1.5% per month from the exact date of deduction until the date of actual bank deposit.

The Token Number (PRN) Lifeline

Throughout the entire lifecycle of regular and correction filings, the single most vital piece of metadata is the Provisional Receipt Number (PRN), referred to within the profession as the Token Number. This 15-digit alphanumeric string is generated upon the successful acceptance of a return at a TIN-FC or via the e-filing portal.

The Token Number acts as the master cryptographic key required to unlock almost every subsequent diagnostic and corrective action on the TRACES portal, from downloading Conso Files to requesting Justification Reports. The loss of a Token Number effectively paralyses the rectification process.

When a practitioner inherits a disorganised new client or simply misplaces a receipt, recovering the Token Number requires specific procedural knowledge. If the return was filed digitally via the Income Tax e-Filing portal, the practitioner can navigate to the ‘View Filed TDS’ section on the portal dashboard, input the exact financial year, form type, and quarter, and retrieve a downloadable PDF of the provisional receipt. This PDF is heavily encrypted, and the password is the deductor’s TAN in lowercase. Alternatively, if the original return was submitted physically via a floppy disk or CD at a TIN-FC, a formal online request for a duplicate receipt must be initiated on the Protean network. This requires the input of exact statement parameters before the duplicate is securely dispatched to the originally registered email address.

The Justification Report

When a default intimation is received, the practitioner’s primary diagnostic tool is the Justification Report. Downloaded directly from the TRACES portal, this document provides a granular, deductee-by-deductee, challan-by-challan breakdown of the precise mathematical and logical errors identified by the CPC-TDS processing engine.

Accessing the report is arduous. It requires navigating a strict multi-factor authentication protocol on TRACES, involving the precise Token Number of the relevant return, specific Challan details (BSR code, date, and amount exactly as filed), and three unique PAN-Amount combinations from that specific return. Once requested, the portal processes the file for approximately four hours before the status changes to “Available”.

The report is delivered in a raw, almost unreadable text format. The practitioner must download the specific ‘TRACES Justification Report Utility V 2.2’ to convert this raw text into a highly structured, readable Excel matrix. Through this process, the practitioner can pinpoint whether a massive default was caused by a genuine short deduction, an unmatched challan due to a transposed digit, or an invalid PAN, forming the exact blueprint for the required correction statement.

Phase 6: The Art of Rectification and C1 to C9 Correction Statements

To cure the specific defaults outlined in the Justification Report, the practitioner must create and file a Correction Statement. This crucial process requires downloading the Consolidated File (Conso File) from TRACES. Unlike the original .txt file residing on the practitioner’s local hard drive, the Conso File represents the cryptographically verified dataset as it is currently structured within the government’s central servers, capturing the precise state of the return post-processing.

Correction statements are not monolithic, generic documents; they are highly specific, categorised based on the exact architectural element of the return that requires modification. Utilising the wrong correction type will result in immediate rejection.

The Typology of Correction Statements

The following table provides an exhaustive breakdown of the official correction types, their operational scope, and real-world scenarios dictating their use:

(Note: Types C6, C7, and C8 do not formally exist within the operational TDS syntax; the schema jumps directly from C5 to C9 to structurally accommodate the distinct online-only nature of challan additions.

Modern practice dictates efficiency; multiple correction types (for example, a combined C1, C3, and C5 correction) can be seamlessly bundled and executed within a single correction file, drastically reducing the administrative burden.

The Six-Year Statutory Limitation

A profound legislative paradigm shift recently altered the strategic landscape of TDS rectifications. The Finance Act (No. 2) 2024 amended Section 200(3) of the Income Tax Act, fundamentally restricting the timeframe within which a deductor may legally file a correction statement.

Previously, correction statements could be filed indefinitely, allowing companies to clean up ancient ledger mismatches. Under the new regime, no correction statement can be delivered after the expiry of six years from the end of the financial year in which the original statement was due. This legislative change, designed to enforce finality in tax administration and align with global best practices, carries severe, immediate implications for legacy disputes.

For financial years spanning from 2007-08 to 2018-19, the CBDT provided a brief transitional window, allowing corrections only up to March 31, 2025. Any defaults, PAN mismatches, or uncredited taxes remaining after this window permanently crystallise into irrevocable, outstanding demands. Practitioners must now conduct aggressive, precautionary audits of historical TRACES data to clear lingering defaults before the statutory guillotine falls. For corrections about very old periods (pre-2011-12) where Conso files are no longer available online, agonisingly slow manual applications supported by detailed paper documentation must be routed through physical TIN Facilitation Centres.

Phase 7: Human Capital, Operational Pain Points, and the Automation Imperative

While the technical architecture of TDS compliance is formidable, the highest friction points within any firm often reside in the operational and human elements of tax practice. Tax practitioners operate in a uniquely punishing environment characterised by asymmetric information, incredibly compressed timelines, poor governmental interface design, and severe, compounding financial penalties for non-compliance.

The Chokehold of Client Communication and Data Collection

A pervasive, almost universal challenge identified across accounting firms is the chronic difficulty in obtaining correct, complete, and timely data from clients. The “shoebox” mentality persists, where clients deliver vast, chaotic dumps of unstructured, unverified financial data mere days—or hours—before a statutory quarterly deadline.

The hidden operational costs of inefficient data collection are immense. Highly skilled practitioners spend an inordinate amount of billable hours engaged in low-value tasks: chasing down missing PANs via WhatsApp, verifying unlinked challans on portal screens, and deciphering ambiguous expense classifications buried in forwarded email threads. When communication gaps occur, critical context is lost, leading to assumptions that inevitably result in FVU validation errors or subsequent CPC-TDS defaults. Furthermore, when practitioners are forced to make last-minute assumptions simply to meet a filing deadline, it frequently triggers the absolute certainty of a subsequent correction statement, effectively doubling the workload for the same initial fee.

Addressing this systemic issue requires establishing aggressive, clearly defined boundaries during the initial client onboarding phase. High-tier professional firms increasingly utilise structured communication templates and secured, cloud-based portals for document submission, actively enforcing strict internal cut-off dates beyond which data will absolutely not be processed for the current cycle. Educating the client clearly on the financial repercussions of late data—such as the triggering of 20% penal deductions under Section 206AA, or the unyielding nature of Section 234E late fees—effectively shifts the burden of urgency and financial risk back to the data source.

Time Pressure, Burnout, and the Automation Saviour

The convergence of multiple statutory deadlines (TDS quarters overlapping with GST filings and Corporate Tax audits) creates a high-pressure crucible known universally as “busy season”. During these periods, workload distribution becomes highly uneven. The highly repetitive, manual nature of TDS data entry, copying values from Excel to the RPU line by line, leads directly to severe staff burnout and a massive increase in the propensity for human error.

To survive, scale, and maintain profitability, reliance on manual Excel-to-RPU workflows must be entirely abandoned in favour of deep, systemic automation. Modern tax practices aggressively integrate automated TDS software platforms directly with the client’s ERP and the TRACES portal via secure APIs.

These platforms deploy intelligent default prediction algorithms that pre-validate data against statutory rules before FVU generation is even attempted. For example, when dealing with the highly complex Section 194Q (TDS on purchase of goods), advanced systems automatically track vendor transaction thresholds across the entire financial year. The software dynamically applies the 0.1% tax rate precisely on the specific invoice where the ₹50 lakh threshold is breached, entirely eliminating the need for manual Excel tracking. Furthermore, automated API integrations allow for the seamless, single-click background downloading of CSI files, Conso files, and Justification reports, drastically reducing the friction of the correction lifecycle.

By automating the repetitive compliance mechanics, practitioners can redirect their intellectual capital and limited time toward higher-value advisory services, such as complex transaction structuring, tax planning, and strategic client consultation.

Conclusion

The administration of TDS and TCS in India is no longer a peripheral bookkeeping task; it is a highly scrutinised, digitally integrated enforcement mechanism that forms the backbone of direct tax collection. The margin for error has been systematically and intentionally eliminated by the algorithmic precision of the TRACES portal and the rigid validation matrices of the FVU.

Absolute success in this domain demands that tax practitioners cultivate a profound dual mastery. They must possess the deep technical acumen to seamlessly troubleshoot Java environments, rapidly interpret cryptic T-FV error codes, navigate cryptographic SSL/TLS failures, and architect precise, targeted C1 to C9 correction statements. Simultaneously, they must command the operational discipline to manage uncooperative data pipelines, enforce strict client communication protocols, and leverage advanced automation to mitigate the profound risks of human error and organisational burnout.

As legislative amendments, most notably the strict six-year limitation on rectifications, continue to aggressively tighten the compliance window, the historical luxury of perpetual, lazy correction is vanishing forever. The future of TDS compliance unambiguously belongs to the proactive, tech-enabled practitioner who utilises intelligent systems to ensure the initial filing is architecturally flawless, thereby transforming a notoriously reactive, penalty-laden process into a seamless, controlled, and highly predictable professional operation.

Please note: The sections mentioned in the above article are the sections as per the Indian Income Tax Act 1961. The sections have now been replaced by new sections according to the Indian Income Tax Act 2025, which are effectively applicable from tax year 2026-27. Appropriate amendments shall be made accordingly in the Return Preparation Utility, and its subsequent versions too.