GST e-invoicing: who must comply and what the ERP must do

The Invoice Registration Portal keeps your registered invoice for exactly one day. CBIC's own e-invoice FAQ is explicit: "As far as data on IRP is concerned, it will be available only for 24 hours." Every gst e-invoicing integration that treats the IRP as a system of record is one outage away from a problem, and that is the design mistake we see most often.

This post covers who is actually inside the mandate as of 27 September 2026, what the real document path looks like, and the behaviour your ERP has to implement — retries, duplicates, signed-payload storage, cancellations and credit notes. It is not tax advice; confirm your own position with your adviser.

Who must comply with GST e-invoicing today

E-invoicing is mandatory for a registered person whose aggregate turnover exceeded ₹5 crore, with the GST Council's notification page recording that Notification 10/2023-Central Tax "seeks to implement e-invoicing for the taxpayers having aggregate turnover exceeding Rs. 5 Cr from 01st August 2023".

Three details about that threshold decide most borderline cases:

• The test looks backwards across years, not at last year alone. The notification wording is aggregate turnover "in any preceding financial year from 2017-18 onwards". CBIC's FAQ works the arithmetic the same way: if you cross the limit in the current financial year, e-invoicing applies from the beginning of the next financial year, "assuming that the aggregate turnover of the subject registered person had not crossed the prescribed threshold of aggregate turnover during any of the previous financial years wef: 2017-18". On that reading, crossing once brings you in and a later fall does not take you out — but it is a reading of the wording, so get it confirmed rather than assumed.
• Aggregate turnover is measured at PAN level, not GSTIN level. CBIC's FAQ answers the case directly: a legal entity with an exempt SEZ unit and a regular DTA unit under the same PAN still has e-invoicing applied to the DTA unit, "because the aggregate turnover of the legal entity in this case exceeds the notified limit".
• For FY 2017-18 the turnover is counted from 1 July 2017, since GST started mid-year.

Which entities are exempt

The exemption list comes from the GST Council's 39th meeting and is reproduced in GSTN's detailed overview of the e-invoice/IRN system. Exempt classes of registered person are Special Economic Zone units; an insurer, banking company or financial institution including an NBFC; a goods transport agency supplying road transportation of goods; suppliers of passenger transportation service; and suppliers of services by way of admission to exhibition of cinematograph films in multiplex screens.

Two things that look like exemptions but are not. B2C supplies are outside the scheme — the API documentation instructs that "the category of transaction of 'Business to Consumer (B2C)' invoices will not be considered and hence the API interface should not request for IRN for these transactions" — but B2C turnover still counts towards the threshold that puts your B2B invoices inside it. And credit notes and debit notes are covered: the documents in scope are invoices, credit notes and debit notes issued to registered persons or for exports. Summaries that list credit notes as out of scope are wrong, and an ERP built on that assumption will under-report.

The ₹2 crore threshold: proposed, not notified, as of 27 September 2026

A reduction from ₹5 crore to ₹2 crore has been discussed at GST Council level for some time. As of 27 September 2026 we have found no notification giving it effect, and the most recent published compliance guidance we checked still records that the mandatory threshold remains ₹5 crore. Until a notification exists, ₹5 crore is the live number.

Which is the practical argument for the engineering position we take on every Indian ERP build: the threshold belongs in configuration, and applicability belongs in a rule the finance team can change without a deployment. A business sitting between ₹2 crore and ₹5 crore today should build as if it will be covered, because the lead time on an IRP integration is longer than the lead time on a notification. Check your own status on the portal's own e-invoice enablement lookup rather than inferring it — enablement and legal liability are different things, but the lookup tells you what the system thinks.

The document path, and the step teams get wrong

E-invoicing is not invoice generation by a government portal. You keep creating invoices in your own ERP. The flow is:

1. Your ERP produces the invoice and serialises it as JSON against the notified schema, Form GST INV-01. The IRP accepts JSON only.
2. The ERP posts it to the IRP, directly on the API or through a GSP or ASP.
3. The IRP validates, de-duplicates against the central registry, and returns the IRN, the complete invoice signed with JWT/JWS using SHA256RSA, and a separately signed QR code.
4. Your ERP stores the signed payload and the signed QR. This is the step that gets missed.
5. The IRP forwards the data to the GST system, which auto-populates GSTR-1, and to the e-way bill system.

Step four is not optional housekeeping. The IRP is deliberately lean — "IRP will not store invoices" — and CBIC's FAQ puts the retention at 24 hours. The signed QR is what makes offline verification possible and, under Rule 46 of the CGST Rules, printing it on the invoice is mandatory. The QR carries supplier and recipient GSTIN, the supplier's invoice number, the invoice date, taxable value and gross tax, the number of line items, the HSN code of the highest-value line item, the IRN and the IRN generation date. If the signed JSON is tampered with, the signature fails and the e-invoice is invalid — so store the bytes you received, not a re-serialised copy.

