India GST E-Invoicing Requirements: Complete IRN & IRP Guide

India's GST e-invoicing system requires businesses above a specified turnover threshold to register every B2B invoice with a government-authorized Invoice Registration Portal (IRP) before issuing it to the buyer. The IRP validates the invoice data against GST rules, generates a unique Invoice Reference Number (IRN) for each document, digitally signs the payload, and returns a JSON file embedded with a QR code. No invoice is legally valid under GST without this IRN. The mandate has expanded progressively since its launch — from businesses with annual turnover above Rs 500 crore in October 2020, down through several phases to Rs 5 crore in August 2023, with the threshold expected to drop further to Rs 2 crore from October 2025. For the thousands of small and mid-sized businesses crossing that line, understanding the system is no longer optional.

What makes India's approach architecturally distinct is its centralized clearance model. If you look at how e-invoicing systems work across different countries, you will find considerable variation: some European models route invoices directly between trading parties through PEPPOL access points, others use post-audit reporting, and a few employ real-time clearance. India chose a centralized registration gateway. Every B2B invoice must pass through the IRP, which acts as the single validation authority. The portal checks for duplicates, verifies GSTIN details, confirms schema compliance, and only then assigns the IRN and digital signature. Without that validation step, the invoice carries no legal weight for GST purposes. The IRP is not merely a reporting destination — it is the gatekeeper that determines whether an invoice exists in the eyes of the tax system.

This centralized design creates a chain of downstream consequences that reaches well beyond the invoice itself. The IRN ties directly into GSTR-1 auto-population, meaning validated e-invoices flow automatically into your sales return without manual data entry. That same data feeds into your buyer's Input Tax Credit (ITC) reconciliation through GSTR-2B, and the e-invoice details link to e-way bill generation for goods in transit. A failure at the registration stage does not just mean a non-compliant invoice — it breaks the entire chain from filing through credit claims to logistics documentation. The sections that follow walk through each link in this chain: the IRP registration workflow and how an IRN is generated, the expanding turnover mandate and its timeline, the JSON schema defined in Form GST INV-01, QR code requirements for B2B and B2C transactions, downstream effects on GSTR-1 filing and ITC, penalties for non-compliance, and the practical steps to prepare your systems.

Four institutions govern how this system operates. The GST Council, chaired by the Union Finance Minister with state-level representation, sets the policy direction and recommends threshold changes. The Central Board of Indirect Taxes and Customs (CBIC) translates those recommendations into binding notifications and circulars. The GST Network (GSTN), a technology company jointly owned by the central and state governments, builds and maintains the IT infrastructure underpinning GST compliance. And the National Informatics Centre (NIC), operating under the Ministry of Electronics and IT, runs the IRP portals that handle the actual invoice registration, validation, and IRN generation. Knowing which body does what matters when you need to trace the authority behind a rule change or find the correct technical documentation.

How the Invoice Registration Portal Generates an IRN

Every GST e-invoice in India passes through a defined technical workflow before it becomes a legally valid document. Understanding this sequence is essential for ERP administrators configuring system integrations and for finance teams overseeing the compliance process.

The Invoice Registration Portal (IRP) is the government-authorized platform that validates, registers, and returns signed e-invoices. Here is what happens, step by step, when a business registers an invoice:

Step 1: Generate the invoice JSON. Your billing or ERP system produces the invoice data in the prescribed JSON format defined by Form GST INV-01. This schema covers supplier and buyer details, item-level particulars, tax breakdowns, and document metadata. The data must conform exactly to the field specifications before submission.

Step 2: Submit to an authorized IRP via API. The JSON payload is transmitted to one of the government-authorized IRP portals through a RESTful API call. The National Informatics Centre (NIC) operates the primary portal (IRP1), but additional authorized portals such as IRIS IRP6 also accept submissions. All portals connect to the same central registration system, so the Invoice Reference Number (IRN) generated is unique across the entire GST network regardless of which portal processes it.

Step 3: The IRP validates the data. On receiving the payload, the IRP runs a series of validation checks:

