GST E-Invoicing and Your ERP: What Must Be Automatic, What Must Stay Manual

GST e-invoicing means that for every B2B, B2G or export invoice above the turnover threshold, your system must send the invoice to the Invoice Registration Portal, receive an Invoice Reference Number and a signed QR code, and print both on the document — and, where goods move, raise the e-way bill from the same record. The 2026 guides ranking for this search explain the mechanics well: API credentials from a GSP or the NIC, JSON to the current schema, HSN at four or six digits by turnover, two-factor authentication mandatory from April 2026, a 30-day reporting window above ₹10 crore. What they do not explain is where automation should stop. This article draws that line.

What the System Must Do Without a Human

• Build the JSON to the current e-invoice schema (version 1.1 per the guides), from the invoice record — never re-keyed.
• Carry HSN at the right digit level for your turnover band (four digits up to ₹5 crore, six above, per current rules), from the item master.
• Split tax by destination: CGST/SGST for intra-state, IGST for inter-state, based on the place of supply logic, not on which warehouse shipped.
• Validate the buyer’s GSTIN before submission; mismatched GSTIN and address is the most common IRN rejection the guides describe.
• Submit to the IRP directly or through a GSP, with 2FA handled per the rules, retries on transient failure, and rejections surfaced with the reason.
• Print the IRN and QR on the PDF and hold the signed JSON for the record.
• Raise the e-way bill from the despatch: vehicle, transporter, distance, validity — from the same record, in the same flow.
• Post the accounting entry to Tally or the book of record through the official integration.

Any of these done by hand is a re-keying error waiting to happen, and at volume the guides are blunt: API integration is the only method that scales.

What Must Stay a Human Decision

The portal validates format, not facts. Four decisions cannot be automated safely, and a system that pretends to make them is the more dangerous kind.

1. Which GSTIN and which address. A buyer with registrations in three states; a delivery to a site that is not the billing address. The system should propose; a person confirms.
2. B2B or B2C. E-invoicing applies to B2B, B2G and exports. A registered buyer purchasing for personal use, or an unregistered trader, changes the treatment. Somebody has to know the customer.
3. Cancellation. An IRN can be cancelled within 24 hours on the IRP; after that the correction is a credit note with its own tax consequences. Whether to cancel or credit is a judgement, and it has a clock.
4. Credit and debit notes that change the tax position. Rate disputes, returns, post-sale discounts. The system prepares; a person who understands the GSTR consequences approves.

The right design surfaces these four as explicit approval steps with the clock visible, and automates everything around them.

Integration Choices: Direct, GSP, or Someone Else’s Portal

For a custom system we integrate through a GSP where volume justifies it and directly where the client wants no third party; either way the four human decisions above are modelled as approval steps, and the accounting entry lands in Tally. That is the architecture behind the systems we build for Indian businesses, and the manufacturing version — works order to e-way bill — is in Manufacturing ERP in India.

The Numbers That Move, and Where to Read Them

Turnover thresholds, HSN digit rules, the reporting window and the 2FA date have all changed since e-invoicing began and will change again. This article states them as the 2026 guides state them and deliberately does not promise they still hold when you read it. The authoritative sources are the GST portal, the e-invoice portal (einvoice1.gst.gov.in) and your GSP’s release notes.

What does not change: the system should read those values from configuration a person can update, not from code a developer has to redeploy; and every threshold crossing — turnover passing ₹5 crore, then ₹10 crore — should be an alert, not a discovery at the next filing.

Frequently Asked Questions

Who needs to generate GST e-invoices in India?

Businesses with aggregate turnover above the threshold set by GSTN — ₹5 crore per the current 2026 guides — for B2B, B2G and export invoices. B2C invoices are outside e-invoicing (though large B2C invoices need a dynamic QR). Check the e-invoice portal for the current threshold.

What should my ERP do automatically for e-invoicing?

Build the JSON to the current schema, carry HSN at the right digit level, split CGST/SGST/IGST by place of supply, validate the buyer’s GSTIN, submit to the IRP directly or via a GSP with 2FA and retries, print the IRN and QR, raise the e-way bill from the same despatch, and post the entry to Tally.

What should never be automated in GST invoicing?

Which GSTIN and address the invoice is raised on, whether a supply is B2B or B2C, whether to cancel an IRN (24-hour window) or issue a credit note, and credit or debit notes that change the tax position. Surface these as approvals with the clock visible.

Can an e-invoice be cancelled?

Within 24 hours of IRN generation, on the IRP, provided no e-way bill is active against it. After that, the correction is a credit or debit note with its own GSTR consequences.

Is 2FA mandatory for e-invoicing?

Per the 2026 guides, two-factor authentication is mandatory for all taxpayers generating e-invoices from 1 April 2026. Systems integrating directly or via a GSP handle it in the credential flow; manual portal users face it on every session.