What is IATA SSIM? A plain-English guide to the format that runs airline schedules

If you work anywhere near airline schedules, you’ve met SSIM — even if nobody explained it to you. It’s the file that lands in your inbox, the feed your systems ingest, the thing an engineer is quietly cursing at on any given Tuesday. This is the plain-English version: what SSIM is, what’s inside it, and why a format this old and this simple is still surprisingly hard to handle well.

The one-sentence version

SSIM is the IATA Standard Schedules Information Manual — and, by extension, the file format that manual defines for exchanging airline schedules between systems. When an airline publishes its schedule to airports, ground handlers, GDSs, online travel agencies, slot coordinators, or its own downstream tools, it almost always does so as an SSIM file. It is the lingua franca of “who flies where, when.”

What the format actually looks like

Here’s the part that surprises people who expect a modern data format. SSIM Chapter 7 — the schedule-data chapter — is a fixed-width, 200-character flat file. No commas, no JSON, no column headers. Meaning is carried entirely by position: character 1 tells you the record type, and every field after it lives at a byte offset the spec nails down exactly.

A flight-leg line reads, to the untrained eye, like this:

3 QF 0011 01APR26 25OCT26 1234567 SYDMEL 0600 0730 738 ...
│ │    │      │        │      │      │     │    │    │
│ │    │      │        │      │      │     │    │    └─ equipment (aircraft type)
│ │    │      │        │      │      │     │    └────── arrival time (local)
│ │    │      │        │      │      │     └─────────── departure time (local)
│ │    │      │        │      │      └───────────────── board/off airports
│ │    │      │        │      └──────────────────────── days of operation (1=Mon…7=Sun)
│ │    │      │        └─────────────────────────────── period end date
│ │    │      └──────────────────────────────────────── period start date
│ │    └─────────────────────────────────────────────── flight number
│ └──────────────────────────────────────────────────── airline designator
└────────────────────────────────────────────────────── record type (3 = flight leg)

(Illustrative and simplified — real records are exactly 200 bytes with more fields at fixed positions.) The whole industry runs on the idea that everyone agrees, to the character, where each value sits.

What’s in a file

A schedule file is a small set of record types stacked in order:

Record	Purpose
Type 1	Header record — the file title / general header, one per file
Type 2	Carrier record — airline designator, the season’s validity dates, time mode, creation date, status
Type 3	Flight leg record — the workhorse: flight number, city pair, days of operation, times, aircraft
Type 4	Segment data record — extra detail per segment: codeshares, traffic restrictions, service info
Type 5	Trailer record — the end marker, with counts to check the file arrived intact

Read the header and carrier records, stream the flight legs, attach the segment data, verify against the trailer, and you have a schedule. We go field by field through these in a companion post on the record types.

Why something this simple is hard

If SSIM is just fixed-width text, why does every schedule team eventually have a war story about it? A few reasons.

• Position is unforgiving. One field written a byte off, one carrier that pads a value differently, and a naïve parser silently misreads every row after it. The format gives you no delimiters to catch the mistake.
• The conventions aren’t all in the manual. Real feeds carry decades of accreted practice — how a particular carrier encodes an operational suffix, a period, a code­share. A parser that only knows the spec flags these as errors; a parser that knows the industry treats them as normal.
• Scale is real. A single multi-carrier feed can be millions of records. “Just load it into a spreadsheet” stops working almost immediately.
• Dates and days are their own puzzle. Schedules operate over a period, on specific days of the week, in a season — expanding that into actual operating dates correctly (including the edges) is where a lot of subtle bugs live.

SSIM is easy to read and hard to read correctly. The gap between those two is where teams lose weeks.

Why it matters right now

This isn’t a museum piece. The industry is flying at record load factors on thin margins, and a multi-year aircraft backlog means schedules are rebuilt far more often than they used to be. Every one of those rebuilds is an SSIM file that somebody has to read, validate, compare against the last version, and trust. The format sits underneath the whole planning stack — get it wrong and everything above it inherits the error.

Where we come in

The reason we built SSIM Toolkit is exactly this gap: reading SSIM correctly — fast, faithful to the real-world conventions, and entirely on your own machine — shouldn’t require a home-grown parser and a folder full of edge-case fixes. Get the foundation right and every workflow on top of it, from validation to analysis to export, gets easier.

In the next post, we open up the record types and read a file end to end.