Why does one organisation end up with several payment accounts?
By Donghui Qian (Milo)Updated 19 September 20264 min read
Short answer
Because each legal entity that sells tickets needs the money in its own account: country subsidiaries, agencies running client events and federations with regional chapters all end up with one payment account per entity. Mapping each event to its entity before sales open lands the money in the right account at the point of sale, instead of splitting a pooled payout by hand afterwards.
Most events need one payment account and one company. This guide is for the ones that do not: agencies holding client money, groups with a company per country, and programmes that sell in several currencies into several bank accounts.
It describes the problem and the four ways teams solve it, including the ways that do not involve us.
First: most events do not need this
One company, one bank account, one country. If that is your situation, everything below is complexity you are better off not buying — and a vendor selling you multi-entity settlement for a single-entity event is selling you a future migration.
The rest of this guide assumes you already have more than one legal entity, for reasons that predate any software decision.
Where the second entity comes from
Nobody creates companies for fun. Four causes produce almost all of them:
| Cause | What it looks like |
|---|---|
| Local presence | Selling into a country needs a local company to invoice, bank, or register there — so the same programme sells through different companies in different markets |
| Client money | An agency runs events for clients. The revenue is the client's, and it should never sit in the agency's account on its way there |
| Business lines | A media group, a training arm and a membership body under one roof, each with its own accounts, budget and board |
| History | An acquisition, a joint venture, or a company nobody has wound up. It still invoices, so it still needs the money |
What breaks when the money is pooled
A platform that collects into one balance and pays out later is not wrong — it is a design that assumes one seller. When there is more than one, five things break in a predictable order.
- The invoice comes from the wrong company. The attendee needs a document from the entity that ran the event; the platform issues from whoever holds the account.
- Reconciliation stops being automatic. One payout covering three entities has to be split by hand, every time, by someone who was not in the room when the tickets were priced.
- Refunds cross a boundary. Money already paid out to entity A is refunded from the pooled balance, and now two sets of books disagree.
- Registration obligations get blurred. Which company is treated as the seller matters to your finance team and to local rules. Pooling makes that question harder to answer, and the answer is not the software's to give.
- The audit trail thins. At year end someone has to show, per entity, what was sold and what was received — from records that were never kept that way.
None of these show up during the event. They show up four to six weeks later, in finance, when nobody remembers the detail.
The four models
Every team solving this ends up in one of four places. The right one depends on how many entities there are and how much manual work you can absorb.
| Model | Works when | Costs you |
|---|---|---|
| One account, split afterwards | Two entities, a handful of events a year, one person who understands the split | Monthly manual reconciliation, and a single point of failure who goes on holiday |
| A separate platform account per entity | Entities are genuinely independent and never share a programme | Duplicated setup, no cross-entity reporting, and attendees seeing several different brands |
| One platform, one payment account per entity | Several entities running one programme, each needing its own money path | Setup discipline: every event must be mapped to an entity before it opens |
| Payment provider sub-accounts | Your provider supports it and your platform can address them | Provider-specific behaviour on refunds and payouts — test both before committing |
The third row is what most conference groups and agencies land on, because it keeps one operational surface while letting the money branch at the point of sale rather than after it.
The number that tells you it is time
If you want a threshold rather than a feeling, count the manual work instead of the entities.
events a year × entities involved × hours per reconciliation
= hours spent turning one payout into several sets of books
Two entities and four events a year is an afternoon each quarter. Five entities and forty events is a job. The second one is worth solving in the tooling; the first usually is not.
What to test before you believe it
Multi-entity support is easy to claim and easy to check. Ask for these five in a demo, with a test event per entity:
- Map two events to two different entities, and show where the money lands first — not where it ends up after a payout.
- Issue a refund on one entity a week after payout, and show what the other entity's books look like afterwards.
- Produce a revenue report per entity and per currency, then the group view, and check the group view says it is converted rather than a balance.
- Show which entity appears on the attendee's card statement and on the document they can download.
- Add a fifth entity and see whether anything has to be re-created rather than added.
Ask every vendor the same five, ours included. The differences are structural: a platform built around one seller does not acquire a second one by adding a field.
Frequently asked questions
Some can, by connecting one payment account per legal entity and mapping each event to the entity that should receive its money, so funds land in that account at the point of sale rather than being split after a pooled payout. It is worth testing rather than assuming: ask to see where money lands first, and what a refund does after a payout has already been made.
It works at small scale. It stops working when refunds cross the boundary, when the invoice has to come from a specific company, or when someone needs a per-entity report at year end from records that were never kept that way. Count events times entities times hours per reconciliation — that number tells you whether to fix it in the tooling.
No, and many agencies prefer not to. If each client's revenue settles into that client's own account, the agency never holds the funds, the client's invoice comes from the client's entity, and the agency's own books stay clear of money that was never theirs.
It can, and that is the part worth being precise about, because merchant of record decides who the attendee has a contract with, who issues the document, and who handles a chargeback. It is a separate question from where the money lands, and it has its own guide.