GSTIN validity — confirms both supplier and buyer GSTINs are active and correctly formatted
Mandatory field completeness — verifies all required fields in the JSON schema are populated
Duplicate detection — checks whether an invoice with the same combination of supplier GSTIN, financial year, document type, and document number has already been registered

If any check fails, the IRP returns an error response with specific codes identifying the problem. Your system must handle these errors and either correct the data or flag it for manual review.

Step 4: IRN generation. When validation passes, the IRP generates a unique 64-character Invoice Reference Number (IRN). This hash is computed from four components: the supplier's GSTIN, the financial year, the document type code, and the document number. Because the hash inputs are unique per invoice, the resulting IRN is a deterministic, non-repeating identifier for that specific document.

Step 5: Digital signing. The IRP digitally signs the entire JSON payload using its private key. This signature serves as the government's authentication that the invoice data was registered through an authorized channel and has not been altered after registration.

Step 6: Return the signed payload. The IRP sends back the digitally signed JSON, now containing the IRN and a generated QR code, to the submitting system. Your ERP or billing software must capture and store this response.

Step 7: Include IRN and QR code on the invoice. The supplier is required to print or embed both the IRN and the QR code on the invoice document provided to the buyer, whether in PDF or paper format. An invoice without these elements is not a valid e-invoice under the GST framework.

Beyond returning the signed data to the supplier, the IRP also pushes the registered e-invoice data directly to the GST portal. This automatic transmission is what enables downstream auto-population of GSTR-1 returns, a process covered in detail in a later section of this guide.

Cancellation window. A registered e-invoice can be cancelled through the IRP within 24 hours of generation. After that 24-hour window closes, cancellation through the portal is no longer possible. The supplier must instead issue a credit note or debit note to adjust or reverse the original invoice, following standard GST procedures for those document types.

India's centralized portal model, where every invoice must pass through a government-operated registration system before it is considered valid, shares architectural similarities with approaches adopted by other countries. Poland's KSeF centralized e-invoicing portal, for instance, also requires businesses to register invoices through a single national platform before they can be issued to buyers. For organizations operating across multiple jurisdictions, recognizing these structural parallels can simplify the process of designing integration architectures that accommodate more than one country's requirements.

The Expanding Mandate: From Rs 500 Crore to Rs 2 Crore

When CBIC (Central Board of Indirect Taxes and Customs) launched mandatory e-invoicing in October 2020, it applied only to the largest enterprises. Since then, the turnover threshold has been progressively reduced, with each phase pulling a new wave of businesses into scope.

Complete Threshold Timeline

Effective Date	Aggregate Turnover Threshold	Approximate Businesses Added
October 1, 2020	Rs 500 crore and above	~500 large enterprises
January 1, 2021	Rs 100 crore and above	~4,000 additional
April 1, 2021	Rs 50 crore and above	~8,000 additional
April 1, 2022	Rs 20 crore and above	~70,000 additional
October 1, 2022	Rs 10 crore and above	~150,000 additional
August 1, 2023	Rs 5 crore and above	~400,000 additional
Expected October 2025	Rs 2 crore and above	Millions of additional SMEs

The pattern is clear: each reduction roughly doubles or triples the covered taxpayer population. The expected Rs 2 crore threshold will be the most consequential expansion yet, sweeping in a vast segment of small and medium enterprises that have had limited exposure to structured digital compliance systems.

How the Threshold Applies

The mandate uses Annual Aggregate Turnover (AATO) as its measure. This is the total turnover across all GSTINs registered under a single PAN, calculated for any preceding financial year from 2017-18 onward. It includes taxable supplies, exempt supplies, exports, and inter-state supplies.

One critical rule catches many businesses off guard: the obligation is permanent once triggered. If your aggregate turnover exceeded the applicable threshold in any financial year since 2017-18, you remain subject to e-invoicing even if your revenue drops below that threshold in later years. A company that crossed Rs 10 crore in FY 2021-22 but fell to Rs 7 crore in FY 2023-24 still must generate e-invoices for every applicable transaction.

