Entertainment Crew Payroll Software: Turning a Production Timecard Into Compliant Gross Pay

Why a crew timecard is not hours multiplied by a rate

A grip works Thursday. Call at 6am, first meal not called until 12:40pm, wrap at 10:15pm, and Friday's call is at 7am. On a spreadsheet that is 16 hours and 15 minutes. On an actual union agreement it is a straight time block, an overtime block, a further premium block once the day crosses the applicable double time threshold, a meal penalty that started accruing when the six hour mark passed and escalates by increment, and a turnaround question because the rest period between wrap and the next call is short.

Now multiply by 140 crew, across three unions and a group of non union positions, on a show that shot two days in a neighbouring state, where four of those people work through loan out corporations and two are on a distant location with per diem. Then add box rentals, mileage, a sixth day worked at premium for the construction department, and a holiday.

Every one of those elements comes from a specific agreement with a specific rate table that was negotiated for a specific term. When the contract cycle turns, the tables change, and the change is retroactive often enough that it matters. Get any of it wrong and you do not get a quiet correction. You get a grievance, a back pay calculation across a department, and a conversation with a business agent who has done this longer than you have.

Problem 1: the rules are a dated rate table, not code

This is the architectural decision that determines whether the project succeeds. Union agreements are dated documents with schedules of rates by classification, by area, by production type and by term. IATSE local agreements differ from each other and from an area standards agreement. Teamsters classifications carry their own structure. Directors, performers and writers all sit under separate agreements with different mechanics entirely. Rates change on effective dates, and you will be asked to reprocess a period under the rules that applied then, not the rules that apply now.

The wrong build encodes rules in application logic. It works for one agreement, then every new client agreement becomes a development ticket, and within eighteen months a compliance analyst is waiting three weeks for a rate change that takes effect next Monday.

What a custom build does: rules and rates live as dated configuration owned by compliance staff, not engineers. A rate is a record with an agreement, a classification, an area, a production type, an effective date range and a value. A rule is a parameterised construct: overtime after this many hours, premium multiplier at that threshold, meal penalty accruing in these increments at these amounts, turnaround measured this way with this consequence. Every calculation stores the rule version it used, so reprocessing a period six months later reproduces exactly what was paid, and a retroactive increase produces an explainable delta rather than a mystery.

Problem 2: the day is a sequence of events, not a total

Most payroll systems think in hours worked. Production payroll thinks in a timeline: call, meal called, meal returned, second meal, wrap, and next call. Meal penalties depend on elapsed time from call or from the previous meal, not from total hours. Turnaround depends on the gap between wrap and the following call, which spans two payroll days and sometimes two weeks. Night premium depends on clock time, not duration. A forced call has consequences that only exist because of when the previous day ended.

What a custom build does: capture the day as timestamped events from the source, meaning the production report and the second assistant director's records, and calculate from the sequence. Then show the crew member and the department head exactly which increments accrued and why, on the timecard itself, before approval. Most disputes are not about entitlement. They are about a number appearing with no explanation attached. Showing the derivation removes the argument, and it also catches genuine data errors while the people who were there can still remember the day.

Problem 3: fringes and remittance are where fines actually come from

Gross pay is the visible part. The obligations attached to it are where a bureau gets into real difficulty. Pension, health and welfare contributions calculate per hour or per day at rates set by agreement and must be remitted to the correct fund with a file the fund can read. Vacation and holiday accruals sit alongside them. Different unions remit to different administrators on different schedules with different file layouts, and a remittance that is late or misformatted becomes a delinquency, which becomes a problem for the crew member's benefit eligibility, which becomes a phone call you do not want.

What a custom build does: treat each fund as a configured destination with its own contribution rules, remittance schedule, file format and reconciliation. Contributions calculate alongside gross and post at the same time, not in a month end reconstruction. Build a control that compares what was calculated, what was remitted and what the fund acknowledged, and surface breaks immediately. This is unglamorous plumbing and it is the single area where a home built system most often fails against an incumbent, because Cast and Crew and Entertainment Partners have been maintaining these relationships and formats for decades.

Problem 4: state lines, loan outs and the paperwork behind them

A show shoots in one state, has a production office in another, and hires people who live in a third. That creates withholding obligations, unemployment registrations, nonresident filings and reciprocity questions that vary by combination. Workers compensation classification codes differ by craft and by state, and getting a code wrong changes premium materially. Some jurisdictions have their own wage payment timing rules that a national schedule can violate without anyone noticing.

