Who is selling the ticket, and where does the money land?

Two ways to sell a ticket

Almost every argument about event money comes from skipping this fork.

Selling on someone else's behalf is the case that goes wrong, because the money passes through you while the obligation belongs to somebody else. Get the entity right at the start and it is administration. Get it wrong and it is a restatement.

The chain that has to name one entity

Write these five down for one ticket type before you open sales. If any line names a different entity from the line above it, you have found the problem while it is still free to fix.

Contract counterparty

Who the attendee is buying from — the name in your terms and conditions

Invoice issuer

Whose name, address and tax registration appear on the document they file

Merchant of record

Whose payment account takes the card payment, and whose name appears on the cardholder's statement

Refund source

Which account the money comes back out of when someone cancels

Payout destination

Which bank account the settled funds arrive in

Three of these five are usually decided by whoever set up the payment integration, on a Tuesday, without anyone calling it a decision. The other two are decided by whoever wrote the terms and conditions. They are frequently different people, and nothing in the software tells them they disagreed.

Merchant of record is not a detail

The merchant of record is the entity the card networks consider to have made the sale. It is the name on the attendee's statement, the entity the acquirer holds responsible, and the entity a chargeback is argued against.

Two models exist and they are genuinely different, not two brands of the same thing:

• The platform is the merchant of record. Attendees pay the platform, the platform holds the funds, and it pays you out later, usually minus a percentage of every ticket. The name on the statement is theirs. Because the money sits with them between sale and payout, their solvency, their payout schedule and their risk appetite are yours to live with.
• You are the merchant of record. You connect your own payment account, attendees pay you, the funds are yours from the moment they clear, and the platform never touches them. The name on the statement is yours. You carry the underwriting, the chargeback liability and the compliance with your provider — which is the same as saying you carry the relationship.

Neither is universally right. The second is what makes multi-entity settlement possible at all, because each entity can connect its own account. The first is simpler for a single organiser selling one small event and nothing else, and it is the only model available on some platforms. What matters is knowing which one you are in — because it decides who the attendee is actually buying from, and that is a question that eventually gets asked by somebody with authority.

Pricing currency and settlement currency are two decisions

They get conflated constantly, and they answer different questions.

If you price in EUR and settle in SGD, somebody converts, and the rate they get is not the rate you read in a newspaper. If you price in six currencies for a roadshow, you have six conversion exposures and six rounding conventions — and a €450 ticket that becomes ¥73,182 reads as a price nobody set on purpose.

The workable rule: price in the currency the attendee thinks in, settle in the currency the entity banks in, and choose round numbers in the pricing currency rather than converting a round number from somewhere else. A price is a message before it is an amount.

What actually reaches the bank

The ticket price is not the amount that arrives, and the gap is bigger than most budgets assume. Put your own numbers through this before you set a price:

The rates above are placeholders — put your provider's real ones in, because they differ by country, card type and contract. The structure is the point: two of those five lines are not recoverable. A refunded order costs you the processing fee twice over — you paid it on the sale and you do not get it back on the refund — and that line is invisible in every revenue report that stops at gross.

One organisation, several entities

Multiple entities are not an exotic case. Four ordinary situations produce them:

• Country subsidiaries. The German events sell through the German company because that is where the tax registration and the bank account are.
• Agencies and PCOs. Each client's revenue has to reach that client, and it must not sit in the agency's accounts on the way — that turns a service fee into turnover and a cash-flow question into a solvency question.
• Chapters and federations. A national body and its regional chapters are usually separate legal persons even when they share a brand and a website.
• Joint events. Two organisations co-hosting one conference need one of them to be the seller, in writing, before the first ticket is sold rather than after.

The mechanical requirement in all four is the same: the entity that sells has to be the entity that collects, and the mapping has to be decided per event or per currency before sales open — not reconciled afterwards by moving money between accounts, which is how an administrative question becomes an accounting one.

Where the tax lines fall across those entities is a question for your tax adviser, in each jurisdiction, and this guide stops here on purpose.

The account that took the money is the only one that can give it back

This is the constraint that turns a naming inconsistency into an operational dead end, and it is worth stating precisely because it is not a policy choice — it is how card refunds work.

A refund can only be sent back to the payment method that was charged. Not to a different card, not to a bank transfer, not to a credit note. If the entity that took the payment is not the entity that owes the refund, there is no button anywhere that fixes it: the paying entity has to refund, and the owing entity has to settle up with it separately, by hand, outside the system, with two sets of books to reconcile.

There is a second constraint underneath it. Refunds are paid out of your available balance with the provider, not out of thin air. If that balance is short — because the payout already ran — card refunds sit pending until the balance covers them, refunds on some other methods fail outright, and in some regions the provider will debit your bank account to recover the shortfall. The money you are refunding in March was paid out to you in January.

What actually goes wrong

These are structural consequences rather than bad luck. Each one follows from a configuration, which is why each one is preventable at setup and expensive afterwards:

• The statement name is a company the attendee has never heard of. They contracted with a conference brand and their card statement shows a holding company. The result is not confusion, it is a chargeback — filed as fraud, because from the cardholder's side that is exactly what it looks like.
• One payment account is used for several entities' events. Everything works until reporting time, when there is no clean way to say which revenue belonged to which entity, and the answer has to be reconstructed from an export by whoever least wants to do it.
• The agency collects into its own account. Client revenue sits in agency accounts, which changes what the agency's own accounts say about its turnover, and makes the client's money an unsecured claim if anything goes wrong in between.
• Refund obligations outlive the payout. Sales close, funds are paid out, the event is cancelled, and the refunds have to come from working capital instead of from the money the attendees paid.
• Nobody wrote down which entity sells. The terms and conditions say one thing, the payment account says another, and neither is wrong on its own — they are only wrong together, and only visible together once someone asks.

Where software actually helps

Four places, and they are what to test a system against before you buy one — ours included:

• Your own payment account, connected directly. Whether funds reach your entity without the platform holding them in between, and whose name lands on the attendee's statement.
• Entity as a mapping, not a workaround. Whether an event or a currency can be pointed at a specific legal entity with its own bank account, or whether multiple entities means multiple logins and a spreadsheet joining them up.
• Every deduction itemised per order. Whether you can see what was charged, what was deducted and what will be paid out on a single order — because a report that stops at gross hides the two lines you cannot recover.
• Refunds issued where the payment was taken. Whether a refund goes back through the original method from the account that charged it, without anyone moving money between entities by hand.

None of that decides which entity should sell. That is a question about your contracts and your tax position, and it is answered before software is involved — which is why it is worth answering deliberately rather than discovering what was decided for you.