IRN Generation Step-by-Step — A Complete Guide for ₹5 Cr+ Businesses

Most "how to generate an IRN" guides online are screenshots of the GSTN portal with arrows. They are useless the moment you cross 20 invoices a day, and they say nothing about the parts that actually break in production: the 30-day reporting cap, the JSON validation errors, the cancellation window, and the difference between the six approved IRPs.

This guide is the version we wish we had on day one of integrating e-invoicing for the first time. It covers the full lifecycle of an Invoice Reference Number — how it is generated, what the JSON looks like, the three ways to get it, and the production gotchas that bite later.

What an IRN Actually Is

The Invoice Reference Number is a 64-character alphanumeric hash generated by the Invoice Registration Portal (IRP) using SHA-256 on four fields:

• Supplier GSTIN (15 characters)
• Financial year in YYYY-YY format (e.g., 2026-27)
• Document type (INV for invoice, CRN for credit note, DBN for debit note)
• Document number (your internal invoice number, max 16 alphanumeric characters)

Once generated, the IRN is unique and immutable. The same combination of GSTIN + FY + doctype + docnum can never produce two valid IRNs. This is why duplicate document numbers within a financial year are the most common cause of rejection.

The IRP returns three artefacts back to your system: the IRN itself, a digitally signed JSON payload, and a base64-encoded QR code containing the key invoice details. All three must be archived — not just the IRN.

Who Is Required to Generate IRNs in 2026

The current threshold (as of April 2026) is aggregate annual turnover of Rs 5 crore in any financial year from 2017-18 onwards. Once crossed, the obligation is permanent. The rule applies to:

• All B2B supplies (invoice, credit note, debit note)
• Exports (with or without payment of tax)
• Supplies to SEZ units and developers
• Reverse charge transactions where the supplier is registered

It does not currently apply to B2C invoices, exempt supplies, or non-GST transactions. Businesses with turnover above Rs 500 crore have a separate obligation to print a dynamic QR code on B2C invoices, which is a different rule and a different system.

Step 1: IRP Enablement

If your business has multiple GSTINs under one PAN, each GSTIN must be enabled separately. The aggregate turnover declaration applies at the PAN level — but the technical enablement happens GSTIN by GSTIN. Skipping a branch GSTIN is a common reason businesses unintentionally issue some invoices without IRNs.

Step 2: Choose Your Generation Mode

There are three ways to actually generate IRNs once enabled. The choice depends entirely on invoice volume and your existing billing setup.

Mode 1: Direct API Integration

Your billing software calls the IRP's REST API directly. Best for businesses with internal IT teams or off-the-shelf billing software that natively integrates with the IRP. Authentication uses Client ID and Client Secret obtained from the IRP, plus a session token that expires every 6 hours.

Sample API endpoint and headers:

POST https://einvapi.gst.gov.in/eivital/v1.04/Invoice
Headers:
  client-id: {your_client_id}
  client-secret: {your_client_secret}
  user_name: {gstin_user}
  password: {auth_password}
  AuthToken: {session_token}
  Gstin: {your_gstin}
Content-Type: application/json

Mode 2: GSP / ASP Route

A GST Suvidha Provider (GSP) sits between your billing software and the IRP, handling authentication, retries, and error normalisation. The six approved IRPs in 2026 are NIC, Cygnet, Clear, IRIS, BDO, and EY. Some offer free clearance with paid value-added services. This mode is ideal for businesses that want resilience and audit logs without building integration in-house.

Mode 3: Manual Offline Tool

The IRP provides an Excel template (and a JSON tool) where you fill invoice data, validate it locally, and upload it to the portal in batches. Each upload returns a JSON response file containing IRNs and QR codes. This works for businesses issuing fewer than 20-30 invoices a day. At higher volumes the manual overhead and error rate make it impractical.

Step 3: The Invoice JSON Payload

Whichever mode you use, the IRP expects a strict JSON schema. The current spec is INV-01 (e-invoice schema) with 28 mandatory fields. A minimal valid payload looks like this:

{
  "Version": "1.1",
  "TranDtls": {
    "TaxSch": "GST",
    "SupTyp": "B2B",
    "RegRev": "N",
    "EcmGstin": null,
    "IgstOnIntra": "N"
  },
  "DocDtls": {
    "Typ": "INV",
    "No": "INV/2026/0427",
    "Dt": "26/04/2026"
  },
  "SellerDtls": {
    "Gstin": "29AAACS1234A1Z5",
    "LglNm": "Softwaller Technologies Pvt Ltd",
    "Addr1": "1st Floor, Sample Building",
    "Loc": "Bengaluru",
    "Pin": 560001,
    "Stcd": "29"
  },
  "BuyerDtls": {
    "Gstin": "27AABCT1234B1Z2",
    "LglNm": "Buyer Pvt Ltd",
    "Pos": "27",
    "Addr1": "Office Building",
    "Loc": "Mumbai",
    "Pin": 400001,
    "Stcd": "27"
  },
  "ItemList": [{
    "SlNo": "1",
    "PrdDesc": "Software License",
    "IsServc": "Y",
    "HsnCd": "997331",
    "Qty": 1,
    "Unit": "OTH",
    "UnitPrice": 100000.00,
    "TotAmt": 100000.00,
    "AssAmt": 100000.00,
    "GstRt": 18.00,
    "IgstAmt": 18000.00,
    "TotItemVal": 118000.00
  }],
  "ValDtls": {
    "AssVal": 100000.00,
    "IgstVal": 18000.00,
    "TotInvVal": 118000.00
  }
}

