Guides, glossaries and calculators to help you scope, cost and run an ERPNext implementation — from GST and e-invoicing setup to module-by-module walkthroughs.
Quick definitions of key terms
Expert insights and updates
Simple step-by-step resources
Easy explanations through videos.
Complete IRN flow in ERPNext (2026)
ERPNext HRMS for India's Labour Codes
ERPNext for Indian hospitals (NABH, ABDM, DPDP)
DPDP Act 2023 Compliance in ERPNext
IRN generated from the invoice, not re-keyed into a portal. E-invoicing fails in one of two ways. Either your team is keying invoices into a portal a second time, or the integration exists but rejects one invoice in twenty and nobody finds out until the buyer calls. Both are fixable, and the fix is mostly in validation, not in the connection.
ERPNext supports IRN generation through the India Compliance app, which talks to the e-invoice portal via a GST Suvidha Provider.
Yes. With the India Compliance app configured against a GST Suvidha Provider, submitting a sales invoice sends it to the e-invoice portal and returns the IRN, acknowledgement number and signed QR code onto the invoice itself. The QR prints on the customer copy and cancellation within the permitted window is handled from the same document.
The portal is strict and unforgiving about things your own invoice format never cared about. That mismatch is where the failures come from.
A missing HSN on one line, a state code that does not match the buyer's GSTIN, a unit of measure outside the permitted list, or a rounding difference of a rupee. Each rejects the whole document, and the message rarely names the field in plain language.
Where failures are not surfaced, an invoice goes out without a valid IRN and the buyer's team finds it during their own credit reconciliation. By then the correction window may have closed.
An IRN can only be cancelled within a limited period after generation, and after that the correction has to happen through a credit note instead. Teams that do not track that clock end up with mismatched books and returns.
Invoices cancelled in the ledger but not on the portal, or generated on the portal and never marked in the ledger, produce a difference that only appears at annual reconciliation, when it is expensive.
The goal is that nobody thinks about e-invoicing on an ordinary day, and that the exceptions are visible within minutes.
Submitting a sales invoice sends it to the portal and writes the IRN, acknowledgement number, acknowledgement date and signed QR back onto the same document.
No second system, no re-keying, and the printed invoice carries the QR because it is pulled from the record rather than pasted in.
The conditions the portal will reject on are checked before the document is sent — HSN present on every line, buyer GSTIN format and state consistency, permitted UOM codes, place of supply, and total rounding.
Catching these at submit turns a portal rejection into an on-screen message the biller can fix in ten seconds.
Rules are configured so e-invoicing applies to the document types and counterparties it should, and not to those it should not, including exports and supplies to unregistered persons.
Applying it too broadly is as disruptive as missing it, because the portal rejects documents that should never have been sent.
Cancellation within the permitted window is initiated from the invoice, and the remaining time is visible. Beyond it, the workflow routes to a credit note instead of leaving the user stuck.
The clock is shown on the document, so nobody has to remember when the window closes.
Any invoice that failed to generate an IRN sits in a visible queue rather than passing silently, and periodic reconciliation compares ledger invoices against portal records.
This is the control that keeps books and portal in step through the year rather than at the annual return.
The exchange is per document and initiated from ERPNext. Nothing is pushed to the portal without a submitted invoice behind it.
| ERPNext field | E-invoice schema | Direction | Notes |
|---|---|---|---|
| Sales Invoice on submit | IRN generation request | ERPNext → Portal | Sent via GSP; validated locally first |
| Company GSTIN & address | Seller details | ERPNext → Portal | Must match the registration exactly |
| Customer GSTIN & billing address | Buyer details | ERPNext → Portal | State code has to agree with the GSTIN prefix |
| Item lines with HSN & UOM | Item list | ERPNext → Portal | HSN mandatory per line; UOM from the permitted list |
| Tax breakup & totals | Value details | ERPNext → Portal | Rounding differences are a frequent rejection cause |
| Shipping address | Dispatch / ship-to | ERPNext → Portal | Required where goods move to a third party |
| IRN, Ack No, Ack Date | Written back to the invoice | Portal → ERPNext | Stored on the document and used on the print format |
| Signed QR code | Invoice print format | Portal → ERPNext | Rendered on the customer copy automatically |
| Cancellation request | IRN cancellation | ERPNext → Portal | Only inside the permitted window; reason code required |
Tested against real documents before cutover, because the first time you find a rejection pattern should not be with a live customer invoice.
Which of your entities and document types are within scope, and which counterparties and transaction types are outside it. This determines the configuration and prevents documents being sent that should not be.
Credentials for your chosen GST Suvidha Provider are configured against your registration, with the connection proved in the sandbox environment before production.
The usual blockers are fixed at source: items without HSN, UOMs outside the permitted list, customer GSTINs that fail validation, addresses with mismatched state codes.
Domestic, inter-state, export, SEZ, credit note and any unusual document type you actually raise are each run through the sandbox until they generate cleanly.
Production cutover with the failure queue and reconciliation report in place from day one, plus a short session so billing staff know what to do with a rejection.
Timeline shown is indicative and depends heavily on master data condition, which stage three establishes. Statutory thresholds and requirements change; applicability is confirmed with your own advisors.
Worth knowing before you assume e-invoicing removes an obligation it does not.
This is general information, not legal or tax advice. Applicability thresholds change; confirm your position with a qualified professional.
In practice yes for most businesses. ERPNext connects to the e-invoice system through a GST Suvidha Provider, and that subscription is contracted in your own name. The connection is configured during implementation and proved in sandbox before any live invoice is sent.
The invoice submits in ERPNext and the IRN request lands in the exception queue rather than blocking your billing. It is retried, and the queue makes it visible that a document is still without an IRN, so nothing slips out silently.
Yes. The signed QR returned by the portal is stored on the invoice record and rendered by the print format, along with the IRN and acknowledgement details. Your existing format is adapted rather than replaced.
Within the permitted window, yes, initiated from the invoice with a reason code. The remaining time is shown on the document. After the window closes the correction has to be a credit note, and the workflow routes you there rather than failing silently.
A periodic reconciliation compares invoices in the ledger against IRN records for the same period, so cancelled-but-not-cancelled and generated-but-not-recorded cases surface during the year rather than at annual return time.
Export invoices have their own treatment within the e-invoice schema and are configured accordingly, including SEZ supplies which are handled differently again. Whether it applies to your business at all depends on turnover thresholds that change, so it is confirmed with your advisors rather than assumed.
A short call about how invoices leave your business today and where IRN generation currently breaks.
ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. References to the GST e-invoice system, IRN and GST Suvidha Providers describe statutory infrastructure operated by or on behalf of Indian tax authorities and are used here for identification only.
