What Odoo GST e-invoicing covers and what it leaves to your team
Odoo's India localization covers the submission and document flows for GST e-invoicing and e-way bills, but it does not make your company compliant on its own. The l10n_in_edi module handles e-invoicing, while l10n_in_ewaybill and l10n_in_ewaybill_stock handle e-way bills, with the stock variant connecting the e-way bill to Inventory movements. For a finance or tax lead, the practical reading is a division of labor: the software generates, sends and records documents, and your team remains accountable for what those documents say and for the tax treatment behind them. Before planning any work, confirm which of these modules your Odoo version provides and which edition you run.
Within that boundary, the platform does several specific jobs. It submits e-invoices to the government portal through BVM IT Consulting Services India Private Limited, which Odoo uses as the GSP for e-invoicing, e-way bills and GST return filing. E-way bills can be created from Sales and Inventory documents, so dispatch data follows the transaction instead of being keyed twice. The GSP connection depends on API users created on the NIC e-invoice and e-way bill portals, so someone in your organization must own those accounts, their credentials and their renewal. Ask who holds those credentials today and where they will be stored before go-live.
Several inputs stay with your business. The company record must carry a valid PAN and GSTIN, and every customer, vendor and branch GSTIN must be correct, because the portal validates what Odoo sends. Your team also owns the tax masters: HSN or service codes on products, tax rates, tax mappings and the rules that decide which transactions are intra-state or inter-state. Invoice accuracy, transporter and vehicle details, and the handling of rejected or cancelled documents are operational duties. Legal interpretation of a taxable supply, and any decision a tax authority asks you to make, belong to your tax advisers and to the authority, not to the module.
DeployOpen's role is to prepare the configuration and the evidence that your team and your advisers need. That includes a documented configuration baseline for the company, tax and product masters, test records showing sample invoices and e-way bills sent through the portal, and a runbook for credential handling and rejected documents. DeployOpen does not issue certifications, audit reports or approvals, and no GSP or government body accepts a DeployOpen statement in their place. Ask any implementation partner, including DeployOpen, to state in writing which documents, company records and test cases are in scope, and which decisions remain with your organization.
Mapping each GST requirement to Odoo capability and configuration
This table maps each Indian GST obligation to the Odoo module or feature that handles it and the setup it needs before go-live. Read each row as a checklist: the capability column names what Odoo provides, and the configuration column lists what your team or partner must prepare, including NIC API users and GSP enablement. Company PAN and GSTIN are a dependency for every row, so verify them first.
| Requirement | Platform capability | Configuration needed |
|---|---|---|
| E-invoice submission to the NIC portal through the GSP | The l10n_in_edi module submits invoices to the NIC e-invoice system through BVM IT Consulting Services India Private Limited as GSP | Company PAN and GSTIN set, GSP enablement for the company, and an API user created on the NIC e-invoice portal |
| E-way bills from Sales and Inventory | The l10n_in_ewaybill module covers Sales documents, and l10n_in_ewaybill_stock covers Inventory transfers | Company PAN and GSTIN set, GSP enablement, and an API user created on the NIC e-way bill portal, plus the transport fields your shipping flow needs |
| GST return filing through the GSP | Return filing services run through the same GSP, BVM IT Consulting Services India Private Limited | GSP enablement for return filing, GSTIN recorded on the company, and filing access confirmed with the GSP and your tax adviser |
| TDS and TCS | Configured through the Odoo India tax setup, as described in the Odoo India fiscal localization documentation | Confirm the exact configuration in the Odoo India documentation and your business's tax policy before creating any TDS or TCS rule |
| Company identity data (PAN and GSTIN) | Required on the company record for the Indian localization and used by e-invoicing, e-way bill and return filing | Enter PAN and GSTIN for each legal entity, and check them against your registration documents before the first submission |
How e-invoices, e-way bills and returns move through Odoo
E-invoicing starts when a customer invoice is posted in Accounting. The l10n_in_edi module builds the e-invoice from the posted record and sends it through the GSP, BVM IT Consulting Services India Private Limited, to the NIC e-invoice portal. The portal's response returns through the GSP and is written back to the invoice, which makes the invoice the main place to check status. Confirm the exact trigger conditions and write-back fields in the Odoo India localization documentation for your version.
- Document path: posted invoice, payload generation, GSP relay, NIC portal, then response recorded on the invoice.
- Records afterward: the invoice shows the submission outcome and any portal reference. Confirm which fields and chatter entries appear.
- Missing company or partner data: validation fails before submission when required fields such as the company GSTIN, PAN or partner GSTIN and address are missing.
- Portal rejections: NIC rejections reach Odoo through the GSP. Users correct the source record and resubmit. Confirm the resubmission steps for your version.
- API users: the NIC API user must exist and be authorized for the company's GSTIN. A missing or misconfigured API user fails at the portal stage.
Before go-live, post and submit test invoices in a duplicated, neutralized test database so each rejection path is seen before production data is involved.
E-way bills are generated from Sales and Inventory activity. The l10n_in_ewaybill module handles the e-way bill itself, and l10n_in_ewaybill_stock links it to stock movements such as deliveries and transfers. The movement is validated in Inventory, the e-way bill request goes through the GSP to the NIC e-way bill portal, and the result is recorded against the movement. Confirm in the Odoo India localization documentation which movement types and documents are supported in your version.
- Document path: validated stock movement or sales document, request built by the modules, GSP relay, NIC e-way bill portal, then the bill number returned to Odoo.
- Records afterward: the transfer or delivery record shows the e-way bill outcome. Confirm which numbers and dates are stored.
- Missing transport data: transporter, vehicle and distance details must be present on the record before the request is sent. Confirm which of these are required in your setup.
- Stock and partner data: missing addresses or GSTIN values on the partner or warehouse can block the request before it leaves Odoo.
- Portal rejections: portal errors arrive through the GSP and are recorded on the movement. Users correct the data and retry.
Test the full path in a duplicated, neutralized database using a delivery, a branch transfer and a cancellation so each stock path produces a known result.
GST return filing is prepared from posted invoices and related tax entries, then sent through the BVM IT Consulting GSP to the GST portal. The filing data is only as accurate as the postings behind it, so tax configuration on products, partners and taxes matters as much as the filing step itself. TDS and TCS are separate obligations with their own configuration. Confirm in the Odoo India localization documentation which TDS and TCS features are included in your edition and version, and which need additional setup.
- Document path: posted invoices and payments feed the return data, which is sent through the GSP to the portal.
- Records afterward: the return status and any portal acknowledgement should be visible to the user. Confirm where these are stored and how they are reconciled to the ledger.
- Missing company or partner data: GSTIN, PAN and state details on the company and partners affect how entries are classified in the return.
- Tax configuration: incorrect tax mapping on products or taxes produces wrong return figures even when the submission succeeds. Review these mappings before the first filing.
- Portal responses: filing acknowledgements and errors come from the GSP and portal, outside Odoo's control. Plan time to investigate them.
Run a complete return cycle in a duplicated, neutralized database, including TDS and TCS entries, and reconcile the output against the ledger before any filing is made from production.
What Odoo records that auditors and tax reviewers can ask for
Auditors and tax reviewers rarely ask for one report. They ask how a GSTIN was validated, which credentials sent an e-invoice, and what the portal returned. The records below sit in the Odoo database, in GSP outputs and in the copies kept for testing and upgrades, so each one needs an owner, an export routine and a retention period in your own storage.
Company master data with PAN and GSTIN
The company record holds the PAN and GSTIN that Odoo's Indian localization requires, and e-invoices and e-way bills take their seller details from it. A reviewer will compare the GSTIN printed on a document with the one stored against the company and each branch or warehouse. Export these records on a fixed schedule and keep dated copies in your own storage. Confirm which GST fields are stored per company and per branch in your Odoo version, and who is allowed to edit them.
NIC API user setup records
Odoo's e-invoice and e-way bill features call the NIC portals through API users created for each company. Keep a record of which API user is configured for each company, when it was created, who set it up and who holds its credentials. Store the credentials in a secrets manager you control and keep them out of exported reports. Run access reviews on the Odoo users who can view or change these settings.
E-invoice and e-way bill records
Each e-invoice and e-way bill generated from Odoo should keep the request data, the portal reference returned on success and any error response. Confirm with your implementation team which portal responses Odoo stores on the invoice, delivery or transfer record, how long they remain there, and whether cancellations and updates leave their own entries. Export invoice and delivery records by period with their attachments, and retain the exports in storage you operate.
GSP filing outputs
GST return filing runs through BVM IT Consulting Services India Private Limited as the GSP. Keep the filing outputs Odoo produces for each return period, including the data files, submission status and the acknowledgments the GSP returns. Confirm where these outputs are kept in Odoo, which return types your setup covers, and how the return is reconciled to the ledger. Store copies outside the database so that a restore does not remove the filing trail.
Configuration change audit trail
Auditors ask who changed a tax setting, when, and what the value was before. Confirm which settings your Odoo version records for company, tax, journal, sequence and API configuration, and whether changes made directly in the database or through scripts are captured. Where tracking gaps exist, record changes in your change management system and tie each entry to a named Odoo user. Review the log on a fixed schedule and keep it for at least as long as the returns it supports.
Database backups and test copies
Keep tested backups of the production database and a dated record of each restore test. Duplicate the database for user acceptance testing and neutralize the copy, then confirm what neutralization disables in your version, such as outgoing mail, scheduled actions and live integrations. Where you use the Enterprise upgrade service, keep the upgraded test database and the test results, since the upgrade should be tested before production. Agree backup frequency and retention with your auditors, and store all copies in infrastructure you control.
Configuration sequence for a GST e-invoicing go-live
This sequence takes an Odoo database from a hosted instance to a live connection with the NIC e-invoice and e-way bill portals through the BVM IT Consulting GSP. Each step produces a record that the next one needs, so gaps usually appear later as rejected submissions. Every step depends on your own tax decisions and portal access, and the order should be confirmed against the current Odoo India documentation before work starts.
Confirm edition and hosting option
Confirm which Odoo edition and hosting option includes the India localization before any configuration starts. Odoo's pricing page limits self-hosting on Odoo.sh or on-premise to the Custom plan, and on-premise Enterprise databases are activated with a subscription code. Ask Odoo or your implementation partner to confirm in writing that the localization modules are included in your plan, and check that order against the current Odoo India documentation. Done when the subscription, hosting target and Odoo version are recorded and approved by the business owner.
Set company PAN, GSTIN and branch data
Enter the company PAN and GSTIN on the company record, then add each branch with its own GSTIN, state and address. E-invoices and e-way bills take the sender's registered details from these fields, so a mismatch can cause portal rejections. Your tax team supplies the values and confirms which GSTIN applies to each place of business. Done when a test invoice from each branch prints the correct GSTIN, state and address.
Install the India localization modules
Install l10n_in_edi for e-invoicing, and l10n_in_ewaybill and l10n_in_ewaybill_stock for e-way bills, on the database that will go live. Install the stock module only if Inventory drives dispatch, because it ties e-way bills to stock movements. After installation, confirm the fiscal localization and chart of accounts are set to India. Done when all three modules show as installed in the Apps list and the versions match what the current Odoo India documentation describes for your release.
Create NIC API users on both portals
Your authorized team creates API users on the NIC e-invoice portal and the NIC e-way bill portal, since the Odoo connection needs credentials issued for your company. The business owner controls who holds portal access and should record the user IDs, the authorized signatory and the registration status. Keep the credentials in a secrets store and out of notes or email. Done when each portal confirms the API user is active and the credentials are stored where the business can audit access.
Enable the BVM GSP connection
Enter the API credentials for the BVM IT Consulting Services India Private Limited connection in the company settings, for each service you plan to use: e-invoicing, e-way bills and GST return filing. Enter the values in the test database first and confirm that authentication succeeds. This step depends on the onboarding you complete with BVM and on the NIC credentials from the previous step. Done when a test authentication succeeds for every service in scope and the tested settings are recorded.
Configure tax and product masters
Set up the GST tax groups, HSN or SAC codes on products and services, units of measure and the document types that will carry e-invoices. Your tax team decides the rates, exemptions and treatment for each product, and Odoo applies only what is configured. Confirm which sales, purchase and stock transactions must generate e-invoices or e-way bills, and which transaction types are excluded. Done when a sample invoice for each product class calculates the expected tax and carries the correct codes, checked against a tax matrix signed by your tax team.
Run test submissions in a neutralized copy
Duplicate the configured database, neutralize the copy as the Odoo on-premise documentation describes for test use, and point it at the portal test environment your GSP and NIC confirm for you. Submit representative invoices, credit notes and e-way bills covering each tax case from the previous step, and record every portal response. Confirm the neutralization effects and test endpoints for your Odoo version before relying on them. Done when each test case returns the expected portal result or has a documented fix and a successful retest.
Document approvals and monitor rejections after go-live
Record sign-off from finance, tax and IT on the test results, the tax matrix, the connection settings and the rollback path, then move the configuration to production. After go-live, trace each rejected submission to its cause in the masters or company data, and fix the source rather than resubmitting blindly. Ask your GSP and Odoo which rejection reporting your version provides. Done when approvals are filed and a named owner reviews the rejection log on the cadence the business agreed.
What Odoo and the GSP do not cover for GST compliance
Odoo prepares GST records and sends them through a GSP to the NIC portals, but several parts of the compliance chain stay with your organization, its partners and its advisers. The cards below cover the items to plan, test and confirm before go-live and during ongoing operation.
GSP and NIC portal dependencies
Odoo's e-invoicing, e-way bill and GST return filing services in India run through BVM IT Consulting Services India Private Limited as the GSP, and API users must be created on the NIC e-invoice and e-way bill portals. Neither the GSP nor the NIC portals are under Odoo's control, so their availability, onboarding steps and rule changes can affect your filings. Confirm the GSP service terms, the API user setup and your fallback procedure for portal outages before go-live.
Changes in GST rules
GST e-invoicing and e-way bill rules change over time, including schema, validation and threshold updates that can alter what a valid submission looks like. Odoo's India localization must be kept current, and your team needs to confirm that each update still produces accepted invoices and e-way bills in your own company setup. Plan a test cycle in a non-production database after each localization or version update, and record the results.
TDS and TCS determination
Odoo can apply tax configuration, but the sections and rates for TDS and TCS depend on your transactions, counterparties and tax position. Your finance team or tax adviser must decide which sections apply to each transaction type, what rates are correct, and when a deduction or collection is due. Document these decisions as tax configuration, then test them on sample invoices and vendor bills before relying on them for filings.
Records, not certification or audit
Odoo prepares invoices, e-way bills, return data and audit trails, but it does not certify your business, issue GST registrations, or replace statutory auditors. Submission status and acknowledgements show what was accepted by the portal, not that your tax position is correct. Agree with your auditors which Odoo reports and logs they will rely on, and keep the approval and reconciliation evidence that sits outside Odoo.
Partner master and HSN data quality
E-invoices and e-way bills depend on accurate company data, including PAN and GSTIN on the company, GSTIN and state on customer and vendor records, and HSN codes on products. Errors in these masters are a common cause of rejected submissions and wrong tax calculations, and Odoo will not detect a wrong HSN code that is still syntactically valid. Assign an owner for each master, define a review step for new partners and products, and run a data check before the first live submission.
Independent legal and tax advice
How GST, TDS and TCS apply to your business depends on facts specific to your entity, sector and transactions, and interpretation can change. DeployOpen implements and configures the platform, but it does not give legal or tax advice. Ask your legal and tax advisers to review the configured tax logic, the e-invoice and e-way bill scenarios your business uses, and any return filing process before go-live.
Edition, hosting and version choices that shape a GST project
The plan you choose decides whether the GST design can be built in your chosen hosting model at all. Only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, external API access and custom modules. A GST project may need several legal entities or branches in one database, outbound API calls to the GSP and custom code around document handling, so these requirements should be checked against the plan before any hosting decision is made. Ask Odoo or your partner to confirm in writing which plan covers each requirement in your design, and record that answer in the scope so the quote reflects the plan you actually need.
The Enterprise source code is not publicly available, so a team that wants to build on Enterprise needs a subscription or partner access before work starts. The Community edition on GitHub is licensed under LGPL-3.0, which lets you read and run the code, but Community does not include the Enterprise features or the upgrade service. For on-premise Enterprise, each database is activated by entering the subscription code, so the code must be available before the test and production databases are built. Confirm which edition includes the India localization modules, namely l10n_in_edi for e-invoicing and l10n_in_ewaybill and l10n_in_ewaybill_stock for e-way bills, because that answer determines whether a Community-based design is possible.
Version support sets the deadline for the whole project. Odoo 19.0 is covered by standard support until September 2028, Odoo 18.0 until September 2027, and standard support for Odoo 17.0 ended in September 2026, so a new GST build should not start on 17.0. Standard support includes security updates and bug fixes, and security patches are only provided during standard support. Paid extended support is limited to Odoo.sh for select versions and to on-premise, so the version you choose determines how long you can run it safely. Plan the go-live date with room for testing and tax sign-off before the end of standard support for that version.
Hosting also determines how upgrades reach you. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so your GST configuration, API user setup and custom modules will be moved to a newer version on Odoo's schedule. On-premise, the upgrade service requires an Enterprise subscription, and Community has no access to it. Odoo's upgrade process produces an upgraded test database that should be tested before production. For GST, that test should include e-invoice and e-way bill transactions run through your API users, plus a check of the GST return data. Agree in the scope who owns that test and how it is scheduled.
Questions buyers ask before hiring help with Odoo GST work
What drives the cost of hiring help for Odoo GST work?
Scope drives most of the cost: the number of legal entities, GSTINs and branches, because each one needs its own company data, portal credentials and test cycle. Other drivers are the GSP and portal setup (creating API users on the NIC e-invoice and e-way bill portals and connecting them to Odoo), masters cleanup for customers, products and HSN codes, custom reports for returns or internal review, and the testing scope. Work agreed as a fixed scope with written deliverables is easier to compare than open hours. Odoo's pricing page also limits multi-company to the Custom plan, which affects licensing as well as services. Ask any quote to show each cost line separately, and state which items are one-time (setup, cleanup, testing) and which recur (subscription, GSP and portal arrangements, support).
How long does an Odoo GST e-invoicing project usually take?
No general duration is published for this work, so treat any figure you hear with caution and ask for one in writing. The project runs in stages: confirm company and branch data (PAN and GSTIN recorded on each company), set up the GSP and NIC portal API users, clean up masters, configure the e-invoicing and e-way bill modules, test with sample invoices and transport documents, then cut over to live filing. Each stage depends on the one before it, and portal approvals and client decisions can set the pace more than the configuration itself. Ask the provider for a stage-by-stage plan with client actions and dependencies marked, so you can see which parts of the schedule are in your hands.
What does our team have to provide for Odoo GST work?
Your tax lead must make the decisions that configuration depends on, such as tax mapping, GST rate handling, how e-way bills are triggered from Sales and Inventory, and how TDS and TCS are treated. You need portal access to the NIC e-invoice and e-way bill portals, people who can create API users there, and the GSP arrangements in your name. Provide representative test data: sample customers, products, invoices, credit notes and transport movements, including edge cases. Someone accountable must sign off each test cycle and the go-live. Agree these responsibilities in the quote so that delays on either side are visible in the schedule.
Can our internal Odoo team set up GST e-invoicing without a partner?
Yes, for configuration, if the team has working knowledge of Odoo accounting, sales and inventory and of Indian GST rules. The localization modules (l10n_in_edi for e-invoicing, and l10n_in_ewaybill and l10n_in_ewaybill_stock for e-way bills) are configuration work on a company that already has PAN and GSTIN recorded. The main risks sit outside configuration: completing the GSP and NIC portal steps correctly, keeping API user set-up and credentials under control, and building the evidence set that shows invoices and e-way bills were generated and reconciled as designed. Teams without a previous GST go-live may want an independent review of the test plan and evidence before cutover, whether internal or external.
Does DeployOpen certify that our Odoo GST setup is compliant?
No. DeployOpen plans, implements, configures and documents self-hosted open-source platforms, and it prepares the systems, controls and evidence that a compliance review would examine. It does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and the tax authorities decide whether your filings and processes meet the requirements that apply to you. The scope of work should name the evidence to be delivered, such as configuration records, test results, sign-off logs and the e-invoice and e-way bill procedure, and your tax advisers should confirm what they need to accept it. The implementation supports your own compliance review but does not replace it.
Which Odoo plan or edition do we need for GST e-invoicing?
Confirm this with Odoo before the build starts, because the answer depends on your company count, hosting and modules. Odoo's pricing page lists three plans, and it limits multi-company, Odoo Studio, external API access and custom modules to the Custom plan. It also allows Odoo.sh or on-premise hosting only on Custom. The Community edition has no access to the upgrade service, and on-premise use of Enterprise requires an Enterprise subscription. If you run several companies, self-host or need custom modules, get Odoo's written confirmation of the plan and modules that cover each requirement, and record it in the scope.
Which Odoo versions still get support for a GST project?
Pick a version that stays inside its support window for the whole project and the years after go-live. Odoo 19.0 (released September 2025) has standard support planned until September 2028, and Odoo 18.0 (October 2024) until September 2027. Odoo 17.0 standard support ended in September 2026, and Odoo 20.0, released in September 2026, has standard support planned until September 2029. Standard support covers security updates and bug fixes on Odoo Online, Odoo.sh and on-premise, and security patches are only provided during standard support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Plan each upgrade and retest the GST flow on an upgraded test database before production.
What should a written quote for Odoo GST work include?
A usable quote lists the scope by deliverable: each company and branch covered, the GSP and NIC portal setup steps, the masters cleanup, any custom reports, the test cycles with their acceptance criteria, and the evidence pack you will receive. It states whether the price is fixed scope, what is excluded, and which assumptions apply, such as the number of test cycles or data volumes. Separate one-time costs from recurring ones, and ask for the Odoo plan, hosting and subscription costs, and any GSP or portal charges that fall to you, with the source of each figure. Ask for a stage-by-stage timeline, a list of client responsibilities with owners and dates, and how changes to scope will be priced.
How DeployOpen scopes and delivers GST configuration and evidence
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in the client's own infrastructure. For Odoo GST e-invoicing and e-way bills in India, we start by confirming company data, the Odoo edition and hosting, then configure the Indian localization, the GSP connection and the evidence your reviewers will ask for. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- The written scope lists which companies, GSTINs and branches get e-invoicing, e-way bills or both.
- We confirm PAN and GSTIN on each company and the Odoo edition and hosting that will run the modules.
- Scope records who holds the NIC API users and who approves GSP credentials, so access is settled before build.
How we build
- We configure the l10n_in_edi, l10n_in_ewaybill and l10n_in_ewaybill_stock modules for the agreed companies and sites.
- We connect submissions to the BVM IT Consulting GSP and test them in a non-production database first.
- We test TDS and TCS settings and GST return filing with sample invoices, and document each result.
How we hand over
- Handover includes a configuration record for each company, listing modules, GSTIN, PAN, GSP and NIC user settings.
- Test evidence covers sample e-invoices, e-way bills, return files and TDS or TCS calculations, with expected and actual results.
- Operators receive a runbook for credential rotation, portal outages, cancellations and the Odoo upgrade path.
How we support
- Ongoing support, upgrades and testing are available as a retainer after handover.
- Major upgrades on Odoo Online and Odoo.sh are mandatory every two years, so GST configuration is retested each time.
- For on-premise Enterprise databases, upgrades use Odoo's upgrade service, which requires an Enterprise subscription.
