How foreign currency works when consolidating multiple Xero entities

Income and expenses are translated at the average rate for the period, assets and liabilities at the closing rate on the reporting date, and the difference that falls out goes to a translation reserve in equity. That is the whole method in one sentence, and it is the same under AASB 121 in Australia as under IAS 21 internationally, since the Australian standard is converged with it. The part nobody tells you is that Xero will not do any of this for you, and that the rates you used have to be stored rather than recalculated.

Does Xero translate entities into a group currency?

No. Xero’s multi-currency features work inside a single organisation, not across them. Within one entity, Xero will hold foreign-currency bank accounts, invoices and bills, and revalue those monetary balances into that entity’s own base currency at period end. That is transaction-level foreign currency, and it is a different thing from translating a whole entity into a group presentation currency.

Because each Xero organisation is a separate ledger with its own base currency, there is no native step that takes an entity reporting in New Zealand dollars and expresses it in Australian dollars alongside its sister companies. Users have been raising this on Xero’s product ideas forum for years — the limitation is well known and long-standing. Group translation happens outside Xero, in a spreadsheet or in a reporting layer above it.

This distinction matters when someone tells you Xero “handles multi-currency”. It does, at the level it operates. It does not handle presentation-currency translation for a group, and no setting turns that on.

Which rate applies to which line?

Three rates apply to three different parts of the statements, and mixing them up is the most common consolidation error.

Income and expenses use the average rate for the period. The logic is that revenue and costs accrued throughout the period rather than on one day, so a single spot rate would misstate them. In practice most groups use a monthly average and compound it for quarters and years, which is more accurate than an annual average when rates have moved sharply.

Assets and liabilities use the closing rate at the reporting date, because a balance sheet is a position at a point in time.

Equity is generally carried at the historical rates in effect when each component arose, rather than being retranslated each period. Share capital contributed five years ago stays at the rate that applied then.

Because different rates apply to different parts of the same set of accounts, the translated balance sheet will not balance on its own. That is expected, not an error.

Where does the difference go?

The difference goes to a foreign currency translation reserve within equity, presented through other comprehensive income rather than through profit or loss. It is a balancing figure by construction: it exists precisely because the standard asks you to apply inconsistent rates to related numbers.

The reserve accumulates period after period for as long as the foreign operation is held. On disposal of that operation, the accumulated amount relating to it is reclassified out of equity and into profit or loss. That reclassification is easy to forget, and it is the point at which a translation reserve that nobody looked at for six years suddenly appears in the income statement.

If your consolidation does not produce a translation reserve, it is not translating properly — it is converting everything at one rate, which will balance neatly and be wrong.

Why do you need to store the rates you used?

You need to store them because a restatement must reproduce, and a recalculated rate will not. If your group’s board pack for the September quarter is questioned in February, the only defensible answer is to reproduce the exact numbers that were published. That requires the rates that were applied at the time, held against the period they belong to.

Rates that are fetched live at report-run time cannot do this. Re-running September’s consolidation in February with February’s data will produce a different September, and you will spend a day working out whether the movement is real or a rate artefact. It is also the single hardest failure to detect, because nothing errors — the report just quietly disagrees with the one you circulated.

Storing rates per period, per currency, per rate type solves it. It also gives you an auditable record of which rate source you used, which auditors increasingly ask for.

What happens when a rate is missing?

An entity with no rate for a period must not be allowed to silently contribute nothing to the group total. This is worth stating explicitly because the naive implementation — treat a missing rate as zero and carry on — produces a consolidated total that is simply too low, with no error, no warning, and nothing visibly wrong on the page.

It is the same principle that governs unmapped accounts in chart of accounts mapping: a gap in the inputs should understate visibly rather than silently. The correct behaviour is to exclude the unrated entity from the total and report it separately, so that a reader sees a group figure covering fourteen of fifteen entities rather than a complete-looking figure that is quietly missing one.

Check this in whatever tool or spreadsheet you use. Add a currency, omit its rate, and see whether the total drops without complaint. If it does, you have a silent understatement waiting for the month somebody forgets.

Which rate source should you use?

Use one source, apply it consistently, and document the choice. The standard does not mandate a particular provider. In Australia most groups use the Reserve Bank of Australia’s published rates or their primary bank’s rates; groups reporting into a European or UK parent often use the relevant central bank series.

What matters more than the choice is the consistency. Switching sources mid-year introduces movements that look like trading performance and are not, and switching without documenting it will cost you time at audit. If you do change source, change it at a financial year boundary and note it.

For the average rate, decide whether you are using a simple mean of daily rates, a mean of month-end rates, or a volume-weighted average, and be aware that large listed groups often weight by transaction volume. For a group of three to thirty entities, a monthly simple average is generally proportionate and defensible.

What does this not solve?

Translation does not eliminate intercompany balances, and the two problems interact badly. An intercompany loan between two entities in different currencies will not net to zero once translated, because each side is translated at rates applied to its own functional currency. The residual is a genuine foreign exchange effect, not a mapping error, and it has to be dealt with as part of eliminations rather than translation.

Translation also does not tell you whether an entity’s functional currency has been correctly identified in the first place. Functional currency is a judgement about the primary economic environment in which an entity operates, not simply the currency it invoices in, and an entity billing in US dollars from an Australian cost base may well have an Australian dollar functional currency. Getting that wrong makes every subsequent translation wrong in a way no reconciliation will surface.

If the numbers still will not tie after translation, the cause is more often a mapping gap or an entity included for the wrong part of the period than a rate problem. Both are covered in the companion guides on chart of accounts mapping and mid-year entity changes.