Skip to main content

VisionONE

Skip to content

GST e-invoicing in India: an ERP readiness and control guide

GST e-invoicing means reporting eligible invoice data to an Invoice Registration Portal (IRP) and receiving an Invoice Reference Number (IRN) and QR code. An ERP readiness project should establish applicability, clean the invoice data, capture the IRP response and reconcile the result. A PDF invoice on its own does not complete that process. This explanation follows the IRP’s overview of e-invoicing.

Sources checked: 3 November 2026.

Does e-invoicing apply to this business?

Start with the legal entity, PAN-linked turnover history, GST registrations, supplier category and document types. The IRP’s e-invoicing mandate page lists Notification 10/2023 (dated 10 May 2023) as bringing businesses with aggregate annual turnover above ₹5 crore into e-invoicing from 1 August 2023, and states that turnover in any preceding financial year from 2017–18 onwards must be considered. Review the underlying notification and applicable exclusions with the business’s GST adviser; do not decide eligibility using only this year’s sales or the portal’s enabled status.

Prepare an applicability worksheet for each registration. Record who checked it, which financial years were considered, the evidence used, any exclusion relied upon and the date for the next review. Distinguish customer-facing B2B/export processes from other invoice flows. Keep an explicit decision for each flow so that an implementation does not silently treat all documents alike.

What reporting deadline should the team monitor?

The IRP advisory effective 1 April 2025 states that taxpayers with AATO of ₹10 crore or more must report e-invoices within 30 days of the invoice date. Treat the reporting window as a separate control from the threshold that determines whether e-invoicing applies. It is not a reason to wait until the end of the window. Confirm current advisories before deployment.

Set an internal daily review of invoices awaiting registration, with an escalation owner and an ageing view. A rejected request should remain visible until corrected or resolved through an approved accounting process. Never change a genuine document date simply to pass a reporting restriction. Agree how finance will handle an outage, a rejected document and a request whose result is uncertain.

Which master data and invoice fields need checking?

Build a mapping workbook that names the source field, transformation, required validation, target field and accountable owner. Include supplier and recipient identifiers, document type/number/date, addresses and state codes, place of supply, item classifications, units, taxable values, tax components and totals. Review special transaction patterns using the current schema rather than treating a standard domestic sale as representative of every case.

Give customer and item masters a controlled correction process. For example, a sales user should be able to report an invalid tax identifier without inventing a temporary replacement. Decide whether a corrected master affects only future invoices or requires a separate review of existing documents. Maintain test cases for rounding differences, discounts and unusual document numbering.

How should the ERP handle requests, responses and retries?

Use separate operational states for preparation, submission pending, confirmed registration, rejection and uncertain outcome. Save the document identifier, request correlation, timestamp, returned IRN/QR information and any error details appropriate to the implementation. Limit access to credentials and avoid putting authentication secrets in ordinary business logs.

Demonstrate recovery from a timeout before approving an automatic retry design. The operator should determine whether a previous request succeeded before creating another business document. Show how the accepted response is attached to the correct invoice, how the customer-facing output is produced and how finance investigates a mismatch. These are proposed acceptance controls; their exact implementation must be confirmed for VisionONE.

How does e-invoicing relate to dispatch and e-way bills?

An IRN and an e-way bill serve different purposes. Ask the implementation team to demonstrate the complete invoice-to-dispatch journey, including what happens when an invoice is registered but transport details are incomplete. Define which team supplies those details and what evidence the dispatch operator checks before releasing goods.

Do not implement a requirement merely because an earlier announcement proposed it. The NIC release notes dated 30 July 2026 say that the proposed mandatory Ship-to GSTIN and EWB Closure enhancements were kept on hold. Recheck the latest release notes and the selected IRP/API version before signing off a Bill-to/Ship-to design.

What should a supervised acceptance session cover?

Agree a test environment and permission before any portal or live submission. Walk through a normal eligible invoice, a rejected master value, a duplicate/uncertain response, a credit or debit adjustment relevant to the business, and a dispatch exception. Use approved synthetic records where possible. Have finance inspect accounting entries and tax totals, while operations checks what the customer and dispatch team actually receive.

Keep an acceptance record with expected result, observed result, evidence, defect owner and approval. Do not mark the integration ready merely because a green status appeared once. Include role permissions, monitoring, support ownership, business continuity and a first-week reconciliation schedule in the handover.

What questions commonly arise before launch?

Is an emailed PDF enough to count as an e-invoice?

No. A PDF is an output format; eligible e-invoicing involves registration with the IRP. Check the returned registration evidence and the invoice output together.

Does an accepted IRN prove that every tax decision is correct?

Use acceptance as evidence of portal processing, alongside the business’s own tax review and reconciliation. Keep responsibility for classification, transaction treatment and accounting approval clear.

Can we assume VisionONE supports every IRP or transaction type?

No product scope is asserted here. Ask for a demonstration against the chosen registrations, IRP, document types and exception cases, and put the supported scope in writing before launch.

For the surrounding evaluation, see ERP software for India, GST e-invoicing and the ERP selection checklist. Prepare a representative scenario list before requesting a demonstration.