Treasury / Intercompany is where ERP discipline either begins or breaks.
Intercompany Cash Transfer and Settlement looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.
The expected business outcome is specific: Intercompany cash movements are recorded accurately in both entity GLs with automatic FX handling, zero out-of-balance risk, and clean consolidation elimination.
The control flow a finance team actually needs.
Step 1
Create Paired Intercompany Journal...
Step 2
Enforce That Due-From And Due-To...
Step 3
Apply FX Translation Using The Spot...
Step 4
Post FX Translation Gain/Loss To...
Step 5
Flag Intercompany Balances For...
The ERP surface involved.
Module
Treasury / Intercompany
Actors
Treasury Manager, Intercompany Settlement Engine, Multiple Entity GLs
Tier
Tier 2
Finance area
Cash Management, Treasury & Banking
Region lens
US and UK finance teams
Publication date
March 29, 2026
Create paired intercompany journal entries in both entity GLs in a single atomic transaction; enforce that due-from and due-to balances net to zero at the intercompany pair level; apply FX translation using the spot rate at transfer date (rate stored as NUMERIC(20,10) string on wire); post FX translation gain/loss to configurable CTA or realized FX account; flag intercompany balances for consolidation elimination per entity pair; prevent circular intercompany transfers without explicit override; support future-dated value-date settlement; generate intercompany netting report showing gross and net positions by entity pair.
US and UK teams have different compliance hooks, but the same control problem.
US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.
The control matrix.
| Control area | Requirement | Acceptance proof |
|---|---|---|
| Control 1 | Create paired intercompany journal entries in both entity GLs in a single atomic transaction | Given entity A and entity B exist in different functional currencies |
| Control 2 | enforce that due-from and due-to balances net to zero at the intercompany pair level | when an intercompany cash transfer is initiated |
| Control 3 | apply FX translation using the spot rate at transfer date (rate stored as NUMERIC(20,10) string on wire | then paired GL journal entries (credit entity A cash / debit entity A due-from |
| Control 4 | post FX translation gain/loss to configurable CTA or realized FX account | debit entity B cash / credit entity B due-to) are posted atomically in a single transaction, FX translation gain/loss is posted to CTA if currencies differ, and due-from + due-to net to zero at the entity pair level |
| Control 5 | flag intercompany balances for consolidation elimination per entity pair | negative) when the atomic transaction fails mid-posting then both sides roll back and no partial entries are persisted. |
| Control 6 | prevent circular intercompany transfers without explicit override | Intercompany cash movements are recorded accurately in both entity GLs with automatic FX handling, zero out-of-balance risk, and clean consolidation elimination. |
Audit evidence is a chain, not a folder.
| Evidence layer | What should be preserved |
|---|---|
| Business event | The treasury manager initiates a transfer from entity A's operating account to entity B's account to fund a subsidiary payroll. The system creates an intercompany transfer record linking both entities. On the sending side it posts a credit to entity A's cash account and a debit to entity A's intercompany receivable (due-from entity B). On the receiving side it posts a debit to entity B's cash account and a credit to entity B's intercompany payable (due-to entity A). FX translation is applied if the entities operate in different functional currencies, with the gain/loss posted to the CTA account. Both GLs balance independently. The intercompany balances are flagged for elimination in the consolidation process. |
| Control rules | Create paired intercompany journal entries in both entity GLs in a single atomic transaction; enforce that due-from and due-to balances net to zero at the intercompany pair level; apply FX translation using the spot rate at transfer date (rate stored as NUMERIC(20,10) string on wire); post FX translation gain/loss to configurable CTA or realized FX account; flag intercompany balances for consolidation elimination per entity pair; prevent circular intercompany transfers without explicit override; support future-dated value-date settlement; generate intercompany netting report showing gross and net positions by entity pair. |
| Acceptance proof | Given entity A and entity B exist in different functional currencies; when an intercompany cash transfer is initiated; then paired GL journal entries (credit entity A cash / debit entity A due-from; debit entity B cash / credit entity B due-to) are posted atomically in a single transaction, FX translation gain/loss is posted to CTA if currencies differ, and due-from + due-to net to zero at the entity pair level; (negative) when the atomic transaction fails mid-posting then both sides roll back and no partial entries are persisted. |
| Data record | |
| System event | |
| Lifecycle state | |
The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.
Implementation contracts.
Reference data model
`intercompany_transfer` { transfer_id: string, payer_entity_id: string, payee_entity_id: string, amount_minor: int64, currency_code: char(3), value_date: date, fx_rate: string, fx_gain_loss_minor: int64, status: enum(DRAFT, POSTED, CONFIRMED), external_id: string }; linked to two `journal_entry` records (one per entity GL); (reference, product may differ).API and events
`POST /v1/intercompany/transfers` { payer_entity_id, payee_entity_id, amount_minor, currency_code, value_date, memo, external_id } -> 201 { transfer_id, status: "DRAFT" }; `POST /v1/intercompany/transfers/{id}/post` -> 200 { status: "POSTED", journal_entry_ids: [...] }; emits `intercompany.transfer_posted` event; idempotent via external_id.State transitions
`DRAFT -> POSTED -> CONFIRMED`; terminal `VOID`; guard: POSTED requires single atomic DB transaction across both entity GLs; circular transfer blocked without explicit override.Common implementation traps.
Treating the workflow as data entry
If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.
Hiding exception logic
Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.
Posting without recovery design
Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.
Skipping evidence design
A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.
Where Rivane fits.
Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.
References and source basis.
These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.