On the e-way bill: it is generated from the same payload if you pass Transporter ID and vehicle details, and the response returns EwbNo, EwbDt and EwbValidTill. The e-way bill does not replace e-invoicing or the other way round — CBIC's FAQ confirms an e-way bill is still required wherever it is mandatory.

The 30-day reporting window, if it applies to you

GSTN's advisory of 27 March 2025 lowered the reporting time limit threshold from ₹100 crore to ₹10 crore AATO with effect from 1 April 2025: businesses at or above that turnover must report e-invoices within 30 days of the document date, across invoices, credit notes and debit notes. After the window closes the portal will not accept the document at all. Below ₹10 crore AATO, the restriction does not currently apply.

Two consequences for the build. Ageing matters: an invoice sitting in a failed-submission queue is a compliance problem on a timer, so the queue needs an age alert well inside 30 days rather than a retry loop that fails quietly. And backdating stops working — the API already rejects requests with document dates before 1 April 2025 outright.

IRN cancellation is 24 hours, and the e-way bill can block it

The cancellation rules are narrow, and the NIC API documentation and CBIC's FAQ agree on all of them:

Rule	What your ERP has to do
IRN can be cancelled within 24 hours of generation	Timestamp from the IRP's AckDt, not your server clock
Cancellation is in toto — no partial cancellation	Model cancel as a whole-document action, then issue a fresh e-invoice
An active or verified e-way bill blocks cancellation	Cancel the e-way bill first; if an officer verified it in transit, neither can be cancelled
A cancelled invoice number can never be reused	Burn the number in your series; never recycle it, even inside the 24 hours
Amendments are not possible on the IRP at all	Corrections go through GSTR-1 on the GST portal, so build the reconciliation, not an amend call

Past 24 hours, the instrument is a credit note with its own IRN, not a cancellation. That is an accounting decision with a system consequence: your invoice lifecycle has a hard one-way door in it, and any workflow that lets a user "edit and resend" an invoice the next morning is wrong by construction.

What the ERP integration must actually handle

The single most useful fact for anyone building this is how the IRN is derived. Per the NIC specification, the IRN is the SHA256 hash of the supplier GSTIN, the document number, the document type and the financial year of the document date. It is a pure function of data you already hold. That makes the whole integration idempotent if you let it.

• Retries. Treat submission as at-least-once and rely on the IRP for de-duplication: "if the IRN is already generated on particular type of document and document number of the supplier for the financial year, then one more IRN cannot be generated on the same combination". A duplicate error on retry usually means your first attempt succeeded and you lost the response, so the recovery path is a lookup, not a resubmission with a new number.
• Duplicates. Your own number series is the primary key the IRP uses. Enforce uniqueness per financial year inside the ERP — the documentation puts that responsibility squarely on the supplier — and reject numbers starting with 0, / or -, which the IRP rejects outright.
• Signed payload and QR storage. Persist the SignedInvoice and SignedQRCode strings verbatim against the invoice record, with the AckNo and AckDt. Your PDF renderer reads the QR from storage; it never re-derives it.
• Status. The response carries a status of ACT or CNL. Mirror it, and make GSTR-1 reconciliation read your mirror rather than re-querying the portal per invoice.
• Credit notes. They need their own IRN under the credit-note document type, with the same uniqueness and window rules as invoices.
• Auth and crypto. The payload is encrypted with a session key and the auth token expires, so token refresh and key rotation belong in the integration layer, not in each caller.
• Cancelled IRNs. An IRN cannot be regenerated for a cancelled e-invoice, so the cancellation path must terminate cleanly rather than looping.

None of this is exotic, but it is the difference between an integration that survives a bad afternoon on the IRP and one that produces a month-end reconciliation nobody can close. It is the same discipline we apply to any regulated flow — well-built API integrations make the compliance edge cases survivable rather than heroic.

Where this fits if you operate across borders

India was early, and the model is spreading with local variations that do not map onto each other. If you also sell into the Gulf, the UAE requires an accredited service provider appointed before go-live. In Europe the obligation has started from the receiving side rather than the issuing side — every French business must now be able to receive an e-invoice — and the validation rules bite differently, as EN 16931 validation, where a discount needs its own VAT rate shows.

The lesson from running all three at once is that the ERP should own one canonical invoice record and treat each jurisdiction's portal as a plug-in with its own schema, its own window and its own idempotency key. Teams that instead fork the invoice model per country end up with three systems of record and no reconciliation. If you are picking a platform for this, what Odoo really costs in India covers the trade-off, and our custom ERP development practice is where we do the integration work.

Start with the enablement lookup and the turnover history. Everything else in this post is engineering you can schedule; applicability is the one thing you cannot find out by testing.