Get FTA-Compliant Before the June 2026 Deadline
Book a free 30-minute call
I agree to the collection and processing of my personal data
CASE STUDY: INDIA
India’s GST E-Invoicing Mandate: Five Years, 840,000 Invoices on Day One, and the Errors That Still Catch Businesses Off Guard
India launched mandatory e-invoicing in 2020 and has since processed billions of transactions through its government clearance platform. The scale is extraordinary — and so is the volume of documented failures. For any country building a similar system, the Indian experience is essential reading.
reading time: 13 min
april 2026
aiverix research
On October 1, 2020, India switched on mandatory e-invoicing for its largest businesses. By end of day, 840,000 invoices had passed through the government’s new clearance portal. By end of month, that number had crossed 50 million — across just 27,000 taxpayers. The system worked. It also buckled under the pressure, threw errors that nobody had anticipated, and exposed data quality problems that years of paper-based invoicing had quietly accumulated. Five years and six expansion phases later, the Indian mandate covers every business with turnover above ₹5 crore. The lessons embedded in that rollout — technical, operational, regulatory — are among the most valuable available to any finance leader preparing for their own government’s e-invoicing mandate.
This article explains how India’s system works, what went wrong at scale, and what the documented failure patterns tell us about mandatory e-invoicing in practice.
This article explains how India’s system works, what went wrong at scale, and what the documented failure patterns tell us about mandatory e-invoicing in practice.
The Architecture: How India's IRP System Works
India’s e-invoicing mandate operates under the Goods and Services Tax (GST) framework and is governed by Rule 48 of the CGST Rules, 2017. The technical model is known as a Clearance system: every B2B invoice must be submitted to a government-operated platform and receive a unique reference number before it is legally valid. The platform is called the Invoice Registration Portal — the IRP.
It is important to understand what this means in practice. The IRP does not generate invoices — businesses continue to create invoices within their own ERP or accounting systems. The mandate is that those invoices must be reported to the IRP, validated, and registered before they can be issued to a buyer. An invoice that has not gone through this process is treated in law as if it was never issued.
It is important to understand what this means in practice. The IRP does not generate invoices — businesses continue to create invoices within their own ERP or accounting systems. The mandate is that those invoices must be reported to the IRP, validated, and registered before they can be issued to a buyer. An invoice that has not gone through this process is treated in law as if it was never issued.
-
Invoice Created in ERP
The business generates the invoice within its own system — SAP, Oracle, Tally, Zoho, or any other accounting platform. The invoice data must conform to the government’s prescribed schema (Form GST INV-01) and be exported in JSON format. The schema contains more than 100 structured fields, of which several are mandatory depending on transaction type. -
JSON Submitted to IRP via API
The JSON file is uploaded to the IRP — either directly via API, through a GST Suvidha Provider (GSP) acting as middleware, or manually via the government portal. For high-volume businesses, API integration is essential; manual uploads do not scale. -
IRP Validates and Generates IRN
The IRP validates the invoice data against its master records — checking GSTINs, HSN codes, tax calculations, and schema compliance. If validation passes, the IRP generates a unique 64-character Invoice Reference Number (IRN) using a hash of the supplier GSTIN, invoice number, document type, and financial year. The IRP digitally signs the invoice and generates a QR code. -
Signed Invoice Returned to Supplier
The IRP returns the signed JSON — now containing the IRN and QR code — to the business. The IRN and QR code must be printed on the final invoice before it is shared with the buyer. Only at this point is the document a legally valid tax invoice under GST law. -
Automatic Downstream Reporting
Once registered, the IRP transmits the invoice data directly to the GST return system, auto-populating the supplier’s GSTR-1 return and making the invoice visible in the buyer’s GSTR-2B for Input Tax Credit (ITC) matching. This eliminates a significant amount of manual reconciliation — when it works correctly. -
Archiving
Electronic invoices must be securely archived for a minimum of eight years and remain accessible for potential GST audits. The integrity of the archived record must be maintained — altered invoices are a compliance violation.
One constraint deserves particular attention: cancellation. An e-invoice can only be cancelled on the IRP within 24 hours of generation. After that window closes, the invoice cannot be cancelled on the portal — it must instead be corrected through a credit note. This 24-hour window creates operational pressure that many businesses discovered only after going live.
The Rollout: Six Phases Over Five Years
India’s approach to expanding the mandate mirrors what other countries have since adopted — starting with the largest, most technically capable enterprises and progressively moving the threshold down toward SMEs. In India’s case, that journey has taken six phases across five years.
Each phase reduction brought in a progressively less technically prepared cohort of businesses. The companies above ₹500 crore had large IT departments, ERP systems already integrated with government platforms, and dedicated compliance teams. The businesses that entered in Phase 6 — those turning over ₹5 to ₹10 crore — often ran simple accounting software, had no IT function, and discovered the mandate’s requirements weeks before their compliance date. ClearTax observed that the largest segment of new entrants in Phase 6 fell in the ₹5−10 crore turnover category, and that these small businesses tend to have a greater transactional magnitude, inviting fresh compliance challenges. Nearly 400,000 businesses entered scope in Phase 6 alone.
840K
Invoices processed on the first day of the mandate — October 1, 2020
50M
Invoices in the first month, across just 27,000 taxpayers
₹10K
Minimum penalty per invoice for failure to generate an IRN
₹25K
Penalty per invoice for issuing an incorrect or non-compliant e-invoice
Where It Fails: The Documented Error Patterns
India’s IRP system generates structured error codes for every rejected submission. Over five years and billions of transactions, a clear taxonomy of failure has emerged — one that cuts across ERP systems, business sizes, and industries. Understanding these error patterns is the most practical preparation any business can do before facing a similar mandate.
The Duplicate IRN Trap
Error 2150 — Duplicate IRN — is among the most frequently encountered and most operationally disruptive errors in the Indian system. It arises when a business attempts to register an invoice for which an IRN has already been generated. That sounds straightforward, but the reality of how it occurs is more insidious.
When an ERP submits an invoice to the IRP via API and the network connection drops before the response is received, the ERP has no confirmation that the IRN was issued. The standard response is to retry the submission. But the IRP has already registered the invoice and generated the IRN — it simply failed to deliver the response. The retry is therefore rejected as a duplicate. The business is left with an invoice it cannot submit again and an IRN it cannot retrieve without additional API calls specifically designed to fetch missing confirmations. This scenario played out at scale across SAP, Oracle, Tally, and custom ERP systems throughout Phase 1. SAP documented the issue formally in a Knowledge Base Article addressing NIC server response timeouts during IRN generation — a problem inherent to the volume of concurrent submissions at peak periods.
When an ERP submits an invoice to the IRP via API and the network connection drops before the response is received, the ERP has no confirmation that the IRN was issued. The standard response is to retry the submission. But the IRP has already registered the invoice and generated the IRN — it simply failed to deliver the response. The retry is therefore rejected as a duplicate. The business is left with an invoice it cannot submit again and an IRN it cannot retrieve without additional API calls specifically designed to fetch missing confirmations. This scenario played out at scale across SAP, Oracle, Tally, and custom ERP systems throughout Phase 1. SAP documented the issue formally in a Knowledge Base Article addressing NIC server response timeouts during IRN generation — a problem inherent to the volume of concurrent submissions at peak periods.
TECHNICAL RISK
The duplicate IRN trap is not caused by user error — it is caused by network instability combined with IRP architecture that does not automatically resync with the calling system after a timeout. Any business processing high invoice volumes without a retry-with-deduplication mechanism built into its integration will encounter this error repeatedly.
The fix — a dedicated "GET IRN API" that retrieves the IRN for an already-registered invoice — was introduced by the government as a workaround after the problem became widespread. But businesses that didn’t know to implement it were stuck in a loop: unable to submit the invoice again, unable to retrieve the IRN, and unable to issue a legally valid document to the buyer.
The duplicate IRN trap is not caused by user error — it is caused by network instability combined with IRP architecture that does not automatically resync with the calling system after a timeout. Any business processing high invoice volumes without a retry-with-deduplication mechanism built into its integration will encounter this error repeatedly.
The fix — a dedicated "GET IRN API" that retrieves the IRN for an already-registered invoice — was introduced by the government as a workaround after the problem became widespread. But businesses that didn’t know to implement it were stuck in a loop: unable to submit the invoice again, unable to retrieve the IRN, and unable to issue a legally valid document to the buyer.
The Case-Sensitivity Bug That Lasted Until 2025
For the first four-and-a-half years of the IRP system’s operation, invoice numbers were treated as case-sensitive. "INV-123" and "inv-123" were recognised as different invoices. For businesses whose ERP systems did not enforce consistent capitalisation of invoice numbers — or whose invoicing conventions mixed cases across departments or billing cycles — this created a persistent source of duplicate IRN errors and reconciliation failures between the e-invoice portal and GSTR-1 returns. A business might submit "INV-2024−001" in one context and "Inv-2024−001" in another, with the IRP treating these as distinct invoices while the underlying accounting system treated them as identical.
The GSTN announced the fix in April 2025 — effective June 1, 2025 — directing the IRP to treat all invoice numbers as case-insensitive by converting them to uppercase before processing. The announcement confirmed what businesses had long suspected: the issue had been causing duplicate IRN errors and cross-platform inconsistencies throughout the system’s operational life. Four and a half years is a long time to run with a bug of this nature in a mandatory tax infrastructure.
The GSTN announced the fix in April 2025 — effective June 1, 2025 — directing the IRP to treat all invoice numbers as case-insensitive by converting them to uppercase before processing. The announcement confirmed what businesses had long suspected: the issue had been causing duplicate IRN errors and cross-platform inconsistencies throughout the system’s operational life. Four and a half years is a long time to run with a bug of this nature in a mandatory tax infrastructure.
GSTIN Validation Failures
Errors 3028 and 3029 relate to GSTIN — the Goods and Services Tax Identification Number assigned to every registered business in India. The error fires when the recipient’s GSTIN is absent from the IRP master database, inactive, or cancelled. The practical problem is that a supplier has no reliable real-time visibility into the registration status of their customers. A buyer’s GSTIN may have been cancelled due to their own compliance failure, a technical error in the GST portal, or a simple administrative lapse — and the supplier’s ERP master data, last updated months ago, continues to carry it as valid. The invoice submits, hits the GSTIN validation check, and is rejected.
This failure mode is particularly consequential because it is entirely outside the submitting business’s control. Cleaning ERP master data before going live — verifying every active customer GSTIN against the live GST portal — became a prerequisite step that many businesses only identified after experiencing their first wave of rejection errors.
This failure mode is particularly consequential because it is entirely outside the submitting business’s control. Cleaning ERP master data before going live — verifying every active customer GSTIN against the live GST portal — became a prerequisite step that many businesses only identified after experiencing their first wave of rejection errors.
HSN Code Mismatches
India’s GST system requires invoices to carry HSN (Harmonised System of Nomenclature) codes identifying the goods or services being billed. The IRP validates HSN codes against a master list maintained by the NIC. When the government updated its HSN code requirements — mandating 6-digit codes where businesses had previously used 4-digit codes — thousands of invoices began failing Error 2270 (Invalid HSN Code) in bulk. The problem was particularly widespread among businesses that had been using older ERP configurations that pre-dated the updated requirements or had not synchronised their product master data with the latest government-issued HSN tables.
Portal Outages at Scale
On February 24, 2023, the NIC e-invoice portal went completely dark for over three hours during business hours. The government’s only guidance during the outage was to raise a support ticket. For businesses required to generate IRNs in real time before issuing invoices — including those with contractual payment terms tied to invoice issuance — every minute of downtime meant revenue stuck in limbo. The government had by that point spent ₹1,379.70 crore (approximately $ 165 million) on GST portal development and maintenance, yet multi-hour outages during peak business hours continued to occur. The episode raised fundamental questions about infrastructure resilience for a mandate that tied the legal validity of every commercial transaction to a single government platform.
The response from most established compliance platforms was to build queue-and-retry infrastructure: invoices generated during outage windows are held, automatically submitted once the portal recovers, and returned with IRNs within the 24-hour reporting window. Businesses relying on direct manual submission had no such buffer.
The response from most established compliance platforms was to build queue-and-retry infrastructure: invoices generated during outage windows are held, automatically submitted once the portal recovers, and returned with IRNs within the 24-hour reporting window. Businesses relying on direct manual submission had no such buffer.
The Penalty Structure: Why Non-Compliance Is Expensive
India’s GST law draws a clear distinction between two categories of e-invoicing violation, and the penalties for each are significant.
To understand what these numbers mean in aggregate: a business with turnover above ₹10 crore that fails to generate IRNs for 500 invoices of ₹50,000 each — an entirely plausible scenario during a system migration or ERP integration project — faces a potential penalty exposure of ₹27.5 lakh on the tax-proportional calculation alone. That is approximately $ 33,000 from a single compliance gap across a few hundred transactions.
The ITC consequence compounds this exposure significantly. When a supplier issues an invoice without a valid IRN, the buyer cannot claim Input Tax Credit on that invoice. Under India’s GST system, ITC is a critical working capital mechanism — businesses use tax paid on purchases to offset tax owed on sales. A buyer who discovers that their supplier’s invoices are non-compliant faces both a loss of ITC entitlement and the operational disruption of going back to the supplier to request corrected documents. In practice, buyers increasingly check IRN validity before accepting delivery — meaning a supplier’s non-compliance directly threatens their ability to complete sales.
The ITC consequence compounds this exposure significantly. When a supplier issues an invoice without a valid IRN, the buyer cannot claim Input Tax Credit on that invoice. Under India’s GST system, ITC is a critical working capital mechanism — businesses use tax paid on purchases to offset tax owed on sales. A buyer who discovers that their supplier’s invoices are non-compliant faces both a loss of ITC entitlement and the operational disruption of going back to the supplier to request corrected documents. In practice, buyers increasingly check IRN validity before accepting delivery — meaning a supplier’s non-compliance directly threatens their ability to complete sales.
The Common Error Codes: A Field Guide
Five years of live operation have produced a well-documented taxonomy of IRP error codes. The most operationally significant ones follow a consistent pattern — they are almost never caused by deliberate non-compliance, but by data quality issues, integration gaps, and ERP configuration problems that businesses were unaware of until they manifested as rejections.
ERROR 2150
Duplicate IRN
IRN already exists for this invoice. Most commonly occurs when a network timeout causes the ERP to retry a submission that the IRP already processed successfully.
ERROR 2270
Invalid HSN Code
The product or service code does not match the IRP master list. Triggered by outdated ERP product data or failure to migrate from 4-digit to 6-digit HSN codes.
ERROR 3028/3028
Invalid/Inactive GSTIN
Recipient’s tax registration number is absent, inactive, or cancelled. ERP master data may not reflect recent changes to a customer’s registration status.
ERROR 2172
Wrong Tax Type
IGST used for intra-state transaction, or CGST/SGST used for inter-state. Tax type must match the place of supply rules; many ERPs require manual configuration.
ERROR 2182
Taxable Value Mismatch
Total taxable value does not equal the sum of line item taxable values. Often caused by rounding differences between ERP calculation logic and IRP validation rules.
ERROR 5002
Invalid Reference Data
Broad validation failure covering incorrect invoice data and technical bugs. Resolution often requires checking the complete invoice schema against the latest IRP requirements.
Case Study: ClearTax and the Large Retail Conglomerate
CASE STUDY · RETAIL SECTOR · INDIA
600,000 Daily Invoices, Patchy Connectivity, and a System That Had to Work Every Day
One of India's large retail conglomerates — operating hundreds of stores across the country, including locations in areas with limited or intermittent internet connectivity — needed a Phase 2 compliant e-invoicing solution that could handle their volume and geographic spread. The business could not afford IRP downtime to translate into invoice generation gaps, and could not accept that invoices from stores in Tier II and Tier III cities would fail simply because of a connectivity issue.
The technical requirements were substantial. The solution needed to process up to one million e-invoices per day during peak seasons, maintain 99.9% uptime independently of IRP availability, support over ten concurrent ZATCA connections to distribute load and ensure redundancy, and report 600,000 invoices daily to the IRP within the mandated timeframe. For stores in areas with intermittent connectivity, a local queuing mechanism was required to hold invoices during connectivity gaps and submit them automatically once connection was restored.
ClearTax built and deployed a platform meeting these requirements, with auto-retry logic ensuring invoices were reported within 24 hours even when IRP servers timed out or went offline. The architecture distributed submission load across multiple IRP connections to prevent single-point failures during peak processing windows.
OUTCOME
The client achieved full e-invoicing compliance across all locations, including stores with poor connectivity, throughout peak retail seasons including high-volume sale periods. The client saved three to four months of estimated internal development effort by working with an established platform rather than building in-house. Auto-retry and queue management eliminated the manual intervention that would otherwise have been required when IRP outages occurred.
The critical design principle: the compliance solution was architected to be resilient to government infrastructure failures, not dependent on them. An in-house integration that called the IRP directly would have inherited every IRP outage as a business outage.
600,000 Daily Invoices, Patchy Connectivity, and a System That Had to Work Every Day
One of India's large retail conglomerates — operating hundreds of stores across the country, including locations in areas with limited or intermittent internet connectivity — needed a Phase 2 compliant e-invoicing solution that could handle their volume and geographic spread. The business could not afford IRP downtime to translate into invoice generation gaps, and could not accept that invoices from stores in Tier II and Tier III cities would fail simply because of a connectivity issue.
The technical requirements were substantial. The solution needed to process up to one million e-invoices per day during peak seasons, maintain 99.9% uptime independently of IRP availability, support over ten concurrent ZATCA connections to distribute load and ensure redundancy, and report 600,000 invoices daily to the IRP within the mandated timeframe. For stores in areas with intermittent connectivity, a local queuing mechanism was required to hold invoices during connectivity gaps and submit them automatically once connection was restored.
ClearTax built and deployed a platform meeting these requirements, with auto-retry logic ensuring invoices were reported within 24 hours even when IRP servers timed out or went offline. The architecture distributed submission load across multiple IRP connections to prevent single-point failures during peak processing windows.
OUTCOME
The client achieved full e-invoicing compliance across all locations, including stores with poor connectivity, throughout peak retail seasons including high-volume sale periods. The client saved three to four months of estimated internal development effort by working with an established platform rather than building in-house. Auto-retry and queue management eliminated the manual intervention that would otherwise have been required when IRP outages occurred.
The critical design principle: the compliance solution was architected to be resilient to government infrastructure failures, not dependent on them. An in-house integration that called the IRP directly would have inherited every IRP outage as a business outage.
The SME Problem: What Happens When 400,000 Small Businesses Enter Scope at Once
The expansion to ₹5 crore turnover in August 2023 brought nearly 400,000 businesses into the mandate simultaneously — the largest single-phase expansion of the Indian e-invoicing system. The profile of these businesses was materially different from every previous cohort: smaller finance teams, simpler software, fewer dedicated IT resources, and often no prior experience with API-based government integrations.
The compliance challenges facing this group were predictable and well-documented by the time Phase 6 arrived. Businesses in Tier II and Tier III cities faced intermittent internet connectivity that made real-time IRP submission unreliable. Many were running accounting software — Tally, Busy, Marg — that required updates or add-on modules to support IRP integration. ERP master data — customer GSTINs, product HSN codes — had never been validated against a live government system and contained errors accumulated over years of manual entry. And crucially, the 24-hour cancellation window meant that errors discovered after invoice issuance could not simply be reversed on the portal — they required credit note workflows that many businesses had never used.
The businesses that navigated Phase 6 most cleanly were those that used the sandbox testing environment GSTN had made available, ran a data quality audit on their customer and product master records before go-live, and chose a GSP or IRP solution with queue-and-retry infrastructure. The businesses that struggled were those that assumed their existing software would handle the change automatically and discovered otherwise on or after their compliance date.
The compliance challenges facing this group were predictable and well-documented by the time Phase 6 arrived. Businesses in Tier II and Tier III cities faced intermittent internet connectivity that made real-time IRP submission unreliable. Many were running accounting software — Tally, Busy, Marg — that required updates or add-on modules to support IRP integration. ERP master data — customer GSTINs, product HSN codes — had never been validated against a live government system and contained errors accumulated over years of manual entry. And crucially, the 24-hour cancellation window meant that errors discovered after invoice issuance could not simply be reversed on the portal — they required credit note workflows that many businesses had never used.
The businesses that navigated Phase 6 most cleanly were those that used the sandbox testing environment GSTN had made available, ran a data quality audit on their customer and product master records before go-live, and chose a GSP or IRP solution with queue-and-retry infrastructure. The businesses that struggled were those that assumed their existing software would handle the change automatically and discovered otherwise on or after their compliance date.
“
An invoice issued by a notified taxpayer without generating a valid IRN from IRP is treated as an invalid tax invoice under Rule 48(4), liable for penalties — and leaves recipients without ITC.
The Reporting Timeline: A Rule That Kept Moving
One of the most operationally disruptive aspects of the Indian mandate has been the repeated revision of invoice reporting timelines — the window within which an invoice must be submitted to the IRP after its creation date.
At launch, there was no formal time limit. Businesses could generate invoices and submit them to the IRP at any point, including retrospectively. In April 2023, the government announced a 7-day reporting limit for businesses with turnover above ₹100 crore — invoices older than seven days would be blocked from IRP registration. The rule was announced, then deferred by three months before it could take effect, as businesses flagged that their ERP systems and processes were not ready. The deferral itself created operational confusion: businesses that had begun reconfiguring their workflows to meet the 7-day deadline had to re-evaluate those changes.
From April 2025, businesses with turnover above ₹10 crore are required to report e-invoices within 30 days of invoice issuance. The IRP now enforces this limit automatically — invoices older than 30 days are blocked from registration, with no manual override. For businesses processing high invoice volumes or running month-end batch submission processes, this requirement mandates a fundamental change to how invoicing workflows are structured.
At launch, there was no formal time limit. Businesses could generate invoices and submit them to the IRP at any point, including retrospectively. In April 2023, the government announced a 7-day reporting limit for businesses with turnover above ₹100 crore — invoices older than seven days would be blocked from IRP registration. The rule was announced, then deferred by three months before it could take effect, as businesses flagged that their ERP systems and processes were not ready. The deferral itself created operational confusion: businesses that had begun reconfiguring their workflows to meet the 7-day deadline had to re-evaluate those changes.
From April 2025, businesses with turnover above ₹10 crore are required to report e-invoices within 30 days of invoice issuance. The IRP now enforces this limit automatically — invoices older than 30 days are blocked from registration, with no manual override. For businesses processing high invoice volumes or running month-end batch submission processes, this requirement mandates a fundamental change to how invoicing workflows are structured.
What Five Years of Indian E-Invoicing Actually Teaches
India’s mandate is the most operationally rich e-invoicing case study available. 840,000 invoices on day one. Six expansion phases. Documented infrastructure failures. A bug in invoice number case-sensitivity that ran for four and a half years. Penalty structures that make non-compliance expensive not just for the seller, but for every buyer in the supply chain who loses ITC entitlement.
The consistent lesson across all five years and all six phases is the same: technical compliance and regulatory compliance are not the same thing. A business can have a valid ERP system, a signed software contract with an IRP provider, and still face systematic invoice rejections on day one — because its customer GSTIN data is stale, because its product HSN codes haven’t been updated, because its ERP rounds tax amounts differently from the IRP validation schema, or because a network timeout during submission creates a duplicate IRN loop that nobody anticipated.
The businesses that have navigated India’s mandate without operational disruption treated compliance as a data project first and a technology project second. They audited their master data before going live. They chose solutions with retry logic and outage resilience. They tested in the sandbox environment. And they did not wait for the mandate to reach their threshold before beginning that preparation.
For UAE businesses facing their own e-invoicing mandate in 2026, India’s pattern is a precise preview. Different platform, same architecture, same failure modes. The question is not whether these issues will surface — it is whether they surface before the compliance deadline or after it.
The consistent lesson across all five years and all six phases is the same: technical compliance and regulatory compliance are not the same thing. A business can have a valid ERP system, a signed software contract with an IRP provider, and still face systematic invoice rejections on day one — because its customer GSTIN data is stale, because its product HSN codes haven’t been updated, because its ERP rounds tax amounts differently from the IRP validation schema, or because a network timeout during submission creates a duplicate IRN loop that nobody anticipated.
The businesses that have navigated India’s mandate without operational disruption treated compliance as a data project first and a technology project second. They audited their master data before going live. They chose solutions with retry logic and outage resilience. They tested in the sandbox environment. And they did not wait for the mandate to reach their threshold before beginning that preparation.
For UAE businesses facing their own e-invoicing mandate in 2026, India’s pattern is a precise preview. Different platform, same architecture, same failure modes. The question is not whether these issues will surface — it is whether they surface before the compliance deadline or after it.