Theatrical Distribution and Exhibitor Booking Software: How Do You Know What Film Hire You Are Actually Owed This Week?

Why settlement is where a distributor quietly loses money

Monday morning at a distributor. The weekend numbers are in from three sources: a paid box office reporting feed, direct emails from two circuits with their own report formats, and a spreadsheet from an independent chain that lists sites by a nickname nobody outside that chain uses. The booker is normalizing site names by hand so the grosses line up with the bookings. The film hire due on the opening weekend depends on terms that differ by circuit, by title and sometimes by site: a sliding scale that starts high in week one and steps down, a house allowance deducted before the split at some chains and not at others, aggregation across a circuit rather than per site for one partner, and a holdover term that only applies if the site meets a minimum.

Nobody in the room can state, with confidence, the total film hire owed on this weekend. They will know approximately, and the invoices will go out approximately, and the difference between approximate and exact is real money that leaks quietly every single week of every single release.

Then the second problem arrives. A site reports that the key expired mid run because the projector's media block was swapped after a service call, so Saturday's 19:30 show did not play. Somebody has to reissue against a new certificate immediately. And a third circuit is 60 days late on film hire from a title that left screens in March, which nobody has chased because the aging lives in the accounting system and the relationship lives with the booker.

Across distribution projects we have delivered, the recurring pattern is the same. The booking, the terms, the grosses, the keys and the money each live in a different place, joined by a person. That person is usually excellent, which is exactly why the problem stays invisible until they leave or the slate doubles.

Problem 1: your deal terms are prose, and prose cannot be calculated

Terms are negotiated per circuit and per title, and they are genuinely complicated. A sliding scale by week. A firm term with a floor. A house allowance that varies by site and sometimes by format. Aggregate settlement across a circuit versus site by site, which produce different numbers on the same grosses. Different terms for premium large format or IMAX engagements. Special handling for event cinema, previews, festival dates and four wall arrangements. A minimum play weeks commitment with a penalty if a title is pulled early.

Almost every independent distributor holds these in a booking sheet and a memory. That works until you have 12 titles in the market at once and a booker on holiday. What a custom build does is make terms a structured object that can be evaluated: scale steps by week, deduction rules with their basis and order of application, aggregation level, format overrides, holdover conditions and any floors or caps. Once terms are data, film hire calculation stops being a weekly manual exercise and becomes a report you check rather than a report you build.

Problem 2: grosses arrive in five formats and none of them match your site master

Reported grosses come from a measurement service, from circuit reporting portals, from emails and from a few chains who still send whatever their system produces. Site naming is inconsistent everywhere, sites open, close and rebrand, and a circuit acquisition renames 40 locations overnight. Matching reported figures to your bookings is the hidden labor in every distribution office.

A build treats site identity as a first class problem. There is one site master with aliases, external identifiers per data source, ownership history and screen and format details, and an import pipeline that maps incoming rows to it with a confidence score. Anything below the threshold goes to a small review queue rather than into the numbers. Once mapped, admissions and grosses attach to the booking, weekly, per screen where available, and the film hire calculation runs automatically. The review queue shrinks week over week as aliases are learned. This is not glamorous engineering, and it is the single change that gives back the most hours.

Problem 3: Comscore tells you what happened, Vista runs the cinema, neither settles your deals

Comscore is the measurement layer for theatrical box office and it does that job at a scale no distributor could replicate. What it does not hold is your negotiated terms, so it can tell you a site grossed a figure but not what you are owed on it. Vista Group's platform is anchored on exhibitor operations, meaning ticketing, scheduling, concessions and cinema management, and it is strong there. A distributor sitting on the other side of the table has a different set of objects: titles, release plans, circuit deals, allocations, keys, film hire and collections.

That gap is why almost every distributor we meet has an Excel workbook as the actual system of record for settlement, with the measurement feed pasted in and the terms applied by formula. The workbook works, until the formulas encode an old scale, or a tab breaks silently, or the person who built it moves on. Criticizing these products for not doing distributor settlement is unfair, because that is not what they are for. The point is simply that nobody should conclude the category is covered.

Problem 4: keys, servers and the show that did not play

