How to reconcile ticket sales with money received in your bank

Your ticket dashboard says you sold $20,000. The bank received $14,000. Before you decide that someone owes you $6,000, check what each number includes and which dates it covers. Some money may still be waiting for payout. Some may have paid fees or gone back to buyers.

To reconcile ticket payouts, match each bank deposit to its payout record, explain that payout using the transactions included in it, then account for the money still held by the provider. Keep the event allocation alongside that work so a refund for last month's show doesn't become a cost of next week's launch.

The first thing you want to do is choose one deposit and follow it through. Comparing an entire event's lifetime sales with one week's bank receipts creates a difference before you've checked anything. We'll work through a complete example, build a reusable record and cover the awkward cases that can make an otherwise sensible spreadsheet disagree.

Decide what you are trying to match

There are two separate checks. One confirms that a payout reached the bank. The other confirms that the provider's record of sales, deductions and remaining funds is complete. You need both, because a deposit can match perfectly while an earlier sale remains unexplained.

Start with the bank statement. Record the amount, currency, posting date and description of the receipt. Find the corresponding payout in the platform or payment account. Use its identifier and transfer reference where available. An amount that happens to match is useful evidence, but it isn't enough when you receive several identical deposits.

Then open the detail behind that payout. You are looking for the actual transactions and adjustments assigned to it. A sales report filtered to the same calendar week may contain a different group of payments, even when the totals look similar.

Stripe's payout reconciliation report illustrates this distinction. It groups automatic payouts with their underlying balance transactions and provides itemized downloads. Its reporting period uses the payout's estimated arrival date, which can differ from the date the bank posts the receipt.

Your provider may use different report names or manage the payment account itself. Ask for the report that explains the deposit, including its deductions. Don't assume that using a particular payment processor gives you direct access to that processor's dashboard through every ticketing arrangement.

Get the records before changing any totals

Collect the ticket order detail, payment activity, payout statement and bank statement for the period. Include refund and dispute activity, together with any separate fee invoices or adjustments. If the account sells several events, collect the full account activity before filtering to your own show.

Use the platform's existing financial reporting wherever it already connects those records. You shouldn't rebuild an order ledger by typing figures from screenshots. An export or saved report should retain the references needed to investigate the exceptions, while the bank statement confirms what arrived outside the platform.

Check the scope of each file as you collect it. Record the account, date range, time zone, currency and download date. Confirm whether the sales total includes taxes, buyer fees, complimentary tickets or pending payments. The word gross doesn't tell you enough about the columns underneath it.

Keep the original downloads unchanged. Do your sorting and calculations in a working copy or accounting tool. If a report is later regenerated with updated refund activity, save the new version separately and explain which version supports the current reconciliation.

The US Internal Revenue Service's business recordkeeping guidance identifies supporting documents such as receipts, deposit information and account statements as records behind business entries. For this task, retain the records that let another person follow the amount without relying on your memory.

You don't need every buyer's personal information in the finance summary. Keep access to detailed order records controlled, and share references and relevant amounts with the people checking settlement. A copied mailing list doesn't make a payout easier to explain.

Understand the amounts between a sale and a deposit

A ticket order can include more than the price you advertised. It may include a fee paid by the buyer, a tax amount or a separately priced extra. Decide which part represents your ticket sale and which parts belong to other categories before adding the orders together.

Next, identify what reduces the balance payable to your business. Depending on your arrangement, that can include organizer fees, payment processing, refunds, promoter commissions or documented adjustments. Some charges come out of settlement. Others arrive as a separate invoice. Only deductions actually taken from the balance belong in this payout calculation.

A reserve or hold needs different treatment from a fee. When funds remain owed to you but temporarily unavailable, explain the held amount and its status. Don't describe it as an event expense simply because it hasn't reached the bank. Confirm the contractual treatment if the provider's explanation is unclear.

