Live Currency Rates, and How Much to Trust Them
Currency is the only conversion that genuinely needs a network, because rates change and can’t be stored as constants. A calculator fetches a rate on a schedule, caches it, and converts locally against that cached value. Two things decide whether the result is usable: whether the app tells you when the rate refreshed, and whether you understand that a mid-market rate isn’t what your bank will give you.
Key takeaways
- Rate freshness matters more than supported currency count, since a figure of unknown age can’t be verified.
- Calculator rates are typically mid-market, which is a reference point rather than what you’ll be charged.
- Saved documents recompute currency lines on reopening, so a total isn’t frozen at what it showed last month.
- Mixed-currency totals need explicit per-line conversion before a sum will resolve.
- Offline behaviour splits between cached fallback and silent failure, and testing which you have takes thirty seconds.
How a calculator gets a rate
Three steps, none of them complicated. The app calls a rate source on a schedule, stores what comes back, and every conversion you type runs locally against that stored table. Your numbers don’t leave the machine. Only the rate table arrives.
That architecture matters for two reasons. It means conversion is instant rather than waiting on a network round trip, and it means the rate you’re using is as old as the last successful fetch, which could be minutes or days depending on the app and your connectivity.
The rate source is usually a public feed publishing mid-market rates. Which feed, and how often it’s called, is the kind of detail worth checking in an app’s documentation before trusting the output for anything beyond estimates.
Mid-market against what you’ll actually pay
The single most misunderstood thing about calculator currency conversion.
A mid-market rate sits between the buy and sell prices in the interbank market. It’s the reference number quoted in news and search results. Nobody transacting small amounts gets it.
| Rate type | Where you see it | What it’s for |
|---|---|---|
| Mid-market | Calculators, search results, news | Reference and estimation |
| Card network rate | Statement after a foreign purchase | What a card charged you |
| Bank transfer rate | Wire and transfer confirmations | What moving money cost |
| Processor settlement rate | Invoice payouts | What you actually received |
The gap between the first row and the rest is a margin, and it varies by provider. For a travel budget the mid-market figure is fine, since you’re estimating. For an invoice denominated in a foreign currency, the number that matters is your processor’s settlement rate, and a natural language calculator for Mac can’t know it.
Use the calculator to plan and the settlement figure to reconcile. Treating the first as the second is how freelancers end up with a small unexplained shortfall on every foreign payment.
Rate freshness, and why it beats currency count
Comparison content in this category counts supported currencies. That’s the wrong metric for almost everyone, since most people convert between two or three currencies and every serious app covers the majors.
The metric that matters is whether the app shows a timestamp. Knowing a rate was fetched four hours ago is actionable, you decide whether that’s fine for what you’re doing. Knowing nothing means either verifying independently every time or accepting an unquantified risk.
This is testable in thirty seconds. Convert something, look for any indication of when the rate came from, and if there isn’t one, treat every converted figure as an estimate regardless of how precise it looks.
Offline behaviour
Three possible behaviours when the network is unavailable, and they differ materially:
- Cached fallback with visible staleness. The best case. Conversion still works, and the app tells you the rate is old so you can judge.
- Cached fallback, silent. Conversion works and looks identical to a fresh result. This is the dangerous one, since a two-week-old rate presents as current.
- No result. Unhelpful in the moment and at least honest, since you know to look elsewhere rather than trusting something stale.
Test which you have by disconnecting and converting. It matters most exactly when you’re least able to check, on a plane or somewhere with poor signal, which is also when people convert currency most.
Writing currency lines that work
Mixed currencies don’t total. A block containing euros and dollars has no meaningful sum, so the total line returns nothing, and that blank looks like a bug rather than a refusal.
The reliable pattern converts each line explicitly before the total:
hotel = 340 eur in usd
flights = 512 usd
transfers = 90 gbp in usd
meals = 260 eur in usd
sumEvery line now carries dollars, so the total resolves. Skipping the conversions and hoping the app picks a base currency produces either nothing or a figure computed against an assumption you didn’t make.
Currency codes and symbols both parse. $50, 50 usd, and 50 dollars all work in most tools. Symbols bind to the adjacent number, so placement matters slightly, and codes are less ambiguous when a document mixes several currencies.
The saved document problem
Reopen a currency document next month and the converted totals will have moved. This surprises people, and it’s correct behaviour misapplied.
A calculation document stores the calculation, not the result. A line reading 340 eur in usd recomputes against whatever rate the app currently holds, so the number changes as rates change. For a budget you’re planning against, that’s exactly right, since you want current figures.
For a record of what a trip actually cost, it’s wrong. The historical figure is gone, replaced by what that amount would cost today.
The fix is deliberate freezing. Once a cost is historical, replace the conversion line with the converted number as a plain value:
hotel_paid = 371.20
It’s the same discipline as pasting values rather than formulas into a spreadsheet, and forgetting it in Numi means a records document that quietly rewrites history each time you open it.
Precision on money
Two rounding issues that produce reconciliation problems.
Display rounding is the visible one. Calculations carry full precision internally and show a rounded figure, so a total can differ by a cent from adding the displayed line values by hand. The total is more accurate, and for an invoice it’s still wrong in the sense that matters, because the client adds the printed lines.
Conversion rounding is the subtler one. A rate carried to several decimal places produces converted values with long tails, and rounding those early against rounding them at the end gives different totals across many line items. For a four-line travel budget it’s irrelevant. For a fifty-line invoice it isn’t.
Set decimal precision explicitly for anything financial rather than accepting a display default, and where the printed figures must reconcile, round each line deliberately in the line rather than leaving it to the display layer.
A workable process
- Check for a rate timestamp before the first serious use, and calibrate how much to trust output accordingly.
- Convert each foreign line explicitly to one base currency rather than mixing and hoping.
- Put the total below the conversions so every contributing value shares a currency.
- Freeze historical figures as plain numbers once a cost is settled rather than recorded as a live conversion.
- Reconcile against the settlement rate for anything invoiced, treating the calculator figure as the estimate it is.
Steps four and five are where most real errors live. The arithmetic in a calculator notepad app is reliable; the assumptions about which rate applies and whether a figure should move are where money goes missing.
Honest limits
- Rates are mid-market estimates, not what any provider will give you.
- Historical rates aren’t available. You can’t ask what a currency pair was worth on a date last year, which a dedicated finance tool can.
- Less common currencies vary in coverage, and support for thinly traded pairs is inconsistent across apps.
- There’s no fee modelling. Transfer fees, card margins, and processor charges sit outside what any calculator line captures.
- Failure is silent. An unrecognised currency code returns nothing rather than saying it isn’t supported, which reads as a typo you can’t find.
None of that makes the feature unreliable for what it’s for. It means Numi app and its competitors are estimation tools for currency, and anything that has to reconcile against a bank statement needs the bank’s number rather than a reference rate.
Frequently asked questions
How often do exchange rates update in a calculator app?
Refresh cadence varies and typically runs on a schedule measured in hours rather than continuously, since a calculator isn’t a trading tool. What matters more is whether the app displays when the rate was last fetched, because a figure of unknown age can’t be verified.
Does currency conversion work offline?
It depends on caching. An app storing the last fetched rate keeps converting offline, which is fine for estimates as long as staleness is visible. An app fetching on demand returns nothing without a connection, which is unhelpful but honest.
Are calculator app exchange rates accurate enough for invoicing?
They reflect mid-market rates, which isn’t what a bank or processor gives you. For an invoice, the rate that matters is the one applied at settlement, so a calculator figure is a reasonable estimate and a poor substitute.
Why does my saved document show a different total than last month?
Currency lines recompute against current rates when the document reopens. The calculation is preserved, not the figure. Correct for a forward-looking budget, wrong for a historical record, which is why past costs should be stored as plain numbers in Numi mac.
Can you total a list of mixed currencies?
Only after converting each line to one base currency. A total across mixed currencies has no meaningful value, so most apps return nothing rather than guessing. An explicit conversion on each foreign line makes the sum resolve.