Enterprise resource planning software lives and dies by its ability to handle local rules. A multinational can have the most elegant inventory system on the planet, but if it can’t compute payroll deductions for the countries where it actually employs people, the software is decoration. Odoo has been methodically filling gaps in its localization map for years, and the latest batch of changes tackles two very different markets — Uzbekistan and India — while also refining how fixed-asset depreciation works for jurisdictions that think in rates rather than durations.
Uzbekistan Gets Its Own Payroll Module
Central Asia has been a conspicuous blank spot on Odoo’s payroll coverage map. Kazakhstan showed up a few releases back, but its neighbors were left to fend for themselves with generic salary rules and manual adjustments. That changes now: Odoo 20 ships a dedicated Uzbekistan payroll localization with the full complement of country-specific structures.
The module covers salary rules aligned with Uzbekistan’s labor code, including the income tax brackets, social insurance fund contributions, and pension fund deductions that employers are required to calculate and remit. For companies operating in the Uzbek market, this is the difference between running payroll inside the ERP and running it in a spreadsheet next to the ERP — a distinction that matters enormously when audit season arrives.
Uzbekistan’s tax system has its own quirks. The personal income tax rate was simplified to a flat 12% in recent reforms, but employer contributions to the social fund and the accumulative pension fund still require separate line items on the payslip. The new localization handles these as distinct salary rule categories, so the breakdown appears correctly on both employee payslips and the journal entries that feed into the general ledger.
The timing makes sense. Uzbekistan has been one of the fastest-growing economies in Central Asia over the past five years, with GDP growth consistently above 5% and an aggressive push to digitize public services and business operations. The government’s mandate for electronic invoicing and digital tax reporting has created a natural market for ERP software that can handle local compliance natively, rather than through add-ons cobbled together by local partners.
India’s TDS and TCS Move to a Generic Withholding Engine
India’s Tax Deducted at Source and Tax Collected at Source framework is one of the more complex withholding systems in the world. Every payment above a threshold triggers a deduction obligation, and the rates, thresholds, and reporting requirements vary by the nature of the payment and the section of the Income Tax Act that governs it. Odoo has supported TDS and TCS for years, but the implementation was India-specific from the ground up — a bespoke module that didn’t share plumbing with withholding tax systems in other countries.
Version 20 changes the architecture. India’s TDS and TCS now run on top of the generic withholding tax engine, the same framework that handles withholding obligations in Latin America, Southeast Asia, and Africa. This isn’t just an internal refactor that users never see — it changes how TDS and TCS are configured and applied in daily operations.
The old threshold-based alert system is gone. Previously, Odoo tracked cumulative payments to a vendor against section-specific thresholds and flagged when the TDS obligation kicked in. It was useful in theory but brittle in practice, since it relied on correctly categorizing every vendor payment by its applicable section and maintaining running totals that could drift if entries were corrected or reversed.
In its place, the new workflow centers on two configuration points: a dedicated TDS journal that isolates withholding entries from the main purchase and payment journals, and a TDS control account that accumulates the withholding liability until it’s remitted to the government. For companies that have been manually tracking TDS liability in a spreadsheet and reconciling it against the books at quarter-end, this is a meaningful improvement.
TCS on Invoices, TDS Through the Pay Wizard
The workflow split between TCS and TDS reflects how these taxes actually flow in Indian business. Tax Collected at Source applies when you’re the seller — certain categories of goods require the seller to collect an additional percentage from the buyer and remit it to the government. In Odoo 20, TCS is applied directly on customer invoices, appearing as a line item that increases the invoice total. The configuration ties to specific product categories or fiscal positions, so it activates automatically when the conditions are met.
Tax Deducted at Source works the other direction: when you’re paying a vendor, you withhold a percentage and remit it on their behalf. The new implementation routes TDS through the Pay wizard, which means the deduction is calculated and recorded at the moment of payment rather than requiring a separate manual adjustment. The vendor bill shows the gross amount, the payment records the net amount after TDS, and the difference posts to the TDS control account — all in one step.
This is cleaner than the previous approach, where TDS often required a two-step process: record the vendor bill at full value, then create a separate journal entry to book the withholding. Accountants who have lived through that workflow will appreciate the consolidation, especially during periods when they’re processing dozens of vendor payments daily and each one needs its own TDS treatment.
Why the Generic Engine Matters Beyond India
The move to the generic withholding tax framework is strategically important for Odoo’s localization roadmap even if it feels like plumbing to the end user. Countries that implement withholding taxes share a common pattern — deduct a percentage at the point of payment, remit to the tax authority, issue certificates to the payee — but each one has its own rates, thresholds, reporting formats, and edge cases.
By consolidating India onto the same engine that serves Colombia, Peru, the Philippines, and Kenya, Odoo can share maintenance burden across localizations. A performance improvement to the withholding calculation engine benefits every country that uses it. A new feature like automatic certificate generation only needs to be built once. And for multinational companies that operate in several withholding-tax jurisdictions, the consistent interface means training costs drop — your accountant in Mumbai and your accountant in Bogotá are using the same workflow, just with different tax codes.
The practical consequence for Indian users is that TDS and TCS configuration now lives in the same place as other withholding tax setups in the system. If you’ve previously configured withholding taxes for operations in other countries, the India setup will look familiar. If India is your only market, the new interface is more explicit about what each field controls, since it was designed to be self-explanatory across jurisdictions rather than assuming India-specific knowledge.
Depreciation Models Replace Asset Models, Add Rate-Based Calculation
In a quieter but equally practical change, Odoo has renamed “Asset Models” to “Depreciation Models” across the accounting module. The rename is more than cosmetic — it accompanies a genuine capability addition: depreciation can now be calculated based on a percentage rate rather than a fixed number of months.
This matters for jurisdictions where tax authorities define depreciation in rate terms. Italy’s fiscal depreciation tables, for instance, express allowable depreciation as a percentage of the asset’s value per year, not as a number of years over which the asset must be written off. Colombia follows a similar pattern for several asset categories. Under the old system, accountants in these countries had to reverse-engineer a duration from the rate, which introduced rounding errors and made the setup less intuitive.
The new rate-based option sits alongside the existing duration-based method, so nothing changes for companies that already have their depreciation schedules configured by month count. It’s purely additive — you pick the method that matches your jurisdiction’s requirements, and the system calculates the periodic depreciation entries accordingly.
The terminology change from “Asset Models” to “Depreciation Models” also reduces confusion for new users. In accounting, an “asset model” could mean many things — a template for creating fixed assets, a classification scheme, a valuation method. “Depreciation Model” is unambiguous: it’s the template that defines how a class of assets loses value over time. Small naming decisions like this accumulate into a system that’s easier to learn, which matters when onboarding is one of the biggest costs of ERP adoption.
The Localization Flywheel
Each new country localization that Odoo ships makes the platform slightly more attractive to the next multinational considering a switch from SAP or Oracle. It’s a compounding effect: the more countries you cover natively, the fewer custom modules a global deployment needs, and the lower the total cost of ownership compared to competitors that charge separately for each country pack.
Uzbekistan is the 78th payroll localization in the Odoo ecosystem. India’s TDS/TCS overhaul is a refinement of an existing localization, but it’s the kind of refinement that determines whether Indian mid-market companies can actually use Odoo as their primary accounting system or need to supplement it with specialized tax software.
The depreciation model changes, meanwhile, address a class of compliance requirements that span multiple countries. Rather than building rate-based depreciation as an Italy-specific or Colombia-specific feature, Odoo built it into the core depreciation engine where any localization can use it. That’s the kind of architectural decision that pays dividends across dozens of country packs simultaneously, and it’s the clearest sign that Odoo’s localization strategy is maturing from “check the box for each country” to “build shared infrastructure that makes every localization better.”