The same care applies to taxes. A bank deposit can contain money that your business must later remit. Reconciliation confirms the cash movement, while your accountant determines how the underlying items belong in your accounts. Matching the deposit doesn't establish that every dollar is yours to spend.

Write the calculation using the provider's actual signed entries. Positive sales and credits increase the amount. Refunds, fees and other deductions reduce it. If the export already gives a net amount after fees, don't subtract the fee again when totaling that net column.

Before you proceed, reconcile one ordinary order manually against its payment record. This is a small check with a useful purpose. It establishes what the columns mean, so the same mistaken assumption doesn't spread across every order in the file.

Work through a complete payout example

Let's use a hypothetical event with all amounts in USD. These figures are an original teaching example, not a provider fee quote, customer result or industry benchmark. There are no separate taxes or buyer fees in this simplified example, and every deduction listed below reduces the provider balance once.

At the beginning of the reporting period, the provider holds $2,000 from earlier activity. During the period, successful ticket payments add $20,000. Refunds reduce the balance by $1,000, organizer fees reduce it by $800, and a documented dispute deduction removes $200. There are no other adjustments.

That leaves $20,000 in the provider balance before payouts. The calculation is $2,000 plus $20,000, less $1,000, less $800, less $200. Notice that the opening money matters. You would get the wrong expected balance if you started from this period's sales alone.

The provider sends two payouts totaling $17,000. One is $14,000 and the other is $3,000. Its ending balance is therefore $3,000. The period is explained by $17,000 paid out and $3,000 still held, together accounting for the $20,000 balance available before those transfers.

Now follow the first payout rather than assuming it contains every transaction above. Its itemized statement includes $15,000 in ticket payments, less $500 in refunds, $400 in fees and a $100 dispute deduction. Those entries total $14,000. The bank statement shows a matching $14,000 receipt with the corresponding reference.

The second payout contains another $4,000 of ticket payments, less $500 of refunds, $400 of fees and the remaining $100 dispute deduction. Those entries total $3,000, matching the second bank receipt. Both deposits are now explained individually.

The ending $3,000 consists of the $2,000 opening balance and $1,000 of current payments that remain unpaid in this example. Check those components against the provider's ending balance detail. Don't infer their composition from subtraction alone when the actual report is available.

Here is the reusable summary for that period:

• Opening provider balance: $2,000.

• Successful ticket payments added: $20,000.

• Refund deductions: $1,000.

• Organizer fee deductions: $800.

• Dispute deductions: $200.

• Total payouts removed from the provider balance: $17,000.

• Closing provider balance: $3,000.

Every item must have supporting detail. Keep that detail with the settlement record. The summary explains why gross ticket payments and bank receipts differ, but it doesn't replace the transaction lists behind the payouts. Keep both levels available so a reviewer can check the arithmetic and then inspect a particular order.

Build a record you can reuse next week

You need a payout summary and the transactions supporting it. Your existing finance system may already provide both. If it doesn't, use a simple working sheet with one row per payout and a separate list of underlying activity. Keep calculated totals separate from amounts copied from source records.

For the payout summary, record the provider account, payout identifier, settlement currency, payout amount, expected arrival date, actual bank date and bank reference. Add the sum of the supporting net transactions and the difference against the payout. The expected result of that last calculation is zero.

Record the bank comparison separately. Subtract the bank receipt from the provider payout amount, in the same currency. A zero result confirms the amounts agree. If one payout arrives through several bank entries, retain all the references and show their combined amount instead of forcing a single receipt into the row.

The supporting activity should retain the transaction identifier, original order reference, event, activity type, relevant date, gross amount, fee and net amount. Add a reference back to the payout when the provider supplies one. Keep the provider's description available for unfamiliar adjustments.

Choose one convention for deductions. You might store refunds as negative numbers, or have separate deduction columns with positive amounts. Either works if the formula matches it. Mixing both conventions can turn a refund into an addition, especially when someone pastes a new export into an older sheet.

