India GST E-Invoicing & IRP Compliance

The problem

Indian GST e-invoicing is not a report you run at month end. Every B2B invoice, credit note and debit note above the notified turnover threshold has to be pushed to an Invoice Registration Portal, come back with an IRN, a digitally signed QR code and an acknowledgement number, and carry that IRN on the printed document before the goods or the service leaves your hands. If a transport movement is involved, an e-way bill has to exist against the same IRN, with the correct vehicle number, transport mode and distance, and it has to be updated when the vehicle changes en route.

NetSuite's own India localization gives you tax codes, GST-aware tax schedules, HSN and SAC fields and some statutory report layouts. What it does not give most accounts is a reliable, auditable pipeline from a posted transaction to an accepted IRP payload and back again — with retries, cancellation windows, error decoding, and a reconciliation view that ties your subsidiary ledger to what the portal actually holds. So finance teams end up keying invoices into a portal by hand, or exporting spreadsheets, uploading them somewhere else, and pasting IRNs back into NetSuite. Every manual hop is a place where a mismatched taxable value, a wrong place of supply, or a missing recipient GSTIN turns into a rejected filing and a blocked customer payment.

What ECOSIRE builds

ECOSIRE builds this as a NetSuite customization inside your account — not a hosted middleware product you rent. The delivered work is a SuiteScript 2.1 / SDF project you own outright.

Record model and data capture

We add custom records for the compliance objects that NetSuite has no home for: an IRN register, an e-way bill register, an IRP request/response log, and an error-code dictionary. Transaction body and column fields are added to Invoice, Credit Memo, Cash Sale and Vendor Bill as required, plus entity-level fields on Customer, Vendor and Subsidiary for GSTIN, registration type, place-of-supply defaults and e-invoicing applicability. Item-level HSN/SAC, UQC and reverse-charge flags are wired to Inventory Item, Non-Inventory Item, Service Item and Kit/Package records so the payload builder reads real master data rather than free text.

Payload build and validation

A User Event script validates the transaction before it can be submitted: recipient GSTIN checksum and state code, place of supply against the shipping address, taxable value versus line-level tax amounts, HSN presence per line, and document-type-specific rules for credit and debit notes. Failures surface as a field-level status on the transaction, not a silent skip. The payload builder assembles the JSON schema the IRP expects, including the seller, buyer, dispatch-from and ship-to blocks, item list with UQC and assessable value, and the value-details totals that the portal cross-checks.

IRP and e-way bill integration

Outbound calls run through N/https from a Scheduled or Map/Reduce script with a token cache held in a custom record, so authentication is refreshed rather than re-requested per document. Responses are parsed, the IRN, acknowledgement number, acknowledgement date and signed QR payload are written back to the transaction, and the QR image is rendered onto the Advanced PDF/HTML template so the printed invoice is compliant. Cancellation, within the portal's allowed window, is exposed as a Suitelet action that records the reason code and writes the outcome to the log. E-way bill generation is handled the same way — Part-A from the invoice, Part-B from a transporter record, with vehicle-update and consolidated-bill actions available to warehouse roles.

GSTR reconciliation

A Map/Reduce job reads the accepted IRP register for a period and compares it against saved searches over your NetSuite ledger, producing a reconciliation record per subsidiary with three buckets: in NetSuite but not at the portal, at the portal but not in NetSuite, and present in both with a value or tax-rate difference. Results are exportable and drillable back to the source transaction, so the person who has to sign the return can see exactly which document caused a variance.

Governance

All of it is permissioned. New roles and permission sets separate who may submit, who may cancel, and who may only view the register. Every call and every state change lands in the request/response log with the user, timestamp and raw payload, which is what an auditor or a GST officer will ask for.

Who this is for

Companies running NetSuite with one or more Indian GST registrations — including OneWorld tenants where India is one subsidiary among several and the group cannot afford an India-specific bolt-on that breaks consolidation. It suits businesses with real transaction volume (so manual portal entry has become a headcount problem), businesses that move physical goods and therefore live with e-way bills, and businesses whose auditors have already flagged the gap between the portal and the ledger.

How delivery works

1. Scoping call. We walk your actual transaction flows, subsidiaries, item types, existing India localization setup and any middleware already in place. We look at your sandbox. 2. Fixed quote and scope document. You get a written scope listing every script, record, field, role and template we will build, plus the acceptance criteria. The price is fixed against that scope. 3. Build. Development happens against your sandbox account as an SDF project. You see progress in the sandbox, not in a demo tenant. 4. Install in test, then production. We deploy and validate in your sandbox with your data and your portal credentials in the test environment first. Only after you sign off does the same bundle go to production, in a window you choose. 5. Support window. A defined post-go-live support period covers defects, portal schema changes encountered during that window, and handover questions. After that, ongoing support is a separate agreement if you want one.

Nothing here is pre-built or downloadable. Typical lead time from signed scope to production install is two to four weeks depending on subsidiary count and how much of your master data needs cleaning first.