Journals, Currency and Consolidation
Every journal line stores three amounts, not one:
- The transaction amount — the currency the transaction actually happened in.
- The functional amount — the entity's own currency, the one that company keeps its books in.
- The reporting amount — the group's currency, the one consolidated statements are produced in.
All three are computed once, at the moment of posting, using the rates applicable then.
Why store all three
The tempting alternative is to store the transaction amount and translate on demand. It is simpler, and it is wrong, because the answer changes every time you ask. Run last year's trial balance today and again next month and you get different figures, because the rate moved. Financial statements that will not reproduce are not financial statements.
Storing all three at post time means a closed period returns the same numbers next year as it did on the day it closed. A rate correction after the fact is a posting, visible as such, rather than a silent restatement of history.
Single-currency systems
If you operate in one currency the three amounts are identical and you can largely ignore the distinction. It costs nothing to have them, and it means adding a second currency later is a configuration change rather than a re-engineering job.
Intercompany
A transaction between two of your own companies posts to both, in one operation, with each side in its own functional currency. This is precisely why entity is a separate dimension from tenant — tenant isolation forbids writing across the boundary, and an intercompany journal has to.
Consolidation
A consolidated view reads every entity at once and reports in the group currency, using the reporting amounts already stored on each line. Because the translation happened at post time, consolidation is a matter of adding up figures that already exist rather than re-translating history.
Practical advice
Set each entity's functional and reporting currency when you create it, before anything posts. Changing a functional currency after postings exist means every stored amount was computed against the wrong basis, and there is no clean automatic fix.