Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
ERP issues invoices and the IRP holds the authoritative IRN repository, but the two registers drift apart through missed IRN generation, expired cancellation windows, schema rejections, and amount truncation, leading to GSTR-1 mismatches and ITC denial for recipients.
Pull the ERP invoice register and the IRP IRN repository for the same period, match on invoice document number and date, then classify exceptions into ERP-without-IRN (compliance gap), IRP-without-ERP (cancelled or missed posting), and matched-but-amount-mismatch (rounding, truncation, GST recompute).
Set the reconciliation period to one GST return month, include all six IRPs the entity uses, freeze the ERP register at GSTR-1 filing cutoff, and apply a one-rupee tolerance for GST rounding under Section 170 while flagging anything above that for review.
A four-bucket exception report: missing IRNs requiring urgent IRP push within the 30-day window, stale cancellations needing credit-note reversal in books, amount mismatches with the variance and root cause, and a clean-matched register ready for GSTR-1 auto-flow verification.
Every taxpayer above the notified turnover threshold runs two parallel invoice registers without always realising it. One sits inside the ERP or billing system, where the finance team posts sales. The other sits on the Invoice Registration Portal as an IRN repository, generated under Rule 48(4) of the CGST Rules. The two are meant to be identical. In practice, they drift, and the drift shows up as GSTR-1 auto-flow gaps, ITC denial notices to customers, and unhappy reconciliations at year-end.
This article walks through how to reconcile the ERP invoice register against the IRP IRN repository, what to do about each class of exception, and how to design the cycle so the books and the portal stay in lock-step.
Quick reference: deadlines, windows, and failure modes
| Item | Position |
|---|---|
| IRN generation deadline | 30 days from invoice date for taxpayers above the notified turnover threshold (Rule 48(4), Notification 17/2022 staged thresholds) |
| IRN cancellation window | 24 hours on the IRP, only if no active e-Way Bill is linked |
| GSTR-1 auto-flow | IRNs reported to the IRP auto-populate GSTR-1 B2B, exports, and credit/debit note tables |
| IRP options | Six designated IRPs: NIC IRP-1, NIC IRP-2, and four GSTN-authorised private IRPs |
| Common failure modes | IRP downtime, schema validation rejection, HSN length mismatch, GSTIN mismatch, recipient state code error |
Why the two registers drift
The ERP issues an invoice the moment the sales document is saved. Posting hits revenue and the customer ledger immediately. The IRN, on the other hand, requires a separate API call to one of the six IRPs, a JSON payload that conforms to the e-invoice schema, and a signed response that must be stored against the invoice record.
There are four standard reasons the two registers drift:
- Schema validation rejection at the IRP. The ERP saves the invoice, but the IRP rejects the payload because of an HSN length error, a non-existent GSTIN, or a state code that does not match the recipient’s place of supply. The finance team often does not see the rejection because it surfaces in the integration log rather than the ERP exception report.
- IRP downtime or timeout. The integration retries, but if the retry queue is not monitored, the invoice ages past 30 days without an IRN. The recipient’s GSTR-2B will not show the invoice, and ITC will be denied.
- Cancellation timing. A sales return arrives on day three. The ERP voids the invoice, but the IRN cancellation window closed on day one and a half. Now the IRN is live on the IRP for an invoice that no longer exists in books.
- Amount truncation and rounding. Some ERPs round GST at line level, the IRP recomputes at invoice level, and the two numbers differ by a rupee or two. Small individually, material at filing volume.
The 30-day window is a hard wall
Notification 17/2022 introduced the time limit for IRN generation. It started as a seven-day window for taxpayers above INR 100 crore aggregate turnover and has since been broadened and re-staged. The current position applies a 30-day window for taxpayers above INR 5 crore aggregate turnover. Once the window closes, Rule 48(5) treats the invoice as not issued, which means the recipient cannot claim ITC on it. There is no procedural remedy to back-date the IRN.
This is why the reconciliation cycle has to run at least weekly, ideally daily, for any business with more than a few hundred invoices a month. A monthly cycle at GSTR-1 filing time is too late, because invoices issued early in the month will already have aged out.
The 24-hour cancellation window is also a hard wall
Once an IRN is generated, it can be cancelled on the IRP within 24 hours, provided no e-Way Bill is active against it. After 24 hours, the IRP locks. If the underlying transaction needs to be reversed, the only path is a credit note in books, which itself must be reported to the IRP as a separate document with its own IRN.
The operational consequence is that finance and sales need a same-day channel to flag invoice-level errors. A return or a billing correction that arrives on day two cannot be fixed by cancelling the IRN. It has to be handled as a credit note, which complicates the customer ledger and the GSTR-1 line.
The IRN-to-GSTR-1 auto-flow
IRNs reported to any of the six IRPs flow into the GSTN system and pre-populate the relevant tables of GSTR-1. The taxpayer still has to verify and file the return, but the auto-flow removes the manual entry burden for B2B invoices, exports, and credit and debit notes.
The reconciliation implication is significant. If an invoice exists in the ERP but no IRN was generated, it will not appear in the auto-populated GSTR-1. The taxpayer either misses it at filing or adds it manually, which then creates a downstream gap because the IRP repository still does not have the IRN. Either way, the recipient’s GSTR-2B will be incomplete, and an ITC dispute is inevitable.
Worked example: 12,800 IRNs in a month
Consider a manufacturing business generating 12,800 invoices in a month, all above the turnover threshold and therefore requiring IRNs. At the end of the month, the reconciliation team pulls two registers for the same period:
- ERP invoice register: 12,810 documents posted to revenue in the GST period.
- IRP IRN repository: 12,795 IRNs generated across NIC IRP-1 and one private IRP the business uses for failover.
The two numbers do not agree. The reconciliation cycle classifies the variance.
Bucket A: ERP without IRN (compliance gap). Matching on invoice document number and date, 18 invoices exist in the ERP but have no corresponding IRN. Investigation shows 11 were rejected by schema validation (a new HSN code was added by procurement without updating the IRP master), four are in the retry queue from an IRP outage, and three are genuine misses where the integration silently failed. All 18 must be pushed to the IRP immediately. Twelve are still within the 30-day window. Six have aged past, and those invoices are now effectively unissued under Rule 48(5). The customers will not get ITC, and the business owes them either a fresh invoice (if the supply is ongoing) or a commercial settlement.
Bucket B: IRP without ERP (cancellation or missed posting). Three IRNs exist on the IRP with no matching ERP entry. Two were cancelled within the 24-hour window on the IRP but the ERP void did not flow through because the user closed the browser before saving. One is a duplicate IRN generated when the integration retried after a timeout. The two cancelled IRNs need their ERP records voided. The duplicate IRN needs to be cancelled on the IRP if still within 24 hours, or a credit note issued if not.
Bucket C: Matched but amount mismatch. 47 invoices match on document number but show a rupee-level variance between the ERP-stored amount and the IRP-stored amount. Applying a one-rupee tolerance under Section 170, 41 fall within tolerance and are accepted. Six show variances above a rupee. Three are line-level rounding errors in the ERP (fixable by patching the rounding routine), two are GSTIN-driven recomputes (the IRP recalculated GST at a different rate because the recipient’s GSTIN registration changed mid-month), and one is a genuine data-entry error.
Bucket D: Clean matched. The remaining 12,742 invoices match cleanly and are ready for GSTR-1 auto-flow verification.
Net of the exercise, the business closes the month with 18 compliance gaps remediated (or commercially settled where the 30-day window had passed), three cancellation hygiene issues fixed, six amount mismatches root-caused, and a clean register ready for GSTR-1 filing. Without the reconciliation, the six aged-out invoices would have surfaced as ITC denial notices from customers six to eight weeks later, after GSTR-2B reflected the gap.
If your business is bleeding ITC because IRN gaps surface late, the ITC Leakage Calculator will help size the annual exposure.
How to structure the reconciliation cycle
Three design choices matter.
Frequency. Run the reconciliation at least weekly for any volume above a few thousand invoices a month. Daily is better. The 30-day window does not forgive monthly cycles.
Scope. Include all six IRPs the entity uses, not just the primary. Most businesses route through one NIC IRP and one private IRP as failover, and exceptions hide in the secondary register.
Cutoff discipline. Freeze the ERP register at GSTR-1 filing cutoff and reconcile against the IRP repository as of the same timestamp. Pulling the ERP register live while the IRP register is from yesterday produces phantom exceptions that waste investigation effort.
What the reconciliation engine has to do
A reliable engine matches on invoice document number and date, applies a tolerance to GST amounts, and classifies exceptions into the four buckets above. It also has to:
- Reach all six IRPs, since the business may route across multiple.
- Handle the IRP repository’s pagination and rate limits without dropping records.
- Preserve the signed IRN payload alongside the match record, for audit defence.
- Surface the 30-day window remaining for each unposted IRN, so the team can triage by deadline rather than by document number.
- Cross-link to the e-Way Bill register, because the 24-hour cancellation window is also gated by EWB status.
Closing
e-Invoice IRN reconciliation is not a GSTR-1 filing exercise. It is a continuous control that runs between the ERP and the IRP, with two hard walls (30 days for generation, 24 hours for cancellation) and one auto-flow (IRP to GSTR-1) that only works if the upstream register is clean. Businesses that treat it as a monthly filing chore lose ITC for customers and, eventually, lose customers.
For the broader GST reconciliation stack, see GST reconciliation software. For the full Indian reconciliation landscape including bank, NACH, and platform settlement coverage, see reconciliation software India.