The IRP validates every field against business rules — GSTIN format and active status, HSN code validity, place-of-supply versus seller state for IGST/CGST split, sum-of-items versus invoice total within Re 1 tolerance, and so on. A single mismatch causes the entire invoice to be rejected.

Step 4: The IRP Response

On success, the IRP returns a JSON containing the IRN, the digitally signed e-invoice payload, and the QR code data. Three fields matter most:

• Irn: the 64-character hash. Print this on the invoice PDF.
• SignedQRCode: a base64-encoded JWT containing key invoice details. Convert to a QR image and print on the PDF. The QR must be readable by any GST officer's mobile scanner.
• AckNo and AckDt: acknowledgement number and timestamp. Required for e-way bill linking and as proof of timely reporting under the 30-day rule.

On failure, the response contains an error array with codes (e.g., 2150, 3028, 2194). Map every code to a human-readable reason in your billing UI so accountants can self-serve fixes without IT involvement.

The 30-Day Rule (Effective April 2025)

From April 1, 2025, businesses with aggregate turnover of Rs 10 crore or more must report invoices to the IRP within 30 days from the invoice date. The rule covers all three document types — invoices, credit notes, and debit notes.

After 30 days, the IRP simply refuses to generate an IRN. There is no late fee mechanism, no penalty payment that recovers the rejection. The only remedy for an unreported old invoice is:

1. Issue a credit note (with IRN) cancelling the original
2. Raise a fresh invoice with a current date (with IRN)
3. Notify the buyer so they can claim ITC against the new invoice number

This rule is widely expected to extend down to the Rs 5 crore bracket within the next two GST Council meetings. Treat it as already universal if you operate near the threshold.

The 24-Hour Cancellation Window

Once an IRN is generated, the e-invoice can be cancelled only within 24 hours. After that, you must issue a credit note (which itself needs an IRN) to neutralise it. Common reasons for cancellation within the window:

• Wrong buyer GSTIN entered
• Duplicate invoice raised in error
• Quantity or rate corrections discovered before despatch

Every cancellation must include a reason code from the IRP's predefined list (1=Duplicate, 2=Data Entry Mistake, 3=Order Cancelled, 4=Others). Cancellation fully voids the IRN — the same invoice number cannot be reused in the same financial year.

Common Rejection Codes and Fixes

• 2150 (Duplicate IRN): The same invoice number was already submitted. Either fetch the existing IRN via GET API or change the invoice number.
• 3028 / 3029 (Recipient GSTIN inactive or invalid): The buyer's GSTIN is suspended, cancelled, or never existed. Verify on the GST portal before billing.
• 2194 (Total item value mismatch): Sum of line items does not equal invoice total within Re 1 tolerance. Usually a rounding issue in the billing software.
• 2234 / 2235 (CGST/SGST or IGST amount mismatch): Tax computation does not match the rate and assessable value. Cross-check the GST rate against the HSN code.
• 2240 (Invoice date older than 30 days): The 30-day reporting cap has expired. The invoice cannot be IRN-generated; issue a credit note plus fresh invoice.

The hard truth: 80% of IRN rejections come from 5 errors. Build validation for those five at the billing-screen level, and your IRP rejection rate drops to under 1%.

The Production-Ready Checklist

Before going live with API-based IRN generation, ensure your system handles all of the following:

1. Token refresh: the IRP auth token expires every 6 hours. Auto-refresh in background; never let an invoice fail because the token aged out.
2. Idempotency: retry logic must be safe. Use the GET-IRN endpoint to check if a duplicate was already generated before retrying a POST.
3. Rate limiting: the IRP rate-limits per GSTIN. Build a queue and respect the limits, especially during month-end batch runs.
4. Signed payload archival: store the full signed JSON, not just the IRN. During audit, the department asks for the signed payload as proof of authenticity.
5. QR rendering on PDF: the QR must be scannable and contain the SignedQRCode payload exactly as returned. Cropped or low-resolution QRs are a common audit finding.
6. Error code translation: map every IRP error to a human-readable message in your billing UI. Accountants should never see "Error 2194" without context.
7. Reconciliation report: end-of-day report listing every invoice raised vs every IRN generated. Mismatches must be flagged before midnight.

Manual Portal vs Software: When to Switch

If you are issuing fewer than 20 invoices a day, the IRP's offline Excel tool is workable. The data-entry overhead is roughly 4-5 minutes per invoice including validation. At 50+ invoices a day, manual entry consumes 4+ hours of daily accountant time and the error rate climbs above 10%.

API integration via your billing software collapses this to under 2 seconds per invoice with sub-1% rejection rate. The break-even point is somewhere between 20 and 30 invoices per day — past that, automation pays for itself within the first month purely on labour and rework savings.