01What it looks like
A real RowFold grid, captured from a running instance. One price column, four currencies, and a footer that converts what it can and states what it cannot.
02The currency is a fact about the record
Before this existed, RowFold took the currency symbol from the person reading — so a $300 deal rendered as £300 to a colleague in London. Not a different presentation of one amount: a claim about a different amount of money, with no conversion behind it and nothing on screen to indicate anything had changed.
So the currency now belongs to the data, resolved in this order: the cell's own currency, else the column's, else the workspace's — which defaults to whoever created the workspace, so it is right without anyone configuring it. What still belongs to the reader is number formatting: whether that amount reads 1,234.50 or 1.234,50. Everyone sees the same currency on the same record; only the punctuation follows the person.
Set a column's currency on its row in the schema editor, and a single record's on the cell itself — right-click a money cell and pick, or choose Follow the column to clear it again. A row only stores a currency of its own when it differs from its column's, so the ordinary case stores nothing at all.
03Rates you supply
A rate off a market API is a number the product invented. It moves every second, it is not the rate your bank gave you, and it knows nothing about the spread you actually paid — so anyone invoicing or reporting from it is relying on RowFold's guess. The rates here are the ones you say applied: from your accountant, your bank, your policy. Those are the only kind that can be reconciled against anything.
Declaring GBP→USD also answers USD→GBP, by reciprocal — being asked to enter the same relationship twice would be bookkeeping with no meaning behind it.
04Each record converts at its own date
The rate applied to a record is the latest one effective on or before that record was created — never today's rate applied across the whole total. A deal struck at €5,000 in March keeps reporting the same dollar figure in November instead of drifting with the market while nobody touches it. That is how transaction-date conversion works in accounting, and it is what makes a converted figure a historical fact rather than a live market read.
Nothing is stamped onto the record. The rate is derived from the record's own creation date against the rates you have declared, which has a consequence worth stating plainly: correcting a rate re-states the conversions that depended on it. That is the right behaviour — you corrected it — and it happens in one visible place rather than being frozen invisibly into thousands of rows.
05Rows keep theirs, totals convert
Only aggregates convert. A £250 deal reads £250 in its row, to everybody, forever — restating it as $317 in the row would have the product assert an amount nobody agreed to. But adding £250 to $300 and printing 550 is worse than either, because a total of unlike currencies is not a number at all. So the rows keep their own currency and the total is converted, which is the one place a common currency is genuinely required.
The grid's summary row, reports, dashboard tiles and every computed column go through the same conversion, so none of them can answer the same question differently. Amounts are decimal and numeric(28,12) throughout, and a set of amounts is summed at full precision and rounded once — rounding each line and then adding compounds an error that stays invisible until somebody reconciles against their books, which is exactly when it matters.
06It never guesses
Where no declared rate covers a pair, RowFold produces no number for it. It does not fall back to 1.0, and it does not reach for the newest rate lying around. The lines it could not convert are counted, named and reported next to the figure — “9 of 10 — 1 needs a JPY→USD rate” — rather than dropped, which would quietly total a subset and present it as the answer.
A workspace that records several currencies but has declared no rates at all still reports its cross-currency lines as unconvertible. Going quiet there would be adding pounds to dollars, which is the exact failure this layer exists to prevent.
07Off until you need it
Most workspaces hold one currency, and for them none of this exists. There is a single switch — we record money in more than one currency — and while it is off there is one currency in play, no per-column currency picker appears anywhere, no rate table is drawn, and nothing ever asks you which currency something is in. Turning it back off genuinely turns it off: a per-column or per-record currency stored earlier is ignored rather than left quietly formatting one row differently from its neighbours.
Changing a workspace's currency reinterprets existing amounts; it does not convert them. The confirmation says so in as many words — “No stored amount was changed.” Eighteen currencies are offered in the pickers.
08Rollups, lookups and formulas
A computed column that produces money converts, and it converts the same way everything else does: every contributing record at its own date and its own currency, before anything is added up. A Total orders rollup over a linked table of pounds, euros and dollars is one figure in one currency, not three kinds of number added together.
The converted figure is the value, and what it was converted from is printed beside it — “$1,714.50 (£1,350.00)” — wherever there is one original to name. A rollup whose contributing records span three currencies has no single original, so it says nothing rather than picking one. The same is true of a lookup pulling one record's amount onto another row: you see the converted amount and the figure the record actually carries.
Because the converted figure is the value, it flows on. A formula reading a rollup reads one number in one currency. A formula reaching another table's money across a link converts it first, so {Client.Credit limit} - {Spent} cannot subtract pounds from dollars. Money a formula reads from its own row is deliberately left alone: 20% of a £250 invoice is £50, not a dollar figure, and that is the same rule as rows keeping their own currency.
09Where it does not reach yet
- Where a calculated column really does convert, the grid stops totalling, sorting, filtering and grouping by it. Each of those is computed by the database over every matching row, and the database cannot apply a per-record rate chosen by a per-record date — teaching it to would mean a second implementation of the rate rules, and two implementations of one number is how a footer and the cells above it come to disagree. So the grid refuses rather than answering from the unconverted amounts: the summary cell says “Converted — see a report” and names why, the sort is skipped, and the column is not offered as a grouping. A report's aggregate column across the same link converts and totals correctly, which is where to take that question. Counts and fill percentages are unaffected, because neither reads the amount.
- It is decided by the data, never by the switch. Turning on “we record money in more than one currency” does not mean every money column holds two — most hold one. A calculated column whose amounts are already in the currency it reports in has nothing converted, so it keeps its total, its sort, its filter and its grouping exactly as before. Single-currency workspaces never reach any of this.
Everything else on this page — the grid, its computed columns, reports including aggregates that reach across a link, dashboard tiles, generated PDF documents, public shared links, and per-record currency set from the grid itself — resolves currency from the data.
Related: units of measure · docs · pricing