Who Is Currently Exempt

Several categories of registered persons remain outside the e-invoicing mandate regardless of turnover:

SEZ units (Special Economic Zone units, though SEZ developers are covered)
Insurers and banking and financial institutions (including NBFCs)
Goods Transport Agencies (GTAs)
Passenger transport service providers
OIDAR service providers (Online Information and Database Access or Retrieval)

These exemptions exist because these sectors either operate under separate reporting frameworks or issue high volumes of low-value documents where the IRP workflow would create disproportionate operational friction. Businesses in exempt categories should still monitor CBIC notifications, as exemptions can be narrowed or removed.

The Revenue Context

The scale of the mandate mirrors the scale of GST itself. According to the Indian government's eight-year assessment of GST, India's gross GST revenue reached a record Rs 22.08 lakh crore (approximately USD 260 billion) in FY 2024-25, reflecting 9.4 percent year-on-year growth, with the active taxpayer base expanding to over 1.51 crore registrations. The government attributes this growth in part to compliance improvements from e-invoicing and automated return filing.

For businesses approaching the Rs 2 crore threshold, the takeaway is straightforward: preparation time is finite. Each previous threshold reduction gave affected businesses roughly three to six months of lead time between the notification and the effective date. Companies in the Rs 2 to 5 crore turnover range should treat compliance readiness as an immediate priority rather than waiting for the formal notification.

Inside Form GST INV-01: The E-Invoice JSON Schema

The e-invoice data structure is defined by Form GST INV-01, a JSON schema containing approximately 120 total fields, of which roughly 50 are mandatory. This schema is the contract between your billing system and the IRP. Every field must conform to prescribed data types, lengths, and validation rules before the IRP will accept the payload and generate an IRN. The NIC provides an API sandbox at einv-apisandbox.nic.in where developers and ERP administrators can test their JSON payloads against production validation rules before going live.

Understanding the mandatory field groups is essential for ERP configuration and data quality. Rather than listing every field, the following breakdown covers the groups your system must populate correctly.

Transaction details form the document header. These include the supply type (B2B, B2C, export, SEZ), document type (invoice, credit note, debit note), document number, and document date. The document number must follow the GST format: a maximum of 16 alphanumeric characters with permitted special characters, unique within a financial year per GSTIN. If your team needs the field-level view of what must appear on that underlying tax invoice before it ever reaches the IRP, this Rule 46 checklist for India GST invoices is the closest companion reference.

Supplier details identify the seller. Mandatory fields include the supplier GSTIN, legal name as registered with GST, trade name, registered address (building/street, city), state code, and PIN code. These values must match your GST registration exactly. Even minor discrepancies between your master data and your GST registration will trigger validation failures at the IRP.

Buyer details mirror the supplier structure. The buyer GSTIN, legal name, trade name, address, state code, PIN code, and critically the place of supply are all required for B2B transactions. Place of supply determines whether CGST/SGST or IGST applies, so an incorrect value here cascades into tax calculation errors across every line item.

Item details are captured per line item and carry the bulk of the schema's complexity. Each line requires an HSN code, item description, quantity, unit of measurement, unit price, taxable value, applicable GST rate, and the computed CGST, SGST, or IGST amounts along with the total item value. HSN code accuracy deserves particular attention. The schema requires HSN codes at the line-item level, and incorrect codes trigger immediate validation errors at the IRP. Since April 2021, businesses with aggregate turnover above Rs 5 crore must use 6-digit HSN codes, while those below this threshold use 4-digit codes. If your product master data contains outdated or imprecise HSN classifications, you will encounter repeated rejections.

Value details aggregate the line-item totals into document-level summaries: total taxable value, total CGST, total SGST, total IGST, total invoice value, and any rounding-off amount. These computed totals must reconcile with the sum of individual line items. The IRP validates this arithmetic, so rounding discrepancies even of a single paisa can cause rejections.

Document period fields (from date and to date) apply to recurring service invoices where the supply spans a defined period. While not required for one-time goods transactions, these become mandatory when your invoice covers a service contract or subscription period.

