The e-invoicing mandate requires vendors above ₹5 Cr annual turnover to generate an Invoice Reference Number (IRN) from the Invoice Registration Portal before submitting invoices to buyers. A vendor portal that accepts invoices without validating the IRN is accepting documents that may not be GST-compliant, creating ITC risk that surfaces at GSTR-2B reconciliation, not at the point of submission. The fix is not a vendor problem. It is a portal design problem.
Most AP teams treat e-invoicing as something their vendors manage. That is accurate up to the point of submission. After that, the compliance obligation shifts. If your vendor portal accepts a non-compliant invoice and your team processes it, the ITC consequence falls on your company, not the vendor.
What the E-Invoicing Mandate Requires from the Buyer's AP Function
The e-invoicing framework, introduced under GST Notification No. 13/2020 (Central Tax) and progressively extended by turnover threshold, places the IRN generation obligation on the supplier. The supplier registers the invoice with the IRP, receives an IRN and a signed QR code, and then submits the invoice to the buyer.
What the mandate does not state explicitly, but what the ITC mechanics make clear, is that the buyer's AP function carries the downstream risk.
GSTR-2B, the auto-populated ITC statement, draws only from invoices reported to the IRP with a valid IRN. An invoice submitted to your vendor portal without an IRN, or with an IRN never registered with the IRP, will not appear in your GSTR-2B. If your team processes it and claims ITC, that claim has no auto-populated support in the return. During scrutiny, the department can deny the credit.
Under Section 16 of the CGST Act, as typically interpreted, a valid tax invoice reflected in GSTR-2B is a condition for ITC eligibility. An invoice without a valid IRN does not meet this condition. The gap compounds across every non-compliant invoice your portal accepts.
Where Vendor Portals Create the Gap
Standard vendor portal implementations validate invoice format: is the PDF readable, are the required fields present, does the GSTIN match the vendor master. These are necessary checks. They are not sufficient.
IRN validation is different. It requires confirming that the IRN on the submitted invoice was actually issued by the IRP for that specific invoice, and that the signed QR code is authentic. This is done via an API call to the IRP at the point of submission. Most vendor portals do not make this call.
The result is a gap that is invisible until reconciliation. The invoice looks correct, the vendor's GSTIN is valid, the invoice number and date are present. Your portal accepts it, your ERP books it, your team processes payment. At month-end, the invoice does not appear in GSTR-2B because the IRN was either absent or fabricated. The ITC claim sits exposed.
The vendor categories that create the most exposure are predictable. Vendors near the ₹5 Cr turnover threshold are most likely to be uncertain about their e-invoicing applicability and may submit invoices without IRNs. New vendors onboarded quickly, without threshold verification, are another common source. Unorganised suppliers in manufacturing, logistics, and construction supply chains frequently operate without reliable invoicing systems.
A portal that does not flag these vendors at onboarding and does not validate IRN at submission is accepting risk on every invoice they submit. Earlier published analysis on common vendor invoice submission errors found that format errors and missing fields are the most visible failure points. IRN absence is less visible and more consequential. Finance teams who have seen why vendor portals fail to reduce AP workload will recognise this as the same pattern: a tool designed for submission, not control.
What a Vendor Portal Needs to Do to Close the Gap
Four controls address the IRN validation gap in sequence.
First, vendor onboarding must capture turnover data and flag e-invoicing applicability. A vendor above the threshold should be tagged in the system so that IRN validation is triggered on every invoice they submit. Vendors below the threshold are exempt; the portal should not apply the same validation rules to them.
Second, IRN presence must be checked at submission. If a vendor above the threshold submits an invoice without an IRN field populated, the portal should reject it at the point of upload with a specific error message, not route it for approval.
Third, IRN authenticity must be verified via IRP API. An IRN field can be populated with an invalid or fabricated number. The IRP provides a public API to verify that a given IRN was issued for a specific invoice. This call should happen at submission, before the invoice enters the AP queue.
Fourth, the portal needs an escalation path for contested rejections. IRP downtime creates a legitimate edge case.
When a vendor's IRN fails IRP validation because the portal cannot reach the IRP, due to outage or sync lag, the invoice is treated as invalid under GST Rule 48(4), as typically interpreted, and will not auto-populate in GSTR-2A/2B. The standard operational response is to hold the invoice in a pending state rather than reject it outright. The vendor must retry IRN generation once the IRP is restored. If the invoice falls outside the 30-day reporting window, a credit note and re-invoice may be required.
ITC eligibility on invoices caught in this scenario is not protected by any regulatory carve-out for technical IRP failures, as of the current position. There is no published GST advisory that provides relief for IRP downtime. Finance teams facing this situation should seek CA or tax counsel for case-specific rulings, and maintain documentation of the IRP downtime as evidence in the event of a scrutiny notice. This is an interpretive position, not a definitive ruling.
A vendor portal that treats IRP downtime as a rejection rather than a hold will damage vendor relationships without reducing compliance risk. The right design holds the invoice, notifies the vendor, and routes it for manual review with a timestamp showing when the IRP became unreachable. For a broader view of how vendor compliance under GST affects AP operations, the controls here follow the same principle: the portal is a compliance checkpoint, not a pass-through.
See how IQInvoice validates IRN at the point of vendor invoice submission.
Key observations
- The e-invoicing mandate places ITC risk on the buyer when a vendor portal accepts non-IRN invoices. The buyer's AP function carries the reconciliation consequence, not the vendor.
- GSTR-2B auto-populates only from IRP-registered invoices; invoices without valid IRNs create ITC gaps that surface at return time, not at payment time.
- IRN presence checks and IRP API authenticity verification are two distinct controls. Most vendor portals implement neither.
- Vendor onboarding is the upstream fix: tagging vendors by e-invoicing applicability at the point of onboarding prevents the wrong validation rules from applying downstream.
- IRP downtime is a legitimate edge case with no regulatory carve-out; the correct response is a timed hold with manual review, not an outright rejection.
FAQ
- Is IRN validation the responsibility of the buyer or the seller under GST e-invoicing rules?
- What happens to ITC if a vendor submits an invoice without an IRN?
- How does a vendor portal validate an IRN against the IRP?
- Which vendors are exempt from the e-invoicing mandate in India?
Published by IQInvoice IQInvoice is an AI-powered accounts payable automation platform for Indian mid-market finance teams.