The mail said e-invoice. The attachment was just a PDF.

Let me open with the thirty seconds that settled it. I pointed my phone at that QR the way you would, expecting the IRN screen. Nothing. Tried the IRN field: two proud letters, NA. Called the supplier, who called their software vendor, who admitted the e-invoice module was quote-unquote in the next release. The stamp had shipped before the integration. I have since learned this is not rare. It is the default failure shape of every new compliance format: the cosmetic layer arrives first, the plumbing months later.

The row, not the document

This is the mental shift the whole page hangs on, so I will state it twice in different words. The e-invoice is a database row. The supplier's system sends invoice data to the portal, the portal validates it and hands back an IRN plus a QR encoding it, and that row is what makes it an e-invoice. The PDF mailed afterwards is a souvenir of that transaction.

And souvenirs can lie, innocently or otherwise, while rows cannot. That asymmetry is your entire verification strategy in one sentence: never trust the souvenir, always check the row. Background on the acronyms if you need it: what IRN means. What follows is the workflow.

One more thing before the field notes. Who has to do this runs on turnover, and the threshold has stepped down several times since e-invoicing began. I will not print the current number because it moves and this page outlives notifications. Judge each voucher by the threshold on the invoice's date, not today's. And when a supplier below the threshold sends you a print with an IRN anyway, voluntary registration, enjoy it: the verification is free and the pedigree is real.

Anatomy of an honest print

When the integration actually exists, the print carries its proof in two places. Learn to find both and the fakes announce themselves:

Three field notes on fake pedigree

Field note one, the commonest: the stamped template. E-INVOICE across the top, no IRN, dead QR. Usually a small supplier whose software prints the stamp by default, or a big supplier's branch that never finished integration. My response is boredom, not alarm. Unverified print, unverified credit, send it back with specifics.

Field note two, the trickiest: an IRN that does not verify. The portal lookup fails, or resolves to different details. Causes I have seen: a cancelled IRN reprinted by habit, a transposed character in the string, once a copied IRN from another invoice entirely. That last one got a phone call, not a posting. Match four things every time: invoice number, date, both GSTINs, grand total. Any drift and the print does not represent the row.

Field note three, the happy one: the honest print. IRN resolves, QR decodes, details match. It still goes through everything else on this site, checksum, fields, HSN, arithmetic within ₹1, regime, then 2B and the 16(4) clock like any bill. The IRN proves registration. It does not prove the supplier filed GSTR-1 or that your 2B line exists. Different halves, same credit.

The tick mark I won't sell you

Every quarter someone asks me whether our gate verifies IRNs, and every quarter I say no. It validates the document in front of it. Portal checks need the portal, your phone, and two minutes. I could fake a tick mark that regexes the IRN format and call it verification. Format is not existence. I would rather tell you plainly where our product ends than decorate the boundary.

So the routine, in full, before the voucher posts: scan the QR, look up the IRN, match the four fields, check applicability by the invoice's date, and only then let the normal gate have it. Two minutes per suspicious print. And triage honestly: a long-trusted supplier whose prints have verified for a year earns spot checks, while a new supplier, a new template, or anything with NA where the IRN should be earns the full routine every time. Trust builds its own fast lane. Suspicion pays full fare.