Beyond the mandatory groups, the schema includes optional sections that become relevant for specific transaction types. Export transactions require port code and shipping bill details. Supplies through e-commerce platforms require the operator's GSTIN. Payment details such as payment mode, account number, and payment terms can be included where applicable.

The most common validation errors encountered at the IRP follow predictable patterns. Duplicate document numbers are rejected outright since the IRP enforces uniqueness per GSTIN per financial year. Invalid GSTINs for either the supplier or buyer fail checksum validation before the payload is even processed. Missing mandatory fields return specific error codes identifying which field group is incomplete. And HSN code mismatches, where the code does not exist in the GST HSN master or does not meet the required digit length for the supplier's turnover slab, account for a significant share of first-time integration failures. Running your payloads through the NIC sandbox before production cutover eliminates most of these issues during the testing phase rather than during live operations.

QR Code Requirements: B2B and B2C Distinctions

India's GST e-invoicing framework creates two entirely separate QR code obligations that apply to different transaction types, carry different technical requirements, and serve different purposes. Conflating the two is a common source of confusion, particularly for businesses that handle both B2B and B2C sales.

The B2B E-Invoice QR Code

When the Invoice Registration Portal generates an IRN for a B2B, B2G, or export invoice, it simultaneously produces a QR code that must be printed on the invoice. This QR code is not created by the supplier. It is generated by the IRP as part of the signed response and returned alongside the IRN and digital signature.

The encoded data within this QR includes:

Supplier GSTIN and recipient GSTIN
Invoice number and invoice date
HSN code(s) for the goods or services supplied
Invoice Registration Number (IRN)
Number of line items
Total invoice value

This QR code serves a verification function. A tax officer conducting a roadside inspection of goods in transit can scan the QR and confirm the invoice details against the IRP's records in real time. Recipients can do the same to verify that an invoice they received was genuinely registered on the portal before claiming input tax credit. The QR effectively turns every printed e-invoice into an instantly auditable document, eliminating the need to log into the GST portal for on-the-spot checks.

Because the IRP generates this QR automatically, suppliers do not need separate QR generation software for B2B e-invoices. Your ERP or billing system receives the QR as part of the IRP response and embeds it into the invoice printout.

The B2C Dynamic QR Code: A Separate Obligation

B2C transactions fall outside the e-invoicing mandate entirely. There is no requirement to register B2C invoices on the IRP, no IRN generation, and no IRP-produced QR code. However, a separate and distinct QR code requirement applies to B2C invoices for large businesses.

Businesses with aggregate annual turnover exceeding Rs 500 crore must include a dynamic QR code on their B2C invoices. This is fundamentally different from the B2B e-invoice QR in both purpose and structure. The B2C dynamic QR is a UPI-compatible payment QR code that enables customers to scan the code and pay directly through any UPI application. It encodes payment details, not verification data.

The distinction matters for ERP configuration. Your system needs to handle two separate QR workflows:

Attribute	B2B E-Invoice QR	B2C Dynamic QR
Source	Generated by the IRP	Generated by the supplier's billing system
Purpose	Invoice verification against IRP records	UPI payment enablement
Applicability	All businesses under the e-invoicing mandate	Only businesses with turnover above Rs 500 crore
Transaction types	B2B, B2G, exports	B2C only
Content	Supplier/recipient GSTINs, IRN, invoice details	UPI payment string with amount and payee details

Why the Distinction Gets Overlooked

Many businesses assume that once they comply with e-invoicing for B2B transactions, their QR code obligations are fully met. This overlooks the fact that the B2C dynamic QR is an independent requirement with its own turnover threshold and its own technical implementation. A company with turnover above Rs 500 crore that has flawless B2B e-invoicing compliance can still face penalties for missing the dynamic QR on its B2C invoices.

For businesses below the Rs 500 crore threshold, B2C invoices carry no QR code obligation at all under current rules. But as the e-invoicing turnover threshold has steadily decreased over the years, finance teams should anticipate the possibility that the B2C dynamic QR threshold could follow a similar trajectory.

