Quickbooky

Accounting News

Multicurrency

QuickBooks Online multicurrency: the adjustments users get stuck on

Multicurrency in QuickBooks Online locks currency choices in place, and revaluation confuses many users. Here is what trips them up and what resolves it.

COMMUNITY ISSUESQUICKBOOKY

Multicurrency in QuickBooks Online rewards planning and punishes improvisation. A community thread that opened in 2023 and still collects replies tells one story: a firm enables the feature, meets its locks, and goes looking for a way around. Almost every turn has a settled answer, and none of it is a bug. These are design decisions that read like malfunctions the first time you meet them. We traced the thread and its accepted fixes; here they are, condensed.

The switch that only goes one way

Multicurrency arrives as a toggle, and the toggle has no opposite position. Once you switch it on, no setting anywhere switches it off. Every posted transaction carries the currency it was written in, and the program will not rewrite that history, so the door simply closes. The home currency is fixed in the same spirit. You choose it when the company file is created, and QuickBooks Online never offers a way to change it afterward. A company that must change home currency starts over.

The feature also carries a plan requirement. Intuit ships it with the Plus and Advanced tiers, so firms on simpler plans hit that wall before anything else.

One currency per name and per account

Each customer, vendor, and account holds exactly one currency, locked by its first transaction. Nothing in the interface offers to change that assignment later. A client who pays in dollars and euros therefore needs two customer records, one per currency. A bank account is created in its currency and keeps it for life. The accepted fix for a wrong assignment never edits the old record. You create a new name or account in the correct currency, use it from that point on, and leave the original dormant.

Where do you run a home currency adjustment?

Revaluation is the piece people hunt for longest, because no menu item is labeled a home currency adjustment. It sits on the Currencies page. Open Settings from the gear icon, choose Currencies, and find the row for the foreign currency. Open the dropdown in the Action column and pick the revaluation option. Set the date, review the proposed entry, and save. The software measures each foreign balance against the current rate and posts the difference to an exchange gain or loss account as an unrealized amount.

Timing matters as much as location. Run the adjustment at period end, after payments are applied and before the books close, and date it as of the final day. The entry revalues what sits on the balance sheet. It never creates cash, and it does not replace the gains that payments themselves record.

Realized and unrealized gains are different entries

Applying a payment is what creates a realized gain. An invoice is written at one rate, the customer pays weeks later at another, and the software books the difference automatically. Revaluation covers the unrealized rest. Firms that revalue mid-period and then apply older invoices see both entries and often read one as a duplicate. It is not a duplicate. One entry records what happened; the other marks time.

To make the books match the bank to the cent, override the rate before you receive the money. The software refreshes exchange rates on its own, but the Currencies screen lets you replace the downloaded figure with the rate your bank actually used. Apply the payment afterward, and the realized difference lands where it belongs.

Payments must land in a same-currency account

The deposit rules catch nearly every firm once. A payment received in euros deposits only into a euro account, because the software will not convert it on the way into a dollar account. Firms with no true foreign bank account keep a clearing account in the payment currency instead. The payment deposits there, then you record the move into the home currency account. The spread between the two rates posts as a realized gain or loss, which is where it belongs.

What settles these reports in practice?

The resolutions in the thread share one shape: discipline up front beats repair afterward. Pick a plan that includes the feature before you need it. Decide every currency before the first transaction on each name and account, because nothing unlocks later. Revalue at period end from the Currencies page, and let payment application record the realized side. Reports print in the home currency no matter what the transactions were written in, so confirm foreign balances in each account’s own register. Firms that follow that sequence meet fewer surprises at close.

← Back to Community Issues