XBRL Filing for Indian Companies: Everything CAs Need to Know for FY 2025-26

What XBRL Is and Why MCA Mandates It

XBRL (eXtensible Business Reporting Language) is a global standard for exchanging financial information electronically. Unlike a PDF or Excel file, an XBRL document tags every financial data point with a machine-readable label from a standardised taxonomy. This allows regulators to automatically aggregate, compare, and analyse financial data across thousands of companies.

The Ministry of Corporate Affairs (MCA) mandates XBRL filing for specific classes of companies as part of the AOC-4 annual filing. The mandate applies to:

• All listed companies
• All companies with paid-up capital of Rs. 5 crore or more
• All companies with turnover of Rs. 100 crore or more
• All companies required to prepare financial statements under Ind AS

For these companies, the financial statements must be filed in XBRL format in addition to the standard AOC-4 form. The XBRL instance document is a separate XML file that encodes every line item of the Balance Sheet, Profit & Loss, and key Notes.

Two Taxonomies: Understanding the Difference

MCA maintains two distinct XBRL taxonomies, and using the wrong one is an automatic rejection.

Commercial & Industrial (C&I) Taxonomy

Applies to companies preparing financial statements under Indian GAAP (Division I of Schedule III). The C&I taxonomy maps to the Division I line item structure — Share Capital, Reserves and Surplus, Long-term Borrowings, and so on.

Ind AS Taxonomy

Applies to companies preparing financial statements under Ind AS (Division II of Schedule III). The Ind AS taxonomy maps to the Division II structure — Equity Share Capital, Other Equity with OCI components, financial instruments by measurement category, and so on.

Critical point: The two taxonomies have different element names for what may appear to be the same concept. "Reserves and Surplus" in C&I taxonomy is NOT the same element as "Other Equity" in Ind AS taxonomy, even though both represent accumulated equity beyond share capital. You cannot cross-reference between taxonomies.

The V3 Portal Migration: What Changed

MCA's migration to the V3 portal (MCA21 Version 3) introduced several changes that directly affect XBRL filing:

Schema URL Changes

The most impactful change is the schema URL. Every XBRL instance document references a taxonomy schema URL that tells the MCA validator which taxonomy version to validate against. The V3 migration updated these URLs.

Instance documents generated with pre-V3 schema URLs will be rejected outright by the V3 validation engine, even if the financial data is perfectly correct. This is the single most common cause of XBRL rejections post-migration.

Validation Rule Updates

The V3 portal introduced stricter validation rules:

• Boolean values must be expressed as "true" or "false" (lowercase). Pre-V3, some validators accepted "True", "Yes", or "1".
• Percentage values must be at the correct scale. A value of "18%" must be expressed as "18" (not "0.18") in most contexts, but some elements expect the decimal form. The taxonomy documentation specifies the expected scale.
• Date formats must be ISO 8601 (YYYY-MM-DD). DD-MM-YYYY format, common in Indian practice, is rejected.
• Mandatory zero-value elements must be present. If a line item is zero, the XBRL element must still appear with a zero value — it cannot be omitted.

Common XBRL Rejection Causes (and How to Avoid Them)

Based on MCA filing data and CA feedback, these are the top rejection causes ranked by frequency:

1. Wrong Schema URL (30-35% of rejections)

Cause: Instance document references a pre-V3 or incorrect taxonomy schema URL. Fix: Verify the schema URL against the current MCA taxonomy documentation. As of FY 2025-26, the V3 URLs are the only accepted references. Any XBRL generation tool must be updated to use these URLs.

2. Incorrect Boolean Formatting (15-20% of rejections)

Cause: Boolean elements (e.g., "Whether company is SME", "Whether auditor's report is qualified") use non-standard values. Fix: Use strictly lowercase "true" or "false". Never use "Yes/No", "1/0", or capitalised forms.

3. Percentage Scale Errors (10-15% of rejections)

Cause: Percentage values expressed at the wrong scale. For example, a tax rate of 25.17% entered as 0.2517 when the taxonomy expects 25.17. Fix: Check each percentage element's unit definition in the taxonomy. Most MCA taxonomy percentage elements expect the value as a whole number (25.17), not a decimal (0.2517).

4. Missing Prior Year Data (10-12% of rejections)

Cause: The XBRL instance document includes only current year figures. MCA requires comparative (prior year) data for most elements. Fix: Ensure both the current and prior period contexts are defined and populated. Zero-value prior year elements must be explicitly included.

5. Missing Mandatory Zero-Value Elements (8-10% of rejections)

Cause: Line items with zero balances are omitted from the instance document. The taxonomy marks certain elements as mandatory regardless of value. Fix: Generate XBRL elements for all mandatory taxonomy nodes, including those with zero values. The element must appear in the instance document with a zero value and correct context.

6. Context Period Mismatches (5-8% of rejections)

Cause: Duration elements (P&L items) assigned instant contexts, or instant elements (Balance Sheet items) assigned duration contexts. Fix: Balance Sheet items use instant contexts (point-in-time, e.g., 2026-03-31). P&L items use duration contexts (period, e.g., 2025-04-01 to 2026-03-31). This distinction is fundamental to XBRL and must be correct for every element.

The Cost of Manual XBRL Conversion

Most CA firms outsource XBRL conversion to specialised vendors. The typical cost structure is:

For a firm handling 100 clients with XBRL requirements, the annual outsourcing cost ranges from Rs. 2-5 lakhs. This cost purchases a mechanical conversion that adds no professional value — the vendor maps the CA's financial statements to XBRL elements, a process that is entirely deterministic once the financial statements are finalised.

Hidden Costs Beyond Vendor Fees

• Turnaround time: Vendors typically need 2-5 working days per instance document. During the September-October filing rush, this can stretch to 7-10 days.
• Revision cycles: If financial statements are revised after XBRL conversion, the vendor must regenerate the instance document (often at additional cost).
• Quality verification: The CA must still validate the XBRL output against the source financial statements. This adds 30-60 minutes per client.
• Rejection handling: If MCA rejects the XBRL filing, the vendor must diagnose and fix the issue, adding another cycle of 2-5 days.

How Automated XBRL Generation Works

A purpose-built system that generates financial statements and XBRL from the same data source eliminates the vendor intermediary entirely. The process works as follows:

1. Taxonomy mapping at source: Each taxonomy node (Share Capital, Trade Receivables, Revenue from Operations, etc.) carries an XBRL element identifier as a property. When the financial statement is generated, the XBRL mapping is inherent.

1. Instance document generation: The system generates the XBRL XML file directly from the computed statement values, using the correct schema URL, context definitions, units, and element references.

1. Built-in validation: Before output, the instance document is validated against the taxonomy schema, checking for mandatory elements, correct context types, boolean formatting, and period alignment.

1. Instant regeneration: If financial statements are revised, the XBRL instance document regenerates in seconds — not days.

ThynkFile generates XBRL instance documents as part of the standard filing package. Because the financial statements and XBRL share the same underlying data, there is no conversion step, no vendor dependency, and no turnaround delay. The V3 taxonomy URLs, validation rules, and mandatory element requirements are built into the generation engine and updated centrally.

For firms currently spending Rs. 2-5 lakhs annually on XBRL outsourcing, the shift to integrated generation eliminates that cost line entirely — while reducing filing risk and turnaround time from days to seconds.