Journals, Currency and Intercompany
Every journal line stores three amounts: the transaction amount in the currency it happened in, the functional amount in the entity's own currency, and the reporting amount in the group's. All three are computed once, at post time.
Where to find it
Architect Panel → ERP - Finance:
- Exchange Rates — the rates used at post time
- Intercompany Rules — how a transaction between your own companies posts to both
- Allocations — spreading a cost across entities, departments or projects
- Journals — the posted result
Why store all three
The alternative — storing the transaction amount and translating on demand — is simpler and wrong, because the answer changes every time you ask.
Run last year's trial balance today and again next month and the figures differ, because the rate moved. Financial statements that will not reproduce are not financial statements.
Storing all three means a closed period returns the same numbers next year as it did on the day it closed. A rate correction afterwards is a posting, visible as such, rather than a silent restatement of history.
Exchange rates
Maintain rates in Exchange Rates. The rate in force at post time is the one captured, so keeping it current matters more than keeping it precise — a stale rate silently misstates every posting made against it, and nothing will warn you.
Single-currency systems
The three amounts are identical and you can ignore the distinction. It costs nothing to have them, and adding a second currency later becomes a configuration change rather than a re-engineering job.
Intercompany
Intercompany Rules declares how a transaction between two of your companies posts to both, in one operation, each side in its own functional currency.
This is exactly why entity is a separate dimension from tenant: tenant isolation forbids writing across the boundary, and an intercompany journal has to.
Allocations
Allocations spreads a cost across entities, departments or projects on a basis you define — headcount, floor area, revenue share.
Run them before closing, and keep the basis documented. An allocation nobody can explain is one that gets argued about at year end, usually by the department carrying the largest share.
Consolidation
A consolidated view reads every entity and reports in the group currency using the reporting amounts already on each line. Because translation happened at post time, consolidation adds up figures that already exist rather than re-translating history.
Worked example
A UK parent recharges its Irish subsidiary for shared services in euro. The intercompany rule posts a receivable in the parent's books in sterling and a payable in the subsidiary's in euro, both from one entry, each carrying its own functional amount and a common reporting amount. Consolidation eliminates the pair without anyone journaling it out by hand.
Recommendations
- Set both currencies on every entity at creation.
- Keep exchange rates current — put it on somebody's checklist.
- Document the basis of every allocation in its description.
- Run allocations before close, not after.