Use an exception field for amounts that need investigation. Name the missing evidence or disagreement, the person handling it and the next review date. Avoid a vague checked column that can mean anything from opened the file to confirmed every transaction against the bank.

A second person should be able to follow a payout without asking which tab you meant. Write the account and reporting scope in the file itself. That becomes especially useful when a venue partner or bookkeeper checks a settlement after the event team has moved on.

Account for everything still with the provider

Matching deposits answers what arrived. Now check the remaining balance. Start with the opening provider balance, add the period's balance increases, subtract its balance reductions and subtract payouts recorded by the provider. The result should equal its reported closing balance for the same scope.

Stripe's balance summary documentation describes this kind of account statement. It reports opening and closing balances, activity and payouts. It also distinguishes this view from the report that associates transactions with individual automatic payouts, which matters when the account uses manual withdrawals.

Don't assign a manual payout to a convenient selection of ticket orders unless the provider actually makes that association. The transfer can simply be money withdrawn from a running balance. You can still reconcile the withdrawal to the bank and reconcile the complete balance over the reporting period.

Keep funds in transit visible too. The provider may have removed a payout from its balance before your bank credits it. That amount belongs in the explanation between the two records. It hasn't disappeared, and it shouldn't be included in both the closing provider balance and bank receipts.

When the next period starts, its opening balance should agree with the previous closing balance under the same reporting basis. If it doesn't, find the adjustment or scope change before continuing. Carrying an unexplained difference into a new week makes the next reconciliation harder to trust.

A closing balance isn't automatically a problem. It may contain recent sales awaiting eligibility, a disclosed hold or money left in the account by choice. What matters is that you can identify the components, explain their status and assign a follow-up where the expected release hasn't happened.

Allocate one deposit across several events

If your business runs a monthly series, a single payout may combine sales for several dates. It can also include a refund from an event that has already finished. Match the whole deposit first, then allocate its underlying activity to the event that generated each item.

Use event identifiers rather than titles alone. Two shows can have similar names, and a rescheduled date may keep the original listing. Keep the original order reference attached to a refund so it returns to the correct event even when a different show is currently selling.

Suppose a payout contains $8,000 net from one concert and $6,000 net from a workshop. The bank receives $14,000. Allocate those supported amounts to their respective events. Don't divide the deposit equally or in proportion to attendance, because neither method describes the transactions that funded it.

For shared account charges, write down the allocation rule and have the person responsible for the accounts approve it. Some charges belong directly to an event. Others support the business across several events. A payment account total alone won't settle that management decision.

Then compare the event's cumulative activity with its cumulative payouts and remaining amount. This is a different view from the account reconciliation, and both should agree when combined. It helps you avoid treating a strong presale for a future event as uncommitted cash from the show you've just delivered.

Our event profit and loss worked example explains how ticket income, refunds and costs affect the event result. Use the reconciled activity to support that statement. Recording a payout as fresh revenue after already recording the underlying sales would count the same business twice.

Keep refunds and disputes attached to the original payment

A refund approved today may relate to a ticket sold and paid out weeks ago. Keep the refund's own reference and date, its original payment reference and the event it belongs to. Those links explain both the current payout deduction and the change to the earlier event's result.

Separate the amount returned to the buyer from any fees retained or charged. Stripe's refund documentation states that its original processing fees aren't returned and describes how refunds use the available balance. Your ticketing arrangement may have its own fee treatment, so verify the applicable records rather than copying another provider's rule.

Don't assume that approving a refund means the cash movement has finished. Check the recorded status and the balance entry. If a refund is pending or fails, retain the evidence and follow the provider's process. Changing the spreadsheet to the amount you intended to refund won't resolve the actual transaction.

Disputes need their own category. Stripe's description of the dispute process explains that a disputed amount and dispute fee can be debited from the account. Track those entries separately, and record any later credit against the same case when the account actually receives it.

