Odoo applies a single company-wide exchange rate per currency per date, resolved automatically from res.currency.rate when a foreign-currency document is confirmed. That works until reality diverges from the rate table: a customer was quoted at a fixed contractual rate weeks ago, a purchase was hedged at a rate your bank locked in, or a payment cleared at a rate that differs from the day's official figure. In stock Odoo the finance user has no clean way to say "this specific invoice should convert at 3.75, not today's 3.71" — they end up editing the global rate (which corrupts every other document dated that day), booking manual exchange-difference journal entries, or reconciling the variance after the fact. Every one of those workarounds is error-prone and audit-unfriendly.

We build a focused module that adds a per-document manual_currency_rate field (with a manual_rate_active boolean toggle) to sale.order, purchase.order, and account.move. When the toggle is on, the document's currency conversion uses your entered rate instead of the company rate pulled from res.currency.rate. Technically this means extending the relevant models via models.Model inheritance, overriding the _compute_amount/_compute_tax_totals and currency_rate computations (with correct @api.depends so amounts recompute the moment the rate or currency changes), and propagating the chosen rate through the sale-to-invoice and purchase-to-bill flows so the manually set rate carries onto the generated account.move. The company amount (amount_total_signed, amount_currency vs balance on account.move.line) is derived from your rate, so the general ledger, tax lines, and currency-exchange postings all reflect the number you actually transacted at — not the table default.

The implementation ships with proper access control and an audit trail. Editing the manual rate is gated through ir.model.access.csv and record rules so only the groups you nominate (typically Accounting / Billing Administrator) can override a rate, and every override is visible on the document and captured in the chatter/mail.thread log for auditors. Views are extended cleanly via XML inheritance (xpath into the existing order and invoice forms) so the field appears next to the currency with an on-screen indicator when a manual rate is in effect, and QWeb report templates are optionally adjusted so the applied rate prints on the PDF invoice or order confirmation. The manually set rate is also exposed through the standard XML-RPC/JSON-RPC API, so external systems that create or read these documents can set and audit the rate programmatically. We target Odoo 17.0, 18.0, and 19.0 and account for Community vs Enterprise differences in the accounting layer where they matter.

Because this is a productized service, nothing is downloaded and switched on instantly. After a short scoping call we confirm exactly which documents need the override, which user groups may set it, how it should behave on the sale/purchase-to-invoice handoff, and whether reports and API access are in scope. We then build against a copy of your Odoo version, deliver on a staging database for your UAT, and go live with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company setups, deeper accounting/localization requirements (e.g. specific exchange-difference posting rules), extra documents, and integration or data-migration work increase the quoted scope.