The same exchange rate means opposite things in Xero and QuickBooks Online: check direction and units

Three numbers, three ways to go wrong

A foreign-currency invoice needs a currency code, an amount in that currency and, sometimes, a rate. Each can be wrong independently: the code can default to the home currency, the amount can be in the wrong unit, and the rate can be inverted or absent. The result looks plausible and passes casual inspection, which is why these errors reach the ledger.

Direction: opposite conventions

Xero expresses a currency rate as the foreign currency per one unit of the base currency, and says many integrations send the inverse. Intuit records QuickBooks Online exchange rates the other way: the number of home-currency units that equal one foreign-currency unit. Take an invented 100.00 USD invoice in a GBP file at 1.25 USD per 1 GBP. The Xero-style rate is 1.25 and the base total is 100.00 divided by 1.25, or 80.00 GBP. The QuickBooks-style rate is 0.80 and the base total is 100.00 multiplied by 0.80, again 80.00 GBP. Copy 1.25 into the QuickBooks field, or 0.80 into the Xero field, and the base total becomes wrong by a large amount, not by pennies.

Do not default the rate to one, and enable the currency first

Xero says never to default or fall back to a rate of one: for base-currency documents it is redundant and for foreign ones it is wrong. The rate can be omitted so that Xero chooses one, and should be set only when a real foreign-exchange transaction took place. Xero also returns non-blocking validation warnings for rates that look inverted, so a document can be created despite one. Currencies must be added to the organisation before use, and Xero does not allow removing them afterwards. In QuickBooks Online, multicurrency can only be switched on in the product, not through the API, and cannot be switched off once enabled, so enabling it is an owner decision with consequences.

• Check the file's base currency and enabled currencies before the first run.
• Decide with your accountant whether an invoice should carry a rate at all.

Units: smallest unit versus whole units

Stripe's API takes amounts in the currency's smallest unit: 1000 means 10.00 in a two-decimal currency but 1000 means 1,000 yen for a zero-decimal currency such as JPY. A sync that divides every amount by 100 will shrink a yen amount a hundredfold. Stripe also lists currencies with special handling, for example some that must be written as two-decimal values whose decimals are always 00. On the accounting side, Xero rounds a unit amount to two decimal places unless four are requested, and tells integrations that calculate tax differently from Xero to check for rounding discrepancies, so decimals need an explicit contract at each boundary.

• Write down, for each source field, whether it is minor or major units.
• Test one zero-decimal currency even if you rarely sell in it.

What fits, what does not, and how it is accepted

The job "Make foreign-currency orders create invoices in the right currency, with the right rate" is from £395 for up to three currencies, an untested published price confirmed after your enquiry, with payment after the agreed checks pass and you sign off. It is accepted when invented orders in the home currency, a two-decimal currency and a zero-decimal currency create invoices with the exact currency and amount, stored rates in the target's direction recompute to the expected base total, no default rate of one appears, and an order in a currency not enabled is held.

It does not choose rate sources, enable multicurrency in a live file or treat exchange gains and losses. This guide is written from vendor documentation read on 11 October 2026. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.