How to settle cashless takings with festival traders

Your festival has finished, the traders have packed up, and the cashless dashboard shows a healthy weekend. Now a food trader asks when they're getting paid. You send the total from their sales report, less your commission, and they come back with a different figure. They excluded refunds. You included them. Neither of you thinks that's what you agreed.

Festival vendor cashless settlement is the process of working out what each trader earned, checking the adjustments, and paying the amount your agreement says they're owed. Start with completed purchases allocated to that trader, apply the agreed treatment of refunds and charges, then show the calculation in a statement they can verify. The bank transfer is the last part of that work.

The first thing you want to do is agree the calculation before anyone trades. Then configure the payment system to produce the evidence that calculation needs. We'll work through the money, a complete example and the checks that let you pay traders without reopening every conversation after the event.

Start with who sold what and who holds the money

Cashless can mean different arrangements. A trader might take contactless card payments through their own account and receive the money directly. You then collect a pitch fee or commission separately. Alternatively, all purchases might run through a festival payment arrangement, with money collected centrally and amounts later paid to traders. A prepaid wristband adds another distinction because loading a wallet and buying lunch are separate transactions.

This guide focuses on centrally collected takings that you need to allocate and pay out. If traders receive their own takings, you still need reliable sales evidence for a percentage fee, but you aren't sending them their sales proceeds. Be clear about that distinction when you ask a supplier to demonstrate settlement. A report showing purchases doesn't establish who can move the money.

Write down the businesses involved. Who sells the food to the attendee? Who contracts with the payment provider? Which organisation receives the collected funds? Who owes the trader, and who can authorise a refund? Answer those questions for your actual contracts rather than inferring the answers from the logo printed on a terminal.

The roles can affect tax treatment as well as payment responsibilities. HMRC's VAT guidance on agents distinguishes agents acting in their principals' names from those acting in their own names. Receiving payment alone doesn't settle how the underlying supply should be treated. Ask your accountant to confirm the arrangement and required documents before configuring the statement. UK guidance illustrates the issue; your local rules determine your treatment.

For prepaid arrangements, also confirm who issues the balance and what rules apply to holding and transferring funds. The FCA's limited network exclusion guidance explains that certain payment arrangements have specific conditions and notification requirements. A festival wristband doesn't establish an exemption by itself. Have your provider explain its role, and get advice on any responsibility your event business takes on.

Turn the trader agreement into a calculation

A commission percentage isn't a complete settlement agreement. You need to define the amount it applies to. Does sales mean the price paid by customers, the amount excluding applicable sales taxes, or the amount left after eligible purchase refunds? Are tips included? What happens when the festival funds a promotional discount? Those choices change the trader's payment even when the headline rate stays the same.

Use the same words in the agreement, the payment configuration and the statement. If the contract says commission applies to sales after purchase refunds, a field labelled gross revenue cannot quietly become the calculation base. Get a sample statement from your provider and work through it with finance before you ask traders to sign. You'll discover missing fields while there's still time to change them.

Our event vendor agreement template covers the wider booking relationship. Add a settlement schedule for the cashless arrangement. It should identify the sales period, included outlets, commission basis, permitted deductions, payment timetable and route for challenging an error. Keep the amount owed for trading separate from responsibilities for physical damage or a disputed site service.

Pitch fees deserve particular attention. A minimum fee credited against commission differs from a pitch fee charged in addition to commission. Suppose a fictional agreement has a $600 minimum and calculated commission of $900. Crediting the minimum leaves $900 in total fees. Charging both leaves $1,500. If $600 was already paid, the remaining deduction is different again. Write the intended method explicitly and test it before trading.

Decide how rounding works too. Rounding commission on every purchase can produce a different total from applying the percentage once to the eligible sales total. Specify the calculation level and currency precision, then have the system follow that method. Don't ask the trader to accept an unexplained small difference because it happens to be small. Repeated differences make the rest of the statement harder to trust.