From E-Invoice to Tax Return: GSTR-1, ITC, and E-Way Bills

Registering an e-invoice with the IRP is not an isolated compliance event. It is the first link in a chain that auto-populates your tax returns, validates your buyer's input tax credit claims, and can simultaneously generate an e-way bill for goods in transit. This interconnected design is what transforms India's e-invoicing from a reporting obligation into the backbone of the entire B2B tax compliance infrastructure.

GSTR-1 Auto-Population

Once the IRP validates and registers an e-invoice, the invoice data is automatically pushed to the GST portal. Starting from T+2 (two days after registration), the e-invoice details auto-populate the supplier's GSTR-1, the outward supply return that every registered taxpayer must file monthly or quarterly.

This means you do not need to manually re-enter invoice data into your GSTR-1. The auto-populated entries appear in your return draft, where you can review and amend them if needed before filing. For businesses processing hundreds or thousands of B2B invoices per month, this eliminates a major source of data entry errors and duplicate entries that previously plagued the filing process.

The practical effect is significant. Before e-invoicing, suppliers maintained their own invoice records, manually entered them into GSTR-1, and discrepancies between what the supplier reported and what actually existed were common. Auto-population from the IRP closes that gap by making the registered e-invoice the single authoritative source for outward supply reporting.

ITC Enablement for the Buyer

The same e-invoice data that flows into the supplier's GSTR-1 simultaneously populates two critical documents on the buyer's side: GSTR-2A (the auto-drafted inward supply return) and GSTR-2B (the auto-generated ITC statement). This is where the chain becomes consequential for both parties in the transaction.

A buyer can only claim Input Tax Credit on invoices that appear in their GSTR-2B. The appearance of an invoice in GSTR-2B depends entirely on the supplier having registered that e-invoice with the IRP. If the supplier fails to generate an e-invoice for a transaction that falls under the mandate, the invoice simply does not appear in the buyer's GSTR-2A or GSTR-2B. The buyer is then unable to claim ITC for that purchase, regardless of whether the goods or services were genuinely received and paid for. For teams building the downstream control layer, this workflow for GST ITC reconciliation across GSTR-2B, IMS, and Rule 37 shows how that portal-fed data is reviewed before credits are finalized.

This creates a direct financial dependency between supplier compliance and buyer tax recovery. A supplier who neglects e-invoice generation does not just risk penalties for themselves. They actively damage their buyer's ability to claim legitimate tax credits. For buyers managing large vendor bases, this makes supplier e-invoicing compliance a procurement concern, not merely a tax department issue. The same vendor-governance discipline also matters when AP teams need Udyam status and acceptance dates for India's MSME payment-deadline rule under Section 43B(h).

It also matters when the payment itself may trigger withholding, because the invoice data feeding GST controls is often the same data AP teams use to check India TDS sections, thresholds, and GST TDS rules on invoice payments.

The connected data flow between IRP registration, GSTR-1, and GSTR-2B is also what has driven measurable improvements in tax administration. The system leaves no room for invoices that exist in one party's records but not the other's. This structural transparency has contributed to a 30% reduction in ITC mismatch disputes, a 45% decrease in fake invoice cases, and a 25% improvement in B2B GST collections, because every claimed credit must trace back to an IRP-registered document.

E-Way Bill Integration

The third downstream process triggered by e-invoice registration is e-way bill generation. If your e-invoice JSON payload includes both Part A (invoice and item details) and Part B (vehicle number, transporter ID, and transport mode), the system auto-generates an e-way bill simultaneously with the IRN. You do not need to visit the e-way bill portal separately or re-enter consignment details. Teams that need the transport-side operational detail can use this guide to India's e-way bill thresholds, Part A, Part B, and validity rules.

This integration eliminates redundant data entry for transactions that require both documents, which is the common case for interstate movement of goods above Rs 50,000. The e-way bill number is generated alongside the IRN and linked to the same underlying invoice data, ensuring consistency between the tax document and the transport document.

