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 and dashboard tiles all go through the same conversion, so the three cannot 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.
08Where it does not reach yet
- A Rollup, Formula or Lookup that produces money is not converted. These resolve in the derived layer rather than through the money lens, so a Rollup totalling a linked table's amounts adds the stored numbers as they are. Give a Rollup or Formula a display format of Currency and it will print a symbol — but on a workspace holding several currencies, know that the numbers underneath were never put into one. A report's aggregate column across the same link is converted; prefer that where the distinction matters.
Everything else on this page — the grid and its summary row, 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