> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://learn.nuwebgroup.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://learn.nuwebgroup.com/_mcp/server.

# What are payment settlement and reconciliation in ticketing?

> Understand how event ticket payments move from authorisation to payout and how operators reconcile orders, fees, refunds, settlements and organiser proceeds.

**Payment settlement is the movement of collected ticket-sale funds through the payment system to the entitled account or accounts. Reconciliation is the process of matching those movements to ticket orders, fees, refunds and accounting records.** A ticket can be issued before the related funds reach a bank account, so successful sales, captured payments, processor balances and organiser payouts should be measured separately.

For a ticketing business selling for several organisers, reliable reconciliation must answer two questions: **Did the payment system collect the correct amount?** And **was the correct amount ultimately allocated to each party?**

## What happens to money after a customer buys a ticket?

**A ticket sale moves through payment and accounting states that do not all occur simultaneously.** The exact steps depend on the payment method, acquiring arrangement and whether the sale is immediate, deferred or partially paid.

A simplified card transaction might involve:

1. The customer chooses tickets, and the booking system establishes the order total.
2. The payment provider authorises the requested charge or confirms a payment method.
3. Funds are captured in accordance with the payment arrangement.
4. The ticketing system marks the order as payable or completed under its rules and issues valid admissions when appropriate.
5. The processor records fees, refunds, reserves or other adjustments in the relevant merchant balance.
6. The processor pays available funds to a connected bank account under its payout schedule.
7. A ticketing business or venue allocates the proceeds between the organiser, platform, venue and other entitled parties under their contracts.

The order may also use an invoice, deposit, local payment method or payment link. In those cases, **reservation, order confirmation, payment confirmation and ticket release may be separate steps**. A deposit can mean a valid commercial order exists even though the full balance is still outstanding.

Settlement terminology varies: some providers use it for card-network/acquirer funds movement, and others use it for payout to the merchant. Define which event each report means instead of assuming every provider uses the same status label.

## What is the difference between reconciliation and reporting?

**Reporting describes activity; reconciliation verifies that records agree across systems and explains differences.** A sales report might say 200 tickets were ordered. A processor report might show 195 captured card payments and several pending or rejected attempts. The quantities need not match because orders can contain several tickets and can be paid through different methods.

A practical reconciliation connects records using stable identifiers:

| Record                         | Relevant identifiers and values                                  |
| ------------------------------ | ---------------------------------------------------------------- |
| **Ticketing order**            | Order ID, status, currency, ticket total, fees, tax              |
| **Payment attempt**            | Payment reference, authorisation/capture status, captured amount |
| **Processor balance activity** | Charge, refund, dispute, processing fee, adjustment              |
| **Payout**                     | Payout reference, date, currency, aggregate net amount           |
| **Organiser ledger**           | Event, seller, revenue share, deductions, payable amount         |

An order ID identifies the booking; a payment reference identifies the money movement; a payout ID identifies the aggregate bank transfer. **Those are not interchangeable.** One basket may contain multiple tickets, one order may have several payment attempts, and one payout may contain activity from many orders or days.

Stripe's reconciliation documentation explicitly distinguishes a real-time account balance from reporting across a defined period. That principle applies more broadly: a mismatch may be caused by cut-off times, pending funds or different grouping rules rather than missing cash.

## How do you reconcile a ticketing payout?

**Match the processor's payout components to the ticketing ledger and investigate every unexplained difference.** The most reliable approach uses transaction-level detail instead of trying to infer individual payments from a lump-sum bank deposit.

Consider a deliberately simplified one-currency example for a completed reporting period:

* Captured ticket-order payments: **£10,000**.
* Customer refunds: **£500**.
* Processor fees: **£240**.
* Other balance adjustments: **£0**.
* Expected net payout: **£9,260**.

The calculation is £10,000 − £500 − £240 = **£9,260**. It is illustrative, not a universal payout formula. Actual statements can include disputes, reserves, tax adjustments, multiple settlement batches and transactions from adjacent dates.

If the bank receives £9,100 instead, the remaining £160 needs to be traced. Perhaps a reserve was withheld, a chargeback was booked after order close or a payment was settled in another payout. Posting the £160 to an unexplained “miscellaneous fee” account would conceal rather than reconcile the issue.

For multi-organiser platforms, the **bank payout is only one side**. A second allocation must determine what each event or organiser should receive under the applicable agreements, including fees retained, refunds charged back, platform commissions and withholding rules.

## Why do ticketing sales and bank deposits often differ?

**Ticket sales totals and bank payouts describe different stages of the same commercial activity.** Common reasons they differ include:

* **Timing:** checkout occurs on one date, while capture or bank payout occurs later.
* **Status:** abandoned, pending, failed, invoiced or partially paid orders are not equivalent to captured sales.
* **Deductions:** processing fees, refunds, disputes or reserves alter the balance.
* **Scope:** a bank payout groups multiple events, shops or currencies.
* **Fees:** some charges belong to a platform or venue rather than the organiser.
* **Tax:** gross receipts may include taxes that are not retained as operating revenue.
* **Foreign exchange:** transactions and payouts may use different currencies and exchange dates.

For example, a theatre company could sell season tickets months before performances. Customer cash receipt, revenue recognition and event attendance are then three distinct concepts. The accounting policy governing recognition should be agreed with the finance team rather than inferred from an order-complete flag.

## How do refunds, disputes and cancellations affect reconciliation?

**Refunds and disputes create new financial events that may occur long after the original ticket sale.** A partial ticket refund must identify which items and fees were reversed. An event cancellation can generate a large batch of refunds or credits across different payment methods.

Chargebacks add another layer: the bank or payment provider may provisionally debit funds, assess dispute fees or reverse an earlier credit. The contractual party responsible for those costs might differ from the organiser receiving the original ticket proceeds.

Operational controls should keep an audit trail of who approved a refund, how much was returned, whether the ticket was invalidated, and whether the organiser payable amount changed. Disputes and chargebacks should be reconciled even if the ticketing order was originally completed successfully.

Reconciliation teams also need consistent timezone and currency treatment. A sale just before midnight in the venue's local time might appear in the following UTC day in the processor's report; that is a reporting boundary issue, not necessarily a missing order.

## What should a ticketing reconciliation process include?

**A robust process connects order data, processor data and organiser-ledger data with repeatable exception handling.** It should identify both the transaction that generated an amount and the party entitled to it.

Establish a daily or event-specific reconciliation cadence, clear owners for exceptions, documented fee definitions and stable transaction IDs. Automate matching where the data is reliable, but make it possible to review reversals, partial refunds and cross-border payments manually.

Ask the provider whether it exposes transaction-level settlement references, downloadable fee breakdowns, payout reconciliation files, report exports and audit records. Do not assume a general sales dashboard can replace a finance-grade ledger.

**Successful ticketing operations reconcile the ticket, the order, the payment and the payout—not just the final bank balance.**

## Related explanations

#### [How can ticketing platforms automate payment reminders?](/checkout-commerce/how-can-ticketing-platforms-automate-payment-reminders)

Checkout & Commerce · Payments and settlement

#### [Can a ticketing business use its own payment gateway?](/checkout-commerce/can-a-ticketing-business-use-its-own-payment-gateway)

Checkout & Commerce · Payments and settlement

#### [How do ticket deposits and instalment payments work?](/checkout-commerce/how-do-ticket-deposits-and-instalment-payments-work)

Checkout & Commerce · Payments and settlement

#### [What is merchant of record in ticketing?](/checkout-commerce/what-is-merchant-of-record-in-ticketing)

Checkout & Commerce · Payments and settlement

[More in Checkout & Commerce →](/checkout-commerce)