What Is a Payment Factory?

A payment factory is a centralized function — and system setup — that processes payments for many entities of a group through a single, standardized channel, instead of each subsidiary paying from its own accounts through its own banks in its own formats. Payments are submitted to the factory, which validates, approves, formats and sends them through a consolidated bank connection. The payoff is real and broad: lower cost, standardized controls, higher straight-through processing, better visibility, and far fewer bank accounts and connections. It's one of the highest-impact centralizations a treasury can make — and one of the ones with the most intercompany complexity to plan for.

What it is

Without a payment factory, payments are fragmented: each entity runs its own payment processes, through its own banks, in its own formats, with its own controls. A payment factory replaces that with a single, standardized pipe. Entities submit payment requests; the factory applies consistent validation, approval and formatting; and payments go out through a consolidated, well-controlled bank channel. One process, one standard, one control model — for the whole group.

Payments-on-behalf-of (POBO)

The payment factory's most powerful (and most complex) form is POBO — payments-on-behalf-of. Here a central entity pays on behalf of the subsidiaries, from its own accounts, rather than each subsidiary paying from theirs. The subsidiary still bears the cost, so an intercompany payable is booked, but the external cash leaves one central account.

The "on behalf of" models

POBO is one of a family of "on behalf of" models, and the same idea runs in the other direction for collections. Each one collapses external accounts — and each one creates an intercompany entry that has to be settled.

(You'll also see ROBO, receipts-on-behalf-of — the same idea as COBO under a different label.) The rule is the same for all of them: the account footprint shrinks, but every flow now books an intercompany entry — so the accounting and settlement have to be designed before the cash moves. These are the mechanics an in-house bank runs on.

Why centralize payments

• Cost. One standardized process and consolidated banking beats dozens of local ones on fees and effort.
• Control. Uniform approval and segregation-of-duties across the group, instead of as many control models as there are entities.
• STP. Standardized formats and one channel mean higher straight-through processing and less manual re-keying.
• Fewer accounts. Especially with POBO, a large reduction in external bank accounts — feeding directly into rationalization and visibility.
• Visibility. Payments flowing through one place are payments you can see and analyse.

How it works

1. Subsidiaries submit payment requests to the factory (from their ERP or a portal).
2. The factory validates — checks data, applies rules, screens as required.
3. Approval and control are applied centrally and consistently.
4. Formatting into the right message for each bank.
5. Single channel out — payments go via the consolidated bank connectivity.
6. Status and reconciliation flow back and are matched.

Payment factory vs shared service centre

These are related but different. A shared service centre is organizational — a central team running a process (e.g. AP) for many entities. A payment factory is the execution mechanism — the technology-enabled centralization of the payment step itself. A shared service centre often uses a payment factory to actually make its payments. One is about who does the work; the other about how payments are technically routed and controlled.

Where it sits with pooling and the in-house bank

A payment factory rarely stands alone. It's part of the same centralization arc as cash pooling and the in-house bank: pooling concentrates the cash, the in-house bank runs internal banking relationships, and the payment factory (often with POBO) centralizes the external payments. Together they turn a fragmented, entity-by-entity treasury into a centralized one — which is exactly why they're usually planned as one programme, not three.

What usually goes wrong

• Underestimating intercompany accounting. POBO generates intercompany payables on every payment; if the accounting and settlement aren't designed up front, you trade external mess for internal mess.
• Over-centralizing. Forcing every payment type and every country through the factory when local regulation, tax or payment methods genuinely require a local approach. Centralize what benefits; respect what can't.
• Weak change management. Subsidiaries lose local control and can resist; a payment factory is as much an operating-model change as a technical one.
• Ignoring regulatory limits. Some countries restrict POBO or cross-border payment centralization — check before you design.

Centralize payment execution through one standardized, well-controlled channel, use POBO where it earns its intercompany complexity, and plan it alongside pooling and the in-house bank — and a payment factory turns scattered, inconsistent, expensive payments into a single controlled flow. It's centralization with one of the best returns in treasury, provided the intercompany plumbing is designed as carefully as the cash.

Part of the Cash & Liquidity Management guide. See also what is an in-house bank and intercompany netting. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.