Short answer: BSP reconciliation means matching every ticket, refund, ADM and ACM in the IATA billing against your own booking and accounting records before the remittance date, so you pay airlines exactly what you owe and catch errors while they can still be disputed. Agencies that reconcile transaction by transaction, from the HOT file rather than the summary billing, catch most problems early. Agencies that only check the total usually discover differences months later, when the money is gone.
One note before we start: this is general information about how the industry settlement system works, not accounting or legal advice. The authoritative source for your market is the IATA BSP Manual for Agents and your local IATA office.
What the BSP is and why it exists
The Billing and Settlement Plan is IATA's system for consolidating sales reporting and payment between accredited travel agents and the airlines they ticket for. Instead of invoicing and paying each carrier separately, an agency's ticketing activity is reported into one national or regional BSP, the BSP nets everything into a single billing, and the agency makes one remittance per settlement period. IATA then distributes the money to the participating airlines.
For an agency the practical consequences are: one payment instead of dozens, one billing document instead of dozens, and one deadline that really matters. Missing a BSP remittance is treated as an irregularity under the accreditation rules, and repeated irregularities put the agency's IATA accreditation and its ticketing authority at risk. That is why BSP reconciliation sits closer to cash-flow survival than to routine bookkeeping. The web platform where agencies see their billings, download files and manage disputes is BSPlink.
The billing cycle: reporting, billing, remittance
The cycle has three moving parts, and the names matter when you read IATA documents:
| Term | What it means in practice |
|---|---|
| Reporting period | The window in which your ticket issues, refunds and exchanges are captured from the GDS and ticketing systems and reported to the BSP processing centre. |
| Billing period | One or more reporting periods rolled into a billing document that itemises what you owe (or are owed) across all BSP airlines. |
| Remittance date | The deadline by which your single consolidated payment must reach the IATA clearing bank account for that billing. |
| Settlement | IATA distributes the remitted funds to each airline, net of refunds, ACMs and commission where applicable. |
How often you remit depends on the market: IATA sets reporting and remittance frequencies country by country, and has been shortening them in many markets over recent years. An agency in a weekly-remittance market holds airline money for days, not weeks, which makes fast reconciliation more important, not less: there is very little time between receiving the billing and having to pay it. Check the current calendar for your BSP in BSPlink rather than relying on habit, because IATA publishes changes to remittance frequency in advance and enforces the new dates from the effective day.
The HOT file: your transaction-level source of truth
The billing summary tells you the total. The HOT file (Hand Off Tape, a name inherited from the era of magnetic tape) is the transaction-level data file behind it, available for download from BSPlink each processing cycle. It lists every document the BSP has billed you for: ticket numbers, fare, taxes by code, commission, form of payment, refunds, exchanges, ADMs and ACMs.
Reconciliation worth the name happens at this level. The workflow is: import the HOT file, match each document against your own record of it (the PNR, the invoice in your back office, the payment you collected from the customer), and investigate every line that does not match. A total-level check can look perfect while two errors cancel each other out; a transaction-level check cannot.
ADMs and ACMs: adjustments after the sale
Two document types adjust the billing after the original sale. An ADM (Agency Debit Memo) is raised by an airline to collect money it believes the agency owes: a fare rule violated, a commission taken that was not due, a refund calculated too generously. An ACM (Agency Credit Memo) works the other way, returning money to the agency. Both flow through BSPlink into a subsequent billing, governed by IATA Resolution 850m, which also gives agents a defined window to review and dispute an ADM before it is billed.
For reconciliation, ADMs are the hard part: they arrive weeks or months after the transaction they relate to, against a booking your team has long since closed. If your process cannot connect an ADM back to the original ticket, the original agent and the original customer, you cannot judge whether to dispute it or absorb it. We cover the causes and the dispute process in detail in our guide to airline debit memos.
Why reconciliation breaks
Almost every unexplained difference between the BSP billing and the back office comes from a short list of causes:
- Timing differences. A ticket issued at 23:50 on the last day of a reporting period lands in a different billing than your back office expects.
- Voids outside the window. A ticket voided after the void deadline is billed even though your system shows it cancelled.
- Refunds and exchanges. Penalties, non-refundable taxes and residual values are the single richest source of calculation differences.
- Commission and incentive differences. The back office assumes one rate, the airline bills another.
- Manual entry. Tickets issued in the GDS but never keyed into the back office, or keyed with the wrong fare.
- Currency and rounding. Multi-currency sales rounded differently by the BSP and by your accounting system.
- ADMs against closed files. Debits that arrive after the booking file was archived and the margin already reported.
None of these is exotic. The failure mode is volume: at a few hundred tickets a month a spreadsheet copes, at a few thousand the exceptions pile up faster than a person can clear them.
What manual reconciliation looks like
The traditional process is a weekly ritual: download the HOT file or billing analysis from BSPlink, export sales from the back office, line the two up in a spreadsheet by ticket number, and eyeball the differences. It works, but it has three structural weaknesses. It happens after the fact, often dangerously close to the remittance date. It depends on one or two people who know the spreadsheet. And it rarely closes the loop into accounting, so the general ledger is corrected long after the operational truth is known.
Agencies running multiple GDSs, an online flight booking engine and offline counters have it hardest, because sales arrive from three directions while the BSP bills them in one stream.
How ERP automation changes the job
A travel ERP treats reconciliation as a data-matching problem rather than a spreadsheet ritual. In practice that means: automatic import of the HOT file each cycle; automatic matching of every document against the PNR and the customer invoice on ticket number; an exception queue holding only the lines that failed to match, each with a reason; ADM capture with a link back to the original booking and agent so disputes are filed inside the Resolution 850m window; and posting of the reconciled result straight into the ledger. The finance team stops comparing files and starts clearing exceptions.
This is one of the core modules we build in travel ERP software and in broader travel agency software projects, usually alongside GDS integration so ticketing data flows in without manual entry. The measure of success is simple: how many minutes after the billing is published do you know, line by line, whether it is right?
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.