# India: reconcile e-invoices, e-way bills and GST returns without duplicating sales Invoice registration, goods movement and return filing are different operating events. A successful invoice response does not establish that a vehicle can depart, and an e-way bill does not establish that the outward-supply return is complete. Joining these events by customer name or invoice value alone creates duplicate sales and hides missing documents. This guide designs one reconciliation for a supplier already confirmed to be subject to the relevant e-invoicing requirements. It does not infer eligibility from a turnover figure, apply one movement rule to all states or replace an assessment of exemptions. The tax owner must first approve which registrations, documents and movements are in scope. The remaining task is to make that assessment executable and auditable. ## Define the three populations The GST portal's GSTR-1 manual describes IRP-generated invoice references and the flow of e-invoice information into outward-supply records. It separately describes review, summary generation and filing. Treat auto-population as an input to reconciliation, not evidence that the statement has been filed. [GST portal GSTR-1 manual](https://tutorial.gst.gov.in/userguide/returns/Creation_of_Outward_Supplies_Return_in_GSTR-1.htm) Start with the ERP's posted sales and credit-note register, divided by supplier [GSTIN](https://erplocalization.com/glossary/global/#global-gstin) and period. For each document retain the document type, number, date, counterparty GSTIN, taxable value, tax components, gross amount and current status. Preserve both original and correction identities rather than overwriting the original document after a rejection. Create a second population of invoice-registration requests and responses. Link the returned IRN and signed response to the exact ERP document. Keep accepted, rejected, pending, cancelled and unresolved-timeout cases distinct. An integration retry is not a new business sale. Create a third population for goods movements. It should identify dispatch, origin, destination, transporter and the approved movement-document decision. One sale can involve operational circumstances that need a separate assessment; a service invoice does not acquire a goods movement simply because its amount is large. NIC's API introduction describes e-way bill integration directly or through a GSP and separately covers generation, vehicle updates and cancellation. It also explicitly labels a pre-production URL section. Public documentation is not proof that a particular taxpayer or connector has production access. [NIC e-way bill API introduction](https://docs.ewaybillgst.gov.in/apidocs/introduction.html) ## Establish a production gate before dispatch Record the actual production provider, authorised GSTIN, account owner, endpoint, credential rotation owner and permitted operations. Keep testing credentials separate from production credentials. Obtain the provider's evidence for the deployed interface and complete an approved production readiness review before relying on automated shipping decisions. No production credentials, live submissions or ERP build were tested for this guide. Its examples are source-based controls and synthetic reconciliations. Production approval remains an implementation deliverable tied to the seller's actual provider and transport process, rather than a claimed feature of a named ERP. Review current change notices as part of that approval. NIC's announcement dated 30 July 2026 says recent e-way bill changes, including closure functionality and mandatory Ship-to GSTIN, are on hold. A previously announced change must therefore not be treated as an active validation simply from its earlier announcement date. [NIC announcements](https://docs.ewaybillgst.gov.in/apidocs/announcements.html) The integration owner should record the effective rule set used by the deployed connection and compare it with the current release notes. Retain acceptance evidence for representative valid and invalid requests. This is particularly important where a sandbox behaves differently from production or a provider introduces its own validation. [NIC release notes](https://docs.ewaybillgst.gov.in/apidocs/release-notes.html) ## Worked example: four tax documents, two forward shipments The synthetic example uses one supplier GSTIN, one reporting period and INR. Assume all three sales and the credit are valid, in-scope B2B e-invoice documents. An approved 18% tax rate applies throughout. The tax owner has separately confirmed that both forward goods movements need e-way bills. There are no exports, advances, rounding differences or cancellations. Invoice A sells goods for INR100,000, tax INR18,000 and gross INR118,000. Invoice B sells goods for INR50,000, tax INR9,000 and gross INR59,000. Invoice C provides services for INR20,000, tax INR3,600 and gross INR23,600. Credit D reverses INR10,000 of A's taxable value, INR1,800 tax and INR11,800 gross. The three sales total INR170,000 before the credit. The signed document population is therefore INR160,000 taxable value, INR28,800 tax and INR188,800 gross. These are the expected ERP and outward-supply reconciliation amounts for the simplified case, subject to correct return classification and period treatment. The invoice-registration population has four document identities, including the credit. Its signed values must match the same INR160,000, INR28,800 and INR188,800. Comparing only the number of documents would miss a wrong amount, while comparing only gross totals could hide an omitted document offset by an unrelated duplicate. The forward-dispatch population has two goods movements, for A and B. Invoice C has no goods movement in this example. Credit D does not automatically create another e-way bill: whether goods are returned, and the applicable document and movement rules, require a separate decision. Preserve the credit-to-invoice link regardless of that logistics outcome. For the return workpaper, identify which documents arrived through auto-population and which require another approved entry path. Match by supplier GSTIN, document type, number and date, then confirm values and classifications. The final reviewer signs the reconciliation and the filing acknowledgement separately. A download of auto-populated records is insufficient completion evidence. ## Resolve a partial success without issuing another invoice Suppose invoice A obtains an IRN but its e-way bill request fails. Keep the invoice-registration success. Route the movement exception to logistics and the integration owner, confirm the authoritative response and follow the approved dispatch hold or alternative legal process. Issuing a second sales invoice to retry the movement would create an accounting and tax problem unrelated to the transport error. If a request times out, look up the existing document's status before resending. Use the same business identity and the provider's supported recovery procedure. Store the correlation identifier, request hash, response and resolution so that a later operator can distinguish a failed request from a response that was simply lost. A different failure occurs if the ERP exports A manually after it has already been imported into the return population. The duplicate raises taxable value from INR160,000 to INR260,000 and tax from INR28,800 to INR46,800. Gross becomes INR306,800, overstated by INR118,000. The return reviewer should remove the duplicate through the supported process and retain the explanation; the underlying valid invoice remains unchanged. ## Assign ownership and prove completion Sales accounting owns posted invoice completeness and corrections. The tax owner owns scope, tax components, return classification and filing. Logistics owns dispatch facts, transporter changes and movement exceptions. The integration owner owns identities, status recovery and provider changes. The controller owns the reconciliation connecting all four areas. At close, freeze an evidence snapshot rather than relying on a dashboard that refreshes after filing. Include documents posted late, accepted responses received after cut-off, credits and cancellations. Age unmatched items with an owner and reason. A pending case needs an explicit decision about dispatch and reporting, not a generic green status because another step succeeded. ## Completion checklist - Approve e-invoice and movement scope for the actual taxpayer and transaction classes. - Confirm production access and the currently deployed validation set. - Join ERP documents, IRNs, goods movements and return records by stable identities. - Reconcile signed values and document counts separately. - Test accepted invoice/failed movement and timeout recovery paths. - Prevent duplicate manual and auto-populated return entries. - Retain filing acknowledgement and unresolved-case decisions with the close snapshot. Use the [India document and movement worksheet](#template). Related reading: [revenue, billing and tax points](https://erplocalization.com/guides/revenue-billing-vat-tax-point/) and the site's [e-invoice status guide](https://erplocalization.com/guides/e-invoice-statuses-finance-operations/). Sources checked 17 October 2026. Current NIC announcements were read alongside the API introduction; no historical API example is presented as a production endpoint or universal movement rule. ## Worksheet: India document, movement and return reconciliation worksheet Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment. Show the worksheet Use with the [India reconciliation guide](https://erplocalization.com/guides/india-einvoice-ewaybill-return-reconciliation/). Establish transaction scope and production access separately before using this control operationally. ### Scope and environment - Supplier GSTIN, period, scope approval and exceptions: - Provider, production endpoint, authorised operations and credential owner: - Current release/announcement review and deployed validation evidence: - Dispatch decision owner and transport evidence: ### Joined populations Record ERP document type/number/date, taxable value, tax components, IRN/status, dispatch identity, e-way bill decision/status and return record/status. Preserve corrections and authoritative responses. Reconcile signed values and counts independently. Rehearsal: goods invoices100,000 and50,000, service20,000 and credit10,000 yield taxable value 160,000;18% tax 28,800; gross 188,800. Four invoice identities do not imply four forward goods movements. Two forward goods shipments are approved; service has none, and credit movement is assessed separately. ### Exception decisions - Accepted IRN/failed movement and dispatch hold resolution: - Timed-out request lookup before retry: - Auto-populated/manual duplicate prevention: - Return reconciliation and actual filing acknowledgement: - Logistics, tax, accounting and integration owner sign-off: Duplicate invoice100,000 would overstate tax by18,000 and gross by118,000. Prove the reconciliation detects it without cancelling the valid original sale. ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/india-einvoice-ewaybill-return-reconciliation/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".