EDI 110: Air Freight Details and Invoice Explained

What is EDI 110?

EDI 110 is the ANSI X12 transaction set air carriers and freight forwarders use to bill a customer for air transportation charges. The transaction set can be used to provide a customer with an air invoice for transportation and other charges related to shipments, including Original Invoices, Past Due Billings, Balance Due Bills and Revisions. If you've ever received an air waybill invoice that lands as a flat file instead of a PDF, there's a decent chance it was a 110 running through your EDI VAN or AS2 connection.

The transaction set lives inside its own functional group. The GS01 functional identifier code for 110 is IA, Air Freight Details and Invoice. That matters when you're setting up trading partner profiles or debugging a GS segment that's rejecting at the envelope level. Underneath the ST/SE envelope, the core segments you'll work with are B3 (Beginning Segment for Carrier's Invoice), B3A (Invoice Type), N1 loops for Bill-To and Shipper parties, and the L1 loop for rate and charge detail.

FedEx, which runs one of the more heavily documented air freight EDI programs, describes the relationship between invoice and shipment plainly: one invoice per 110 transaction set, and multiple tracking numbers per invoice. That's a structural detail worth remembering when you're reconciling against air waybills later, since a single 110 can roll up charges for a dozen or more shipments under one invoice number.

EDI 110 vs. the other freight invoice sets (210, 410, 310, 810)

EDI 110 is mode-specific to air freight. The equivalent transaction sets for other modes carry different numbers entirely, and X12's own document list keeps them grouped by transport mode: 210 is Motor Carrier Freight Details and Invoice, 310 is Freight Receipt and Invoice (Ocean), and 410 is Rail Carrier Freight Details and Invoice. If a carrier sends you a 210 and you're trying to map it with 110 logic, you'll get segment mismatches fast, because the loop structures and code lists diverge even though the family resemblance is obvious on paper.

Here's the quick distinction table:

The confusion with EDI 810 is the one that trips people up most. EDI 810 is the generic invoice used across procurement, retail, and manufacturing for billing on goods or services generally. It doesn't carry the freight-specific charge breakdown that 110 standardizes through the L1 segment, things like fuel surcharge codes, security surcharge lines, and route information via the R1 segment. A supplier invoice and a carrier invoice look structurally similar at the envelope level, but the detail sections are built for completely different purposes. If your freight audit team is trying to force air carrier invoices through an 810 mapping built for merchandise, you'll lose the charge-level granularity that makes freight audit possible in the first place.

How the EDI 110 segment flow actually runs

A real 110 file follows a predictable path from header to charge detail. The B3 segment opens with the carrier's invoice number, SCAC code, and invoice date. B3A immediately follows with an invoice type code; for example, an EDI 110 document is used to provide customers an invoice for all the charges related to a shipment, such as transportation charges, balance due bills, past due billings, and revisions. Those invoice categories map directly to B3A codes like SS for standard shipment invoices or revision codes for corrected bills.

After B3A, you hit the N1 loops. A sample from 1EDISource's EDI 110 reference shows the Bill-To and Shipper parties populated back to back, followed by route and pickup data, then the actual charge lines. The charge detail looks like this in practice:

• L1 segment, freight charge: rate code FR with the charge amount and a plain-text description such as "FREIGHT CHARGE"
• L1 segment, fuel surcharge: a separate L1 line with its own code, commonly tagged "FUEL SURCHARGE"
• R1 segment: airline and airport routing, including origin and destination airport codes and the port of discharge
• P1 segment: pickup date and time details tied to the shipment

One actual sample shows this exact pattern in sequence: L1*1*114*FR*19900****400****FREIGHT CHARGE L1*2*114*FR*1000****405****FUEL SURCHARGE, which tells you the invoice carries two separate charge lines against the same shipment weight basis, one for base freight and one for fuel. That's the level of granularity freight audit teams actually want, because it lets you dispute a fuel surcharge without touching the base rate.

Worked example: reconciling a FedEx air invoice

Say a manufacturer ships components via FedEx Express under a negotiated air freight agreement, and instead of a PDF invoice landing in accounts payable, FedEx transmits an EDI 110 file through the trading partner's AS2 connection. The invoice structure follows FedEx's own implementation guide, where ST01 carries the code 110 for Air Freight Details and Invoice, which includes air waybills, manifests, and all automated shipping data rolled into a single transmission.

The reconciliation team pulls three data points to match against the original air waybill: the ST02 control number (unique to that transmission), the B3 invoice number (FedEx's billing reference), and the tracking number carried in the N9 segment. The tracking number that should be sent can be found in the 110 invoice in the N9 segment with qualifier AW, which is the field you match against your TMS shipment record or the original booking confirmation.

Once the invoice posts, FedEx expects a response cycle to close the loop. One invoice per 110 transaction set, and multiple tracking numbers per invoice means your reconciliation logic has to handle one-to-many matching, not one-to-one. If the customer only pays a subset of tracking numbers on that invoice, if you pay all of the tracking numbers on an invoice, create only one payment record for that invoice; if you make a partial payment, create a separate record for each tracking number in the 820 remittance that follows. A 997 functional acknowledgment confirms the 110 was received and syntactically valid, separate from whether the dollar amounts actually match what was quoted.

Why this matters for freight audit and TMS reconciliation

Companies running multi-modal freight, air alongside ocean and motor, need systems that ingest 110, 210, and 310 invoices without manual re-keying. Each transaction set has its own charge code conventions, which means a freight audit platform has to maintain separate mapping logic per mode even though the invoices all eventually need to land in the same general ledger line.

This is where dedicated freight audit and TMS platforms earn their keep. Vendors like Transporeon and MercuryGate have built multi-carrier invoice ingestion into their platforms for years, and lighter-weight multi-carrier tools such as Cargoson are increasingly positioned to pull EDI invoice feeds directly into freight-spend dashboards rather than leaving teams to reconcile L1 charge lines against tendered rates in a spreadsheet. The actual mechanics don't change, you're still matching B3 invoice numbers against AWB or BOL references, but the manual labor of opening raw EDI files to find an N9 tracking number disappears.

FAQ

Is EDI 110 the same as an air waybill (AWB)? No. The air waybill is the shipping document that travels with the cargo and establishes the contract of carriage. EDI 110 is the electronic invoice that bills against one or more AWBs or tracking numbers, referenced through the N9 segment.

Do all air carriers support EDI 110? Major integrators and large forwarders generally do, including FedEx and parcel-focused carriers handled through brokers like C.H. Robinson. Smaller regional air carriers may still rely on PDF invoices or web-based EDI portals instead of native X12 connections.

What acknowledges receipt of a 110? A 997 functional acknowledgment confirms the file was received and structurally valid, the same pattern used across most X12 transaction sets, including the 210 and 810.

Is EDI 110 being replaced by APIs? Some carriers now expose invoice data through REST APIs for modern freight audit tools, but EDI 110 remains the standard for high-volume B2B air freight billing, much like EDI 210 persists in motor carrier invoicing despite API alternatives existing.

How does EDI 110 relate to EDI 810? EDI 810 is the generic, cross-industry invoice used for merchandise and services billing broadly. EDI 110 is purpose-built for air freight, carrying charge-level detail through the L1 segment that the generic 810 doesn't standardize the same way.