Multi-Currency & Financial Consolidation

1. Functional versus Transaction Currency

The two currencies in every foreign transaction

SamvraCore supports multi-currency transactions built on the distinction between functional currency and transaction currency. The functional currency is the currency in which the organisation keeps its books, while the transaction currency is the currency in which a particular business event actually takes place. A sale invoiced in a foreign currency, for example, is recorded in that transaction currency but must also be expressed in the functional currency for the ledger.

This separation is the foundation of the whole multi-currency capability. It allows invoices, payments, and journal entries to be entered in any currency while the accounting system continues to report in one consistent functional currency. Conversion between the two happens using exchange rates (covered in the next chapter).

To keep conversions and balances accurate, SamvraCore performs decimal math throughout using the shopspring/decimal library rather than floating-point arithmetic. This choice matters for financial software because floating-point representation can introduce rounding errors in money calculations; using a decimal type keeps monetary values exact.

In practice this means a business can trade internationally, record each deal in the currency the customer or vendor uses, and still produce clean functional-currency financial statements. The functional-versus-transaction model underpins the gain and loss calculations that arise whenever exchange rates change between the moment a transaction is booked and the moment it is settled or revalued.

2. Managing Exchange Rates

The rate history behind conversions

Exchange Rates are managed on the ExchangeRatesPage. Because conversion between transaction and functional currency depends entirely on the rate used, SamvraCore treats rates as time-sensitive data with an effective-date history rather than a single current value.

The capabilities of exchange rate management include:

• Historical rate tracking — past rates are retained, not overwritten, so transactions can be converted at the rate that applied on their own date.
• Rate effective dates — each rate carries the date from which it applies, letting the system choose the correct rate for any given transaction date.
• Batch rate import — rates can be loaded in bulk rather than entered one at a time, which is useful when maintaining many currency pairs.

Keeping an effective-date history is what makes accurate conversion possible across time. When an invoice is booked, the system looks up the rate in effect on that date; when a payment later settles, a different rate may apply, and the difference is what produces realised gain or loss.

A typical maintenance routine is to import the day's rates in a batch, which adds new effective-dated entries without disturbing historical ones. Downstream features — multi-currency transactions, revaluation, and consolidation currency translation — all draw on this same rate history, so disciplined rate maintenance directly affects the reliability of every foreign-currency figure in the system.

3. Multi-Currency Transactions and Realised Gain or Loss

Trading in foreign currencies

With exchange rates in place, SamvraCore lets users transact in any currency. Invoices, payments, and journal entries can all be recorded in foreign currencies, and the system performs automatic conversion at the transaction rate so that each foreign-currency event also carries its functional-currency equivalent.

A key behaviour here is realised gain or loss calculation on payments. When an invoice is raised in a foreign currency and later paid, the exchange rate at payment time often differs from the rate at invoice time. That movement creates a realised gain or loss, which the system calculates when the payment is recorded. The gain or loss is realised because the transaction has actually settled.

Consider a worked example. A customer is invoiced in a foreign currency, converted at the rate effective on the invoice date. Weeks later the customer pays, but the currency has moved. The functional-currency value actually received differs from the functional-currency value originally booked, and SamvraCore recognises that difference as a realised gain or loss at the moment of payment.

Because conversion is automatic and based on the effective-dated rate history, users can focus on recording the business event in its natural currency while the ERP handles the functional-currency accounting and the gain or loss that arises from exchange movement.

4. Currency Revaluation

Period-end adjustment of unsettled balances

Currency Revaluation, on the CurrencyRevaluationPage, addresses foreign-currency balances that are still open at period end. Unlike realised gain or loss, which arises when a transaction settles, revaluation produces an unrealised gain or loss: the balance has not yet been paid, but its functional-currency value has changed because the exchange rate has moved since it was booked.

The revaluation process computes this unrealised gain or loss against an income or expense account and generates the corresponding journal entry. In other words, revaluation does not merely report a number — it posts an adjusting entry so the financial statements reflect current exchange rates for open foreign-currency items. SamvraCore also keeps a revaluation history, so each period-end run is recorded.

