Eight legal entities across three SEPA countries, four banking partners, one Group CFO. Every morning, that CFO manually consolidates balances from each subsidiary’s banking portal to get a group cash position that reflects yesterday. The dashboard presented at the executive committee meeting shows Friday evening, not today.
This scenario remains commonplace in mid-market European companies in 2026, even though cash pooling — centralising liquidity at the group level — has been standard practice in large corporates for two decades. The real question is no longer “should we implement cash pooling?” but “which mechanism to choose, and can our ERP handle it without investing in a standalone TMS at €200,000 per year?”
This guide answers both questions with a concrete benchmark of the treasury modules in the four leading ERPs on the market.
Cash Pooling: The 4 Architectures and What They Mean for the Group CFO
Physical Zero-Balancing (ZBA): The European Standard
Zero-balancing is the most widespread cash pooling architecture in the eurozone. The principle is straightforward: each evening (or several times a day since the rise of SEPA Instant Payment), balances from all subsidiary accounts are automatically swept up to a master account held by the holding company or group parent. At the end of the day, subsidiary accounts show a zero balance, or close to it.
This mechanism relies on real transfers between accounts. The movements are traceable, recorded as intercompany advances, and compatible with ISO 20022 and SEPA formats (PAIN.001 for payment orders, CAMT.053 for statements). It is the simplest architecture to integrate into an ERP, since it produces standard banking flows that the treasury module can process like any other transfer.
The rollout of SEPA Instant Payment (SCT Inst) — made mandatory for eurozone banks since October 2025 under EU Regulation 2024/886 — has opened a new possibility: intraday ZBA. Subsidiaries can now sweep surpluses several times a day, reducing idle balances between sweeps and limiting short-term intragroup credit needs.
Target Balancing: ZBA with a Safety Net
Target balancing works like ZBA, with one difference: a minimum liquidity threshold is maintained on each subsidiary account. The sweep to the master account only occurs above that threshold. This variant is useful for subsidiaries operating in countries where local law requires maintaining sufficient liquidity to cover current liabilities, or for entities subject to local FX hedging constraints (Turkey, Poland, Hungary, China).
From an ERP perspective, target balancing is slightly more complex to configure than standard ZBA: the module must manage thresholds per entity and recalculate sweep amounts based on observed balances, rather than applying a systematic zero-reset rule.
Notional Pooling: Offset Without Moving Funds
Notional pooling is fundamentally different from the two previous architectures: no funds move between subsidiary accounts and the master account. The bank calculates a net consolidated position across all group accounts, then applies interest (debit or credit) on that net position, as if all accounts were one.
The advantage is real: subsidiaries retain local management autonomy, intercompany movements are avoided, and accounting complexity is lower. The drawback is equally real: this mechanism is increasingly rare. It depends entirely on the banking partner agreeing to provide this virtual offset. The trend among major European banks since 2020 has been to reserve it for large corporates (consolidated revenue > €500M) or to tie it to significant banking relationships. For mid-market companies, physical ZBA is typically simpler and less expensive.
Notional pooling remains more common in the Netherlands and Belgium, where certain banks (ING, Rabobank) have maintained it as a standard product for mid-market clients. In other major European markets, the main banks offer it but with stricter eligibility criteria.
SEPA Instant + Hybrid Pooling: The New 2026 Architectures
The obligation on banks to offer instant transfers at the same price as standard transfers changes the cash pooling equation for mid-market companies. Intraday ZBA was until 2024 reserved for groups with access to SWIFT lines or costly proprietary bank connectors. With SCT Inst available 24/7, a group can now trigger automatic sweeps every hour, reducing average idle balances in subsidiary accounts and optimising the master account position.
This hybrid architecture — daily physical ZBA supplemented by trigger-threshold instant sweeps — is the emerging trend among companies with €100M–€500M in revenue. It requires an ERP treasury module capable of processing real-time settlement confirmations (CAMT.054 real-time) and adapting sweep rules accordingly.
What Your ERP Must Handle to Give You Group Treasury Visibility
Real-Time Multi-Entity Position Consolidation
The baseline functionality expected from an ERP for cash pooling is the aggregation of treasury positions across all group entities into a consolidated view. This consolidation can be done same-day (real-time via banking API) or next-day (import of morning CAMT.053 statements). Modern ERPs offer both modes, but real-time consolidation requires an active multi-currency banking connector — not just a scheduled file import.
Intercompany Loan Management and OECD Compliance
Every ZBA sweep generates an accounting intercompany advance: the subsidiary whose account is zeroed out becomes a creditor of the holding company for the swept amount. This receivable must be tracked in the ERP with a documented interest rate that complies with OECD transfer pricing guidelines.
OECD rules require that intercompany advances be remunerated at an arm’s-length rate — that is, a rate comparable to what independent third parties would accept in similar circumstances. In practice for a SEPA group, this rate is often indexed to the 1-month EURIBOR with a credit spread. The ERP must automatically calculate interest, generate the associated accounting entries in each entity, and produce transfer pricing documentation in the event of a tax audit. An ERP that treats ZBA as a simple treasury movement without recording intercompany interest exposes the group to real tax risk.
Post-Sweep Reconciliation and Consolidated Accounting
ZBA movements generate symmetric intercompany flows: the holding records a receivable from the subsidiary, the subsidiary records a payable to the holding. These entries eliminate on consolidation, but they must be correctly tracked in each entity so that the monthly close runs without issue. An ERP that handles ZBA natively produces these entries automatically. An ERP that delegates ZBA to an external module then needs to manually import the journals — a source of errors and close delays.
13-Week Rolling Cash Forecast
Centralising cash is pointless if the Group CFO cannot anticipate future flows with enough precision to decide whether to invest the master account surplus or draw on a short-term credit facility. The treasury module must offer a 13-week rolling forecast, fed by real ERP data: open orders, outstanding invoices, supplier payment schedules, existing credit lines. The direct method (expected actual flows) is more accurate than the indirect method (forecast income adjusted for non-cash items).
Benchmark: Cash Pooling Coverage in the 4 Leading ERPs
| Feature | SAP S/4HANA (TRM) | Oracle Fusion Cash Mgmt | Sage XRT Advanced | Cegid Treasury + Allmybanks |
|---|---|---|---|---|
| Native ZBA or via banking API | Native (full TRM) | Native | Native (EBICS + SWIFT) | Via Cegid Allmybanks |
| Notional pooling | Yes (bank config) | Yes | Yes | Via Cegid Treasury |
| Intercompany loans + interest | Native | Native | Yes (with interest calc) | Partial (configurable) |
| 13-week forecast | Native (ML since 2024) | Native | Yes | Basic |
| SEPA IP CAMT.054 reconciliation | 2025 update | 2026 roadmap | Via Sage Payment 2025 | Via Cegid Allmybanks |
| Multi-bank connectivity | SAP Multi-Bank Connectivity | Oracle Financial Messaging Hub | EBICS, SWIFT, SFTP | SWIFT, EBICS via Allmybanks |
| Indicative module price | Enterprise (on request) | Enterprise (on request) | On request (modular) | On request |
SAP S/4HANA Treasury and Risk Management (TRM) is the most comprehensive module on the market. It natively covers ZBA, notional pooling, intercompany loans with automatic interest calculation, and machine-learning-based forecasting since the 2024 release. It is aimed at groups that already have SAP S/4HANA deployed — adding TRM to an existing SAP instance is costly but delivers real ROI for groups above €500M in revenue.
Oracle Fusion Cloud Financial Management (Cash Management) offers coverage comparable to SAP, with native integration into the Oracle Fusion suite. SEPA IP reconciliation is on the 2026 roadmap — Oracle groups wanting intraday ZBA today need to go through a third-party aggregator until the update is available.
Sage XRT Advanced is the benchmark for mid-market companies with €50M–€500M in revenue and no SAP. It is a specialist TMS — not an ERP module — with certified integration into Sage X3 and Sage Intacct. It covers ZBA, notional pooling, intercompany loans with interest calculation, and includes native EBICS and SWIFT banking connectors. The 2025 update adds SCT Inst payment processing via Sage Payment. Its modular pricing remains accessible for mid-market companies, unlike enterprise TMS pricing.
Cegid offers two complementary products: Cegid Treasury (group treasury module integrated into Cegid XRP Ultimate) and Cegid Allmybanks (group banking connectivity, cash pooling and payment automation solution, compatible with SWIFT and EBICS). The combination covers ZBA, notional pooling and SEPA instant payments. Intercompany loan features are configurable but less native than SAP or Sage XRT. This combination works well for groups already in the Cegid ecosystem.
Standalone TMS vs ERP Treasury Module: When to Move to a Dedicated TMS?
Staying Within the ERP: The Criteria
A group can manage its cash pooling within its ERP without a standalone TMS if its context meets most of these criteria:
- Fewer than 20 legal entities in the pooling perimeter
- Fewer than 5 banking partners
- Operations exclusively in the SEPA zone (no complex multi-currency)
- No FX derivatives (forwards, options)
- No multi-line banking covenant management
- ERP already equipped with a treasury module covering ZBA and intercompany
For a group with 8 SEPA entities, 4 banks, €200M in revenue: a well-configured ERP treasury module — SAP TRM, Sage XRT or Cegid Treasury + Allmybanks — is more than sufficient. No need to invest in Kyriba or ION Treasury.
Investing in a Dedicated TMS: The Criteria
Standalone TMS solutions (Kyriba, GTreasury, ION Treasury / Wallstreet Suite, Finastra) become necessary when the group exceeds several of these thresholds:
- More than 20 active legal entities
- Multi-currency operations with significant FX exposures
- Complex financial instruments: syndicated facilities, commercial paper, interest rate swaps
- Multi-party banking covenant reporting
- Multilateral intercompany netting across multiple currencies
Kyriba is the reference for international mid-market groups. Its pricing starts at approximately $70,000–$180,000 per year for mid-market deployments according to TrustRadius, before implementation fees. ION Treasury (Wallstreet Suite) is positioned for even more complex profiles, with implementation timelines of 12 to 24 months.
The Middle Ground: ERP + Lightweight TMS Connector
For groups with €150M–€500M in revenue that do not have an ERP with an advanced treasury module (Dynamics 365 Finance, Odoo, Dolibarr) and do not want to invest in an enterprise TMS, intermediate solutions exist: Agicap (350+ ERP integrations, forecast treasury dashboard with banking connectors) and Embat (UK/Spain, cash forecasting + manual cash pooling). These tools do not replace a TMS for complex operations, but they bridge the gap for groups whose ERP does not cover the consolidated multi-entity view.
3 Regulatory Watch Points for Cash Pooling in 2026
1. OECD Transfer Pricing on Intercompany Advances
Every ZBA flow between a subsidiary and the holding is an intercompany advance. The interest rate applied to these advances must be documented and comply with OECD transfer pricing guidelines. In a tax audit, the authority can reclassify as profit distributions or taxable income any interest not recorded or recorded at a rate that is manifestly non-market.
In practice, the ERP must be configured to:
- apply an interest rate updated quarterly (typically EURIBOR 1M + spread)
- generate interest entries in each borrowing and lending entity
- produce a summary report by entity and period for the transfer pricing file
An ERP that processes ZBA as a simple treasury movement without recording interest exposes the group to tax risk in every country of operation.
2. Local Constraints on Cross-Border Cash Pooling
Certain EU member states and third countries impose explicit restrictions on international cash pooling:
- Turkey: Turkish law limits outward liquidity flows to non-resident group entities. Turkish subsidiaries generally cannot participate in a ZBA to a European master account without specific contractual arrangements.
- Poland and Hungary: minimum interest rules on intercompany advances and financial transaction taxes can increase the cost of cross-border ZBA.
- China: capital flow restrictions de facto limit the participation of Chinese subsidiaries in a global pool.
The ERP must allow pooling rules to be configured per entity, with entities explicitly excluded from the pool or participating only through separate contractual flows distinct from automatic sweeps.
3. SEPA Instant Payment and New Reconciliation Requirements
The rollout of SCT Inst creates a new reconciliation requirement. An instant transfer received at 23:45 on a Friday generates an immediate credit on the master account — but also a CAMT.054 confirmation (debit/credit notification) that must be processed in near-real-time by the ERP so that the treasury position is accurate. A treasury module that only processes CAMT.054 at the next business day opening will display an incorrect position overnight, which is a problem if investment or credit-line decisions are made based on that position.
Additionally, Verification of Payee (VoP) — operational since October 2025 — requires banks to verify the payee name before executing an SCT Inst. For automatic ZBA sweeps, this means the IBANs of subsidiary accounts referenced in the ERP must be current and match the exact account names registered with the bank.
Which Architecture for Which Group Size?
For a group with 3 to 15 SEPA entities, a daily ZBA configured in your ERP — with intercompany advance management and automatic interest calculation — covers the core centralisation need. If your ERP supports it, add intraday ZBA on SEPA Instant Payment to reduce idle balances and optimise master account returns.
For a group with 15 to 40 entities including non-SEPA subsidiaries, FX exposures or syndicated banking lines, it is time to evaluate Sage XRT Advanced or a mid-market TMS like GTreasury before committing to Kyriba or ION.
For groups beyond 40 entities or with complex financial instruments, enterprise TMS solutions are the right choice — but your ERP remains the system of record for accounting and operational flows. The TMS connects to the ERP; it does not replace it.
To go further on treasury in your ERP:
- SEPA Instant Payment 2026: Why Your ERP Treasury Module Is Probably Not Ready — the complete guide to reconfiguring your treasury modules for SCT Inst
- ERP and Treasury Management: Real-Time Cash Flow Control — the 5 key treasury functions of a modern ERP, with vendor comparison
- ERP and Open Banking PSD2: Real-Time Treasury via Bank APIs — how to automate multi-entity bank synchronisation without additional costs
