A property company that owns buildings in more than one country is really running several businesses in several currencies at once. Rent may be billed in euros, a construction contractor may invoice in US dollars, the mortgage may be in pounds, and the investors may expect a single set of financial statements in Canadian or US dollars. Every one of those amounts moves a little every day as exchange rates change.

Multi-currency accounting is the discipline that keeps those moving parts honest. Done well, it gives local teams accurate books in their own currency and gives head office a consolidated picture that auditors, lenders, and investors can rely on. Done poorly, it produces unexplained variances, manual spreadsheet adjustments, and a month-end close that never quite ties out.

This guide explains the key terms, the accounting rules behind them (IFRS and US GAAP), how global property owners structure the process in practice, and how Yardi Voyager supports each step.

In short:

• Multi-currency accounting records, remeasures, and reports transactions that occur in more than one currency.

• Every legal entity has a functional currency, the currency of its primary economic environment, which drives how it is accounted for.

• Revaluation updates open foreign-currency balances to today's rate and produces unrealized gains or losses in profit or loss.

• Translation converts a whole set of books into a reporting currency for consolidation; the difference goes to the cumulative translation adjustment (CTA) in equity, not profit or loss.

• The governing standards are IAS 21 under IFRS and ASC 830 under US GAAP.

• In Yardi Voyager, each legal entity has a base currency; transactions can be entered in other currencies, and revaluation and translation run as rule-driven, schedulable processes.

Multi-currency accounting is the process of recording transactions in the currency in which they occur, converting them into the currency in which each entity keeps its books, and then presenting the group as a whole in a single reporting currency. It answers three separate questions, and most problems start when they get blurred together.

1. What currency did this transaction happen in? A tenant in Frankfurt paying rent in euros is a euro transaction, regardless of where the landlord is headquartered.

2. What currency does this entity measure itself in? A German property company normally lives in euros, so the rent lands in the ledger as euros. A Canadian entity paying a US contractor records a US-dollar invoice converted into Canadian dollars.

3. What currency does the group report in? A North American fund may present everything in US dollars, so the euro and Canadian-dollar books must be converted again for consolidation.

Each conversion uses a different exchange rate and produces a different kind of gain or loss, understanding which is which underpins everything that follows.

The vocabulary is where most confusion begins, because accounting standards and software vendors sometimes use different words for the same idea. Finance teams need to share these terms before configuring any system.

Foreign currency accounting is governed by IAS 21, The Effects of Changes in Foreign Exchange Rates under IFRS, and by ASC 830, Foreign Currency Matters under US GAAP. The two standards reach broadly similar answers and follow the same three-step logic.

Everything starts here. Both standards ask which currency mainly influences the entity's prices and costs, and which currency generates its financing and operating cash flows. For a property-owning entity, the main indicators are usually:

• the currency in which leases are priced, and rent is collected;

• the currency of the local market whose conditions set rental rates and property values;

• the currency of operating costs, staff, property taxes and construction contracts;

• the currency in which debt is raised, and cash is retained.

The answer is a judgment; document it, and change it only when the underlying economics change. Choosing the wrong functional currency affects every downstream number, so the controller and auditors should decide this before anyone configures a system.

Step 2: Record foreign-currency transactions and remeasure monetary items

A transaction in a foreign currency is recorded at the spot rate on the transaction date (an average rate is acceptable when rates are stable). At each reporting date:

• monetary items (cash, receivables, payables, loans) are restated at the closing rate, with the difference recognized in profit or loss;

• non-monetary items carried at historical cost (such as buildings under the cost model) stay at the historical rate;

• non-monetary items carried at fair value (such as investment property under the IAS 40 fair value model) use the rate on the date fair value was measured.

US GAAP uses the word remeasurement for a related situation: when an entity keeps its books in a currency that is not its functional currency. In that case, the ledger must be remeasured into the functional currency using historical rates for non-monetary items and current rates for monetary items, and the result goes through net income, with no CTA. This is common for Canadian or European entities that report into a US parent and are judged to have a USD functional currency while keeping local-currency books for tax.

Step 3: Translate into the reporting currency

To consolidate a foreign operation, its functional-currency statements are translated into the group's reporting currency:

• assets and liabilities at the closing rate;

• income and expenses at the transaction-date rates, or an average rate as a proxy;

• equity items at historical rates.

Because the balance sheet and income statement use different rates, the books will not balance after conversion. The difference is the cumulative translation adjustment, recorded in other comprehensive income and accumulated in equity. It is reclassified to profit or loss only when the foreign operation is disposed of.

Two further points matter for property groups. Long-term intercompany loans that are not expected to be repaid can form part of the parent's net investment in a foreign operation, so their FX differences go to equity on consolidation rather than profit or loss. And entities operating in hyperinflationary economies (IAS 29 under IFRS, or the highly inflationary rules in ASC 830) need special treatment altogether.

Global owners, REITs, funds and developers tend to converge on the same operating model: keep each entity's books in its own currency, push foreign-currency activity through controlled processes, and convert to the reporting currency as late and as mechanically as possible.

A typical month-end sequence

