monetary

The Monetary widget takes a number and renders it the way an amount should look: thousands separators, the right number of decimals, and the currency symbol on the side the currency defines. It is the default rendering for monetary fields and can be applied to plain float and integer fields too.

The key mental model, read straight from the source: almost everything you see comes from the currency record, not from the field. The symbol, its position, and the decimal precision are properties of the currency in Accounting, Configuration, Currencies. The widget just asks the currency how to format. A monetary field without a reachable currency falls back to a bare number.

Amount formatting sounds cosmetic until an export goes wrong. A quotation showing 1,500 with no symbol reads as ambiguous to a customer paying in a different currency; a report mixing two-decimal and three-decimal amounts looks unreliable to an auditor. Multi-currency companies live and die by this widget behaving consistently.

The business decisions that reach this widget are real ones. Whether prices show four decimals in purchasing but two in sales is a decimal-precision setting the widget respects. Whether your Vietnamese dong amounts show the symbol before or after the number is a currency setting the widget reads. Getting these right once, centrally, is far cheaper than fixing them report by report.

On implementations, we treat currency precision as a day-one configuration decision, because changing it after months of transactions creates rounding differences that reconciliation then has to explain.

Studio handles the standard case end to end.

1. Open the form in Studio and drag a Monetary field from the Add a field panel.

2. Studio creates the amount field and, if the model has no currency field yet, adds currency_id alongside it and places both on the form.

3. In Properties, the Currency selector appears when the model carries more than one currency field, letting you pick which one drives the formatting.

Two things stay out of Studio's reach.

Hiding the symbol in a dense list column needs the no_symbol option in XML.

Forcing the field's own decimal setting instead of the currency's needs the undocumented field_digits option, and the decimal precision itself is configured under Settings, Technical, Decimal Accuracy, which is developer-mode territory.

Standard monetary column

<field name="amount_total" widget="monetary"/>

The widget looks for currency_id on the record. Keep that field in the view, invisible is fine:

<field name="currency_id" column_invisible="1"/>

A different currency field

<field name="purchase_price"
       widget="monetary"
       options="{'currency_field': 'company_currency_id'}"/>

Cost in company currency next to a price in customer currency on the same line: two monetary widgets pointing at two currency fields.

No symbol, for dense lists

<field name="amount_untaxed"
       widget="monetary"
       options="{'no_symbol': True}"/>

Field decimals instead of currency decimals

<field name="unit_cost"
       widget="monetary"
       options="{'field_digits': True}"/>

With a field defined as fields.Float(digits="Product Price"), the four-decimal purchase precision now wins over the currency's two decimals. This is how product costs show more precision than invoice totals.

Three formatting rules from the source explain nearly every "why does it show like that" question.

The symbol disappears while editing. The formatter is called with noSymbol whenever the field is editable, so users type against a clean number and the symbol returns when the field is saved or readonly. Teams occasionally report this as a bug; it is deliberate.

The currency must be on the record, in the view. The widget resolves the currency from the record's data at render time. If the currency field is not loaded in that view, there is no symbol and the currency's precision cannot apply. This is why core views carry invisible currency_id columns.

Trailing zeros are kept by default. 1.50 renders as 1.50, and the hide_trailing_zeros option flips that to 1.5. Useful for quantity-like monetary values; leave it off for accounting amounts, where 1.5 reads as sloppy.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

All three documented options survive unchanged: no_symbol, currency_field and hide_trailing_zeros, and field_digits is still read in extractProps. Views should carry over untouched.

The parsing internals change. Typed input is parsed with the generic float parser instead of the dedicated monetary parser, and the component's internals move to the new Owl props system. Neither changes XML, but JavaScript patches against MonetaryField internals will need review, which is exactly the kind of check our Odoo migration team runs before an upgrade.