Racetrack and Racing Office Software: Why a 9am Scratch Rewrites the Entire Race Day

Why race day is the least forgiving deadline in operations

Scratch time. A horse comes off the vet's list problem in one race, two more scratch in another, and the fourth race is now below the minimum number of starters, which means it either runs short or comes off the card entirely. The also-eligible list draws in for race six, which changes post positions. The program was printed last night. The past performances were distributed to the wagering public. The tote system needs the field before pools open. The broadcast graphics come from a feed that is already live. Three jockeys now have a conflict because a mount they lost in one race overlaps with a mount they just gained in another. Every one of these is somebody's phone call, and first post is in ninety minutes.

The racing office is where wagering, regulation, animal welfare and the horsemen's livelihood all intersect on a fixed clock. The systems around it reflect decades of accumulated industry structure. InCompass Solutions is effectively the standard racing office platform across much of North American thoroughbred racing, and it is tightly coupled to industry data sources in a way that is genuinely useful. AmTote and Sportech sit on the wagering side, and the totalisator is a world of its own with interfaces designed a long time ago that still work.

The gap is not that these systems are bad. It is that they encode one industry structure. If you operate outside that structure, whether that is a different jurisdiction, mixed breeds on the same card, a track running its own account wagering, or a racing authority whose rules are set by its own regulator, you spend your days translating between a system built for someone else's rulebook and the one you actually operate under. That translation is done by experienced people, on race day, at speed.

Problem 1: eligibility is computed from history, and the conditions are prose

A condition book is written in a compressed technical language: restrictions on wins within a period, claiming price bands, age and sex restrictions, state or country bred preferences, and weight allowances including apprentice claims. Deciding whether a horse is eligible for a race means evaluating that prose against its complete record, then working out what weight it carries.

When this is manual, entry taking becomes a bottleneck staffed by people whose knowledge is irreplaceable, and errors surface late. An ineligible runner is a serious matter, because the wagering public acted on the field as published.

What a custom build does: turn conditions into structured, evaluable rules rather than free text, with a writer's interface that produces both the machine-readable condition and the printed wording from the same source. Eligibility then computes at the moment of entry, with the reason shown to the person entering: this horse fails on non-winners of two, this one qualifies but carries five pounds more. Preference rules, which decide who gets in when a race overfills, become deterministic and explainable rather than a judgement someone has to defend to a trainer. The office keeps its expertise but stops spending it on lookups.

Problem 2: the draw and the scratch are the same problem seen twice

The draw is a controlled event with rules: post position assignment, coupled entries where two horses run as one betting interest, main track only entries that apply if a turf race is moved, and an also-eligible list ordered by preference. A scratch runs the same machinery in reverse, under time pressure.

The cost of handling this badly is not internal. Every downstream consumer has already published: the printed program, the data providers, the tote, the broadcast and every off-track outlet.

What a custom build does: treat the field as a versioned object with an explicit state and publish changes as events rather than as replacements. Every consumer subscribes and receives the change with a reason and a timestamp, so nobody is comparing two PDFs to work out what moved. Coupled entries, also-eligible draw-ins and surface changes are modelled properly rather than handled by editing a list, which matters because a surface change reshapes the field through main track only entries in a way that is very easy to get wrong at 9am. And every version is retained, so when a query arrives after the race about what the field was at a given moment, the answer is a record rather than a memory.

Problem 3: integrity and veterinary records now have to be systematic

Pre-race examinations, the veterinary list and its restrictions on entry, medication and treatment records, and stewards' rulings all determine whether a horse or a person can participate. In the United States, the Horseracing Integrity and Safety Authority framework has made reporting and record-keeping obligations considerably more explicit for covered races, and jurisdictions elsewhere have their own regimes. The exact obligations that apply to your meet are a question for your regulatory counsel rather than for a software vendor, but the operational shape is the same everywhere: a horse's eligibility to run now depends on records held by several parties who must agree.

What a custom build does: connect the veterinary and integrity record directly to the eligibility check rather than leaving it as a parallel list somebody consults. A horse on the vet's list with a restriction is simply not eligible to enter until the restriction clears, and the block states why and who can clear it. Stewards' rulings apply to people as well as horses, so a suspended jockey cannot be named on an entry. Reporting to the relevant authority is generated from the same records rather than compiled separately, which is the difference between a compliance function and a compliance department.

Problem 4: the tote is a hard interface and it does not wait

The wagering system needs the field, the betting interests, the coupling, the scratches and the results, in a defined format, on time. Systems from AmTote, Sportech and their equivalents are the backbone of the money and they are conservative by design, which is correct: nobody wants an experimental interface between a racing office and a betting pool.

