Why a multicurrency account needs more than one total balance
Use dollars, euros and a CNY valuation to distinguish native balances, holds, available funds, conversion entries and reconciliation.
If an account holds 100 dollars and 50 euros, does it have “150”? You can write the number, but it has no common unit and cannot tell you which payment the account can complete.
A multicurrency product looks like a balance with a few extra flags. The harder work is explaining what is held, what is available and what the holdings are worth in another currency. These examples describe a hypothetical prefunded account without credit or overdrafts.
Three questions deserve three answers
The posted balance records funds on the account. Holds identify funds temporarily unavailable. The available balance describes what can fund a new operation now.
| Currency | Posted balance | Held | Available |
|---|---|---|---|
| USD | 100.00 | 30.00 | 70.00 |
| EUR | 50.00 | 0.00 | 50.00 |
In this simplified model, available funds equal the posted balance minus holds. A product with pending credits, reserves, credit facilities or other restrictions needs its own explicit definitions.
Someone paying an 80 USD order may assume a displayed “100 USD balance” is enough. “70 available, 30 held” explains the current situation.
Valuation is useful, but native balances remain essential
Assume 1 USD = 7.20 CNY and 1 EUR = 8.00 CNY. Posted funds have an estimated total value of 1,120 CNY; available funds have an estimated value of 904 CNY. These are hypothetical rates, with conversion fees ignored.
Both numbers describe scale. Neither means the account can make a payment of the same value in any currency. Automatic conversion, routes, minimums, fees and limits depend on the account’s actual capabilities.
Keep each native-currency balance and label the valuation currency, rate time and included funds. A “total assets” display must not quietly imply that held funds are available to spend.
Every amount needs its unit
A reliable money value includes at least an amount and currency. Do not infer the currency from the current screen selection or drop it from a query or callback.
Two decimal places are not universal. JPY is commonly represented with zero and USD with two, but API minor-unit conventions and exceptions still need checking. Rates, fees and display values may require different precision.
Use exact decimals or integer minor units under explicit currency rules, rather than accumulating money with binary floating point. Specify where rounding happens and how any remainder is allocated so the calculation is reproducible.
Conversion is a linked set of entries
Suppose a conversion decreases funds by 100 USD and increases funds by 92 EUR. It is more than updating one balance field, and adding −100 to +92 cannot establish whether the entries balance.
Record each currency’s movement and link the two sides through the conversion order, quote and appropriate clearing or bridge accounts. Each currency must remain reconcilable under the ledger model. Fees have their own currencies and entries; business valuation and functional-currency accounting require separate rules.
If one side is confirmed while the other remains unknown, preserve the corresponding pending state. Do not increase the second currency’s available balance simply to make the screen appear complete. Correct entries through linked reversals while retaining the original record.
Reconciliation returns to each individual currency
The original transaction, authorization hold, final posting, fee and refund can be separate records with different times. Match currency, account and provider references before explaining a cross-currency relationship.
Refunds link to the original transaction; partial refunds need cumulative limits; duplicate notifications must be processed once. Preserve unknown external outcomes until queries and reports resolve them. A green check on a screen cannot establish a ledger posting.
An unchanged total valuation does not prove every currency reconciles. Missing dollars and excess euros might cancel at a particular rate while remaining two real accounting errors.
Keep the interface simple and the explanation complete
I would highlight available funds by currency, holds, pending items and a timestamped valuation. Transaction, fee and conversion records can expand beneath them.
This needs clear data layers: provider results, the internal funds and state model, public APIs and the view. Preserve native amounts, string identifiers and correlation references instead of collapsing everything into one number too early.
Read exchange rates and actual cost next, or return to authorization decisions to see how these balances participate in a spending decision.