What is BXF? The Broadcast Exchange Format, explained

A TV channel runs on two kinds of system that have to agree all day long. The traffic and scheduling system plans what airs: programmes, commercials, promos and fillers, to the frame. The playout automation plays it. A schedule travels from one to the other, and a record of what actually played — the as-run log — travels back.

For decades every pair of systems agreed on its own file format for that exchange: fixed-width text logs, spreadsheets, vendor-specific XML. BXF, the Broadcast eXchange Format, is the industry standard that replaces those one-off formats with one shared language.

BXF in short

• What it is: an XML-based format and protocol published by SMPTE as the ST 2021 family of documents.
• Who uses it: traffic, scheduling, programme management, playout automation and content delivery systems.
• What it carries: schedules, as-run logs, content metadata and instructions to move or prepare content.
• Why it exists: to give traffic and automation a consistent, flexible way to exchange schedule, as-run and content data without a custom integration for every pair of products.

What a BXF message carries

Schedules

The playlist for a channel and a period: every event with its start time, duration, the material it plays (by house number or another content ID), its segments, and the secondary events that ride on it, such as logos, graphics or subtitles. Breaks and the spots inside them are events too.

As-run logs

What actually played, with the real start times and durations. The as-run log is what traffic needs for as-run reconciliation: checking the day against the plan before advertisers are invoiced.

Content metadata

Titles, IDs, durations and segment points of the material in the schedule, so both sides describe the same clip the same way.

Content movement

Instructions around the media itself — record, dub, transfer or purge orders — and notifications such as “this material has arrived” or “this material is missing”, so a missing commercial is found before air, not during it.

How BXF travels: files or messages

The standard describes two ways of moving BXF between systems:

• File-based: one system writes a BXF file to a shared folder or server and the other picks it up. This is how most channels start: the day’s schedule is exported, the as-run comes back the next morning.
• Message-based: the systems stay connected and send messages as things change — a single event updated, a query answered, a heartbeat to show the link is alive. This is what makes near-real-time changes possible: traffic can update one break in the on-air day without reloading the whole log.

Why it matters for a channel

• Fewer custom integrations. A traffic system and an automation system that both speak BXF need configuration, not a new interface.
• Changes closer to air. With message-based exchange, late changes reach playout as updates instead of a re-exported day.
• Faster reconciliation. The as-run log comes back in the same structure the schedule went out in, so matching it to the plan can be automated.
• Missing media found early. Content notifications tell traffic which items are not ready while there is still time to replace them.

BXF in practice: what to check before go-live

“Supports BXF” does not mean two products work together on day one. The standard is broad and has been revised several times; vendors implement the parts they need, sometimes with extensions of their own. Before you switch a channel over, agree on these points with both sides:

1. Version and message types. Which edition of the schema, and which messages — schedule only, or as-run and content notifications too?
2. Transport. Files (where, how often, how they are named) or a live connection.
3. Identifiers. How house numbers, event IDs and segment IDs map between the systems. Most reconciliation problems start here.
4. Time. Local time or UTC, the broadcast day start, and the frame rate. At 29.97 fps, check whether both sides count in drop-frame timecode.
5. Secondary events. How logos, graphics and subtitles are expressed, and which ones the automation actually executes.
6. Breaks. How breaks and spots inside them are marked, so the automation and the as-run log keep them apart from programmes.

Then run real days through both systems — a busy weekday, a live event, a day with late changes — and compare the as-run with the plan before going live.

BXF and other playlist formats

Many channels still exchange schedules as CSV or fixed-width text, or in the native format of their automation. Those formats work, but each one is a separate integration with its own rules. BXF is the vendor-neutral option: the one to ask for when you choose new systems, and the one that makes changing one of them later less painful.

How 9eye uses BXF

9eye exports each channel’s playlist as BXF, alongside common automation formats. Every time inside 9eye is an exact frame count at the channel’s own frame rate, so a BXF schedule leaves with the timing it was planned with, and each channel chooses whether its BXF times are local or UTC. The as-run log from playout is reconciled against the plan, with every difference explained. See how it fits together in 9eye TV traffic software, or ask for a demo with your own automation in mind.

More guides

• As-run reconciliation: how TV channels check what actually aired — Matching the as-run log against the plan, which differences matter, and how make-goods work.
• Drop-frame timecode, explained: 29.97 and 59.94 fps — Why 29.97 fps needs drop-frame timecode, which frame numbers are skipped, and how to convert between frames and timecode.