The reconciliation record should explain the cash effect without guessing the final outcome. An open dispute remains open even after you submit evidence. Keep its response deadline with the person handling the case, and review the financial entry when the provider reports the decision.

If customer support has already refunded a disputed order, investigate the linked records before making another payment. Your finance and support teams need the same case references. A buyer's complaint, a refund request and a dispute entry can describe one underlying order, with different actions required.

Find differences in a sensible order

Start with the reporting scope. Check account, currency, date filters and whether the file contains the complete activity. Then check payout status and whether the money has reached the bank. These checks are quicker than opening individual orders and often explain why two otherwise correct totals disagree.

Next, compare the provider's payout amount with the sum of its listed transactions. If they differ, check for missing report pages, excluded adjustment types and duplicated rows. A second download can overlap the first. Removing duplicates by order number alone can also remove legitimate partial refunds or separate activity on the same payment.

Use the activity's unique transaction reference to identify a duplicate. Keep refunds and fees as their own entries where the provider does. Several entries can belong to one order without being copies of the same transaction. The order reference connects them, while the activity reference distinguishes them.

If the statement agrees internally but the bank amount differs, investigate transfer charges, conversion, splitting or reversal with the provider and bank. Confirm which party charged what. Don't bury a real bank charge inside ticket processing fees just because that makes the comparison reach zero.

For a payout that hasn't arrived, gather its identifier, currency, amount, expected date and current status. Ask the provider for the available trace reference when appropriate. Your bank needs information that identifies the transfer, rather than a ticket order number used only inside the event platform.

For example, a $75 difference should become a question you can answer. Which balance entry accounts for the $75, and does it belong to this payout? If support says it is a retained fee, request the transaction reference and applicable explanation. If it is a hold, record the expected review or release condition. Keep the amount unresolved until the evidence supports one treatment. The same amount can represent very different problems, so its size alone should never determine the category you assign to it.

Leave the unresolved difference visible until you have evidence. An adjustment called rounding can hide an omitted refund or duplicated fee. Genuine rounding differences should be explained by the calculation and currency precision involved, with a consistent treatment approved by the person responsible for your accounts.

Handle cutoffs and currencies without inventing a missing sale

A sale date, funds availability date, payout date and bank posting date describe different moments. Keep the dates your reports actually provide. A late evening purchase can fall into a different reporting day when one system uses local time and another uses UTC.

Set a named reporting time zone and check how each export handles it. When comparing sales at a month boundary, inspect transactions around the cutoff instead of moving the whole difference into the next month. You need evidence of which activity moved, especially when the accountant is closing a reporting period.

Compare money in the same currency. Keep the buyer's payment currency separate from the settlement currency and the bank account currency. Use the provider's recorded converted amounts and any conversion charges to explain the settlement. A current online exchange rate won't reproduce a historic conversion automatically.

If the bank converts the transfer again, retain its conversion record too. That creates another step between the payout amount and the bank receipt. Reconcile each step in its own currency before deciding whether the difference is a missing payment, a fee or a currency movement.

For a business with several currency balances, complete a separate reconciliation for each one. Adding unlike currencies produces a total that has no useful financial meaning. Convert for your management reporting using the agreed accounting policy after the original currency records are explained.

These checks also matter when an event changes dates or customers transfer tickets. A change to attendance entitlement doesn't necessarily create a new payment. Follow the actual financial entry and the platform's order history so moving a ticket doesn't accidentally become another sale in your finance records.

Review the settlement before paying partners

A joint event can create pressure to distribute money as soon as a deposit arrives. Before you do that, agree what the payment represents. Is it an advance against an eventual share, reimbursement of an approved cost or the final settlement? Those decisions affect what remains available for refunds and unpaid bills.

