Functional currency vs presentation currency.
Pick one functional currency. For a US-based business, that is almost always USD. Every transaction in any other currency must be translated to USD for the ledger. The presentation currency on Shopify storefronts can be EUR, GBP, or AUD, but the books are USD. Mixing functional currencies in a single org leads to a chart of accounts no auditor will accept.
A common confusion is that Shopify Markets shows merchants prices in the storefront currency. Those are presentation prices. The journal entry must convert each line to your functional currency using a defined rate at order time. The rate source matters: gateway rate, central bank rate, and bank receipt rate are all different, and the books should pick one and stick with it.
Three rates and which one to use.
There are three FX rates floating around on a single Shopify order. The gateway conversion rate is what Shopify Payments or the gateway used to compute the merchant payout. The market rate at order time is the spot reference rate (often the ECB daily rate or a similar feed). The bank receipt rate is what your bank applied when crediting the deposit. They are usually within 1-2% of each other but the gap is enough to move margin.
Best practice: book sales at the market rate at order time. Book the bank receipt at the actual bank rate. The difference between the two is realized FX gain or loss, posted to a Foreign exchange gain/loss account. Do not book sales at the bank rate, because then your revenue moves with currency markets instead of operations.
- Order time: spot reference rate, post sales in functional-currency equivalent
- Payout time: gateway conversion is informational, not a booking event
- Bank receipt: actual bank rate, drives realized FX gain/loss
- Month end: revalue any open clearing balance at the closing rate (unrealized FX)
A worked example, €500 order from Berlin.
A Berlin customer places a €500 order on the EU storefront. ECB rate at order time is 1.08 USD per EUR, so USD equivalent is $540. Shopify charges 2.9% + €0.30 in fees, leaving €484.55. The gateway converts at 1.075, depositing $520.89 in your US bank.
Journal: debit Shopify clearing $540, credit Sales $540 at order time. At payout, debit Bank $520.89, debit Processing fees $15.84 (the €14.80 fee at 1.075), debit FX loss $3.27 (the rate spread on the gross), credit Shopify clearing $540. Sales is intact at the operational rate. Fees are visible. FX is isolated.
COGS in a multi-currency world.
COGS should always post in the functional currency at the source-branch WAC. If the SKU was imported and inventory cost includes EUR freight that was paid at 1.08 USD/EUR, that USD cost is what posts to COGS, regardless of what currency the customer paid in. The cost basis does not move when the storefront currency changes.
This is the cleanest test of whether a Shopify accounting setup is correct. Run the same SKU through a USD sale and a EUR sale. COGS should be identical in USD. Revenue should differ only by the storefront price strategy. If COGS differs because the system pulled the cost field through a EUR lens, the books are broken.
Refunds in a foreign currency.
A refund of a €500 order weeks later happens at a different rate. ECB rate has moved to 1.10. Shopify refunds the customer €500 from the gateway. USD equivalent at refund time is $550. But the original sale was booked at $540.
Reverse the sale at the original USD amount, $540, not at today’s rate. The $10 difference is realized FX, not a revenue change. This is how you avoid refund-driven revenue drift. Nonari snapshots the order-time rate on every order so the refund webhook reverses at the original USD amount automatically.
Cross-border tax considerations.
Selling cross-border to EU customers raises VAT and marketplace facilitator considerations. Shopify, when selling on an EU market, may collect and remit VAT on your behalf depending on whether you are above or below the EU OSS threshold (€10,000 for distance sales). Other regions have analogous rules: UK VAT post-Brexit treats imports differently for orders under £135, Australia applies 10% GST on low-value imports, and US state sales tax follows the Wayfair economic nexus thresholds.
In practice: track VAT/GST/sales tax collected per market in a separate liability account, not in revenue. If the marketplace remits, the liability clears when Shopify remits. If you remit, file in the destination country and clear the liability on payment. Either way, do not park tax inside the revenue line.
Period-end revaluation.
On the last day of the month, any open balance in a foreign-currency account should be revalued. The Shopify clearing account is the most important one. If a payout straddles month-end, the clearing balance at month-end should be revalued at the closing reference rate. The delta is unrealized FX, posted to a separate account from realized FX so a reader can tell the difference.
Nonari runs this revaluation automatically on close. Realized FX accumulates per payout from bank rate spreads. Unrealized FX accumulates from open balances at month end. Both feed the same FX gain/loss page so you can see exactly how much margin is operational vs currency-driven.
Where Nonari fits.
Each Shopify storefront, USD or EUR or GBP, is its own online branch in Nonari. Each branch can present in its native storefront currency while the org books in your functional currency. Order-time rates are snapshotted per order, payouts auto-reconcile, and FX gain/loss flows to a dedicated account. Because credentials are AES-256-GCM encrypted at rest and connections are per-branch, you can run three storefronts without crossing data.
For merchants graduating from a single domestic storefront to international expansion, the upgrade is mostly turning on the second storefront in Nonari. The accounting layer already handles multi-currency. You stop fighting spreadsheets, your gross margin stops drifting with FX, and you can answer the question of how much you actually made on the EU market in your functional currency.