Every Thai company that pays a vendor for services, rent, or professional fees has to withhold tax at source. That tax gets reported to the Revenue Department the following month. Get the Odoo withholding tax Thailand setup wrong and you end up reconciling by hand every close. You chase missing certificates. You re-key numbers into the PND 3 or PND 53 forms. We have rebuilt this configuration for enough Thai entities now that we treat it as a fixed sequence: tax records first, certificate layout second, filing report last.
This post walks through how we configure Odoo withholding tax Thailand setups on real projects. We cover what PND 3 and PND 53 actually require from the system. We also cover where teams usually get tripped up during their first month-end close.
PND 3 vs PND 53 in Odoo withholding tax Thailand setups
PND 3 covers withholding on payments to individuals: freelancers, landlords who are natural persons, independent consultants. PND 53 covers payments to juristic entities, meaning companies and partnerships. The rate table overlaps for many service categories. But the form, the recipient classification, and sometimes the rate itself differ.
In Odoo this distinction lives on the vendor record, not on the tax itself. We set the partner's company type, individual or company, correctly during data migration. That single field decides whether a withholding entry flows to PND 3 or PND 53 reporting later. Get this wrong on fifty vendors during go-live and you spend the first filing cycle correcting it.
Setting up the withholding tax records
We create a dedicated set of withholding tax records in Accounting, separate from VAT. Each one ties to a specific income type under Thai Revenue Department categories: rental, service fees, transportation, advertising, professional fees, and so on. Each record needs:
- A tax name that matches how your accountant refers to it (for example "WHT 3% Service")
- The correct percentage, since rates vary from 1% to 5% depending on income type
- A dedicated tax grid or tag so amounts land in the right box on the filing report
- The scope set to purchases, since withholding tax transactions always originate on vendor bills, not customer invoices
We avoid stacking the withholding tax directly as a negative line hidden inside the main VAT tax group. It needs its own identity. That way it can be isolated later in the certificate and in the monthly summary. Your chart of taxes will have more entries than a non-Thai instance of Odoo. That surprises some finance teams until they see the filing report run cleanly off it.
Mapping taxes to accounts
Each withholding tax record points to a dedicated payable account, typically something like "Withholding Tax Payable - PND 3" or "- PND 53". These accounts should never mix with the general VAT payable account. We have inherited instances where someone merged them to save a line in the chart of accounts. Untangling a year of transactions to split PND 3 from PND 53 amounts cost those clients real reconciliation time. Keep them separate from day one.
Vendor withholding tax certificates
The vendor expects a WHT certificate (หนังสือรับรองการหักภาษี ณ ที่จ่าย) for every payment where tax was withheld. It must show the gross amount, the rate, the tax withheld, and the income type code. This is not optional paperwork. Vendors need it to claim the credit against their own tax liability.
In Odoo, once the withholding tax line exists on the vendor bill and payment, we generate the certificate from a dedicated report template built around the standard Thai format. The fields that matter most on this template:
- Company tax ID and vendor tax ID, both validated at entry, not left to the printed document to reveal a typo
- Payment date versus invoice date, since the certificate is based on the date tax was actually withheld, which is the payment date, not the bill date
- Income type code matched exactly against the Revenue Department's published list
A real limitation here: Odoo does not ship a Thai WHT certificate template out of the box the way it does for some neighboring markets. This report is something we build or customize per client, typically as a QWeb template tied to the payment record. If your current implementation skipped this, you are probably still exporting certificates to Word and filling them manually. That approach does not scale past a handful of vendors a month. It is one reason we fold this work into our Odoo ERP customization services rather than treat it as a one-off report request.
Preparing the PND 3 / PND 53 monthly filing
The filing itself is a summary. Every vendor paid during the month, grouped by income type, with gross amount, tax withheld, and vendor tax ID, gets submitted. That happens either via the Revenue Department's e-filing portal or through an accountant's software that accepts a structured import.
We build the Odoo side of this as a saved filter or a lightweight report on payments and journal items. It is filtered by the withholding tax tags set up earlier, grouped by tax type and income category. The goal is simple: by the first working day after month-end, someone in finance can pull this list without touching a spreadsheet macro.
Two things consistently catch new instances out:
- Payments made in a different month than the bill date get missed if the filter is built on invoice date instead of payment date. PND filing is strictly based on when the withholding happened, which is the payment event.
- Partial payments against a single bill each carry their own withholding tax portion, proportional to the amount paid. If the system calculates withholding only once at full invoice value, partial payment scenarios overstate the tax withheld on the first installment.
Once the report structure is right, reconciling it against the general ledger balance in the withholding payable accounts becomes a five-minute check rather than a half-day exercise.
Where Odoo withholding tax Thailand setups usually go wrong
Most of the problems we see are not Odoo limitations. They are configuration drift from going live without walking the full vendor and tax mapping exercise first. Generic tax templates imported from an international chart of accounts do not carry Thai withholding categories. Unless someone builds them deliberately, bills get recorded with VAT only. Withholding then gets bolted on as a manual journal entry after the fact. That manual journal entry is where certificates get missed and PND filings fall out of sync with the books.
We handle this as part of our broader Thai localization and accounting setup work. Withholding tax configuration rarely stands alone. It touches the chart of accounts, the vendor master data, e-Tax invoice workflows, and the month-end close checklist all at once. If you are migrating from another system, or inheriting an Odoo instance set up without Thai tax specifics in mind, consider an audit before your next filing deadline. That beats an audit triggered by a penalty notice.
Automating certificates at volume
For companies running multiple entities, or handling both PND 3 and PND 53 at volume, we also look at whether the existing chart of accounts can absorb automated certificate generation. The trigger point is the payment confirmation itself, rather than a manual export step each month. This often ties into our Odoo implementation services when a client is rebuilding the finance workflow from the ground up. It is a small change. It removes one recurring task from the finance team's calendar.
One trade-off worth naming plainly: none of this replaces a conversation with your accountant about which income type code applies to a borderline payment. Odoo will calculate and report exactly what the tax record says. But the classification judgment still sits with a human: whether this is a service fee or a rental, whether this vendor is an individual or a juristic entity for this specific contract. Getting that call wrong propagates through every certificate and filing until someone catches it.
