Multi-Entity Treasury: Running Accounts for Several Group Companies

A multi-entity treasury should provide one operating view without treating a corporate group as one legal wallet. The parent finance team may administer payments, liquidity and reporting centrally, but each bank account, stablecoin balance and transaction must remain attributable to the company that owns it. This distinction is essential for reconciliation, audit evidence, tax analysis and protection against accidental commingling.

Choose an operating model before opening accounts

Account architecture should follow the group’s legal and accounting model. Some groups let every subsidiary hold and move its own funds. Others centralise payment preparation while retaining entity-specific approval. More mature groups may use documented intercompany funding arrangements to concentrate liquidity at a parent or treasury company.

Central administration does not change legal ownership. If group staff initiate a payment for a subsidiary, the record should show that they acted under the subsidiary’s authority and that the subsidiary’s funds were used.

Keep accounts and controls separate by legal entity

Each operating company should be onboarded and maintained as a distinct legal entity. Depending on jurisdiction and provider eligibility, its setup may include fiat accounts or virtual IBANs, multi-currency balances and stablecoin wallets or vaults. A group-level dashboard can aggregate these positions, but the underlying ledger should preserve the owner of every balance.

At minimum, separate the following:

• Account ownership: Record the company that legally owns each fiat account, virtual IBAN and stablecoin wallet.
• Balances: Do not present one subsidiary’s money as another subsidiary’s available operating cash.
• Authority: Define initiators, approvers, signing quorum and payment limits for each entity.
• Beneficiaries: Associate bank details and wallet allowlists with the entity that approved them.
• Evidence: Retain statements, transaction hashes, invoices, approval histories and conversion records by entity.

For stablecoin transactions, multi-party computation or another distributed signing arrangement can reduce reliance on one private key. Whatever custody model is used, finance should document who can initiate, who can approve, how many signers are required and how access is removed when responsibilities change.

Prepare for entity-by-entity KYB

Know-your-business review is generally performed for each legal entity, even when the parent has already been approved. Requirements depend on jurisdiction, ownership, activity and expected payment flows. Approval of one group company should not be interpreted as approval of every subsidiary or every currency corridor.

Prepare a reusable onboarding pack containing:

• Certificate of incorporation and a current company extract.
• Articles of association or equivalent constitutional documents.
• Registered and operating addresses.
• Directors, authorised signatories and ultimate beneficial owners.
• A group chart showing direct and indirect ownership.
• A description of products, customers, counterparties and expected flows.
• Expected currencies, stablecoins, networks, volumes and payment corridors.
• Source-of-funds or source-of-wealth evidence where requested.

Track eligibility by entity in an account register. It should show the provider, account owner, currencies or tokens supported, approved networks, authorised users, limits and current onboarding status.

Select the intercompany transfer route

The right route depends on what the receiving company needs, not simply what the sender holds. Compare settlement currency, urgency, cut-off times, network compatibility, conversion cost and the receiving entity’s ability to hold the asset.

These are indicative operating ranges, not guarantees. Weekends, holidays, cut-offs, sanctions screening, beneficiary review, intermediary banks and blockchain congestion can change completion time.

If one company holds USDC but another needs EUR, map the complete route before approval: token transfer, conversion, fiat payout and receiving bank credit. Identify which legal entity executes each step and bears each fee. A low network fee can be outweighed by a poor conversion rate or an unsuitable off-ramp.

Prevent token, network and address errors

Stablecoin symbols are not enough to identify a valid route. USDC and USDT are issued or represented on multiple blockchains, and provider support varies by token and network. A destination that accepts one token on Ethereum must not be assumed to accept the same token on Base, Arbitrum, Solana, Tron or another network.

Before the first transfer to an entity, complete this checklist:

1. Confirm the receiving legal entity and economic purpose.
2. Verify the exact token, blockchain network and destination address.
3. Check that both sending and receiving services support that combination.
4. Screen the address and approve it under the correct entity’s process.
5. Consider a small test transfer for a new destination.
6. Record the transaction hash and link it to the internal transfer reference.

Do not use manual copying as the only address control. Approved address books, independent verification and signing quorum reduce the chance that one operator can redirect funds unnoticed.

Classify the transaction before moving money

An intercompany payment is not an accounting category. The movement may be a loan, capital contribution, dividend, management charge, expense reimbursement, settlement of an invoice or another legally supported transaction. Finance should determine the classification before execution and obtain tax or legal review where necessary.

The payment record should identify the sending and receiving entities, amount, currency or token, network, business purpose, agreement or invoice, approval basis, valuation source and timestamp, bank reference or transaction hash, and the entity responsible for fees.

Both companies should use the same intercompany reference. If Company A records a receivable from Company B, Company B should record the corresponding payable. Differences caused by fees, foreign exchange, valuation timing or payments in transit should be explained rather than left as unmatched consolidation entries.

Build consolidated reporting without losing ownership

A group treasury report should aggregate liquidity while retaining entity, currency, token and network detail. It should distinguish external cash from intercompany receivables and payables, flag transfers in progress, show conversion and network fees, and identify amounts that require elimination on consolidation.

Apply a documented valuation policy to stablecoin transactions and period-end balances. Do not rely solely on the token’s stated reference currency. Record the rate source and timestamp used so that both sides of an intercompany transaction can be reconciled consistently.

A practical month-end close should:

1. Export fiat and stablecoin activity separately for each entity.
2. Match bank references and blockchain hashes to approved payment records.
3. Reconcile intercompany balances in entity pairs.
4. Post gas, conversion, bank and intermediary fees to the responsible company.
5. Value remaining token balances under the group’s accounting policy.
6. Eliminate intercompany balances and transactions in consolidation.
7. Retain statements, approvals, agreements and exception evidence in the close pack.

Centralise the process, not the legal ownership

The strongest multi-entity setup combines an entity account register, standard approval matrix, controlled beneficiary data, documented funding categories and a repeatable reconciliation process. Group treasury gains consolidated visibility and execution capacity while each subsidiary retains identifiable assets and records.

Stablerail provides one business account for USDC and USDT treasury, with approvals and signing quorum, sanctions and address screening before send, corporate cards, global payouts, fiat off-ramp and exportable audit evidence. Availability and onboarding should still be assessed for each company and required corridor.