Digital cinema packages are delivered by drive or electronically, and playback requires a key delivery message issued against the certificate of the specific media block or server at that screen, valid for a stated window. That means your right to be shown is bound to a piece of hardware, and hardware gets serviced, swapped and moved between screens. A key issued for the wrong certificate or with a window that ends before a holdover extension produces a dark screen and an angry exhibitor, and the recovery is manual and urgent.

A build keeps a key register: which title version, which site, which screen, which certificate, which validity window, requested when, issued when, by which facility. Then the system checks forward: every booked performance in the next 14 days is evaluated for whether a valid key covers it. A holdover extension automatically raises key extension requests. The alerting is boring and that is the point. The failure mode you are removing is a Saturday night phone call about a show that will not start.

Problem 5: film hire due, film hire reported, film hire paid, three different numbers

Settlement is not the end of the process. Statements go out, exhibitors query lines, credits get raised for cancelled performances or technical failures, and payments arrive partially and late. In many offices the aging sits in accounting while the relationship sits with the booker, so the person who could get the money paid does not see the debt until it is old.

A build closes that loop. Calculated film hire produces a statement per circuit with the underlying detail, the exhibitor can see and query lines rather than emailing, disputes open as records with a reason code, and the aging report is visible to the person who talks to the customer. The reason codes matter more than they sound: after a season you can see that one circuit's queries are almost all house allowance disputes, which is a negotiation problem, not an admin problem, and you can fix it at the next deal.

What this costs and how long it takes

A first release covering the title and release plan, site master with alias resolution, the deal terms engine, booking allocation and weekly gross import with automated film hire calculation runs $70,000 to $150,000 and ships in 12 to 18 weeks in our delivery experience. A full platform adding key tracking against server certificates, statement generation and exhibitor portal, invoicing and collections with aging and dispute handling, marketing materials distribution and slate level profitability reporting runs $180,000 to $450,000 phased across 6 to 12 months.

What drives price up specifically in theatrical distribution: the number of territories, since reporting sources, currencies, tax treatment and settlement conventions all change at the border. Integration with a box office measurement feed, which is a commercial as much as a technical exercise. Electronic delivery and key issuance integration with the facility that masters your packages. Multi format releasing, because premium large format terms and screen commitments create a separate allocation problem. And historical data migration, which is optional but usually worth it, since your negotiating power comes from knowing what a circuit actually delivered on your last four titles.

What keeps it down: one territory, your existing circuit deals, and settlement only. That is where the leak is.

Build versus buy, and when buying is right

Do not build if you release one or two titles a year, or if you place your films through a third party services deal where someone else does the booking and settlement. Your economics do not support a platform and your booker plus a maintained workbook is a reasonable system at that size. We would tell you to spend the money on prints and advertising instead.

Build when two or more of these are true. You release more than roughly six titles a year across a few hundred sites. Your terms vary meaningfully by circuit, with sliding scales, house allowances and mixed aggregation rules. You operate in more than one territory and reporting formats differ. Settlement currently depends on one workbook and one person. Or your film hire collections regularly run past 60 days without anyone noticing until a quarter closes.

The tipping point is not slate size in itself. It is whether the join between grosses, terms and money is computed or performed. Once it is performed weekly by a human under time pressure, small errors become permanent, because nobody ever goes back and recalculates a weekend from four months ago.

How to choose a developer for distribution and settlement software

Ask them to model a sliding scale with a house allowance and aggregate settlement on a whiteboard before you sign. Someone who has done this will ask whether the allowance is deducted before or after the split, whether aggregation is across the circuit or the site, and what happens in the week a title moves screens. Someone who says the calculation is simple has not read a real deal memo.

Ask how they will handle site identity. If the answer does not include aliases, external identifiers per source, ownership changes and a human review queue for low confidence matches, the gross import will produce numbers nobody trusts, and untrusted numbers get replaced by a spreadsheet within two months.

Ask what they have actually integrated. A box office reporting feed, an exhibitor portal export, an electronic delivery and key issuance system and an accounting package such as Xero, NetSuite or Sage are four separate problems with four different failure modes. Ask for the specific system and the specific direction of data.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to bring in another firm whenever you want. At Digital Heroes the client owns the code from the first commit. A settlement system holds the financial history of your entire release slate, and that is not something to rent.