Guide · Cross-border billing
Why one total is wrong on a multi-currency statement
Published 2026-09-12 · Updated 2026-09-12 · InvoiceNow AI
If you have invoiced one client in two different currencies over the same period, a single closing balance on their statement is almost certainly wrong. There is no honest way to add €4,000 to £2,500 and print one number, because the answer changes every day and none of the possible answers is what the client actually owes.
A correct statement keeps each currency on its own line and says so. What follows is what goes wrong when a tool does otherwise, and how to tell which kind of statement you are looking at.
The three ways tools get it wrong
1. Converting everything at today's rate
The most common approach, and the most misleading. An invoice raised in March at one rate is restated at September's rate, so the statement shows a debt that neither party agreed to. The client owes the amount on the invoice they received, not a figure that moves with the currency market.
2. Adding the raw numbers together
Rarer, and worse. Summing 4,000 and 2,500 into "6,500" produces a number in no currency at all. It looks like a total, which is precisely the problem — nothing on the page signals that it is meaningless.
3. Silently dropping one currency
The most dangerous, because it usually looks correct. A statement that reports only the home-currency invoices and omits the rest understates the debt, and neither party notices until the year-end reconciliation.
A worked example
A consultancy bills one client twice in a quarter: once in euros, once in pounds. Neither invoice is paid by the period end.
| Invoice | Issued | Amount | Rate on the day |
|---|---|---|---|
| INV-0041 | 3 March | €4,000.00 | recorded at issue |
| INV-0058 | 19 May | £2,500.00 | recorded at issue |
A tool that converts at the period-end rate might print a closing balance of roughly 7,100 in the home currency. By the time the client reads the statement a week later, the honest figure has moved again. Neither number matches either invoice, so the client cannot reconcile the statement against anything they hold — and a statement that cannot be reconciled does not get paid, it gets queried.
What a correct statement shows
EUR — opening €0.00 charges €4,000.00 closing €4,000.00
GBP — opening £0.00 charges £2,500.00 closing £2,500.00
Two balances, each one matching an invoice the client already has. No single figure, and an explicit note saying that the absence of one total is not a zero balance.
Why the exchange rate has to live on the invoice
The rate that matters is the one on the day the invoice was issued, not the day the statement was printed. If your system does not store it, that information is gone — and every later report becomes an estimate.
Recording the rate and the converted amount on each invoice lets you do two things at once: show the client the figure they were actually billed, and keep your own reporting in one consistent currency. Those are different numbers with different purposes, and a system that only keeps one of them forces you to choose.
When a single total is fine
If every invoice to a client is in the same currency, one closing balance is correct and clearer than a breakdown. The per-currency split only earns its complexity when a period genuinely spans more than one currency, which is why it should appear then and not before.
This guide describes how statements should present currency. It is not tax advice, and the treatment of foreign-currency income differs by country — check the rules that apply to you.
How InvoiceNow handles this
InvoiceNow records the exchange rate and converted amount on every invoice, and refuses to print a single closing balance when a statement period spans more than one currency — it shows each currency separately and states on the document that this is not a zero balance.