1.Load exchange rates for every currency pair and rate type (daily spot, month-end, monthly average) from an approved source, ideally automatically.

2.Post foreign-currency activity in each entity: tenant charges and receipts, vendor invoices and payments, debt draws and interest, each converted at the transaction-date rate.

3.Settle and book realized gains and losses on anything paid or collected during the month.

4.Revalue open monetary balances in each entity at the month-end rate, booking unrealized gains and losses.

5.Reconcile intercompany balances in both currencies so each side agrees before translation.

6.Translate each functional-currency ledger into the reporting currency using translation rules, generating the CTA.

7.Consolidate and eliminate intercompany balances and investments in subsidiaries, then roll up to group statements.

8.Review and lock the period, with documented rate sources and variance explanations for auditors.

A worked example

A Canadian-dollar property books a US$100,000 invoice from a contractor when USD/CAD is 1.36, so the payable is recorded at C$136,000. At month-end, the invoice is still unpaid, and the rate is 1.38. Revaluation restates the payable to C$138,000 and books a C$2,000 unrealized FX loss. Next month, the invoice is paid at 1.37, so the final cost is C$137,000, and the loss settles at a realized C$1,000.

Now the US parent consolidates. The Canadian entity's balance sheet is translated to USD at the month-end rate and its income statement at the monthly average. The building, the payable, and the rent all convert at different rates, and the leftover difference lands in CTA. The same US$100,000 invoice has now touched three different exchange rates and two different kinds of FX results, which is why clear rules and a reliable system matter.

Property businesses face currency issues that a typical trading company does not, because their assets are large, long-lived, and financed over many years.

• Leases priced in a foreign currency. Some commercial and hospitality leases are denominated in USD or EUR even where the local currency differs. Each billing creates a foreign currency receivable to revalue, and some arrangements raise embedded-derivative questions under IFRS 9 or ASC 815.

• Development and capital projects. Equipment, steel, and specialist contractors are often priced in another currency. Capitalized costs use the rate at the date each cost is incurred, so the project ledger needs transaction-level rate history, not just month-end balances.

• Debt in a different currency. Mortgages and construction loans are monetary items, so a large foreign-currency loan can swing reported profit every month. Many groups hedge this exposure, which brings hedge accounting into scope.

• Investment property at fair value. Under the IAS 40 fair value model, valuations are non-monetary and use the valuation-date rate, which must be kept separate from operating FX movements.

• Funds and multi-layer ownership. Investors may commit capital in one currency, invest through holding entities in another, and own assets in a third. Each layer needs its own functional-currency analysis.

• Tax and statutory reporting. Local regulators usually want books in local currency, while group reporting wants another. Keeping both reliable without double entry is a core system requirement.

• Indirect taxes. Sales taxes such as GST, QST, or VAT on foreign-currency invoices must still be reported in local currency at the rates the tax authority prescribes, which can differ from the accounting rate.

Yardi Voyager handles multi-currency through its international currency functionality, which maps closely to the accounting steps above. The building blocks are configured once and then run as part of the normal close.

• Base currency by legal entity. Each legal entity is assigned a base currency, and every property linked to it inherits that setting. Different entities in the same database can use different base currencies.

• Rate providers and rate types. Teams define where rates come from and which types they need, typically a spot rate for balance sheet use and an average rate for the income statement.

• Exchange rate tables. Rates are stored per currency pair, provider, type, and date. They can be keyed manually or loaded automatically through ETL and Task Runner, which is the better practice for audit trail and consistency.

• Additional GL books. Translation results are written to a separate translated book, so the local-currency books stay untouched.

Non-base currency transactions

Voyager lets users create lease charges, ad hoc charges, receipts, payables, payments, and journal entries in a currency other than the entity's base currency. The system looks up the rate, shows both the transaction-currency and base-currency amounts, and records the base-currency value in the ledger. When a foreign currency item is settled at a different rate, Voyager books the realized currency gain or loss.

Currency revaluation

Revaluation calculates unrealized gains and losses on open non-base currency items and posts them as journal entries, normally at month-end, though it can run daily. Revaluation rules can be set to reverse the next month automatically or to calculate the change from the prior period without reversing. Getting the account scope right is essential, since every monetary account exposed to foreign currency should be covered.

Currency translation

Translation converts a base-currency book into a reporting-currency book using translation rules. Each rule covers a range of GL accounts and assigns a rate type so that balance sheet accounts can use a closing rate, income statement accounts an average rate, and selected accounts a historical rate. The Historical Weighted Average (HWA) option translates selected balance sheet accounts transaction by transaction at the rate in effect on each transaction date, which is useful for equity and certain long-lived assets. You can rerun translation within a month, with each run backing out the prior result.

Automation, consolidation and reporting

Task Runner can schedule rate loads, revaluation, and translation so they run each period consistently. Translated books then feed Voyager's consolidation and intercompany tools, where account trees, consolidation rules, and elimination rules roll entities into group-level statements.

In practice, the software is only as good as its design. The same Voyager functions can produce clean, auditable results or a stream of manual adjustments, depending on how functional currency, segments, intercompany accounts, rule ranges and close sequencing are set up.

