Concert Touring and Settlement Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the scope creep from settlement into a full tour operating system?

The problem that gets a budget approved is the money. The specification that comes back includes itineraries, day sheets, guest lists, travel booking, hotel blocks, production advancing and a crew messaging feature, because those are the things a touring party touches daily and they are easy to picture.

The trouble is that the daily tooling is a solved problem and the settlement is not. Master Tour is genuinely excellent at advancing, itineraries and day sheets, and rebuilding it produces a worse version of something you already have. Meanwhile the settlement engine, which nobody else sells, gets whatever budget is left after the itinerary screens are built.

There is a second reason the drift happens. Itinerary problems are visible every day, so they generate constant complaints. Settlement problems are only visible in aggregate, once a year, when it is far too late to act. The loudest evidence points at the cheapest problem.

The fix is a boundary in the statement of work. You build the show record with configurable deal expressions, advance capture of cost assumptions, settlement computation with variance flags, and the tour cost ledger. Itineraries and day sheets stay in Master Tour, and the two are linked by the show. Write that sentence down before anyone estimates, because it is the difference between a first release inside a touring cycle and a platform that is still in development when the routing starts.

What goes wrong when you migrate historical settlements and deal terms?

Migration here is not really data movement, it is evidence recovery, and its real value is as a test set.

The first problem is that your history is photographs. Settlement sheets are handwritten on promoter templates, photographed on a phone in poor light, and stored in a messaging thread. There is no structured source to import. Some of it can be transcribed, and the honest question is how far back it is worth going. Our answer is usually one full cycle per deal structure you actually use, because the purpose is not a complete archive, it is a set of test cases.

That is the second point and the important one. Every deal type you run needs at least one real historical settlement transcribed with its inputs and its agreed outcome, so the deal expression can be proved against a number a human already accepted. A settlement engine that has only been tested on invented examples will be wrong in exactly the places promoters differ from each other.

The third problem is deal terms themselves. The contract says guarantee against a percentage of net box office receipts after costs, and the allowable cost list is either an appendix or a verbal understanding that has drifted over three tours with the same promoter. Extracting those terms is work for whoever negotiates them, not for a developer, and it usually reveals that two people in the business hold different beliefs about the same deal. Better to find that out during migration than at settlement.

Why do ticketing feeds and accounting integrations break after launch?

Because in this business the counts and the ledger both arrive from parties with their own systems and their own reasons for delay.

Ticketing is inconsistent by market. In some territories you receive a feed with counts by price tier. In others you receive whatever the promoter prints at settlement, and that is the only number you will get. Design for both from the start: a structured feed where one exists, and a manual entry path with the source recorded, so a count typed from a printout is visibly different from a count received from a system. Where a feed exists, expect it to change without notice, so validate the shape on arrival and quarantine anything unexpected rather than loading it.

The accounting side breaks more slowly and more expensively. Management companies, promoters and production companies all run different ledgers, and the mapping between show level costs and general ledger accounts is bespoke. It works at launch because someone built the mapping for the accounts in use at the time. Then a new cost category appears mid tour, freight or a visa agent fee, and it posts to a suspense account or to nothing, and the tour profit and loss quietly diverges from the accounts.

Fix it with an explicit unmapped state that blocks nothing operationally but appears on a list the tour accountant reviews weekly. The failure to avoid is silent defaulting, where an unrecognised category is posted somewhere plausible and nobody knows the number is wrong until a year end reconciliation.

What happens when withholding documentation and work permits are not covered?

You leave reclaimable money in other countries and you cancel shows for administrative reasons.

Foreign entertainer withholding differs by territory and by treaty position, and the correct treatment for your artist and entity structure is a question for a specialist adviser rather than for software. What software must do is capture what was actually deducted at each settlement, in the local currency, with the supporting paperwork attached to the show. When that documentation exists only as a photograph in a messaging thread, the reclaim your adviser could have pursued becomes impractical to evidence, and it is regularly abandoned for that reason alone. This is not an exotic feature. It is a document, a figure and a link to a show, captured at the moment the deduction is made.

Permits fail harder. A visa or work permit that does not cover a specific date or a specific territory is a cancelled show, a forfeited guarantee and a routing you cannot repair. The reason this happens is not carelessness, it is that the itinerary lives in one system and the personnel records live in a folder, so nothing checks one against the other.

The fix is a set of date range checks nobody has because the two data sets have never been in the same place. Each person carries permit coverage with dates and territories, each show carries a date and a country, and the routing validates itself continuously. A border crossing on a date where one crew member's coverage has lapsed should surface during routing, not at immigration.

Should you build custom or configure what you already own?

If you are running straight guarantee shows in one currency and your real problem is logistics rather than money, do not build. Master Tour is a strong product for exactly that and you should keep using it. Thirty club shows a year on flat guarantees needs a good tour manager and a good accountant, not software.

If you are a promoter or venue whose pain is holds, offers and confirmations rather than settlement, Prism.fm addresses that specific workflow and configuring it properly will get you further than a build. Muzeek is a reasonable fit for acts at a scale where booking and payment collection are the bottleneck. In each case, check whether the thing failing is the tool or the process: advance assumptions that were never written down anywhere cannot be compared to settlement figures by any software.

Build when the settlement itself is where value leaks. Concretely: you run versus deals and co promotes, so the number depends on a formula rather than on a figure. Settlements happen against promoter cost lists you cannot verify in the room. Your tour profit and loss takes weeks to assemble after the routing ends, which means it can never change a decision. Or you tour internationally and withholding documentation goes missing. Touring companies consistently overinvest in itinerary tooling and underinvest in the settlement record, for the reason above: one problem complains daily and the other only complains annually.

How do hidden costs get into a touring software quote?

They enter through deal variety, through currency, and through the assumption that connectivity exists.

• Each deal structure is a formula that needs testing. Flat guarantee, guarantee against a percentage, guarantee plus bonus above breakeven, door deals, co promotes and festival buyouts each define gross and allowable deductions differently. Six structures is six sets of test cases against real settlements.
• Multi currency done properly. Rate policy, revaluation and an audit trail, not a conversion at export. The original currency and amount must survive alongside the converted figure or you cannot defend a number later.
• Offline everywhere. Back offices, trucks and border crossings all lack usable connectivity and all generate data. This is not a phase two item, and treating it as one means the sheet gets photographed again and nothing has changed.
• Accounting mapping. Bespoke per company, and it needs an unmapped state rather than a plausible default.
• Ticketing by market. A feed in one territory and a printout in another means two intake paths, both with provenance recorded.
• Per diem and payroll rules. Day rates and per diems run on different clocks and vary by contract.

What separates a build that works from one that fails here?

Four things, and you can test three of them in one conversation.

Ask them to express a guarantee against a percentage of net after costs, with a bonus tier, in front of you. If they reach for a fixed set of fields rather than a configurable deal expression, they will build a calculator for one deal type while you use six, and the other five will go back into a spreadsheet within a month.

Ask what happens when a tour manager opens the app in a promoter's office with no signal. It has to work fully offline, hold the settlement locally with a device timestamp and sync later. Anything else means the sheet gets photographed again.

Ask how currency is handled. The right answer captures the original currency and amount, applies a rate under a stated policy and keeps both. Converting at entry and discarding the source figure is a decision you cannot undo.

Then settle ownership in writing before kickoff, covering the repository, the infrastructure and the settlement data. At Digital Heroes the client owns the code and the data from the first commit. Your show by show settlement history is the evidence base for every future negotiation with those promoters, and it is worth more each year it accumulates, which is exactly why it must be portable.