Multi-Currency NetSuite + WooCommerce — Three Problems Every Integration Hits
- Problem 1: WooCommerce stores a single currency per order; NetSuite’s Sales Order requires both the transaction currency and a base-currency equivalent for every financial record.
- Problem 2: Exchange rate timing — the rate shown to the customer at checkout can differ from the rate NetSuite has on file by the time the order syncs, and nothing forces the two schedules to agree.
- Problem 3: Tax must post in the currency and at the conversion rate each jurisdiction accepts — UK, EU, and Australian rules each specify their own method, and none of them match NetSuite’s default consolidated rate.
Multi-currency support sounds like a configuration task — enable currencies in WooCommerce, enable them in NetSuite, connect the two. It isn’t, because WooCommerce doesn’t have native multi-currency support to enable: WooCommerce’s own documentation states that each store sets exactly one base currency, and displaying or charging in additional currencies requires a separate multi-currency extension. Once that extension is connected to NetSuite, three classes of integration problem appear — none of them visible in testing, all of them surfacing in production financial reconciliation. This guide, part of the NetSuite + WooCommerce integration guide library, covers each problem, the exact NetSuite fields it touches, and the fix.
Problem 1: Dual Currency Record Structure
WooCommerce records one currency per order — the currency the customer paid in, set by whichever multi-currency extension handled that checkout. NetSuite’s Sales Order record splits that single amount into two: the transaction currency (what the customer paid) and the base-currency equivalent (what posts to your P&L and consolidates across subsidiaries). Your integration has to supply both, plus the exchange rate that justifies the conversion between them.
NetSuite’s own documentation is explicit about the mechanism: a transaction records in its transaction currency, and when the resulting GL impact posts to an accounting book in a different currency, NetSuite converts using either its own stored exchange rate or a rate set explicitly on the transaction. Omit the rate, and NetSuite falls back to whatever it already has on file — fetched independently of your storefront, and not guaranteed to match the number the customer saw at checkout.
The diagram shows the split for a single UK order: one WooCommerce amount becomes five distinct NetSuite fields, and the two currency amounts have to reconcile against the same rate — checked at a books-close review, not at sync time, which is why a mismatch here surfaces weeks after the order, not the day it happens.
Problem 2: Exchange Rate Timing
WooCommerce currency plugins (WOOCS, Currency Switcher, and similar multi-currency extensions) fetch exchange rates on a schedule — typically hourly or daily. NetSuite maintains its own stored exchange rates on a separate schedule, either entered manually or imported through NetSuite’s currency exchange rate integration. The two schedules are not the same schedule, and nothing forces them to agree.
A customer browses at 9am when the storefront rate is 1.27, places the order at 11am while the storefront still shows 1.27, but NetSuite’s stored rate updated to 1.29 at 10am. The order posts to NetSuite with a different rate than the one on the customer’s receipt — a 2-cent discrepancy per dollar that looks trivial on one order and becomes a real reconciliation gap across thousands of them.
When an order is placed in WooCommerce, record the exact exchange rate used for that transaction as order meta (_exchange_rate_at_order). When the integration syncs the order to NetSuite, use this stored rate explicitly in the exchangerate field rather than relying on NetSuite’s current rate. This ensures the financial record matches the customer-facing receipt.
Rate drift doesn’t fail the sync — the order still goes through either way. It only shows up in a reconciliation report or a books-close review, which is why it belongs on the same alerting surface as everything else in what a NetSuite integration should monitor and alert on: a daily job comparing each order’s stored _exchange_rate_at_order against the rate that actually landed in NetSuite’s exchangerate field, flagging any pair that doesn’t match exactly.
Problem 3: Tax in the Correct Currency
EU VAT, UK VAT, and Australian GST rules all specify that tax has to be calculated and remitted in a particular currency at a particular conversion rate — but the currency and the accepted conversion method differ by jurisdiction, and getting this wrong doesn’t fail at sync time. It fails at a VAT or GST audit, months later.
| Jurisdiction | Tax must post in | Accepted conversion rate |
|---|---|---|
| UK VAT | Sterling | HMRC’s published period rate, the UK market-selling rate at time of supply, or the ECB reference rate — one method, applied consistently |
| EU VAT | The invoicing member state’s national currency | The ECB reference rate under the VAT Directive’s currency-conversion rule, or a state-approved alternative |
| Australian GST | Australian dollars | The Reserve Bank of Australia rate on the transaction date, or another rate applied consistently and evidenced |
None of these let NetSuite’s default consolidated exchange rate stand in for the tax-specific rate. If your WooCommerce tax plugin calculates tax in the customer’s currency and your integration converts it to base currency before writing it to NetSuite, the rounding difference between the storefront’s FX source and the jurisdiction’s accepted rate is exactly what an auditor checks first. Populate the NetSuite Sales Order’s tax fields in the transaction currency, not the converted base-currency amount — NetSuite converts tax amounts for GL purposes internally, using the same base-currency exchange rate as the rest of the order, so a second manual conversion on top of that only adds a second rounding error.
Multi-Currency Go-Live Checklist
The three problems above turn into a short list of things to verify before a multi-currency integration goes live. Work down it in order — later items assume the earlier ones already hold.
- Confirm which multi-currency extension is active on WooCommerce, and which currencies it fetches rates for.
- Store the exact exchange rate used at order placement as order meta, before the order reaches the integration.
- Pass that stored rate explicitly in NetSuite’s
exchangeratefield — never let the sync fall back to NetSuite’s current stored rate. - Populate
foreignsubtotalandforeigntotalin base currency, and confirm they equal subtotal × exchangerate within rounding tolerance. - Populate tax fields in the transaction currency, using the accepted conversion method for the customer’s tax jurisdiction — not the order’s general exchange rate.
- Test a refund placed in a non-USD currency specifically; refund-rate handling is a separate code path from order-creation rate handling in most integrations.
- Add a daily reconciliation check comparing each order’s stored rate against the rate NetSuite actually recorded, and alert on any mismatch.
- Confirm FX gain/loss postings land in the GL account your accounting team expects, before the first real multi-currency month closes.
For teams building this from scratch rather than patching an existing sync, NetSuite Integration Pro handles the dual-currency field mapping and rate-lock behavior above out of the box.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
References
- NetSuite Multiple Currencies ExamplesOracle NetSuite Help — how transaction currency converts to base currency using stored or transaction-specific exchange rates.
- WooCommerce Shop Currency DocumentationWooCommerce.com — confirms one base currency per store natively; multiple currencies require an extension.
- HMRC VAT Valuation Manual — VATVAL09500HMRC — accepted methods for converting foreign currency amounts to sterling for UK VAT.
- Council Directive 2006/112/EC (EU VAT Directive), consolidated textEUR-Lex — Articles 91 and 230 govern currency conversion and the invoicing-currency requirement for EU VAT.
- GSTR 2001/2 — Foreign Exchange ConversionsAustralian Taxation Office — accepted methods for converting foreign currency to AUD for GST purposes.
Frequently asked questions
Why is the dual currency record structure a problem?
Because NetSuite records both the transaction currency and the base currency equivalent for every order, and integrations that only populate one of them produce Sales Orders that fail reconciliation the first time someone checks the P&L against the storefront total.
When should the exchange rate be captured?
At order placement, stored as order meta, not recalculated at sync time. Capturing it later means using whatever rate NetSuite happens to have on file at that moment, which drifts from the rate the customer actually saw.
What about tax in multi-currency setups?
Tax has to post in the currency and at the conversion rate each jurisdiction accepts — HMRC’s or the ECB’s rate for UK/EU VAT, the RBA’s rate for Australian GST — not the general order exchange rate, or reporting won’t reconcile even when the order total looks right.
Does WooCommerce support multiple currencies natively?
No. WooCommerce core sets exactly one base currency per store; showing or charging in additional currencies requires a separate multi-currency extension, and that extension’s rate schedule is what your integration ultimately has to reconcile against NetSuite’s.
Leave a Reply