Speak Money in Any Currency: Multi-Currency & FX Revaluation Done Right

Plenty of accounting tools claim to "support multiple currencies." Open one up and the support turns out to be a currency dropdown on the invoice form. That works right up until you try to close a period, run a balance sheet, or explain to an auditor why two reports that should agree don't. LedgerQ treats multi-currency as what it actually is — an architecture decision, not a form field — with full support for international operations built into the ledger itself.

In summary: Real multi-currency stores every foreign transaction with two amounts — the transaction currency the document is denominated in, and the functional (base) currency your books are kept in — captured at the right rate. LedgerQ records both on every foreign document, then at period-end revalues open foreign-currency balances and posts the unrealized FX gain or loss straight to the general ledger. Because the functional amount is always present and revaluation is posted, every base-currency report is correct by construction.

Why does "just add a currency field" break?

Imagine you keep your books in Philippine pesos (₱) and you issue an invoice to a customer in US dollars. The naïve approach stores one number — $1,000 — and tags it "USD." It feels done. It isn't.

The moment you ask a real question, the cracks show. What's this invoice worth on the balance sheet, in pesos? At which exchange rate — the day you issued it, the day you're reporting, or the day it gets paid? When you sum all your receivables for a report, you can't add ₱ and $ and €; they're different units. And when the dollar moves before the customer pays, the peso value of that receivable changes even though nobody touched the invoice. A single currency-tagged number has no answer to any of this. You end up bolting on spreadsheets, and the spreadsheets become the real ledger.

What's the difference between transaction currency and functional currency?

The fix is a distinction every serious accounting system makes, and most SMB tools quietly skip:

• Transaction currency is what a document is denominated in — the USD on that invoice. It's what the customer agreed to, what's printed on the page, what they'll pay.
• Functional (or base) currency is what your books are kept in — the ₱ your financial statements report in.

LedgerQ stores both, together, on every foreign transaction: the original transaction amount and its translated functional amount, captured at the right rate. The $1,000 invoice is recorded as $1,000 USD and as its peso equivalent at the issue-date rate. Nothing is thrown away and nothing is guessed at later.

That single design choice is what separates real multi-currency from bolted-on currency fields. Because the functional amount is always present, every report in your base currency is correct by construction — there's nothing to recompute, no rate to re-guess. And because the transaction amount is preserved, the document still shows the customer exactly what they owe, in the currency they owe it. You don't have to pick between an accurate ledger and an honest invoice. You get both.

Everything else builds on this. Multi-currency invoicing lets you issue and receive invoices in any currency while your books never leave their functional currency. Behind it sits exchange-rate management — manual entry, daily rates, and automatic updates — with a comprehensive currency master and rate endpoints, so the right rate is always on hand when a transaction is recorded. It all posts through the same double-entry general ledger as everything else, which is why the correctness holds all the way to the statements.

What is period-end FX revaluation, with a worked example?

Here's the part the dropdown approach can't reach. Your USD receivable sits on the books at the peso value it had the day you issued it. But exchange rates move. By month-end, that same $1,000 is worth a different number of pesos — even though the invoice is untouched and the customer hasn't paid.

Walk it through with illustrative rates (not real market data):

• You issue a $1,000 invoice when the rate is ₱56.00 / $1. It's booked as a receivable of ₱56,000 in your functional currency.
• At month-end the rate has moved to ₱57.50 / $1. That same open $1,000 receivable is now worth ₱57,500.
• The difference — ₱1,500 — is an unrealized FX gain. The peso value of an asset you already hold went up purely because the currency moved.

That ₱1,500 is a real economic event: your peso-denominated net worth changed because of currency movement, and your financial statements have to say so. Pretending it didn't happen until the cash lands would overstate or understate your position for every period in between.

LedgerQ handles this with currency revaluation: at period-end it calculates the unrealized gain or loss on open foreign-currency balances — the ₱1,500 above — and posts it automatically to the general ledger, adjusting the peso carrying value of the receivable against an FX gain/loss account. "Unrealized" because the cash hasn't settled yet — but it still belongs on the books, and the entry still has to keep the ledger balanced. This is exactly why the gain or loss must post to the GL rather than live in a side report: an entry that adjusts the peso value of an asset without a matching, posted offset would break the fundamental accounting equation. When the customer finally pays, any further movement between month-end and settlement becomes a realized gain or loss — and because the earlier revaluation already posted, there's no double-count. Revaluation isn't cosmetic; it's what keeps the books true between issue and settlement — and because it posts automatically, it's one less manual step in the period-end close.

How do you see FX risk before it hits the books?

Alongside revaluation, FX exposure tracking lets you monitor and analyze currency risk directly — so the movement that drives those revaluation entries is something you can see coming, not just something you discover at close. Knowing you hold a large open USD receivable before the dollar moves is what turns FX from a month-end surprise into a managed position.

Can LedgerQ report in more than one currency at once?

Some businesses need to report in more than one currency at the same time — local management in the functional currency, a parent or regulator in another. LedgerQ supports parallel ledgers: it maintains the local (functional) and a reporting currency simultaneously, rather than forcing a one-off conversion at report time. Both views stay live and consistent.

This extends naturally into consolidation, where currency translation uses both the current-rate and temporal methods, with translation adjustments captured as part of the process — the established techniques for rolling subsidiaries in different currencies up into one set of group statements. A group with a PH operating entity and, say, a Singapore subsidiary can translate each on the appropriate basis and consolidate without a manual conversion pass.

Why does getting this right protect every report?

Currency is deceptively easy to fake and genuinely hard to get right. A dropdown looks like support; an architecture that stores transaction and functional amounts together, revalues open balances into the GL at period-end, and maintains parallel ledgers is support. The difference doesn't show on a single invoice — it shows when every report has to agree.

Because the functional amount is always recorded, your balance sheet foots. Because revaluation posts to the GL, your income statement reflects FX movement in the period it happened. Because the transaction currency is preserved, your AR aging still speaks to each customer in their own currency. Get the foundation right and every report downstream inherits that correctness for free. Get it wrong, and no amount of careful reporting can put the missing number back. That's the whole reason LedgerQ builds multi-currency into the ledger instead of onto the form.

Frequently asked questions

What's the difference between transaction currency and functional currency? Transaction currency is what a document is denominated in — the USD a customer agreed to pay. Functional (base) currency is what your books are kept and reported in — the ₱ on your financial statements. LedgerQ stores both on every foreign transaction, so the invoice stays honest to the customer while the ledger stays correct in your base currency.

What is FX revaluation and why does it post to the GL? Revaluation recalculates the base-currency value of open foreign-currency balances at period-end and books the unrealized gain or loss. It posts to the general ledger — not a side report — because adjusting an asset's carrying value needs a balanced offset; otherwise the accounting equation breaks. LedgerQ posts it automatically to an FX gain/loss account.

What's the difference between an unrealized and a realized FX gain? Unrealized gains and losses arise on balances that are still open — the currency moved but the cash hasn't settled. Realized gains and losses crystallize when the payment actually lands. Because LedgerQ posts the unrealized revaluation at period-end, the later realized movement is measured from there, so there's no double-count.

Can LedgerQ report in two currencies at the same time? Yes. Parallel ledgers maintain your functional currency and a reporting currency simultaneously, kept live rather than converted once at report time — useful when local management reports in one currency and a parent or regulator needs another.

How does multi-currency work in consolidation? Consolidation translates subsidiaries using the current-rate and temporal methods, capturing translation adjustments as part of the process. That lets a group roll up entities kept in different currencies into one set of group statements without a manual conversion pass.