Summarise the article with your AI
Here you can read:
When you're running a mid-market group with subsidiaries across multiple countries, payment operations can quickly spiral out of control. Each entity maintains its own bank accounts, logs into separate banking portals, and manages vendor relationships independently. The result? Fragmented cash visibility, duplicated fees, and treasury teams spending hours on manual processes.
Payments on behalf of (POBO) offers a cleaner alternative: It is a treasury structure where a central entity executes outbound payments for multiple subsidiaries from one account, holding distinct intercompany records so each entity retains financial accountability. Mid-market groups with multiple entities adopt POBO to reduce bank accounts, lower FX costs, and gain real-time cash visibility.
What does "payments on behalf of" (POBO) actually mean?
Payments on behalf of (POBO) is a cash management structure where a central entity makes outbound payments for multiple subsidiaries, keeping intercompany records so each entity retains its own financial accountability. Each payment clearly identifies which subsidiary it originated from, preserving separate profit-and-loss reporting for every entity.
The originating subsidiary must appear in the remittance information. This allows beneficiaries to reconcile payments correctly and keeps each entity's distinct profit-and-loss reporting intact. Without real-time automated intercompany posting, POBO becomes a month-end reconciliation burden.
A proper payment on behalf of treasury structure needs three elements working simultaneously: centralised payment execution, automated intercompany journal entries, and remittance data that clearly identifies the originating entity.
POBO vs COBO: what's the difference?
POBO handles outbound payments to suppliers and vendors. COBO (Collections on Behalf Of) does the reverse, centralising inbound customer receipts. Many groups implement both structures to create a complete in-house bank model.
| Feature | POBO (Payments on Behalf Of) | COBO (Collections on Behalf Of) |
| Cash flow direction | Outbound to vendors, suppliers, employees | Inbound customer receipts |
| Account structure | Central entity pays from its account | Central entity collects via shared account |
| Typical use case | Payment factory intercompany disbursements | Receivables centralisation |
| Intercompany treatment | Payable recorded in subsidiary, receivable in central entity | Receivable in subsidiary, payable in central entity |
Both structures fit into a broader corporate payments architecture, but POBO gets adopted more widely because accounts payable volumes and vendor relationships tend to create more operational work than collections.
Why mid-market companies are adopting POBO now
Three shifts have made POBO accessible to mid-market groups in recent years:
Multi-entity expansion has made subsidiary payment management unsustainable
Operating three entities across two countries is manageable. At eight entities across four jurisdictions, you're logging into dozens of banking portals daily, consuming significant treasury time. Each subsidiary traditionally maintains its own bank relationships, creating duplicated fees, fragmented cash visibility, and multiplied compliance burdens.
Eliminating unnecessary overdrafts and trapped cash
Whilst handling bank relationships across multiple entities, monthly account fees, FX spreads on cross-border payments, and per-transaction charges multiply with each additional entity for corporate treasury departments.
Also, fragmented liquidity is a major driver for POBO adoption. For example, Entity A might hold £5 million in surplus cash it does not need for weeks, while Entity B only has £2 million but needs to execute a £4 million supplier payment run.
Without POBO, Entity B must dip into an overdraft and pay credit fees to its bank. Centralising the payment flow through one entity solves this structural inefficiency without the heavy administrative burden and complex money movements required by traditional cash pooling.
ERP connectivity has matured enough to make intercompany automation accessible
Native API-based integrations with major ERPs now let payment instructions flow from the ERP to the treasury platform and back again without file uploads. This bidirectional connectivity makes automated intercompany posting reliable for mid-market groups.
How POBO works in practice: a step-by-step structure
Here's an end-to-end cycle example for a typical centralised payments subsidiaries model:
- Instruction: The subsidiary raises payment instruction in the ERP (vendor invoice approved, payment due date approaching).
- Approval: A robust approval workflow validates payment against delegation limits and policy rules.
- Execution: The central entity executes payment from the consolidated bank account.
- Intercompany posting: The ERP records the intercompany payable and receivable automatically at the exact moment of execution.
- Reconciliation: The bank statement reconciles against both the payment instruction and the GL entry (three-way reconciliation: instruction, bank movement, accounting entry)
Step four and five are where manual POBO structures often struggle the most. If intercompany posting happens as a month-end batch journal instead of at execution, you create a reconciliation gap that lets errors compound.
The real benefits of POBO and the numbers behind them
Transitioning to a central payment factory unlocks measurable operational efficiency and hard-cost savings across the entire treasury function.
Reduction in external bank accounts
Fewer bank accounts mean lower costs. Groups consolidate from five to eight accounts per entity down to one or two per currency. That translates to reduced monthly account fees, simpler compliance reporting, and less time managing banking relationships.
FX cost reduction through payment aggregation
Paying 50 invoices individually incurs 50 separate FX conversions. Batching those payments into a single transaction allows treasurers to net exposures, which can reduce total FX costs by up to 20 to 30 per cent, which is particularly for global banking operations with regular cross-border payment flows.
Improved cash visibility in real time
Real-time cash visibility replaces yesterday's data. When subsidiaries hold separate accounts, treasury sees balances from downloaded statements. A centralised structure connected via API shows today's position across all entities, enabling intraday liquidity decisions.
Reduced payment processing time
Payment execution accelerates. Groups report cutting payment processing from several minutes per transaction to seconds after centralisation. Faster execution means fewer missed payment windows and stronger supplier relationships.
Fraud reduction through centralised approval
Fraud controls improve naturally. Separating payment preparation (at subsidiary level) from payment execution (at central treasury) creates a control layer. Approval workflows can require dual authorisation for high-value payments before funds move.
Before and after POBO
The operational difference between a decentralised setup and a mature POBO structure is stark:
| Metric | Before POBO | After POBO |
| Bank accounts per entity | 5–8 | 1–2 per currency |
| Payment execution time | Several minutes per transaction | Seconds (batch processing) |
| FX cost transparency | Fragmented across entities | Aggregated, negotiable spreads |
| Cash visibility | T-1 via downloaded statements | Real-time API feeds |
| Audit trail quality | Manual month-end journals | Automated intercompany posting |
The regulatory considerations you can't ignore
A successful implementation requires strict adherence to international tax and compliance frameworks. You must secure formal tax and legal sign-off before executing a POBO strategy.
UK transfer pricing (HMRC)
UK transfer pricing rules apply. POBO creates intercompany payables and receivables between connected parties. HMRC's transfer pricing guidance requires these arrangements to be documented and priced at arm's length, particularly for longer-term intercompany balances. BDO's transfer pricing guidance confirms that financing arrangements between connected parties can trigger review. Get formal tax and legal sign-off before you implement it.
EU SEPA remittance compliance
The European Payments Council's 2025 SEPA Credit Transfer guidelines require ISO 20022 structured fields to identify the debtor and ultimate debtor. For UK groups making payments into the EU post-Brexit, remittance data must clearly show the originating subsidiary to comply with the EU Funds Transfer Regulation.
AML and originator identification (FATF)
Ongoing revisions to FATF Recommendation 16, aim to ensure that payment messages carry standardised originator and beneficiary information across the entire payment chain. These rules ensure payment messages carry accurate originator and beneficiary information throughout the chain, making the originating entity identifiable to authorities.
How to implement POBO: the four prerequisites
Before re-architecting your payment flow, ensure your organisation meets these four foundational requirements:
Legal structure clarity
Get legal structure clarity first. Designate the central paying entity, establish intercompany agreements that authorise it to pay on behalf of subsidiaries, and define tax treatment of intercompany balances. This needs formal documentation, not informal arrangements.
Bank agreement on third-party payments
Confirm bank permission explicitly. Not all corporate banks permit a central entity to process payments on behalf of other legal entities. Verify this for each currency and jurisdiction in scope before building your structure. Some banks require formal letters of authority from each subsidiary.
ERP integration with automated intercompany posting
Automate intercompany posting at execution. Payment instructions must flow from ERPto the corporate payments platform, and intercompany journal entries must post automatically when payments execute, not as a month-end batch. Native connectors to major ERP systems now make this standard, not aspirational.
Approval workflow with exception handling
Build flexible approval workflows. Your workflow needs delegation limits, joint-signature requirements where appropriate, and crucially the ability to remove individual payments from a batch without regenerating the entire file. Treasury teams report that being unable to exclude one disputed invoice from a 200-line payment batch creates bottlenecks that undermine the entire structure.
