The entity sprawl problem
Growth-stage businesses expand into new markets by incorporating local entities. Each entity opens its own bank accounts, often at different banks chosen for local convenience rather than group strategy. After two or three years of expansion, a company operating in eight markets may have 30+ bank accounts across 12+ banking partners, with no consolidated view of cash positions and no systematic approach to moving funds between entities.
The symptoms are predictable: month-end close takes 15–20 business days because intercompany balances cannot be reconciled. Treasury cannot answer "how much cash do we have globally" without a manual spreadsheet exercise. FX exposure accumulates silently because no one owns the aggregated position. Idle cash sits in low-yield local accounts while the parent borrows at higher rates to fund operations elsewhere.
Account structure design
A well-designed treasury architecture uses three account tiers per entity:
- Collection accounts: Receive customer payments, marketplace settlements and other inbound funds. Typically one per entity per currency. Balances are swept to concentration daily or on a fixed schedule.
- Disbursement accounts: Fund outgoing payments — supplier payments, payroll, tax settlements. Funded from the concentration account on demand or via a scheduled top-up.
- Concentration accounts: The entity-level hub. All collection sweeps land here; all disbursement funding originates here. One per entity, typically in the entity's functional currency.
Above the entity tier sits the group concentration account (or accounts, if multi-currency). This is where excess cash from all entities pools and where intercompany lending, FX hedging and investment decisions are executed. The group account should sit at a bank with strong cross-border capability and API access for automated sweeping.
Physical sweeping versus notional pooling
Physical sweeping moves actual cash between accounts on a scheduled basis (typically end-of-day). The subsidiary's collection account balance is swept to the group concentration account, creating an intercompany loan. This works in most jurisdictions but requires intercompany loan documentation and has tax implications (withholding tax on interest, thin capitalization rules).
Notional pooling does not move cash. The bank calculates interest on the net position across all participating accounts. Each entity retains its own balance legally, but the group benefits from offsetting positive and negative positions. Notional pooling is restricted or prohibited in several jurisdictions including China, India, Brazil and parts of the Middle East, where local regulations require cash to remain within domestic entity accounts.
Practical recommendation: use physical sweeping where legally permitted, with documented intercompany loan agreements at arm's-length interest rates. Where notional pooling is restricted, implement a manual "virtual pool" — a daily report that calculates the net position and triggers manual transfers where the benefit exceeds the transfer cost.
Intercompany positions and transfer pricing
Every sweep creates an intercompany balance. These must be tracked, documented and priced. The group treasury function owns the intercompany loan agreement template, sets the interest rate (typically a benchmark rate plus a spread reflecting the borrower's creditworthiness), and ensures monthly statements are issued to each entity.
Transfer pricing authorities expect intercompany financing to follow arm's-length principles. This means documented credit analysis of the borrower entity, interest rates benchmarked against comparable market transactions, and formal loan agreements executed before funds move — not reconstructed at audit time. Failure here creates tax risk disproportionate to the amount involved.
Treasury architecture is not a banking product. It is an operating model that happens to use bank accounts as its primitives.
Architecture layers
| Architecture layer | Purpose | Typical tooling | Risk if missing |
|---|---|---|---|
| Account hierarchy | Organize collection, disbursement and concentration tiers | Bank portal; internal account register | Orphan accounts; no single cash position view |
| Sweeping engine | Move cash on schedule between tiers and entities | Bank cash pooling product; TMS module | Idle cash; manual transfers prone to delay |
| Intercompany ledger | Track loan positions, accrue interest, generate statements | ERP intercompany module; dedicated IC system | Unreconciled IC balances; tax exposure |
| FX exposure aggregation | Consolidate net currency positions across all entities | TMS; treasury dashboard; bank FX reporting | Unhedged exposure; surprise P&L swings |
| Bank connectivity (API) | Automated balance retrieval, payment initiation, statement download | Host-to-host; SWIFT; bank APIs (PSD2, Open Banking) | Manual downloads; stale data; key-person dependency |
| Cash forecasting | Predict 13-week rolling cash position by entity and currency | TMS forecasting module; ERP + ML overlay | Reactive borrowing; missed investment windows |
| Reporting & close | Consolidated treasury reporting; month-end IC elimination | BI layer on ERP; consolidation system | Close takes 15+ days; board reporting delayed |
Banking partner consolidation and API connectivity
Operating across 12 banks means 12 portal logins, 12 statement formats, 12 sets of API documentation (if APIs exist at all) and 12 relationship managers. Consolidating to three or four banking partners — one global transaction bank, one or two regional specialists, and one FX provider — reduces operational complexity dramatically.
Selection criteria for a treasury banking partner: API maturity (camt.053/camt.054 statement delivery, pain.001 payment initiation, real-time balance webhooks), cross-border capability in your corridors, cash pooling product availability in your jurisdictions, and integration support. The cost differential between banks is secondary to the operational efficiency gained from automation.
Cash visibility and forecasting
Visibility precedes optimization. Before you can pool, hedge or forecast, you need a single-pane view of every account balance across every entity, refreshed at minimum daily. Build this aggregation layer first — even if it is a simple automated report pulling balances via bank APIs into a central database.
Once visibility is established, implement a 13-week rolling cash forecast by entity and currency. The forecast drives three decisions: how much to sweep, when to convert currency, and whether to borrow or invest surplus. Without it, treasury operates reactively — borrowing at spot rates when cash runs short and leaving surplus idle when it accumulates.
Implementation sequence
Do not attempt to build every layer simultaneously. The sequence that works:
- Inventory (week 1–2): Map every bank account, every entity, every currency. Identify orphans and duplicates. Close unnecessary accounts.
- Connectivity (week 3–6): Establish API connections to your top 2–3 banks. Automate daily balance retrieval and statement download.
- Visibility (week 6–8): Build the aggregation dashboard. Single pane showing all positions, all currencies, refreshed daily.
- Sweeping (week 8–12): Implement automated sweeping from collection to concentration accounts. Document intercompany agreements before first sweep.
- Forecasting (week 12+): Layer on the 13-week forecast once you have 8+ weeks of historical position data from your connectivity layer.
The end state is a treasury function that answers "where is our cash, what is it doing, and what should it do next" in under five minutes, with full audit trail on every movement.