Foreign currency and EUR conversion
Receiptu is built for Dutch bookkeeping and VAT workflows where amounts are often needed in EUR, even when the supplier issued the document in another currency (for example GBP or USD).
This page describes the intended behaviour for multi-currency handling. Exact field names and API shapes are defined in engineering design documents when the feature ships.
What we store
For each relevant financial document (see your product UI: attachment / invoice context), Receiptu aims to preserve:
- Original amount and currency — what the document expresses as the payable or stated total.
- Optional EUR equivalent — when a reliable conversion can be applied, together with metadata so you can see how EUR was derived.
If conversion is not possible (missing date, unknown currency, missing rate), the original currency values remain and EUR fields may be empty until you or a future workflow supplies a rate.
Conflict rule: totals win
OCR sometimes extracts mixed or inconsistent figures (for example a total in one currency and line items in another, or rounded lines that do not match the printed total).
Policy: for conversion and display consistency, the document total (as interpreted from the invoice’s main total area) takes precedence over line-item sums when they disagree. Line items remain useful for detail; the total drives the primary amount and currency for FX.
How EUR conversion is chosen (precedence)
Receiptu uses a small chain of strategies so we can add or change sources without rewriting the whole product. The order is:
- Rate printed on the document — if the invoice states an explicit exchange rate (and usually a date), that rate is preferred for converting the total to EUR, because it reflects what the supplier used.
- Official reference rates — if no usable on-invoice rate exists, Receiptu may use a published daily rate (for example ECB) for the invoice date (or the best resolved document date available).
- No automatic conversion — if neither applies safely, we keep original currency only and do not guess EUR.
The API or UI should indicate source (for example invoice, ecb) and as-of date for the rate so accountants can reconcile.
Not tax advice. Rates affect reporting in your own books; verify with your accountant or bookkeeping tool.
Why a swappable “FX provider” internally
Engineering implements conversion behind a single interface with multiple backends (invoice-stated, ECB, manual override in future, etc.). That keeps behaviour consistent in one place and makes it safe to switch the reference data source or add a provider without scattered if logic across the codebase.
Related reading
- Attachments & OCR — where original amounts come from
- Domain knowledge —
raw_datavs editable columns (developer-oriented) - FX reference rates pipeline — backend policy for on-demand ECB cache, fallback dates, retries, and traceability