Keep wallet money separate from trader sales

An attendee loads $80 onto a festival wallet, spends $30 at a food stall and leaves $50 unused. In this fictional example, the food stall has $30 of purchases allocated to it. The remaining $50 hasn't been spent there. Paying a trader a share of top-ups would allocate money for goods they never supplied and leave the festival with a separate refund obligation.

Keep a record of wallet funding and remaining balances, and another record of purchases by trader. They need to reconcile within the payment system, but they answer different questions. One tells you what the attendee funded and used. The other tells you which business made a sale. A successful top-up doesn't tell you whether a particular trader's lunch order completed.

The same distinction matters when money goes back. Returning unused wallet balance isn't a refund of the food purchase. A refund for an incorrect food order should identify that purchase and follow the agreed trader adjustment rule. Otherwise, a general refund export can deduct customer money from the wrong business or reduce the same trader's takings twice.

Festival-funded credit also needs its own treatment. If you give staff a meal allowance or sell a ticket with food credit included, decide who funds redemption and how traders get paid. A trader supplying the meal may still be owed its agreed value even though the attendee didn't load money for that purchase. Confirm the funding and accounting treatment before distributing the credit.

You can handle those programmes without making every trader learn your entire ticket offer. Tell them which products qualify, how a valid redemption appears, the amount they receive and the evidence available if it fails. Internally, allocate the cost to the programme that created it. That keeps promotional spending visible rather than reducing an outlet's takings through an unexplained adjustment.

Configure records around each trader

Give each trader a stable identifier connected to its legal business name. Then map every outlet and terminal that can sell on its behalf. A business running two food stalls needs both sets of purchases allocated correctly. A replacement terminal needs the same mapping as the device it replaces. These are simple setup choices with very expensive consequences when nobody checks them.

Keep the trader name a customer recognises, the legal payment recipient and the outlet name as separate fields where your system allows it. They often differ for legitimate reasons. Changing a display name shouldn't create a new payment recipient, and moving a terminal between stalls shouldn't move yesterday's purchases with it. Confirm the supplier's actual behaviour rather than relying on how the screen looks.

Before opening, make a test purchase through each configured outlet and follow it into the trader report. Test the refund route and a discounted purchase too. Mark test transactions clearly and remove or reverse them through the supported process. Keep their references so the finance team can explain their treatment later. An undocumented test sale can look like real money owed.

Agree who can change prices, issue refunds and move devices between traders. Staff need enough access to serve customers and fix mistakes, while changes affecting another business need an accountable approver. If a supervisor temporarily reallocates a device during a rush, record the effective time and reason. The settlement team needs to distinguish that approved change from a mapping error.

Take daily snapshots or exports using the provider's supported reporting process. Preserve the original files and record their reporting period and status. You want to compare what a trader saw on Saturday night with the final total after devices synchronised. Replacing every earlier export with a new file removes the evidence that would explain the difference.

Work through a complete trader payment

Let's use one fictional food trader, with all amounts in USD. These figures are illustrative assumptions, not market rates or tax advice. To keep the calculation clear, assume there are no applicable sales taxes or taxes on the festival's charges in this example. Real statements need the treatment your accountant confirms. The trader has no tips, promotional credit or deposit in this calculation.

The final transaction report shows $24,000 in completed purchases for the agreed trading period. Purchase refunds allocated to this trader total $400. The contract applies a 20% commission to purchases after those refunds. That leaves a commission base of $23,600 and a festival commission of $4,720. The trader's share after commission is therefore $18,880.

The contract also permits a $300 equipment charge and $180 of identified payment charges. Those are separate from commission and are stated without further tax in this example. Deducting them leaves $18,400 owed to the trader before previous payments. The festival already paid a $10,000 advance, so the remaining amount to transfer is $8,400.

