Every B2B invoice above the GST e-invoicing turnover threshold has to be reported to the Invoice Registration Portal (IRP) before it is legally valid, and any consignment above the value limit needs a live e-way bill before the goods move. Handled manually, that means finance teams re-key the same Sales Invoice into the GST/NIC portals, copy the IRN and signed QR back onto the print format, and chase Part-B vehicle updates by phone — slow, error-prone, and a genuine risk when a truck is stopped without a valid EWB. Stock ERPNext gives you the Sales Invoice, GST tax templates, and HSN/SAC fields, but it does not natively talk to the IRP/GSTN e-invoice APIs, mint an IRN, embed the government signed QR, or manage e-way bill Part-A/Part-B generation and cancellation. That last mile is exactly where teams fall back to the portal.

ECOSIRE builds a proper Frappe app — its own module, DocTypes, and hooks.py doc events — that closes that gap inside ERPNext. On submit of a Sales Invoice, a server-side on_submit handler validates the payload (GSTIN format, HSN/SAC presence and length, place-of-supply, tax breakup) against the schema the IRP expects, calls the authenticated IRP/GSTN API through your GSP or the sandbox, and writes the returned IRN, acknowledgement number, acknowledgement date, and Base64 signed QR back onto the invoice. A GST E-Invoice Log DocType stores the full request/response, the digitally signed invoice, and the QR image so every filing is auditable, and the print format renders the signed QR automatically. E-way bill generation is driven from the same document: Part-A is derived from the invoice, Part-B (transporter ID, vehicle number, mode) is captured on a dedicated DocType, and the EWB number, validity, and updates are pushed and pulled through the NIC EWB API. Cancellation within the government time window, IRN cancel, and reason codes are all handled through whitelisted server methods rather than the portal.

Under the hood it is standard, upgradable Frappe engineering — not a fragile script. Auth tokens are cached and refreshed on a scheduler_event so you are not re-authenticating per call; API credentials live in encrypted Frappe settings, never in code. Whitelisted methods (@frappe.whitelist()) expose generate/cancel actions to client scripts and buttons on the Sales Invoice, and the same methods are reachable over the Frappe REST API for your own integrations. Role profiles and DocType permissions keep e-invoicing actions scoped to your accounts and compliance roles. We also build the GSTR-1 and GSTR-3B data preparation layer — report views and export scripts that reconcile booked invoices, IRN status, and EWB status so your return filing starts from clean, matched data rather than a spreadsheet dump. The whole thing targets Frappe/ERPNext v15 and v16 and is delivered as a versioned app on your bench, so bench update and future migrations behave.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to confirm your GSP versus direct-IRP setup, turnover thresholds, document types in play (invoices, credit notes, exports, SEZ), and how your transporters work. You get a fixed statement of work, then we build and test against the government sandbox, run UAT on a staging bench with your real invoice patterns, and only cut over with a rollback plan agreed in advance. Typical delivery is one working week from confirmed scope. You receive the full source, the git repository, technical and user documentation, a training session, and a post-go-live support window.