Across multi-currency property portfolios, the same lessons come up repeatedly. Most issues are not software defects but gaps between accounting policy and system configuration.

• Decide functional currency before configuring anything. If an entity's ledger currency differs from its functional currency, the setup must remeasure correctly (historical rates for non-monetary items, results in net income), not simply translate. Treating a remeasurement case as a translation case is one of the most expensive mistakes to unwind.

• Revalue every monetary account, not just bank and receivables. Payables, accruals, deposits, intercompany balances, and loans in foreign currency all carry exposure. A revaluation scope narrower than the accounting definition leaves FX misstated.

• Govern exchange rates like master data. Use one approved source, load rates automatically, restrict manual overrides, and keep a record of which rate was used for each run.

• Design intercompany for two currencies from day one. Each side should agree in its own currency and in the reporting currency, with clear rules for which balances form part of a net investment.

• Fix the close sequence and stick to it. Revalue before translating, translate after the period's activity is complete, and define when reruns are allowed. Running steps out of order is a common source of unexplained variances.

• Plan reporting detail early. Translated books may summarize activity rather than reproduce every transaction line, so decide up front what drill-down analysts and auditors need in the reporting currency.

• Test with real scenarios. Reconcile translated trial balances, CTA and FX gain/loss accounts to an independent calculation for a few entities before go-live, and again after any configuration change.

• Document for auditors and SOX. Functional currency memos, rate sources, rule definitions, and reconciliation evidence turn a working process into a controlled one.

The core challenge hasn't changed in decades: matching transactions from your ERP system to bank statements remains a tedious, line-by-line exercise. Finance teams spend countless hours comparing amounts, dates, and descriptions, often across hundreds or thousands of transactions per month. This manual matching isn't just time-consuming; it's cognitively taxing work that can lead to fatigue-induced errors, especially during high-volume periods such as rent collection cycles.

The problem intensifies with scale. Organizations managing multiple properties across multiple bank accounts face exponential complexity. Each account requires its own reconciliation workflow, which multiplies manual effort and creates inconsistent processes across the portfolio.

Modern reconciliation workflows often require toggling between your ERP system, online banking portals, spreadsheets, and email. When a transaction appears on the bank statement but not in your system, switch contexts to create the missing entry, then switch back to continue matching. This constant context-switching fragments attention, introduces delays, and dramatically increases the likelihood of errors or omissions.

For organizations using property management platforms such as Yardi or MRI Software, this often means exporting data, manipulating it externally, and re-importing a workflow that undermines the purpose of an integrated system.

Perhaps the most damaging consequence of manual reconciliation is the lag it creates in cash visibility. When reconciliation occurs only monthly or even quarterly organizations operate with a fundamentally outdated view of their cash position. Treasury decisions get made on stale data. Cash flow forecasting becomes guesswork. And unexpected shortfalls or surpluses only surface weeks after they occur.

In today's interest rate environment, where idle cash has real opportunity cost and credit facilities carry meaningful costs, delayed cash visibility directly impacts the bottom line. Organizations that reconcile in real-time or daily gain a significant operational advantage.

When questions arise about specific transactions, and they always do, the investigation often happens through email chains, phone calls, or hallway conversations. This creates two problems. First, the back-and-forth extends resolution time, leaving transactions in limbo. Second, none of this context gets captured in the system of record, creating audit gaps that become problematic during reviews or when team members change.

Auditors increasingly expect transaction-level documentation and clear decision trails. When your reconciliation notes live in someone's inbox rather than attached to the transaction itself, you're creating compliance risk and adding audit preparation burden.

Standard matching handles the simple cases. But real estate finance involves complex scenarios that standard tools struggle with, including multi-line journal entries, security deposit allocations, job cost distributions, handling overpayments, and non-tenant receipts. Each exception requires manual intervention, slowing the entire process and demanding specialized knowledge that may reside with only one or two team members.

Error handling compounds the challenge. Reversals, adjustments, and suspense account management require careful attention and proper documentation. Without streamlined workflows for these edge cases, they become bottlenecks that delay close cycles and increase risk.

The good news is that these challenges are solvable. Modern approaches to bank reconciliation leverage automation for routine matching, intelligent algorithms that learn from historical patterns, and direct integration with banking systems to eliminate manual data handling. Organizations that adopt these approaches report dramatically reduced reconciliation times, improved accuracy, and, critically, the ability to reconcile daily rather than monthly.

The key is to find solutions that integrate seamlessly with your existing ERP ecosystem, whether it's Yardi, MRI, or other platforms. Bolt-on tools that create yet another silo only shift the problem rather than solving it.

If your organization is still wrestling with these reconciliation challenges, you're not alone but you don't have to stay stuck. Understanding your current pain points, quantifying the time and cost involved, and exploring modern alternatives is the first step toward transforming this traditionally painful process into a streamlined, value-adding operation.

At Assetsoft, we've spent 25 years helping real estate organizations optimize their technology and processes. We understand these challenges intimately and we know how to solve them. If you're ready to explore what's possible, we'd welcome a conversation about your specific situation.