You should be able to explain that in the same order on the statement. Purchases of $24,000, minus $400 in purchase refunds, leave $23,600. Deduct $4,720 commission, $300 equipment and $180 payment charges to reach $18,400. Deduct the $10,000 advance to reach the $8,400 balance. The advance reduces the remaining payment; it doesn't reduce sales or commission.

Now check it backwards. The trader receives $18,400 across the advance and final transfer. The festival retains $4,720 commission and $480 in agreed charges. Together they account for the $23,600 remaining after purchase refunds. That's a useful check on the arithmetic. It doesn't prove the underlying purchases, refund allocation or agreed charges are correct; you still need their records.

What if the trader already paid the $300 equipment invoice before the event? It mustn't be deducted again. Record the charge and its prior payment clearly, or leave the paid invoice outside the settlement deductions with a cross-reference. The same applies to deposits and pitch fees. Seeing a charge on an agreement is no evidence that it remains unpaid.

What if the refund report already presents sales net of the $400? Start at $23,600 and show how the report defines it. Don't subtract the refunds again. Before using any export, confirm whether its total includes reversals, discounts and refunds. The most common spreadsheet mistake can be a correct formula applied to a total that already contains the adjustment.

Reconcile the records before approving payment

Start by closing the agreed trading period and confirming that every relevant device has uploaded its records. A device still holding offline transactions can leave the central report incomplete. Ask the provider how it identifies outstanding uploads and what it considers a final transaction. An approved-looking screen during a network interruption isn't enough evidence to assume the money has cleared.

Ask what happens if a device cannot be recovered at all. The provider should explain which records exist centrally, what can be reconstructed and which amounts remain uncertain. Agree how your team will investigate with the trader and how the contract handles missing evidence. Don't invent sales to fill a gap or assume the absence of an uploaded record proves no purchase happened. Record the uncertainty, preserve the available evidence and use the agreed escalation route. A lost terminal needs an investigation before anyone changes the trader's payment entitlement permanently.

Next, compare the trader-level totals with the full event purchase report. Every included purchase should belong to an identified trader or an explicitly defined festival outlet. Investigate unallocated purchases, duplicated references and unexpected activity outside trading hours. Don't spread an unexplained difference across traders to make the event total balance. Find what created it and correct the affected records through the supported process.

Then compare the payment provider's movement of money with your collection account. Expect timing differences where transactions are still pending or transfers are in transit. Record those differences by reference and status rather than forcing the sales report to equal one bank deposit. A deposit might combine several trading periods or arrive after fees have already been deducted.

Keep those payment fees distinct from charges you pass to traders. Your provider may deduct its own costs before sending funds to you. If your trader statement then subtracts the contractually agreed trader share, make sure finance records both sides correctly. The business can recover an agreed cost without pretending the provider deposited the gross amount. Your bank reconciliation and trader calculation serve different purposes.

Give each unresolved difference an owner and a next check. A missing device upload belongs with operations and the supplier. A charge allocated to the wrong trader needs transaction evidence and correction. A commission disagreement needs the signed schedule. Treating all differences as a finance problem makes resolution slower because the person checking the totals may not have the information needed.

Make refunds and later disputes traceable

Agree who can authorise a purchase refund during the festival and afterwards. Traders need a practical route to correct a wrong order, but the central payment team needs the purchase reference and reason. A customer complaint shouldn't become an undocumented cash repayment beside a digital sale that still looks complete. Support staff should know when they need trader approval and when the event must investigate directly.

Our event refund policy guide covers the wider customer communication. For settlement, the task is narrower. Identify which purchase changed, whether money actually returned and how that affects the trader's share. An approved refund request and a completed refund can have different statuses. Your statement should follow the agreed rule and show any pending amount separately.

Later card disputes need similar care. A chargeback is a payment reversed through the card dispute process, rather than an ordinary purchase refund you issue. In a prepaid wallet arrangement, a disputed top-up may have funded purchases at several outlets. Don't automatically charge one trader for the entire funding dispute. Ask the provider for the evidence and apply the responsibility your contract actually assigns.

