Why Your Reports Show Separate Totals Per Currency

If you invoice clients in more than one currency, every financial report in the product — the aging report, the tax summary, the accountant report, the client statement — shows you separate totals per currency instead of one blended number. A USD row, a EUR row, a GBP row, each with its own subtotals, sitting side by side rather than combined. This is a deliberate design decision, not a missing feature, and it comes down to one fact: there is no exchange-rate conversion happening anywhere in the platform's reporting layer, by design.

How Currency Grouping Actually Works Under the Hood

Every invoice stores its own currency code and currency symbol directly on the record — set when the invoice was created and never recalculated afterward. When a report aggregates numbers across many invoices, it doesn't total everything into a single running number. Instead, it builds a composite key out of the currency code and symbol for each invoice, and accumulates totals into a bucket keyed by that combination. An invoice billed in USD adds to the USD bucket; one billed in EUR adds to a completely separate EUR bucket. The report's final output is a list of these per-currency buckets, each fully independent of the others — there's no step anywhere that takes a USD figure and a EUR figure and adds them together into one number.

Why Not Just Convert Everything to One Currency?

The tempting alternative — pick a home currency, convert everything else into it using current exchange rates, and show one clean total — introduces a problem that's worse than the inconvenience of reading multiple rows. Exchange rates move constantly, sometimes by meaningful amounts within a single day for volatile currency pairs. A converted total is only accurate as of the specific moment and the specific rate used to calculate it; the second real market rates shift, that "single clean number" is already slightly wrong, and it keeps drifting further from reality the longer it sits unrefreshed. Worse, if you ran the same report twice on different days, you could get two different totals for the exact same set of invoices — not because anything about your invoices changed, but because the conversion rate used behind the scenes changed. That's a genuinely confusing experience for a financial report, where the expectation is that the same underlying data always produces the same answer.

Keeping currencies separate avoids that entirely. A USD total is always exactly the sum of your USD invoices — full stop, no external dependency, no rate that needs fetching, no cache that needs refreshing, no discrepancy between two runs of the same report on the same data. It's a smaller number of guarantees, but every one of them holds unconditionally.

The Trade-Off: No Single "Total Revenue" Figure

The honest cost of this design is that if you genuinely operate across several currencies, there's no single headline "total revenue across all currencies" number anywhere in the reports — you have to look at each currency's total individually, or do the conversion yourself outside the tool if you need one blended figure for a specific purpose, like a board report denominated in a single reporting currency. For a workspace that only ever bills in one currency, this trade-off is invisible — every report just shows one bucket, and it looks identical to a version of the tool that only supported a single currency to begin with. It only becomes visible, and matters, the moment a workspace starts genuinely operating across more than one.

This Applies Consistently Across Every Report

The same per-currency bucketing pattern shows up identically in the aging report (outstanding totals bucketed by both aging window and currency), the tax summary (taxable revenue and tax collected bucketed by both month and currency), the accountant report (workspace-wide totals and per-client totals, all currency-separated), and the client statement (a single client's invoices and expenses, still split by currency if that one client happens to have been billed in more than one). None of these reports special-case currency handling differently from the others — they all share the same underlying "group by currency code and symbol" approach, which is part of why the behavior is predictable once you understand it in one report: it works exactly the same way in every other financial report in the product.

What To Do If You Need a Converted Total

If your business genuinely needs a single blended figure — for internal reporting, for a board deck, for your own bookkeeping in a home currency — the practical approach is to export the relevant report as CSV, where you'll get the same per-currency breakdown in spreadsheet form, and apply whatever exchange rate and conversion logic is appropriate for your specific purpose there. That keeps the source data exact and unopinionated, while letting you apply a conversion rate that's explicit, dated, and chosen deliberately for whatever the specific report is for — rather than having an implicit, potentially stale rate baked invisibly into a number the platform generated for you.

The Underlying Principle

Across the reporting features generally, the pattern is to show you exactly what's true about your own data with nothing estimated, interpolated, or fetched from an external source layered on top. A per-currency total is always precisely correct because it's just addition. A converted total is only ever an estimate, accurate as of a specific moment, using a specific rate, that the tool would have had to fetch from somewhere and would eventually go stale. Between "always exactly right, but split into more rows" and "one row, but only approximately right as of an unknown moment," the reports consistently choose the former.

A Worked Multi-Currency Example

Say a workspace has billed three invoices this year: two in USD totaling $5,000, and one in EUR for €2,000. The aging report, if all three are still outstanding, shows a USD bucket set summing to $5,000 and a separate EUR bucket set summing to €2,000 — never a single combined figure like "$7,340" arrived at by converting the euros using whatever the exchange rate happened to be at report-generation time. The accountant report's per-client totals work the same way if that client has been billed in both currencies: two separate lines for that one client, one per currency, rather than one blended client total. This holds true consistently whether you're looking at the aging report, the tax summary, the accountant report, the client statement, or the account data export — currency code and symbol are treated as part of the identity of a total, not as metadata to be normalized away.

How This Shows Up in the Account Data Export

The same non-conversion principle extends to the full account data export: every invoice, expense, and payment record in the exported JSON retains its original currency exactly as stored, with no conversion or normalization applied anywhere in the export process. If you're building your own external reporting on top of an exported file — importing it into a spreadsheet or another system — the responsibility for any currency conversion sits entirely with you and whatever tool you're using downstream, using whatever exchange rate and date you consider appropriate for your purpose. The export, like the in-app reports, is deliberately just a faithful copy of what's actually stored, not an interpretation of it.

The Currency Is Set Per Invoice, Not Inherited From a Global Default

Because each invoice stores its own currency code and symbol independently, a single workspace can genuinely bill different clients in different currencies without any special configuration — there's no single "workspace currency" setting that every invoice is forced to inherit. Your business profile can carry a default currency that pre-fills new invoices for convenience, but that default is just a starting point on a fresh invoice, not a constraint the invoice is locked to afterward. This is what makes the per-currency bucketing in every report a natural consequence of how the data is modeled, rather than an extra layer bolted on top: the reports are simply grouping by a field that already varies invoice by invoice, the same way they'd group by client or by status.

The practical upshot is that adding a new currency to your invoicing workflow requires no setup step, no toggle to enable multi-currency support, and no migration of existing data — you simply create an invoice with a different currency selected, and every report that touches invoice totals automatically picks up a new bucket for it on the next run. There's nothing to configure in advance, and nothing that needs to be turned on; the currency-grouping behavior described throughout this article is simply how totals have always been calculated, whether a workspace happens to use one currency or several.