The critical operational risk here is the reverse scenario. If an e-invoice is required for a transaction but has not been generated, any e-way bill created independently for that shipment is considered invalid. Goods in transit without a valid e-way bill can be detained at checkpoints, and the transporter faces penalties under both GST and transport regulations. For businesses with active supply chains, a single missed e-invoice can halt a shipment, delay delivery commitments, and trigger penalties that extend well beyond the original compliance failure.

Penalties for Non-Compliance and Cascading Consequences

Failing to generate a valid e-invoice carries direct financial penalties under GST law, but the real exposure extends far beyond the fine itself. Each non-compliant invoice triggers a chain of downstream consequences that affects not just the supplier but the buyer and the physical movement of goods.

Direct Penalties

Three penalty provisions apply to e-invoicing failures:

Failure to generate an e-invoice: Rs 10,000 per invoice or 100% of the tax due on that invoice, whichever is higher. For a high-value transaction where the GST component exceeds Rs 10,000, the penalty scales with the invoice amount.
Incorrect or erroneous e-invoices: Rs 25,000 per invoice for invoices that contain errors in the mandatory fields of the JSON schema.
Invoice treated as "not issued": An invoice generated without a valid IRN is not recognized as having been issued under GST law. This is not a technical distinction. The invoice cannot be regularized retroactively. It simply does not exist in the eyes of the GST framework.

To put the per-invoice penalty in perspective: a business issuing 100 invoices per month without valid IRNs faces a minimum penalty exposure of Rs 10 lakh per month, before accounting for the tax-proportional penalty on higher-value invoices.

The Cascading Consequences Chain

What makes e-invoicing non-compliance particularly damaging is the way a single failure propagates through multiple systems and affects multiple parties. Without an IRN, the invoice is not recognized as having been issued under GST. Every downstream process described in the previous section breaks simultaneously: the buyer's GSTR-2A/2B is never populated, denying them ITC on a purchase they already paid tax on. The supplier's GSTR-1 is not auto-populated, forcing manual entry and creating reconciliation gaps. And if the transaction requires an e-way bill, the absence of a valid e-invoice renders it invalid too, meaning goods in transit can be physically detained at checkpoints.

The cascading nature means your non-compliance becomes your customer's financial problem. The buyer loses their tax credit through no fault of their own. A single missing IRN can halt a shipment. And the exposure compounds: persistent non-compliance across multiple invoices triggers GST audit attention, and the inability to produce valid IRNs for a volume of transactions creates a documentation gap that is difficult to defend during assessment.

A Supply Chain Problem, Not Just a Tax Filing Problem

The critical insight is that e-invoicing non-compliance is not contained within the supplier's own tax filings. The buyer loses ITC. Goods get detained in transit. Business relationships suffer when your customers discover their tax credits were denied because of your compliance failure. For businesses operating in sectors with tight margins or high transaction volumes, the combined financial exposure from penalties, lost buyer goodwill, and operational disruption from detained shipments far exceeds the cost of implementing compliant e-invoicing processes from the outset.

If you discover that your business should have been generating e-invoices but has not been doing so, past invoices cannot be retroactively registered with the IRP. The invoices already issued without IRNs remain legally invalid, and the penalty exposure for those periods is real. The practical course of action is to begin compliant e-invoice generation immediately for all new invoices and consult a GST practitioner about voluntary disclosure and potential penalty relief for the non-compliant period.

Reporting Deadlines, MFA, and Preparing for Compliance

The e-invoicing framework is not static. GSTN has introduced several technical changes in 2025 that affect how businesses interact with the Invoice Registration Portal, and more are scheduled for mid-year. If your organization is newly in scope or approaching the Rs 2 crore threshold, understanding these changes now prevents costly surprises later.

Reporting Windows: 30 Days or 3 Days

The standard reporting window for uploading e-invoices to the IRP is 30 days from the invoice date. If you issue an invoice on March 1, the JSON payload must reach the IRP and receive an IRN by March 31 at the latest.