If you agree to hold money back against defined unresolved exposure, explain the basis and release process before trading. State which events can trigger a hold, how the amount is calculated, when it will be reviewed and how the trader can challenge it. A general concern that something might happen doesn't explain an arbitrary deduction. Check that the proposed arrangement is lawful and proportionate for the contracts involved.

You may be able to pay an undisputed amount while investigating a specific difference, depending on the agreement and applicable rules. Show the amount paid, the amount awaiting resolution and the next review date. Don't mark the entire account settled while a balance remains outstanding. Equally, don't leave a trader guessing whether a small disputed item has stopped their whole payment.

Send a statement a trader can actually check

A useful statement identifies the event, trader, covered dates, currency and issue date. It shows the purchase total and each adjustment in the order you applied them, with the commission percentage and its base. Previous payments have their own line. Finish with the amount now due, its payment date and the bank reference the trader should expect.

Attach or provide access to the supporting detail the trader needs. That might be transaction-level sales, refund references and the invoices behind equipment or power charges. Keep customer information out of the trader's export unless it is necessary and appropriate to share. Traders need evidence for their own account, not access to everyone else's purchases or the whole festival's payment data.

Use the same statement version when requesting approval and preparing the transfer. If a correction changes the amount, issue a clearly identified replacement and preserve the original. Explain the changed line rather than asking the trader to compare two long files. A short note saying that an already-paid equipment charge was removed tells them exactly why the final payment increased.

Set a practical way to report discrepancies, with a named contact and information to include. Ask for the statement reference, disputed line, reason and supporting record. Make it possible to ask a question without automatically forfeiting payment. Any review deadline should fit the agreement and applicable law; it shouldn't appear for the first time in the message containing the statement.

Be careful about what you call the document. A settlement statement showing a net payment isn't automatically a valid tax invoice. HMRC's self-billing guidance explains the formal agreement and invoice requirements for UK VAT self-billing. Whether that arrangement fits your supply relationship needs checking. Don't label a report self-billed simply because your team generated it on the trader's behalf.

Keep the required invoices and records alongside the statement. HMRC's VAT record-keeping guidance lists sales and purchase records, invoices, credit notes and self-billing records among the material UK businesses may need. The useful operational lesson is to preserve the evidence behind the net transfer. Your accountant should set the document requirements and retention period for your business.

Pay on a timetable you can deliver

Work backwards from the promised payment date. Allow time for final uploads, provider reports, statement checks, trader questions, approval and bank processing. Agree which milestones depend on the payment supplier and confirm its commitments in writing. If the supplier cannot produce final data before your promised date, resolve the gap before you recruit traders into the arrangement.

An advance can help traders manage stock and staff costs, but it needs an agreed basis. Specify how you calculate it, who approves it and how it appears in the final statement. Keep the advance in the payment history even if a later report changes expected takings. Otherwise, the next person preparing the payout may pay the same amount again.

Keep trader money visible in your event cash forecast. The collection account can look healthy while much of its balance is owed to traders or customers. Separate the festival's earned charges, trader amounts payable, attendee balances and unresolved items in your records. Our event budget guide helps with the broader forecast; use the settlement records to establish the amounts you actually owe.

Have one person prepare the payment file and another check the payee, approved amount and account details before release. The FBI's business email compromise guidance recommends verifying payment requests and changes in account information using a trusted channel. Call a previously verified contact if banking details change. Don't rely on the number supplied in the same message requesting the change.

After sending the payment, record the transfer reference and actual date, then check its status. A rejected transfer is still an unpaid balance. Tell the trader what happened and resolve the recipient details through your verification process. When the money arrives, the statement, approved calculation and payment record should all point to the same amount.

Deal with mixed trading arrangements separately