Loan out companies add another layer. A performer or department head engaged through their corporation is not an individual employee for payroll purposes, which changes withholding, fringe handling and the paperwork you must hold to support the treatment. Bureaus that treat loan outs casually create exposure for themselves and for their clients.

What a custom build does: model the employment relationship type explicitly and let it drive downstream treatment rather than leaving it as a flag someone sets. Registrations, workers compensation codes and jurisdictional rules become configuration by state with effective dates. Start paperwork completeness is enforced as a gate: no start slip, no timecard entry, which sounds harsh and is far kinder than discovering an incomplete file at year end.

Problem 5: production cares about the cost report, not the payslip

The unit production manager does not read your payroll register. They read a cost report against a budget, by account code, by department, by episode. Payroll is the largest line in that report and it arrives as an allocated total that nobody can interrogate. When the number is high, the question is which day and which department, and that question takes somebody a day to answer.

Add tax incentives. Qualifying labour spend has to be identifiable by jurisdiction and by qualifying criteria, and the criteria differ by programme. If your payroll data cannot produce that view, the production's incentive claim gets built by hand from exports, which is both expensive and risky.

What a custom build does: cost coding is captured at the timecard, not applied afterwards, with account, department, episode and any incentive qualifying flags carried through calculation into the register. Then the cost report is a query, drillable from a total down to a specific person on a specific day. For a payroll bureau this is a genuine differentiator, because clients change providers over reporting quality far more often than over rates.

What this costs and how long it takes

A first release covering digital start paperwork, timecards with event capture and approval routing, a versioned rules and rate engine, and gross pay calculation for a bounded set of agreements runs $90,000 to $190,000 and ships in 16 to 22 weeks. That is longer and dearer than most categories at similar scope, and the reason is that every calculation must be verified against known correct output before anyone relies on it.

A full platform adding fringe calculation with fund remittance files, multi state withholding and registration handling, loan out treatment, cost coding and client reporting, and a client portal runs $250,000 to $600,000 phased over 9 to 18 months.

We insist on one thing in this category and will not compromise on it: a parallel run. New system and incumbent process the same weeks, side by side, until the gross to net matches on every crew member for at least four consecutive weeks including a week with a holiday, a sixth day and a distant location. Build that parallel period into the budget and the timeline, because a payroll system that goes live on confidence rather than evidence will find its errors on a Thursday with 140 people waiting.

What drives cost up: the number of distinct agreements in scope, at real weeks each. Countries, since Canadian and United Kingdom production payroll are different systems, not variations. Residuals, which is a separate domain and should not be scoped into a first build. And the depth of client reporting a bureau needs to be competitive.

Build versus buy, and when buying is the right call

Buy. For nearly every reader of this page, that is the answer, and we would rather say so than take a project that should not exist. Cast and Crew, Entertainment Partners, Wrapbook and Greenslate maintain rate tables across contract cycles, hold the fund relationships, carry the registrations and absorb the compliance risk. A production company or even a mid sized production group that builds its own payroll engine to save fees has taken on a permanent maintenance obligation in exchange for a one time saving, and the maintenance never stops because the agreements never stop changing.

Build when payroll is your product, not your overhead. Specifically: you are a payroll bureau processing meaningful volume whose margin depends on automation, or an international payroll operation where no incumbent covers your territories properly, or a large production group already acting as its own employer of record where the calculation is happening in house regardless and currently sits in spreadsheets.

There is a third path worth naming, and it is the one most companies should actually take. Keep the incumbent for calculation, remittance and compliance, and build only the operational layer around it: digital start paperwork, timecard capture with proper event sequencing, approval routing, cost coding and reporting. That is a $60,000 to $140,000 project rather than a $400,000 one, it removes most of the daily pain, and it leaves the regulated calculation with people who carry the risk for a living.

How to choose a developer for entertainment payroll software

Ask how they will version rules and rates by effective date, and how they would reprocess a period from eight months ago under the rules that applied then. If the answer involves editing code or updating a table in place, stop. Retroactive processing is not an edge case in this industry, it is a normal Tuesday after a contract settles.

Ask them to calculate the Thursday described at the top of this page from timestamps, including meal penalty increments and the turnaround consequence. A developer who has done payroll but not production payroll will compute total hours and miss the entire structure. That gap is the domain.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire any other firm. At Digital Heroes the client owns the code from the first commit. A bureau whose calculation engine is controlled by a vendor has outsourced the thing its clients are paying it to be responsible for, and no commercial arrangement makes that a sensible position.