However, taxpayers with an aggregate annual turnover exceeding Rs 10 crore face a significantly tighter constraint: a 3-day reporting window. That same March 1 invoice must be reported by March 4.

The consequence of missing either window is straightforward and severe. The IRP will not generate an IRN for a late submission. Without the IRN, the invoice is non-compliant under GST law, which means the buyer cannot claim Input Tax Credit on it and the seller faces penalty exposure under Section 122.

Mandatory Two-Factor Authentication

From April 2025, two-factor authentication is mandatory for every user accessing the e-invoice portals. This requirement applies universally regardless of your turnover bracket. Whether your business sits at Rs 5 crore or Rs 500 crore, every login to the IRP now requires MFA.

For organizations with multiple users generating or managing e-invoices, this means each individual must have MFA configured on their account. ERP administrators should coordinate with their finance teams well before the enforcement date to ensure no one is locked out during a critical invoicing cycle.

Invoice Number Case-Insensitivity

Starting June 2025, the IRP will auto-convert all invoice numbers to uppercase before processing. "INV-2025-001" and "inv-2025-001" will be treated as identical, and the second submission will be rejected as a duplicate.

This change has real implications for businesses whose billing or ERP systems treat invoice numbers as case-sensitive. If your numbering scheme relies on mixed-case distinctions to differentiate invoices, branches, or series, you need to update those configurations before June. Audit your existing invoice number formats and confirm that converting everything to uppercase produces no collisions.

Preparing for the Rs 2 Crore Threshold

If your business is approaching or has recently crossed the Rs 2 crore aggregate turnover mark, preparation should begin months before e-invoicing becomes mandatory for you. The following steps cover the essential groundwork.

Verify your turnover status. Aggregate turnover is calculated across all GSTINs under a single PAN, and the relevant period extends back to any financial year from 2017-18 onward. If your turnover exceeded Rs 2 crore in any of those years, you are already in scope even if current-year revenue is lower.

Assess your billing system's readiness. Your ERP or accounting software must be capable of generating invoice data in the Form GST INV-01 JSON schema and integrating with the IRP's APIs. If your current system cannot produce the required JSON output, you need either an upgrade, a middleware solution, or a different billing platform entirely.

Review HSN code accuracy. Every line item on an e-invoice requires a valid HSN or SAC code. Businesses with turnover up to Rs 5 crore must use 4-digit codes; those above Rs 5 crore need 6-digit codes. Inaccurate or missing HSN codes will cause the IRP to reject the invoice outright.

Test in the sandbox environment. The NIC provides an API sandbox at einv-apisandbox.nic.in where you can submit test payloads and validate your integration before going live. Use it extensively. Discovering schema errors or authentication issues in production means failed invoices and compliance gaps.

Ensure invoice numbering compatibility. With the June 2025 case-insensitivity rule, confirm that your invoice number series will not produce duplicates when converted to uppercase. Update your numbering logic now rather than troubleshooting rejection errors later.

Set up MFA for all portal users. Every person in your organization who will access the e-invoice portal needs two-factor authentication configured and tested before their first real submission.

Given the volume of structured data that Form GST INV-01 demands — approximately 50 mandatory fields per invoice spanning supplier details, buyer information, line items, and value breakdowns — businesses processing high invoice volumes increasingly rely on automated invoice data extraction tools to standardize and validate invoice data before IRP submission. Extracting and formatting this data manually at scale invites the kind of errors that trigger rejections and downstream compliance failures.

That same preparation should also distinguish IRP registration from India's GST reverse charge and self-invoice rules, which create a separate recipient-side document workflow.

India's e-invoicing mandate has moved steadily in one direction since 2020: more businesses, tighter reporting windows, stricter technical requirements. The Rs 2 crore threshold will bring millions of additional SMEs into scope, many for the first time. Whether you are already generating e-invoices or preparing to start, understanding the full chain from IRP registration through GSTR-1 auto-population, ITC reconciliation, and e-way bill validity is what separates compliant operations from costly surprises.