Prepare the partner statement from the event allocation you've already checked. Show the ticket activity, deductions and payouts relating to that event, then apply the agreed commercial arrangement. Keep the provider's cash movement separate from the calculation of what each partner earns. A bank receipt by itself doesn't establish the amount a co-promoter is owed.

Record advances already paid. If a partner received money before the event, deduct the applicable advance once when calculating the remaining payment. Keep the bank reference beside the advance so the settlement reviewer can confirm that it happened. An informal message saying paid isn't a reliable replacement for the transaction.

Where the event isn't financially complete, state what remains provisional. You may still be waiting for a refund decision, a supplier invoice or a held payout. Agree what can be distributed now and what amount stays available for identified obligations. Don't promise a final figure while leaving known adjustments outside the calculation.

Have the responsible person approve the statement before the transfer leaves your bank. Save that approval with the supporting records. If the same business runs the next event, the record should still explain the previous settlement without using next month's sales to disguise an unresolved amount.

Make the next reconciliation easier

Choose a review frequency that fits the money moving through the business. A busy sales period may justify more frequent checks than a quiet interval between events. At minimum, decide who reviews each payout and who checks the overall provider balance when the accounting period closes. Put those responsibilities in the event handover.

A useful handover includes the latest explained closing balance, matched transfers, unresolved amounts and where the source records are stored. Include the reason and owner for every exception. The person taking over should be able to distinguish money still awaiting release from an amount that needs to be challenged.

Watch for the same exception recurring. If refunds repeatedly lose their event reference, fix how that reference is retained. If the bank description doesn't identify the payout, ask which transfer field provides a dependable match. Improving the source record is more valuable than building a longer set of manual corrections every week.

Keep a separate record of provider corrections. If support confirms that a fee was wrong, retain the original charge and the eventual credit, linked to the same case. Removing the wrong charge from your working copy before the credit arrives makes the expected balance disagree with what the provider still holds.

Review access when staff or contractors leave. The person preparing the reconciliation needs access to the relevant reports, while authority to change bank details or send payments needs deliberate assignment. Financial checking shouldn't depend on borrowing the departing event manager's login after the show.

Before signing off, ask someone to trace a small selection of entries in both directions. Start with a bank receipt and find its payout detail. Then start with a ticket payment or refund and find its settlement status. This checks whether the records connect, beyond whether the totals agree.

Include an unusual entry in that selection, such as a partial refund or a deduction belonging to an older event. Ordinary payments can all match while the exception handling fails. Save the outcome and any correction so the next reviewer can see what changed and why.

Use the connected financial view, then check the bank

The aim is to explain your money with the fewest repeated tasks. If ticketing, refunds and promoter payments already share a financial record, use that record. Reserve manual investigation for unsupported adjustments, external costs and differences, rather than recounting every settled ticket each week.

Loopyah's current event financial view brings ticket, door and sponsorship sales, refunds, fees, promoter payments and AI Ads Manager spend into its event figures automatically. It keeps cash separate from profit. That helps you see the sales and deductions in context while checking what has reached the bank.

Your responsibility is to confirm the bank receipts and supply costs or transactions that aren't already captured. You still need to resolve an unfamiliar deduction and agree the accounting treatment of taxes or shared expenses. A connected event view reduces repeated entry, but an unexplained bank difference still needs investigation.

The same applies to commissions. With Loopyah's promoter payments, commission is taken from your payout and paid to the promoter's own account. Check the recorded commission in settlement rather than preparing another manual payment for the same sale. Otherwise, the promoter can be paid twice.

Once receipts are confirmed, put their actual dates into your event cash-flow forecast. Keep money still awaiting payout separate from bank cash. That lets you assess the next supplier bill against funds you can actually use, with expected receipts clearly identified.

Finish the period by saving the source reports, the matched payouts and the remaining exceptions together. Record who checked them and when the outstanding items will be reviewed. Next week should begin with an explained opening balance and a short list of specific follow-ups, rather than another attempt to remember why sales and the bank didn't agree.