Sell in Several Currencies, Keep One Set of Books

The two choices QuickBooks will not let you take back

Before anything touches Stripe, settle the QuickBooks side, because Intuit treats both of these as one-way doors.

Turning Multicurrency on is permanent. QuickBooks asks you to confirm that you understand it cannot be undone, and after that the feature stays on for the life of the company file. There is no setting to reverse it.

Your home currency is locked at the same moment. You can change it freely while Multicurrency is off, and not at all once it is on. Your home currency is what runs your Profit and Loss, your Balance Sheet and every primary report, so this is the single most consequential field in the setup.

What you gain is the ability to assign a foreign currency to specific customers, vendors, bank accounts and credit card accounts, and to hold documents in those currencies while reporting in one. That is the whole point, and it is worth having. Just make the decision deliberately rather than as a side effect of wanting one Canadian invoice to look right.

What Stripe has already done before QuickBooks sees anything

Stripe separates two ideas that are easy to run together. The presentment currency is the currency of the charge, the one your customer sees. The settlement currency is the currency your bank account accepts. When they differ, Stripe converts the charge into your settlement currency.

If you hold a single balance, that is the whole story: you can charge in any supported currency, and Stripe converts everything into your default balance currency as it arrives. Conversion costs apply, and they are part of what makes the payout smaller than the sum of the sales.

If you have enabled settlement in additional currencies, charges in a currency you hold route into that balance, and anything in a currency you do not hold converts into your default. Stripe's own example is worth repeating: with GBP and USD accounts and GBP as the default, any non-USD charge converts to GBP. Each settlement currency needs its own bank account in your Stripe payout settings.

That matters here because the number of balances you keep decides how many bank accounts, holding accounts and QuickBooks reconciliations you are signing up for. It is a bookkeeping decision disguised as a treasury one. If you hold more than one balance but genuinely only use one, the simpler answer is to drop the spare and run the single-balance setup.

Two levels of support, and which one you actually need

Acodei's multicurrency handling comes in two levels, and they solve different problems.

**Enable Multicurrency Support** is the general level. It makes sure a transaction's currency in Stripe matches or maps appropriately to QuickBooks, by managing the currency on the QuickBooks customer record. If your sales convert into one Stripe balance and you are content for QuickBooks to hold them in your home currency, this is the level you want.

**Invoice Multicurrency** is the advanced level. It lets an invoice keep a non-home currency in QuickBooks, and applies exchange rates at payment, payout and refund. If your customers need to see an invoice denominated in their own currency, and you need that invoice to sit in Accounts Receivable in that currency, this is the level you want.

One practical note that changes how you plan the rollout: neither toggle is self-serve. Both Multicurrency Support and Invoice Multicurrency are enabled by the Acodei team rather than switched on from your dashboard. Treat it as a conversation to schedule, not a checkbox to find.

Per-currency customer records are the design, not a defect

This is the part that surprises people most often, so it is worth stating before you see it rather than after.

When a transaction arrives, Acodei checks whether the Stripe transaction currency matches the currency assigned to the QuickBooks customer. If they match, the existing customer record is used. If they do not, a new QuickBooks customer record is created in the format `CustomerName - [CurrencyCode]`. An existing customer set to USD who pays you in Canadian dollars produces a second record named `CustomerName - CAD`.

That is not duplication creeping in. QuickBooks assigns one currency per customer, so a customer who transacts in two currencies has to exist as two records for the documents to be valid at all. Acodei is following the constraint rather than working around it.

What it means in practice is that your customer list gets longer than your customer count, and that any report or process keyed on customer name needs to expect the suffix. Plan for it in your naming and your reporting, and it is a non-event.

Multicurrency makes your holding account decision for you

On a single-currency setup, Undeposited Funds and a regular asset clearing account are both viable and the choice is about how you want fees to behave. Multicurrency narrows that.

If you want Invoice Multicurrency, Undeposited Funds is not available. The two are not permitted together, and the app enforces it: with Invoice Multicurrency on, Undeposited Funds is not offered as a holding account. An asset clearing account is the documented setup for advanced multicurrency work.

If you run more than one Stripe balance, the documented recommendation goes further. Assign a separate deposit account per balance and a separate holding account per balance, and keep those holding accounts off Undeposited Funds. The reason is straightforward: multiple balances mean multiple bank accounts, and a holding account that mixes currencies cannot be reconciled against any one of them.

Fees follow the money rather than the invoice. A fee is recorded in the currency of the balance transaction that actually carried it, so a charge presented in Canadian dollars that settles into a US dollar balance produces a fee recorded in US dollars. And under Invoice Sync, fees never sit on the invoice itself, because that would put the invoice total out of agreement with Stripe.

Where each exchange rate comes from

With Invoice Multicurrency on, the rate is sourced differently at each stage, and knowing which is which is what makes a mismatch diagnosable later.

At invoice creation, the invoice is pushed to QuickBooks in the original Stripe currency. No exchange rate is attached at that point, because Stripe does not provide an invoice-level rate at `invoice.created`. QuickBooks' own ExchangeRate API supplies a rate where one is needed.

At payment, the payment is recorded in the invoice currency and an exchange rate is stored alongside it, so QuickBooks shows the correct home-currency equivalent. Stripe's rate is used when it can be derived, and QuickBooks' rate is the fallback when it cannot. A 1,000 CAD invoice paid at a rate of 0.8 records as 1,000 CAD with an 800 USD home-currency value, and the invoice closes fully rather than leaving a remainder open.

Refunds and credit notes carry a rate when their currency differs from your home currency, and a credit note is replicated as a credit memo in the same currency as the invoice.

Payouts are recorded as a Transfer, with the exchange rate applied when the payout currency differs from your home currency.

Four stages, up to four rates. That is the mechanism behind payouts that do not tie back to the sales that produced them, and [why your Stripe multicurrency payout and QuickBooks disagree](/blog/stripe-multicurrency-quickbooks) works the arithmetic through end to end.

What this setup does not do

Zero-decimal currencies are not supported today. Japanese yen is the common one. If part of your revenue is denominated in a currency with no minor unit, that portion needs handling separately rather than being assumed to flow through.

Neither multicurrency level is a self-serve toggle, so a same-day switch is not on the table. Both are enabled by the Acodei team.

The sync is one-way. An invoice edited in QuickBooks does not travel back to Stripe, and changing a currency assignment in QuickBooks after the fact does not rewrite what already synced.

And none of this decides your revenue recognition policy for you. Which rate your accountant wants revenue recorded at, and how unrealised gains and losses are treated at period end, are decisions for the close process rather than for the integration.