What a custom build does: treat the tote interface as a first-class integration with strict validation, explicit acknowledgement, and a reconciliation step rather than fire and forget. Field data goes out, the acknowledgement comes back, and any mismatch raises immediately rather than being discovered when pools behave oddly. Results flow the other way and reconcile against the official order of finish including any change following an inquiry or objection, because a result that changes after an objection has to propagate cleanly to wagering, purses and data providers in a defined order. That sequencing is exactly the kind of logic that lives in someone's head today.

Problem 5: purses, licensing and horsemen's accounts are the relationship

After the race the money moves. Purse distribution follows the schedule for that race by finishing position, with jurisdiction-specific splits and deductions, plus jockey mount fees and percentages, starter fees, and contributions to funds set by rule or agreement. The horsemen's bookkeeper maintains accounts for owners and trainers, and payments to those accounts are how a track's relationship with its horsemen is actually experienced.

Licensing sits alongside it: jockeys, trainers, owners, grooms and other participants hold licences with expiry dates and conditions, and stewards' suspensions modify them. A participant whose licence lapsed should not be able to be named on an entry, and today that check is frequently a person remembering.

What a custom build does: derive purse distribution from the official result and the race's purse schedule automatically, apply the deductions your jurisdiction defines as configurable rules, and post to horsemen's accounts the same day rather than at the end of the meet. Owners and trainers get a statement they can read, which removes a large share of the office's phone calls. Licence validity becomes a hard precondition for entry and for naming a rider, checked automatically rather than remembered.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and the shape for a racetrack or racing authority is this. A first release covering the condition book with evaluable conditions, entry taking with computed eligibility and preference, the draw with also-eligible and coupling handling, and versioned field publication with scratch cascades runs $80,000 to $180,000 over 14 to 20 weeks. A full platform adding veterinary and integrity records, stewards and rulings, purse distribution and horsemen's accounts, licensing, tote and data provider interfaces, and regulatory reporting runs $220,000 to $550,000 phased across 9 to 18 months.

What pushes the number up: the number of jurisdictions you operate under, since rules and reporting differ and cannot be averaged. Mixed breeds on the same programme, because thoroughbred, standardbred and quarter horse racing have different conditions, eligibility logic and data sources. Tote integration, which is careful, slow work with a partner whose change control is appropriately conservative. Historic data migration, since a horse's record is the basis of eligibility and importing it incompletely produces wrong answers rather than missing ones. And account wagering, if you run your own platform and want it fed from the same field data.

What holds it down: the condition book, entries, draw and scratch cascade first. That is the sequence that consumes race week, and it delivers value before you touch money movement.

Build versus buy, and when buying is clearly right

Buy if you are a single standard thoroughbred meet in North America. InCompass Solutions is the established racing office platform there, it is connected to the industry data your operation depends on, and rebuilding that connection is not a good use of your capital. The same logic applies on the wagering side: nobody should be building a totalisator.

Build when two or more of these are true. You operate outside the footprint the established systems were designed around, so you are translating rules daily. You run multiple tracks or mixed breeds and need one operational picture. Your jurisdiction's rules on eligibility, purses or integrity reporting are genuinely specific and change by regulation rather than by industry convention. You run your own account wagering or media rights operation and want field and result data flowing from a single source you control. Or your race day depends on two or three people whose knowledge has never been written down and who are within a few years of retiring.

Our position: the last one is real and the industry is quietly bad at facing it. Racing offices run on people who have absorbed decades of rules, and when they leave, the rules leave with them. Encoding that knowledge is the most durable reason to build, and it is worth more than any efficiency argument.

How to choose a developer for racing office software

Ask them to model a race day on a whiteboard. A capable team draws race with conditions, entry, horse with a full record, betting interest as distinct from horse, field version, result with an official status, and purse distribution. If they do not separate the horse from the betting interest, they do not understand coupling and they will get the tote interface wrong.

Ask how a scratch propagates. The right answer is versioned field state published as events with reasons and timestamps to every consumer, with retained history. A system that regenerates a document and emails it has automated the wrong step.

Ask about the tote interface specifically and by name. You want a developer who talks about validation, acknowledgement and reconciliation, and who treats the wagering partner's change control as a schedule constraint rather than an obstacle.

Ask who owns the code, the data and the cloud accounts, and get it written down before kickoff. A track's racing records are a regulatory archive as well as an operational database, so also agree retention, audit logging and what happens on the day a regulator asks for a record from four seasons ago. At Digital Heroes the client owns everything from the first commit.