Broadcast Traffic and Billing Software: When the Log, the Order and the Invoice Stop Agreeing

Why traffic is the least visible and most expensive system in a station group

Traffic sits between three departments that do not naturally agree. Sales sells inventory that may or may not exist. Programming changes the schedule, sometimes on the day. Master control airs whatever the log says. Finance invoices whatever the as run claims happened. Traffic is the function that makes those four versions of reality reconcile, and it does it every single day, for every station, before a deadline that does not move.

When it works nobody notices. When it fails the failure is specific and expensive: a spot that did not air, a spot that aired in the wrong break, a spot that aired next to a competitor's, a package that was sold across linear and digital and billed twice on one side and not at all on the other. Each of those becomes a makegood, which is inventory given away for free, or a credit, which is revenue reversed after it was booked. Both come out of the same place.

The daily reality in most groups is a traffic manager working through a log build in the afternoon with two other windows open: an email inbox full of agency traffic instructions arriving as PDFs, and a spreadsheet tracking the cross platform packages that the traffic system cannot represent. Programming sends word that a live event may run long. Political orders are stacking up ahead of a primary, and those carry rate obligations and public file duties that have nothing to do with any other advertiser. The log gets built anyway, because at some point it has to be sent.

Problem 1: avails are calculated per platform and sold as a package

Ad sales stopped being linear only some time ago. A seller now walks into an advertiser with a package: spots across three stations, insertion into the group's FAST channels, pre roll on the streaming app, maybe sponsorship of a newscast segment. The advertiser buys one thing. The group fulfils it in three systems and invoices from at least two.

WideOrbit and Marketron are the backbone of American broadcast traffic and they are genuinely capable at what they were designed for, which is linear inventory with a defined sales model. Imagine Communications serves a similar core. Myers ProTrack has real strength in public and educational broadcasting where the scheduling model differs. What none of them was designed to do is hold a single order whose lines fulfil in a linear log, a digital ad server and a FAST platform, then reconcile delivery across all three into one invoice. So the package lives in a spreadsheet, and every month somebody rebuilds the reconciliation from three reports.

A custom layer holds the order. One order object, lines with a fulfilment target, an avails view that shows true remaining inventory across platforms rather than three separate sellout percentages, and a delivery record that pulls back from each system. The traffic system keeps doing linear, which it does well. The layer owns the thing your vendor never built because no vendor can build a general version of your specific inventory mix.

Problem 2: traffic instructions arrive as email, and copy rotation is manual

An agency buys a flight and then sends instructions: this creative in weeks one and two, that creative in week three, this one only in the morning drive, different copy in the two markets. Those instructions arrive by email as a PDF or a spreadsheet, sometimes late, frequently amended. Somebody reads them and enters the copy rotation into the traffic system by hand, matching creative codes to media that arrived through a delivery service.

The error rate here is not a reflection on anyone's care. It is what happens when a human transcribes hundreds of instruction lines a week under time pressure. And the errors are the expensive kind, because a spot that airs with the wrong creative is a makegood plus an unhappy agency plus a conversation about whether the group can be trusted with a bigger buy.

This is the clearest place for document extraction in the whole category. Inbound instruction documents get parsed into structured rotation rules, matched against the order lines and the received media, and presented to the traffic coordinator as a proposed change to confirm rather than a document to retype. Anything ambiguous goes to a queue instead of being guessed. In the builds we have delivered, this kind of intake settles at a high no touch rate within a few weeks of corrections, and the residual queue is small enough to work through in minutes. The point is not eliminating the coordinator, it is moving them from typing to checking.

Problem 3: political advertising has its own rules and its own deadline

Political is the one advertiser category where getting the paperwork wrong is a regulatory matter rather than a commercial one. Federal candidates are entitled to lowest unit charge during the windows preceding a primary and a general election, which means your rate calculation for those orders is a function of every other rate you charged for comparable inventory in that period. Stations must maintain a political file in the online public inspection file, and it has to be current.

Traffic systems support political to varying degrees, and stations generally get through election seasons on the strength of an experienced traffic manager and a lot of manual checking. The load is uneven: for most of the cycle it does not matter, and then for a few months it dominates the department's time, exactly when inventory is tightest and preemption is highest.

