An illustrative project pattern — not an attributed client engagement — showing how we typically approach a common Odoo problem: a business registered under several GSTINs, each one submitting e-invoices to the IRP separately, with no single view of what’s failed and why.
Picture a retail chain running Odoo, operating warehouses and billing counters across several
Indian states. Each state means a separate GSTIN, and under India’s e-invoicing mandate, each
invoice above the applicable turnover threshold has to be reported to the Invoice Registration
Portal (IRP) individually — per GSTIN, not per company. Odoo’s Indian localisation
(l10n_in_edi) handles the submission itself well enough. What it doesn’t give you out
of the box is a combined view across registrations.
In practice that means someone on the finance team logs into a separate view (or filters by company) for every GSTIN, every day, looking for invoices the IRP rejected — usually for a mismatched HSN code, a duplicate invoice number, or a schema validation error the portal doesn’t explain in plain language. A rejected invoice sits there until a human notices, re-opens it, fixes the field, and resubmits by hand. Multiply that by five or six state registrations and the checking itself becomes a job.
The pattern doesn’t replace Odoo’s e-invoicing integration — it sits on top of it, pulling every GSTIN’s submission status into one place and closing the loop on failures automatically.
Every company record’s IRP submission status — acknowledged, pending, rejected — rolled into one screen, filterable by GSTIN, date, or failure reason.
Rejected invoices land in a queue instead of a dead end. Transient failures (portal timeouts, rate limits) get retried on a schedule without anyone touching them.
The IRP’s raw schema error codes get translated into the actual field that’s wrong — HSN mismatch, duplicate invoice number, incorrect place-of-supply — so a fix doesn’t need a specialist to interpret.
Where a shipment needs an e-way bill, it’s generated and linked back to the matching IRN automatically instead of being a separate manual step someone has to remember.
State-level finance staff see and act on their own GSTIN’s queue; group finance sees the roll-up across all of them — without spreadsheet exports in between.
Anything that fails after repeated automatic retries gets flagged to a human immediately, instead of surfacing three weeks later during GSTR-1 reconciliation.
This is a description of a design pattern and its intended effect, not a measured result from a real deployment. We’d expect the specific numbers — how many invoices, how many GSTINs, how much staff time — to vary a lot by business, which is exactly why we don’t print fabricated ones here.
Tell us how many registrations, states, and roughly how many invoices a month. We’ll come back with a straight answer on whether a unified dashboard and retry queue is worth building for your setup — and what it would take.