Key points:

• Unrealised gain or loss — recognised on open balances that have not yet settled.
• Posted against an income or expense account — the adjustment lands in the books, not just a report.
• Journal entry generation — the entry is created automatically as part of the run.
• Revaluation history — prior runs are retained for reference and audit.

A typical period-end flow is to ensure exchange rates are current, run revaluation for the open foreign-currency balances, review the computed unrealised gain or loss, and let the system post the adjusting journal entry. This keeps reported balances honest between the dates transactions are booked and the dates they finally settle.

5. Subsidiaries and Consolidation Methods

Defining the group structure

Financial Consolidation begins with Subsidiary Management on the SubsidiariesPage, where the parent-subsidiary company structure is defined. SamvraCore supports hierarchical, nested subsidiary relationships, so a group can be modelled with subsidiaries that themselves own further subsidiaries.

Each subsidiary is configured with several attributes that govern how it rolls up:

• Consolidation method — one of Full, Proportional, Equity, or None, determining how the subsidiary's figures are combined into the group.
• Ownership percentage — the share of the subsidiary held by the parent.
• Functional currency per subsidiary — each entity can keep its books in its own functional currency.
• Intercompany account mapping — accounts designated for elimination entries between group members.

These settings matter because a group is not simply the sum of its members. The consolidation method decides whether a subsidiary is fully combined, combined in proportion, accounted for under the equity approach, or excluded. The ownership percentage feeds minority interest calculations, and the per-subsidiary functional currency means figures must be translated into a common reporting currency during consolidation.

A typical setup is to register each legal entity as a subsidiary, assign its consolidation method and ownership percentage, set its functional currency, and map its intercompany accounts. With the structure defined, the consolidation runs can combine the entities correctly and eliminate internal activity.

6. Intercompany Transactions

Tracking activity within the group

Intercompany Transactions, managed on the IntercompanyPage, capture dealings between subsidiaries so that they can be identified and eliminated during consolidation. Transactions between group members are not genuine income or expense from the group's point of view, so they must be tracked separately.

SamvraCore recognises several intercompany transaction types: Sale, Purchase, Loan, Dividend, Service, Transfer, and Interest. This range lets the group represent the common ways one subsidiary can transact with another, from trading goods and services to lending money and paying dividends.

Each intercompany transaction moves through a status that supports reconciliation:

• Pending — recorded but not yet paired with its counterpart.
• Matched — paired with the corresponding entry on the other subsidiary.
• Eliminated — removed during consolidation so it does not inflate group figures.

Transaction matching drives reconciliation between the two sides, and balance reconciliation reports help confirm that intercompany balances agree. A typical flow is to record the transaction on both entities, match the pair so the status moves from Pending to Matched, and then rely on the consolidation run to eliminate it. This discipline ensures the consolidated statements show only genuine external activity.

7. Consolidation Runs and Consolidated Reports

Producing group financial statements

Consolidation Runs on the ConsolidationRunsPage process the consolidated financial statements, with a run lifecycle and the ability to delete runs. A run automatically generates intercompany elimination entries, performing multi-step elimination that covers both Revenue and Expense and Receivable and Payable pairings, so internal trading and internal balances are removed together.

Because subsidiaries may use different functional currencies, a run applies currency translation with rates appropriate to each figure type.

A run also calculates the Cumulative Translation Adjustment (CTA) that arises from these differing rates, and computes minority or non-controlling interest based on ownership percentages. The run moves through a processing status workflow of Draft, then Processing, then Completed or Failed.

The outputs are Consolidated Reports: a Consolidated Balance Sheet with subsidiary detail, a Consolidated Income Statement, a Consolidated Trial Balance, and an Elimination schedule. Consolidation Settings at the organisation level hold the default intercompany accounts, the reporting currency, and auto-elimination settings. A typical close is to confirm rates and intercompany matching, launch a run, let it eliminate and translate, and then review the consolidated statements once the run reaches Completed.