A custom layer earns its place here by computing rather than recording. Track comparable inventory and rates continuously so the lowest unit charge position for a class of time is a live figure rather than an end of period reconstruction. Generate the disclosure records as orders are accepted so the public file obligation is satisfied by the process rather than by someone remembering. Flag when a political order would displace commercial inventory in a way the group has decided it will not accept. None of that is glamorous and all of it is the sort of thing that shows up in an enforcement complaint if it is missing.

Problem 4: as run reconciliation is where revenue quietly leaks

The log goes to playout. Playout returns an as run. Somewhere between the two, a live event ran long and four spots were dropped, a break was moved, and one spot aired outside its purchased daypart. Reconciliation compares what was ordered to what aired, decides what is billable, what needs a makegood and what needs a credit, and then produces an invoice with an affidavit.

In most groups this comparison happens per station, per system, with human judgement applied to discrepancies. Two things go wrong. Small discrepancies get waved through because chasing them costs more than they are worth individually, which is true individually and false in aggregate across a year and thirty stations. And makegoods get placed by whoever has capacity in the moment rather than against a policy, so premium inventory gets given away to satisfy a claim that could have been settled with a credit.

A build makes reconciliation systematic. Every ordered spot has an expected airing, every as run line matches or does not, exceptions are classified automatically by reason, and makegood placement follows a rule set that respects the value of the inventory being given away. Group level reporting then answers the question nobody can currently answer: what did preemption actually cost us last quarter, by station, by daypart and by cause. That number is usually larger than the executive team assumed.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering cross platform order capture, unified avails, and as run reconciliation with exception classification runs $90,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding traffic instruction intake and copy rotation, political order handling and public file records, makegood management with placement rules, and invoicing integration into your finance system runs $250,000 to $600,000 phased over 9 to 18 months.

What drives price up specifically in broadcast: the number of systems you have to read from and write to, because a traffic system, a digital ad server, a FAST platform and a playout automation system each have their own interfaces and none of them are the same twice. Agency order intake, since electronic ordering through platforms such as Mediaocean is its own integration with its own certification effort. The number of stations and whether they share inventory. Invoicing, because affidavit requirements differ by advertiser and agency. And any requirement to touch the existing traffic system's data directly, which is slower and more delicate than reading exports.

What keeps price down: starting read only. A layer that reads orders, logs and as runs and produces reconciliation and reporting proves its value in weeks without any risk to the daily log build, and it earns the political capital you need to write back later.

Build versus buy, and when WideOrbit is enough

Buy, and change nothing, if you are a single station or a small group selling linear inventory with a conventional sales model and little or no digital fulfilment. WideOrbit and Marketron do that job properly, everyone in your traffic department already knows them, and replacing them is an expensive way to obtain what you already have. Myers ProTrack is a sensible answer in public broadcasting where the underwriting and programming model differs from commercial.

Build a layer, not a replacement, when two or more of these are true. You sell cross platform packages and reconcile them in a spreadsheet. You operate FAST channels or a streaming app and the inventory is not visible alongside linear. Traffic instructions are retyped from email by more than one person full time. Your political workload requires an experienced individual and a manual checking routine every cycle. Or you cannot answer what preemption cost the group last quarter.

Our position, stated plainly: nobody should write a replacement for a traffic system in 2026, and any developer offering to is either inexperienced or optimistic about your budget. The value is in the order layer above it and the reconciliation layer below it, both of which are specific to how your group sells and neither of which any vendor can generalise. Keep the backbone. Own the parts that describe your business.

How to choose a developer for broadcast traffic software

Ask them to model a cross platform order on a whiteboard. A developer who has worked in broadcast will separate the order, the line, the fulfilment target and the delivery record, and will ask how you want to handle a package where linear over delivers and digital under delivers. A developer who draws orders and line items with a quantity has built a commerce system and will discover avails maths on your budget.

Ask how they would handle a live event overrun in reconciliation. The answer should involve classifying dropped spots by cause and applying a makegood policy, not flagging a mismatch for a human to interpret. That distinction is the difference between a report and a system.

Ask what they have actually integrated. Reading a traffic system export, writing back to it, taking orders from an agency platform, and pulling as run data from playout automation are four different problems with four different failure modes. Ask for the specific vendor and the specific interface, not a general claim about APIs.

Ask who owns the code and get it in writing before kickoff. The group should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and in a business where revenue reporting depends on this layer we would insist on that even if you did not.