Contracts & the pay engine
How contracts, riders, work types, and premiums layer together to price a week of work.
Every dollar Function TimeTrack estimates comes from your contract. A contract is a structured version of the deal you're working under — the base rate, the overtime rules, the premiums, the holidays, and the benefit contributions. This page explains, in plain terms, how those pieces fit together and how a week gets priced. It's an overview for understanding your numbers, not a spec of the internal math.
The mental model: log reality, let the engine classify
The single most important idea: you record what happened, and the engine works out what it's worth. You do not label hours as straight time, overtime, or double time yourself. You log:
- the calls you worked (start and end times, to the minute),
- any travel time, tagged separately from work,
- your meal breaks and other unpaid windows.
The engine then reads your contract's rules and derives the pay classifications, penalties, and premiums. When a real-world exception happened that the rules don't capture, you can override that specific day — reality is what you log, and overrides are how you handle the odd exception.
The layers of a contract
A contract prices work in layers. Each layer answers a different question.
Base pay
The foundation: your hourly rate, day rate, or weekly salary. A day rate isn't a separate kind of pay — it's expressed as an hourly rate plus a minimum-call guarantee and a rule for what happens beyond the minimum (straight time, immediate overtime, or absorbed into the day). That lets one model handle "flat $X for the day," "guaranteed 10 then overtime," and true hourly work.
Work types
A single call can be different kinds of work that pay differently — a rehearsal day versus a performance day, for instance. Those are the contract's work types. When you set a day's work type in the week editor, the engine prices that day using the rate and premiums that work type carries.
Overtime and day-type rules
Your contract defines when straight time turns into overtime and double time — daily thresholds (after 8, 10, or 12 hours), weekly thresholds (past 40), sixth- and seventh-day rules, and night work. Because you logged real times and meal breaks, the engine can apply these consistently across the week.
Ladders with more than three rungs
Some agreements go past double time — for example 2.5× after fourteen worked hours and
3× past fifteen elapsed hours. Those upper rungs are supported as extended-hour rungs,
and each one names which quantity it measures:
- Worked hours are paid work hours — what the classifier buckets.
- Elapsed hours count from the time you reported, meal periods included.
Fourteen worked hours inside a fourteen-hour span and fourteen worked hours inside a sixteen-hour span owe different money, so the distinction is carried explicitly rather than guessed. Each rung tops up only the shortfall over what the hour was already paid, so a rung the base ladder already satisfies costs nothing.
Extended rungs assume a non-compounding agreement
This shape is only equivalent to a real fourth band where the agreement says premiums do not compound. On a contract that does compound, the top rungs need different treatment — so these are authored only where the paper says so.
Premiums
Premiums are adjustments stacked on top of base pay. They come in two broad shapes:
- Rate premiums — multipliers tied to a day-type or work-type context (a Sunday multiplier,
a night premium). Whether they compound is a term of your contract, not a fixed behaviour of
the app. Each contract carries a stacking policy:
- Multiply — premiums compound. A Sunday worked into overtime layers the overtime multiplier on top of the Sunday multiplier.
- Add — the marginal parts of each premium are summed, not multiplied.
- Highest wins — the premiums are compared by the dollars each would actually pay, and the biggest one applies alone. Many agreements say this in so many words: "overtime and premium rates may not be compounded."
- Event premiums — flat amounts owed because a qualifying event happened, regardless of hours. These are either a flat dollar figure per event (for example a per-performance pyro fee) or a fraction of your weekly salary per event (for example a holiday-worked premium of one-sixth of the week). See Event tagging for how these get triggered.
Riders
A rider is a layer of modifiers applied on top of the base contract — the way a real deal memo amends a standard agreement. Riders can adjust rates or add premiums without you having to rebuild the whole contract. The base contract plus its riders together form the effective set of rules the engine uses.
Holidays
Your contract carries a holiday calendar — the specific dates that count as holidays under your agreement. When you work one of those dates, the engine automatically recognizes it and fires the contract's holiday premium. You don't tag holidays by hand; the calendar does it. (Non-calendar events like pyro or costume fees are tagged by hand — that's the manual side covered in Event tagging.)
A holiday can also carry an observation shift, for agreements that move a holiday off a weekend — Saturday to the previous Friday, Sunday to the following Monday, or both to Monday. The default is no shift: the calendar date is the observed date, because moving a weekend holiday is a convention and not every agreement adopts it.
Fund contributions
Finally, the contract describes how much flows into each of your Local's benefit funds from a week's earnings. This is where pay meets benefits — see Benefits & union funds.
How a week gets priced
Putting the layers together, pricing a week runs roughly like this:
- Read reality. The engine takes each day's worked and travel sessions and your meal breaks. Times are logged to the minute but billed at your contract's rounding increment.
- Classify the hours. Using your contract's overtime and day-type rules, each stretch of time becomes straight time, overtime, or double time.
- Apply work-type and rate premiums. The day's work type and any context multipliers adjust the rate, compounding where the rules call for it.
- Evaluate penalties. Meal-penalty and turnaround rules are checked against the breaks and gaps you logged.
- Add event premiums. Auto-detected holidays and any events you tagged add their flat or fraction-of-weekly amounts.
- Build the gross, then the funds. The worked pay (plus any in-gross funds — vacation, most commonly) forms your gross, and the Local's fund contributions are computed from it. Every part of that build-up is a named line in the week's composition — day pay, flat salary, weekly OT, penalties, event premiums, other premiums, performance-call lines, work-type rate lines, vacation, and taxable allowances — so a week total always reconciles to the lines behind it rather than leaving a residual nobody can explain.
Why the gross matters
Several benefit funds are calculated as a percentage of your gross. If the gross is off, every fund that keys off it is off too. That's why logging complete, accurate reality — including meal breaks and work types — is worth the few extra seconds per day.
What you actually do
- Set up the contract once with its base pay, then flesh out work types, riders, holidays, and fund contributions as you confirm the deal.
- Log each week honestly — real times, real breaks, the right work type per day.
- Override the rare exception on the specific day it happened.
- Read the priced result in the week and income views, and trust that it reflects your contract's rules.
Contracts & rate configuration
Create a contract, set its pay basis and rules, and layer on premiums, per-diem, touring levels, deductions, and effective-dated revisions.
Work — leads, holds & the pipeline
Track a job from the first ask through hold, offer, confirmed, active and wrapped in one stage-filtered list; watch overlapping holds on the calendar; and keep the referral network that feeds you work.