Browse the knowledge base

Multi-currency invoices and live ECB rates

When the AI extracts a non-base-currency invoice, we look up the European Central Bank reference rate for the invoice date and store both the original amount and the converted amount. ECB rates are what most EU tax authorities expect, so conversions are defensible. Available on Business and Growth plans; Free and Starter show invoices in their original currency only.

When to read this

You receive invoices in currencies other than your base currency (you bill in EUR but get an AWS invoice in USD), and you want to know how the conversion works, where the rates come from, and whether the converted amounts are defensible for tax purposes. Or you're trying to reconcile a bank transaction in your local currency against an invoice in a foreign one. This article covers both.

For the broader extraction story (what's extracted, confidence scores, corrections), see what the AI reads, and how to correct it. For year-end exports that include multi-currency data, see export your records for year-end.

How conversion works

When a document is extracted and the AI detects a currency that isn't your base currency, three things happen automatically:

  1. Currency detection. The AI reads the currency from the invoice — typically the printed currency code (USD, GBP, CHF, JPY) or symbol ($, £, Fr., ¥). Some invoices state currency only in the line items ("$ 100.00" repeated); others state it explicitly ("Amount: 100.00 USD"). The detection works either way.
  2. Rate lookup. The pipeline fetches the European Central Bank's reference rate for the invoice date (not the upload date — see below). For weekends and ECB-non-business-days (holidays, official observances), the most recent published rate is used.
  3. Storage. Both numbers are stored: original net/VAT/gross in the invoice currency, converted net/VAT/gross in your base currency, the exact rate used (e.g. EUR/USD = 1.0823), the rate date (the invoice date), and the source (ECB).

Both numbers display on the invoice detail page side-by-side. Both go into year-end JSON exports. Tax-advisor invites see both.

Where the rates come from

We use ECB daily reference rates — the official rates published by the European Central Bank each business day around 16:00 CET. The same source is used by most EU tax authorities for converting foreign-currency transactions for tax reporting. Using ECB rates makes your conversions defensible without further justification.

For currencies the ECB doesn't publish (less common: exotic emerging-market currencies, cryptocurrencies), the conversion field is left blank with a manual review flag — you supply the rate yourself. The user-supplied rate is clearly tagged in the audit log as source: user_supplied to distinguish from ECB rates.

We do not use bank-side rates, mid-market rates from a different source, or any other reference. Banks use their own rates with margins built in, which is fine for what your bank actually charged you, but not what tax authorities use. The two are different on purpose; see the troubleshooting section on bank-vs-ECB reconciliation.

What gets stored per multi-currency invoice

For each multi-currency document, the data model includes:

  • Original net, VAT amount, VAT rate, gross — in the invoice currency
  • Converted net, VAT amount, VAT rate, gross — in your base currency
  • Rate used — e.g. EUR/USD: 1.0823 (the rate as published by the ECB)
  • Rate date — the invoice date (the date the rate was effective at the time of the transaction)
  • Rate sourceECB (or user_supplied for manually entered rates)

Year-end JSON exports include all of these fields per document. Spreadsheet imports of the JSON can show converted columns directly; tax filings typically use the base-currency converted amount as the reported figure.

Conversion-date semantics

The rate used is the rate for the invoice date, not for the upload date. This is the convention most EU tax authorities expect.

Concrete example: you receive an invoice dated 2026-03-15 (today's-date convention) in USD. You upload it on 2026-05-21 (today). We use the EUR/USD rate from 2026-03-15, not from 2026-05-21. The conversion reflects what the invoice was worth at the time it was issued, not at the time you got around to uploading it.

This means uploading an old invoice doesn't change historical books retroactively in a different way than uploading it at the time would have. Your book valuation is consistent.

For the rare cases where you want a different conversion-date convention (e.g. you're using payment-date conversion for cash-accounting purposes), open the document, click the conversion field, and override manually with the rate you want. The override is stored with source: user_supplied.

Plan availability

Live ECB conversion runs on Business and Growth plans. The pipeline is identical on both; the only difference is plan availability.

Free and Starter plans show invoices in their original currency only — the data is extracted, but no conversion is performed. If you upgrade later, the historical invoices stay in their original currency (no retroactive conversion); only new uploads from the upgrade onwards convert. To convert historical invoices, run Settings → Plan → Backfill conversions after upgrading (Business+).

Common scenarios

EU business receiving USD invoices from US vendors

Most common case. Your base currency is EUR, AWS / Stripe / Microsoft / Adobe / Google send USD invoices, the pipeline converts each at the ECB EUR/USD rate on the invoice date. Year-end exports show EUR totals with USD originals visible.

UK business with GBP base, receiving EUR invoices

Same pattern, reverse direction. Base currency = GBP, EUR invoices convert via ECB's published EUR/GBP rate. The ECB publishes EUR-X rates rather than GBP-X rates directly; we use the inverse where needed (1/rate). The result is the same number.

Multi-base setup across multiple companies

If you have two companies in one account with different base currencies (e.g. an EU operating company in EUR and a UK subsidiary in GBP), each company has its own base; conversions are independent. The same USD invoice uploaded to both companies converts to EUR in one and to GBP in the other, at their respective ECB rates for the same invoice date.

Cryptocurrencies and non-ECB currencies

Cryptocurrencies aren't covered by ECB reference rates. The conversion field on a Bitcoin or stablecoin invoice gets a manual review flag; you enter the rate you want (typically from a cryptocurrency-reference source like CoinMarketCap, the issuing exchange's listed rate at invoice date, or your accountant's preferred reference). The rate is stored as source: user_supplied and is auditable.

Edge cases

I uploaded an invoice today but it's dated 6 months ago — which rate? Rate-on-invoice-date. We look up the ECB rate for the invoice date, not the upload date. This matches how tax authorities expect amounts to be reported.

The rate I see in the app differs from what my bank charged me. Banks use their own rates with margins built in. Our conversion uses the official ECB rate, which is the standard for tax-reporting purposes. The two are deliberately different. For reconciliation between your books and your bank statement: match against the actual bank amount in your local currency (the matching pipeline's amount-signal uses the bank's number), not against the ECB-converted figure. The ECB conversion is for tax reporting; the bank conversion is for cash flow. Both are stored.

My vendor uses a currency the ECB doesn't publish (e.g. crypto). The conversion field is left blank with a manual-review flag. Type the rate you want to use; we save it as source: user_supplied, clearly distinguished from ECB rates in the audit log and the export.

Rate looks stale on a recent invoice. Check the invoice date. If the invoice date is today and the ECB hasn't published today's rate yet (typically released ~16:00 CET), we use yesterday's rate. The next ECB publication does not auto-update past invoices — that would change historic books retroactively, which is what you don't want. If today's rate publishes and you want to backfill the rate on today-dated invoices, use the Re-fetch rate action on the document (only available within 7 days of upload).

Currency changed during the invoice period (e.g. some Eastern European countries adopted EUR). The ECB rate before the changeover uses the old currency; rates from the changeover date onward use EUR directly (no conversion needed). The pipeline handles the cutover automatically based on the published ECB calendar; you don't need to do anything special.

The currency on the invoice is ambiguous (e.g. $ could be USD, CAD, AUD, NZD, HKD, SGD). The AI uses the address, country code, and vendor's known currency mix to disambiguate. A $ from a US-based AWS invoice resolves to USD; from a Canadian vendor it resolves to CAD. If the disambiguation is wrong, click the currency field on the document and pick the right one — the rate is re-looked-up for the corrected currency.

Multi-currency invoice (rare — one document with line items in different currencies). The AI extracts the dominant currency for the invoice-level total; line-item-level currencies are also stored individually. The conversion uses the dominant currency for the top-level totals. This is unusual but happens occasionally with international vendor consolidations.

I want to override the rate on a one-off basis. Click the conversion-rate field on the document, type your rate, save. Stored as source: user_supplied. The audit log captures the override with your user attribution. Future invoices from the same vendor still default to ECB rates — the override is per-document, not per-vendor.

Can I change my base currency later without re-converting everything? Yes. Settings → Company → Base currency. Past invoices keep their original conversions (they show the original currency and the conversion to the previous base currency, marked as historical base). New invoices convert to the new base currency. The system doesn't retroactively re-convert because that would change historic book valuations, which would invalidate prior tax filings. For a one-time migration to a new base, contact [email protected] for a coordinated re-conversion.

Related

Didn't answer your question? Write to [email protected] · the AI chat in the bottom-right corner answers most common questions.