In a COBO structure, customers of several group companies pay into one or a small number of centrally controlled collection accounts. The collecting entity identifies the underlying subsidiary and customer, clears the receivable and records an intercompany amount so legal-entity accounting remains complete.
Where collections on behalf of, COBO fits in the transaction
In a COBO structure, customers of several group companies pay into one or a small number of centrally controlled collection accounts. In practice, the finance team should translate that rule into a specific amount, owner and deadline instead of relying on the product name alone.
The collecting entity identifies the underlying subsidiary and customer, clears the receivable and records an intercompany amount so legal-entity accounting remains complete. The important point for a business is that the operational treatment can change when the contract, currency, legal entity or transaction date changes.
The operating mechanics of collections on behalf of, COBO
Centralisation does not remove the need for good remittance data because more entities sharing one account can make unidentified receipts harder to allocate. Treasury should therefore test the exact wording or processor response before assuming the same treatment applies to every transaction.
Virtual accounts, unique customer references and structured remittance information can improve matching and let the group centralise without losing payer identity. That makes traceability essential: the bank record, internal approval and accounting entry should all point back to the same commercial event.
What treasury should verify before acting
Customer terms, invoice wording, account ownership, tax treatment and local restrictions should be reviewed before payment instructions are changed. A simple written control around this point can prevent a later cash, reconciliation or customer-service problem that is much harder to unwind.
Client-money rules, withholding tax, local-currency controls or contractual requirements can make some receipts unsuitable for a standard central collection model. The practical objective is not more paperwork; it is to know what must happen next and who has authority to change the planned outcome.
Risk, exceptions and escalation
The current auto-match rate should be measured before migration because centralising weak reference data multiplies reconciliation work instead of eliminating it. The important point for a business is that the operational treatment can change when the contract, currency, legal entity or transaction date changes.
Suspense cash should have named ownership, ageing targets and escalation so large unidentified balances do not quietly distort receivables and liquidity reporting. That makes traceability essential: the bank record, internal approval and accounting entry should all point back to the same commercial event.
Worked example: turn the concept into a decision
Three subsidiaries invoice separately but direct sterling receipts to one central account. A £25,000 payment arrives with a unique reference linked to Subsidiary B, allowing the system to clear B’s invoice and create the correct intercompany posting automatically.
Use the example as a method, not a universal rule. The article-specific control point is this: Centralisation does not remove the need for good remittance data because more entities sharing one account can make unidentified receipts harder to allocate. The business should reproduce the numbers and timing from its own contract, bank service or processor record before acting.
Building collections on behalf of, COBO into routine control
Implementation check: Customer terms, invoice wording, account ownership, tax treatment and local restrictions should be reviewed before payment instructions are changed. The operating owner should convert that requirement into a named approval, a dated record and a reconciliation step so the intended treatment can be reproduced later.
Monitoring check: The current auto-match rate should be measured before migration because centralising weak reference data multiplies reconciliation work instead of eliminating it. Management reporting should show whether this control is working, including unresolved exceptions and material changes rather than only completed transaction volume.
Escalation check: Suspense cash should have named ownership, ageing targets and escalation so large unidentified balances do not quietly distort receivables and liquidity reporting. If the assumption behind that point changes after approval, treasury should stop and reassess the transaction before cash, credit exposure or customer outcome becomes irreversible.
Decision check: Virtual accounts, unique customer references and structured remittance information can improve matching and let the group centralise without losing payer identity. The commercial choice should be made with that trade-off visible, then recorded together with the reason management accepted the remaining risk.
Editorial Verdict
BanksGB’s view starts with the underlying rule: In a COBO structure, customers of several group companies pay into one or a small number of centrally controlled collection accounts. For collections on behalf of, COBO, the business should be able to show how that rule connects to the amount, timing, legal entity and financial outcome of the transaction rather than relying on the product label.
The second test is operational: Client-money rules, withholding tax, local-currency controls or contractual requirements can make some receipts unsuitable for a standard central collection model. A strong collections on behalf of, COBO process makes that failure mode visible early, preserves the evidence used for the decision and gives management a realistic escalation route before the position becomes expensive to unwind.
Sources
- Treasury Management International, Collection Factory and Collection on Behalf Of: https://treasury-management.com/articles/collection-factory-and-collection-on-behalf-of-myth-or-reality
- Deutsche Bank, Operational efficiency in treasury: https://flow.db.com/cash-management/operational-efficiency-in-treasury