Quick answer. The Venezuelan fiscal and payroll localization for Odoo 19 is published and free. 11 modules under LGPL-3 (one is AGPL-3 by dependency), covering the VEN-NIF chart of accounts, VAT, IGTF, VAT and income-tax withholdings with their SENIAT files, purchase and sales fiscal books, municipal business tax, digital-printer invoicing, fiscal printer on POS, and full Venezuelan payroll. No license fee and no gated version: github.com/bwealthics/l10n-venezuela-bw. It is not certified by the SENIAT, and it is not finished. That is why it is open.
Why we published it instead of keeping it
Venezuela is one of the hardest countries in the world to keep an ERP compliant in. The rules move by Gaceta Oficial and by Providencia Administrativa, the exchange rate moves daily, and the portals sometimes enforce rules that have no published legal instrument at all. We built this suite over the past year for our own clients, and there was still no complete, openly documented Venezuelan localization for Odoo 19.
So we published ours, in full, under LGPL-3. Every module, the documentation, and the legal basis. There is no reduced free edition and no paid unlock. If you want assisted implementation on top of it, that is what we sell. You do not need us to use it.
What the suite covers
| Module | What it solves | Legal basis |
|---|---|---|
| chart | 6-digit chart of accounts aligned to VEN-NIF, VAT rates, Special Taxpayer (SPE) flag, taxpayer type on the contact | BA VEN-NIF No. 0, LIVA |
| igtf | Financial-transactions tax: own expense on foreign-currency payments and 3% collection as a Special Taxpayer | IGTF Act (G.O.E. 6.687), Decreto 4.972 |
| wh_iva | VAT withholding in both directions, voucher numbered AAAAMM + 8 digits, form 99035 TXT export | PA SNAT/2025/000054 |
| wh_islr | Income-tax withholding, historical Tax Unit for the subtrahend, AR-C voucher, monthly SENIAT XML | Decreto 1.808, PA 0095/2009 |
| fiscal_books | Purchase and Sales books in XLSX, control number, issuance channel per journal, contingency | LIVA Regulation arts. 70 to 78, PA 0071 |
| invoice_format | Form requirements on the PDF: legal date and time, (E) mark, printer data, Bs equivalent with the rate note, per-line tax breakdown | PA 0071, PA SNAT/2024/000102 |
| municipal | Monthly provision for the industry and commerce license, rate and minimum taxable amount | Municipal ordinances, LOPPM |
| einvoice | Connector for authorized digital printers, with a neutral core so a new provider is one file | PA SNAT/2024/000102, PA 000121 |
| fiscal_printer | Fiscal printer on the Point of Sale through a local bridge | PA 0071 (Z report) |
| compliance | Umbrella module: installs the suite and leaves the audit log created and subscribed | PA SNAT/2024/000102 art. 18.7 |
| payroll | IVSS, RPE, FAOV, INCES, income tax (AR-I), CEPP, food allowance, dual-currency payslip | LOTTT and social-security acts |
The real asset is the legal traceability
There are already half-finished Venezuelan localizations on GitHub. What makes this one different is not the code, it is docs/BASAMENTO-LEGAL.md: every law, Providencia and court ruling we implemented, sitting next to the design decision it forced in the code, plus the open questions we could not close. When the SENIAT changes something, you can see exactly which module moves and why.
Two design decisions worth stealing even outside Venezuela:
1. No hardcoded rates. Every volatile rate, cap and threshold is a date-versioned rule parameter, following the pattern of the official payroll localizations. In Venezuela that is not a nice-to-have: the exchange rate moves daily, and the minimum wage, the Tax Unit and the indexed minimum income each move on their own schedule.
2. Fiscal logic separated from the provider. In the e-invoicing connector, all fiscal logic produces a neutral dictionary, and a provider is four methods on an abstract model. Changing digital printers is writing one file, not rewriting the module.
The repository also ships a configuration and month-to-month operation manual, a changelog per module, and a contributing guide written against the real tree: which modules you can test without Enterprise, without the OCA dependencies, and without fiscal hardware.
What is not finished, said out loud
| Limitation | What it means for you |
|---|---|
| Payroll requires Odoo 19 Enterprise | The code is LGPL-3, but it will not install on Community, which also keeps it out of the OCA |
| The real digital-printer adapter is pending a signed provider | What ships is the neutral core plus a simulated provider, with the polling cron disabled |
| The fiscal-printer bridge is not in the repository | It implements a commercial vendor's protocol and is being reviewed separately |
| No continuous integration yet | Tests exist and are documented, but nothing runs them automatically on a pull request |
| Not certified or endorsed by the SENIAT | It is a support tool, not tax advice. Responsibility for filings, vouchers and books stays with the taxpayer and their accountant |
How to help make it excellent
A country localization is not finished by one firm. It is finished by the community that operates it every month. Issues and pull requests are open, and there is a normative change issue template that asks for the Gazette reference, the effective date and the affected modules, which is exactly what makes a fix possible without researching from zero.
If you are an accountant in Venezuela, the most valuable thing you can do is read the legal basis document and tell us where our reading of a norm is wrong. If you are a developer, install it, break it, and open the issue. One hard rule from the code of conduct: no third-party tax data, not in an issue, not in a test, not in a screenshot.
Open the repository on GitHub →
Thanks to Binhex, and the road to the OCA
Binhex will help us take the qualifying modules into the OCA (Odoo Community Association): the ones that install on Odoo Community, which are the chart of accounts, IGTF, VAT withholding, income-tax withholding, municipal tax, fiscal books and invoice format. That path is stricter than our own repository. It means pre-commit tooling, atomic commits in English, one responsibility per module, test coverage and approval from two core maintainers.
It is worth it. Landing in the OCA is the moment the localization stops belonging to one firm and starts belonging to the community that maintains it, which is where a country localization should live.
Running Odoo in Venezuela, or with Venezuelan operations?
BWEALTHICS is an outsourced financial-operations firm that operates the finance layer inside Odoo. We built this suite because our clients needed it, and we maintain it in production. If you want it implemented, configured and operated month to month, book a call and assessment.
Published August 2026 against Odoo 19.0. Venezuelan tax and labor rules change frequently and without much notice: check the changelog of each module and the legal basis document before relying on any calculation, and confirm the current norm with your accountant.