account-tax-totals-field

Every accounting document in Odoo ends with the same block: untaxed amount, one line per tax group, total, and sometimes rounding lines. That block is not a set of separate fields. It is one widget, account-tax-totals-field, rendering one JSON value computed server-side into the tax_totals field.

The JSON carries subtotals, tax groups with their amounts, the currency and its decimal precision. The widget walks that structure and renders each tax group through a child component. On a draft document, those group amounts are clickable: the cell becomes an input, and committing a change updates the JSON and hands it back to the record, which triggers the server recomputation of the document.

Note the name: account-tax-totals-field, with hyphens. Almost every other field widget in Odoo uses underscores, so this one regularly gets mistyped in custom views, and a mistyped widget name fails silently to the default field rendering.

The editable tax amount is the business feature hiding in this widget. Vendor bills routinely arrive with a cent or two of tax difference from what Odoo computes, and the legally correct amount is the one on the paper. Instead of fighting tax configuration, an accountant clicks the tax amount on the draft bill, types the vendor's figure, and the widget spreads the difference into the totals. That is the intended workflow for rounding discrepancies.

The guardrails matter too: the edit only works while the document is a draft, a zero tax amount is refused outright, and an unchanged value does nothing. Teams should still treat manual tax edits as an exception with a policy behind it, because the edit overrides what your tax configuration says and flows straight into the tax report.

How core applies it (invoice form)

<field name="tax_totals" widget="account-tax-totals-field"
       nolabel="1" colspan="2"
       readonly="state != 'draft'"/>

The readonly expression is what disables tax editing on posted documents; the widget itself only checks the readonly prop it receives.

Reusing it on a custom model

<field name="my_tax_totals_json" widget="account-tax-totals-field"/>

This only works if two conditions hold: the model exposes a currency_id field (the source states this requirement in a comment), and the field's value reproduces the core JSON contract with subtotals, tax groups carrying tax_amount_currency, currency_id and currency_pd. In practice that means calling the same server-side helpers the core uses.

The edit cycle is more careful than it looks. Each tax group line is a TaxGroupComponent with three states: readonly, edit and disable. Clicking enters edit; committing enters disable while the change is applied, so you cannot double-submit; any re-render drops the line back to readonly.

On commit, the widget does not just store your number. It computes the delta against the old amount and adds it to four places in the JSON: the tax group, the subtotal it belongs to, the document's tax amount, and the document total. Then it calls record.update with the whole totals object, and the server recomputes the document from there. If you type something unparseable, the input resets to the old value and stays in edit mode; if you type 0 or the same value, the line simply returns to read-only, because a zero tax group is not a rounding fix but a configuration question.

One more detail from the source: after pushing an update, the widget deletes cash_rounding_base_amount_currency from its local copy of the JSON, so the rounding base is recomputed server-side rather than compounding client-side.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows is read from the public development branch, which is unstable until feature freeze; we re-verify this page against the shipped release.

This widget is getting one of the larger upgrades we have tracked in this series. The development branch adds a cash rounding manager directly inside the totals block: a dropdown listing rounding methods from account.cash.rounding, with select, create (via a form dialog) and remove actions, wired to invoice_cash_rounding_id and saved immediately. It only appears for users in the cash rounding group, on customer documents (out_ move types) in draft.

Alongside it, a computed taxGroupWithRoundingAmount highlights the tax group carrying the biggest rounding line when has_biggest_tax_cash_rounding_line is set, and the component migrates to the new signals-based frontend (computed, signal, proxy instead of useState and lifecycle hooks). Patches against the 19.0 lifecycle hooks will not survive that migration.