Multi-currency for cross-border clients

When this article is for you

You're a tax advisor with clients invoicing or being paid in multiple currencies, and you want to know how TaxItEasy handles the conversion, what's stored vs computed, and where the FX edge cases bite. This article walks through the model, the per-client setups, and the cross-border quirks (payment processors, exchange-rate fluctuations, multiple-company arrangements).

For the underlying multi-currency mechanics on the client side, see multi-currency and live ECB rates. For language preservation in exports (related to multi-locale work), see language handling in exports. For period semantics in bulk exports, see period-filtered bulk export.

The model

Each company (TaxItEasy's tenant unit) picks one base currency at onboarding — EUR, USD, GBP, CHF, JPY, etc. All views, exports, and aggregations are in that company's base currency. Different clients can have different bases; one client can even have two companies with different bases.

For invoices not in the base currency:

• Original amount + currency are stored exactly as on the document
• Converted amount is stored, computed using the European Central Bank reference rate on the invoice date (not the upload date)
• Rate used + rate source ("ECB") are logged

The cockpit + VAT view + bulk exports show converted amounts in the client's base. The original amounts are visible by clicking through to the invoice detail page; the converted is the default sum-and-aggregate field.

Common cross-border scenarios

Single base currency, foreign invoices

The most common case. Client based in Germany, base currency EUR, but pays some US vendors in USD (AWS, Stripe, GitHub):

• USD invoices: converted to EUR at the ECB EUR/USD rate on each invoice's date
• VAT view: shows EUR totals only (the converted amounts); the per-rate breakdown sums in EUR
• Bulk export: EUR amounts as the primary fields, original USD + rate + rate-date as additional fields per invoice

Your cockpit sees this client purely in EUR. The USD originals are accessible per invoice but don't appear in summary views.

Multi-currency client with one company, multiple operating regions

Client based in Cyprus (your firm), base currency EUR, but with business operations + a bank account in the UK (GBP):

• GBP transactions in the bank import: shown alongside the EUR-converted amount on the transaction row
• Matching against EUR-based invoices works because matching uses EUR-converted amounts on both sides (transaction.amount_in_eur ↔ invoice.amount_in_eur, with the standard amount-tolerance)
• VAT view: EUR totals; the GBP-source amounts are accessible per transaction but don't aggregate separately

This is one company straddling two currency zones. The base is EUR (one company = one base), but transactions in the bank import can be in GBP.

Multiple companies in different base currencies

A client with two separate legal entities — one EUR, one USD:

• Each company is fully separate (different base currency, different books, different VAT IDs, different invoices)
• Your cockpit shows them as different rows; you switch between them by clicking
• Exports are per-company, in each company's own base currency

You cannot consolidate the two companies into a unified view at the TaxItEasy level — each is its own legal entity. For consolidated reporting, your accounting software / process handles the consolidation (typically using EUR as the reporting currency, converting the USD subsidiary at the period-end rate).

Multi-currency invoice (rare)

A single invoice with line items in different currencies — unusual but happens with some international vendor consolidations. The AI extracts the dominant currency for the invoice-level total and stores it as the invoice's currency. Per-line currencies (if different) are also stored individually under line_items[*].currency.

Bulk exports include both the invoice-level currency and per-line-item currencies. Most accounting tools handle this case via per-line conversion in their import step.

What about exchange-rate fluctuations

For tax-purpose accounting:

• The invoice-date rate is what's used for the recorded expense / income. This is what the tax authority expects on a VAT return.
• The payment-date rate (when the bank actually charged the EUR amount) is what your client's bank used. Usually different from ECB rate (banks add a margin / FX spread).
• The difference is a currency gain/loss event for accounting purposes — typically goes into a "FX gain/loss" expense account.

TaxItEasy stores:

• Invoice: invoice-date ECB conversion (used for VAT-purposes EUR amount)
• Bank transaction: actual EUR amount the bank charged (the post-FX-margin number)

The difference between the two is the currency gain/loss. Your accounting software / process is where you compute this entry — TaxItEasy gives you both numbers per invoice-transaction match; the subtraction is downstream.

Worked example

• USD 1,000.00 invoice on 2026-03-15 from a US vendor
• ECB rate on 2026-03-15: EUR/USD = 1.0823 → invoice converted amount = €923.91
• Client's bank transfer happens 2026-03-22 at the bank's rate (with margin): bank charges €925.50
• Currency loss for accounting: €925.50 − €923.91 = €1.59

TaxItEasy stores both €923.91 (invoice-date ECB) and €925.50 (bank's actual charge). The €1.59 is computed in your accounting flow.

Payment processors (Stripe, Wise, Revolut Business)

A specific edge case: clients using payment processors that handle FX themselves.

• The processor receives the invoice in foreign currency (e.g. USD)
• The processor converts at their own rate (typically with a margin)
• The bank statement shows the converted amount (e.g. EUR) plus any processor fees

In this scenario:

• Invoice: USD 1,000 → ECB-converted €923.91 (TaxItEasy's invoice-side number)
• Stripe receives the USD payment, charges processor fee (say 2.9% + €0.30 ≈ USD 29.30)
• Stripe transfers EUR amount to client's bank: ~€891 (after Stripe's FX margin + fees)

So:

• Invoice EUR-converted: €923.91 (the "purist" tax number)
• Actual EUR received: €891 (the cash-flow number)
• Difference: €32.91 = processor fee + FX margin

Both numbers are useful for different purposes. TaxItEasy preserves the original USD invoice + the ECB conversion; the bank transaction shows the EUR received. The accountant decides where the €32.91 sits (fee expense, FX loss, processor fee category).

Changing a client's base currency

A client's base currency was wrong (someone picked the wrong one at onboarding), or the client legitimately wants to change it.

Settings → Company → Base currency lets the client change. Note:

• Past invoices keep their original conversion. Changing base currency does NOT retroactively re-convert historic books (that would invalidate prior tax filings).
• Future invoices use the new base currency going forward.
• For consistency at the change moment, run a fresh export of the period straddling the change so the receiving accounting tool has the correct base recorded.

If a client genuinely needs all-historic-data re-converted to a new base (e.g. legal entity migration to a different jurisdiction), that's a one-time migration handled by [email protected] with the appropriate verification.

Cockpit view for multi-currency clients

When your cockpit lists clients in different base currencies, each client card shows the amount in that client's base. There's no auto-conversion to "your firm's base" because:

• You might have many clients in many bases
• The "your firm's base" concept doesn't exist (TaxItEasy is multi-tenant per client, not per firm)
• Cross-client aggregation in a unified currency would require an arbitrary reference choice

If you need a cross-client overview in one currency for your own reporting, run bulk exports per client, convert each to your preferred unified currency in your accounting flow, then aggregate. Most firms do this monthly or quarterly.

Edge cases

"Client's base currency was wrong — I want to change it." They change it themselves in Settings → Company → Base currency. Past invoices keep their original conversions. New invoices use the new base. Consider a fresh period-export at the change moment for consistency in your accounting flow.

"ECB doesn't publish a rate for the currency (e.g. crypto)." Conversion field is left blank with a manual-review flag. The client or you supplies the rate. Source = user_supplied, clearly distinguished in the audit log. For Bitcoin/USDT/etc., a common practice is the issuing exchange's rate at invoice date (Kraken / Binance EUR-pair).

"Client uses a payment processor that converts at their own rate." Two amounts: the invoice's foreign-currency amount (what the vendor charged) → ECB-converted in TaxItEasy → invoice-side number. The bank-transaction EUR amount (what the client actually paid through the processor) → bank-side number. Both stored. The difference is the processor's margin + fees; goes into your "FX loss" or "processor fees" expense category in the accounting flow.

"Some invoices for the same vendor are in different currencies." Fine. Each invoice is independently in its own currency. The trading partner record collects all of them; the matching pipeline uses converted amounts on both sides. The per-vendor view shows historical amounts as-printed (in each invoice's original currency) so you can see whether the vendor changed currencies over time.

"Multi-currency client wants a consolidated report across companies." Not a TaxItEasy feature — each company is its own tenant. Run per-company bulk exports in each base currency, consolidate downstream in your accounting tool with whatever period-end conversion rate you prefer. ECB rate for the period-end date is the conventional choice.

"Client's bank charges in EUR but the invoice was in CHF." Standard scenario. Invoice: CHF → EUR-converted at invoice-date ECB. Bank: EUR transaction (the actual amount charged). The matching engine uses EUR-on-both-sides; difference is FX margin.

"I want to override the ECB rate for a specific invoice." Client opens the invoice → clicks the conversion-rate field → enters their preferred rate. Source becomes user_supplied. Useful for: contractual rates ("paid at the rate of the day"), exchange-house actual rates, or correcting a stale ECB lookup.

"ECB had no publication on the invoice date (weekend / public holiday)." The system uses the most recent published rate (Friday's rate for a Monday-dated invoice over a regular weekend). This is the same convention every tax authority uses. No manual override needed; the audit log records the rate date used.

"Currency code on the document is non-standard (e.g. CN¥ for Chinese Yuan instead of CNY)." The AI normalises currency codes during extraction. If it gets it wrong (extracts CN¥ as CNY but the invoice was actually in HKD), correct the currency field on the document; the ECB rate is re-looked-up for the corrected currency.

Related

• Multi-currency and live ECB rates — the client-side mechanics in detail
• Language handling in exports — multi-locale considerations alongside multi-currency
• Period-filtered bulk export — exports preserve per-invoice currencies + conversions
• Tax-advisor cockpit — the cross-client base-currency view