You may have festival bars using the central system, food traders using prepaid balances and craft sellers collecting card payments themselves. Keep the settlement method attached to each trader record. Otherwise, the payment team might prepare a transfer for a business that already received its takings directly, or miss a centrally collected outlet because its terminal looked different.

For a trader collecting its own money, your settlement statement may be a commission calculation and an invoice for what it owes the festival. Request the agreed reporting evidence and reconcile any advance pitch payment against the correct fee. Don't describe that invoice as a deduction from centrally held takings when your business never held those takings.

If a trader has permission to accept an alternative payment method during an outage, record when permission started and ended. Agree how those sales enter the commission calculation, who receives the money and what evidence the trader must supply. You need to include the sale once and account for the right recipient. Adding every reported sale to the central payout would pay the trader twice for money it collected independently.

Tips, returnable cup deposits and optional donations also need distinct treatment. A customer's payment can contain more than the price of a product. Confirm who is entitled to each component and which amounts form the commission base. Then make sure the sales export can separate them. If the system cannot distinguish amounts that your agreement treats differently, simplify the offer or fix the reporting before opening.

Currency is another decision to settle early. Keep the trader's agreed settlement currency explicit and explain any conversion method and charges before accepting the booking. Don't combine totals in different currencies and apply a percentage to the result. If customers can see a different currency at checkout, ask the provider which currency its transaction and transfer reports use and how differences are documented.

Resolve a discrepancy without rewriting the whole account

Suppose the fictional trader challenges the $180 payment charge. The total sales and refund records agree, but the trader says the contract makes that charge the festival's responsibility. Pull the signed schedule and the provider's charge detail. The question is who agreed to pay the charge, not whether your bank balance is $180 lower.

If the trader is correct, remove the deduction through your approved correction process. Its total entitlement becomes $18,580, and the balance after the $10,000 advance becomes $8,580. Your business absorbs the $180 cost. Keep the reason with the revised statement so finance doesn't restore the deduction while trying to make the provider report match.

If the agreement supports the deduction but the underlying amount is wrong, correct only that amount and explain the evidence. If you still disagree about the contract, follow its dispute process and obtain appropriate advice. Avoid editing the agreement retrospectively to make the calculation work. The statement should reflect the agreement both parties made, with any later change recorded as a change.

Close the account and improve the next edition

Once the agreed amounts are paid, confirm whether any named items remain open. Record the reason, responsible person and promised review date for each one. A final statement should distinguish a genuinely closed account from one with a retained amount or a pending correction. Keep the trader informed when the status changes rather than waiting for another payment enquiry.

Review settlement alongside the event's trading performance. Which outlets needed mapping corrections? Which charges caused repeated questions? Did your payment promise allow enough time for the supplier's actual reporting? Those observations tell you what to change in next edition's agreement and setup. A lower complaint count alone doesn't prove the records were right; check the actual errors and their causes.

Keep a clean sample statement and the confirmed calculation rules for the next supplier discussion. Update the example when you change the commercial arrangement. That gives your team something concrete to test before anyone signs, and gives traders a preview of the information they'll receive after the event.

Test the difficult cases before festival weekend

Take the fictional trader example into your supplier demonstration. Ask the supplier to show the completed purchase, the $400 purchase refund, the commission calculation and the previous advance. Then ask what happens if the refund arrives after an advance was paid. A system that can produce a total but can't explain those changes will leave your team doing the explanation later.

Test a terminal moved between outlets, an offline device recovered after closing and a trader who already paid an equipment invoice. Ask which report changes and what evidence remains. You don't need to simulate every possible incident. You do need confidence that ordinary mistakes can be corrected without losing the purchase history or creating a second payment.

Finish by sending the sample statement to someone who didn't configure the system. Give them the agreed schedule and ask them to explain the final amount. If they have to guess what sales includes or where an advance went, improve the statement now. The traders packing up after your festival should receive the same clear explanation, supported by their own actual records.