Logistics technology glossary

Freight software is full of acronyms that mean different things to dispatch, finance and engineering. This glossary is written for founders, ops leads and product teams building or buying a transportation stack — not as a legal dictionary. Use it alongside Kode Builder’s TMS overview and TMS EDI integration guide when you are scoping a custom platform. Jump to a section, then read the definitions in order; later terms assume earlier ones.

Transportation Dispatch Visibility Documents Compliance Payments Integrations Fleet

Transportation systems and operating models

Start here if you are choosing software. Who moves the freight, who owns the trucks, and which system is the source of truth for a load versus a warehouse pallet.

TMS (Transportation Management System)

A TMS is software for planning, executing and settling the movement of freight. Typical modules include orders or loads, rating or procurement, dispatch, tracking, documents, billing and partner connectivity (EDI or APIs). Carriers use a TMS to keep trucks productive; brokers use it to match shippers with carriers; shippers and 3PLs use it to buy transportation and see status. A TMS is not a map app and not a warehouse system — it is the operational ledger of moves. For a fuller walkthrough, see what a TMS is and Kode Builder’s TMS software development work.

TMS vs WMS

A warehouse management system (WMS) tracks inventory inside four walls: receiving, putaway, picks, packing and shipping dock. A TMS tracks inventory in motion: which load, which truck, which appointment, which invoice. Many 3PLs run both. Integration is the usual pain: the WMS says a shipment is packed; the TMS needs a load, a carrier and a tracking event. Do not buy one product hoping it replaces the other unless your operation is small and genuinely simple.

Broker vs carrier

A carrier (motor carrier) operates trucks and holds operating authority to haul freight. An asset carrier owns or leases the fleet; some carriers also broker overflow. A freight broker does not typically haul the freight. The broker arranges transportation between a shipper and a carrier, often taking a margin between the shipper rate and the carrier rate. Software implications: brokers need a carrier network, load boards or EDI tenders, and dual-sided settlement. Carriers need dispatch, driver apps, ELD/HOS awareness and equipment. Mixing both models in one TMS is common — and is a design choice, not an afterthought.

3PL (third-party logistics)

A 3PL provides logistics services on behalf of shippers: warehousing, fulfillment, transportation management, or all of the above. In software, “3PL TMS” often means multi-customer (multi-tenant) operations: each shipper has rates, labels, billing rules and visibility portals, while the 3PL’s staff share docks and trucks. A 4PL is a broader orchestrator; you do not need the label to know whether you need multi-account isolation in the product.

Dispatch: tenders, delays and extra charges

Dispatch is the live board: who has the load, when it must pick up, and what extra money is owed when the plan breaks.

Load tender

A tender is an offer of a shipment to a carrier (or an acceptance workflow inside a private fleet). Digitally this is often EDI 204 or an API “offer load” call. The carrier responds with accept, decline or counter. Until acceptance, the load is not committed. Your TMS should record tender time, response, and which version of the rate and stops was agreed — arguments after delivery almost always start with a fuzzy tender.

Detention

Detention is time charged when a truck is held at shipper or consignee beyond the free time in the contract (loading or unloading). It is not the same as layover (overnight) or storage (freight sitting in a yard). Product-wise you need appointment times, geofence or driver timestamps, free-time rules, and a dispute trail. Without those, detention invoices become email wars.

Accessorial

An accessorial is a charge beyond the linehaul rate: liftgate, inside delivery, residential, layover, lumper, extra stop, hazmat, and detention itself. Rating engines and invoices must treat accessorials as first-class line items with who authorized them. If your TMS only stores “one number per load,” finance will rebuild the truth in spreadsheets.

Visibility: where the truck is and proof it was there

Customers do not buy “a GPS pin.” They buy predicted arrival and evidence of delivery. Driver apps, ELD pings and customer portals all feed this layer.

ePOD (electronic proof of delivery)

ePOD is digital evidence that freight was delivered: signature, photos, timestamp, geolocation, exception notes (shortage, damage). It replaces or supplements paper BOLs at the consignee. A good ePOD flow is usable with gloves and poor signal, syncs later, and ties to the load ID the TMS already knows. It is also a billing artifact — finance wants the same document operations captured in the cab. See building a driver tracking app for how mobile capture usually sits next to the TMS.

Geofence

A geofence is a virtual boundary around a location (pickup, yard, consignee). When a device enters or exits, the system can auto-arrive, auto-depart, start detention clocks, or suppress noisy GPS jitter on the highway. Fences that are too tight miss events; fences that are too wide mark a truck “on site” while it is still on the frontage road. Treat fence radius and dwell rules as configuration, not a one-size default.

ETA (estimated time of arrival)

ETA is a prediction, not a GPS coordinate. Inputs typically include current location, remaining driving hours, traffic, appointment windows and whether the driver is on break. Publishing a single ETA without a confidence band trains customers to distrust the portal. Useful products show appointment vs ETA, and they stop updating after delivery rather than leaving a ghost truck on the map.

Documents and EDI transaction sets

Paper and EDI are still how many North American partners commit to a load. Your TMS either speaks these messages or staff retype them.

BOL (bill of lading)

The bill of lading is the core shipment document: shipper, consignee, description of goods, pieces and weight, and often liability terms. It can be the contract of carriage and the receipt. Drivers still photograph paper BOLs; eBOL and ePOD reduce that, but partners may still require a PDF. In software, the BOL number is a join key across TMS, WMS and customer portals — colliding numbers across customers is a classic 3PL bug.

Rate confirmation

A rate confirmation (rate con) is the broker’s or shipper’s written agreement of the agreed price, stops, equipment and notes, sent to the carrier after (or with) the tender. It is not the BOL. Carriers hang rate cons in the truck; factoring companies want them; disputes cite them. Store the PDF or structured fields with a version history. If the rate changes after dispatch, the TMS should show which confirmation is current.

EDI 204, 214, 210 and 990

EDI (Electronic Data Interchange) is structured B2B messaging, still dominant in truckload. X12 transaction sets you will meet constantly:

EDI 204 — Motor Carrier Load Tender

Shipper or broker offers a load: stops, dates, equipment, references. The digital “please haul this.”

EDI 990 — Response to a Load Tender

Carrier accepts or declines the 204. Without 990 (or an equivalent API), the shipper does not know the tender stuck.

EDI 214 — Transportation Carrier Shipment Status Message

Status updates: departed, arrived, delayed, delivered. This is visibility for partners who will not use your portal.

EDI 210 — Motor Carrier Freight Details and Invoice

The carrier invoice in EDI form: linehaul, accessorials, references. Finance and audit teams live here.

Mapping these into internal load states is a project of its own. Partner-specific segments and “creative” use of reference numbers are normal. Details live in the TMS EDI integration guide.

Compliance: hours, fuel tax and devices

These terms show up in US-centric fleets; similar regimes exist elsewhere under different names. Software should record evidence, not pretend to be the regulator.

IFTA (International Fuel Tax Agreement)

IFTA is a fuel-tax reporting compact among US states and Canadian provinces. Carriers file quarterly based on miles traveled per jurisdiction and fuel purchased. A TMS or fleet system may store IFTA miles from GPS/ELD, fuel receipts, and jurisdiction boundaries. It does not replace a tax advisor. If you sell “IFTA” as a feature, be explicit: mileage capture and reports versus full filing.

ELD (Electronic Logging Device)

An ELD records driving time to support hours-of-service (HOS) rules. It connects to the vehicle and produces logs regulators can inspect. Product teams confuse ELD with “tracking.” Tracking can come from a phone; HOS-grade ELDs are certified devices with specific data. Your TMS usually consumes ELD or telematics events (location, duty status) rather than becoming the ELD. Integration quality decides whether dispatch sees a live HOS remaining clock or a stale ping.

Payments: settlement and cash-flow tools

Moving freight and getting paid are different workflows. Brokers, carriers and factors all touch the same load with different documents.

Settlement

Settlement is reconciling what was agreed (rate con, accessorials, detention) with what is billed and paid — carrier pay, driver pay, shipper invoice, and deductions. A TMS settlement module typically holds payables, receivables, short-pay disputes and batch payments. “We invoiced it” is not settlement; settlement is when both sides agree the load is closed. Audit history matters more here than on the dispatch board.

Factoring (brief)

Freight factoring is selling approved invoices to a factor for faster cash, at a fee. Factors often require rate cons, BOLs and PODs before they advance funds. If you build carrier-facing software, plan document packets and status that a factor can consume. Factoring is a financing product, not a TMS feature — but missing paperwork is why carriers call you at month-end.

Integrations: how the stack talks

A TMS that cannot talk to partners becomes a data-entry terminal. Integration is the product for many mid-market fleets.

Besides EDI 204/214/210/990, expect REST or SOAP APIs to load boards, ELD vendors, fuel cards, accounting (QuickBooks, NetSuite), customer portals, and webhooks for “load delivered.” VANs (value-added networks) still sit in the middle of many EDI relationships. Build an integration layer with retries, partner-specific maps, and a dead-letter queue humans can replay. Do not hard-code one shipper’s 214 quirks into dispatch logic. Industry context for custom builds is in logistics software development.

When you scope a project, list each partner, message type, and whether you own the certificate or mailbox. That list predicts calendar time more accurately than screen designs.

Fleet and telematics

Fleet is equipment, drivers and the sensors that say where they are. It overlaps dispatch but has its own master data: tractors, trailers, owner-operators, maintenance and fuel.

Telematics

Telematics is vehicle (or asset) data sent over the air: location, speed, engine diagnostics, fuel, temperature for reefers, door sensors. Providers include ELD vendors and dedicated hardware. A TMS uses telematics to power maps, ETAs, geofences and exception alerts. Ownership question: is the telematics platform the system of record for location, or does the TMS store a copy? Duplicating every ping forever is expensive; storing trip-level breadcrumbs and events is usually enough for operations and claims.

Driver-facing apps sit on top of telematics and TMS: navigation, load details, ePOD, chat, and sometimes HOS display. If those three systems disagree on “current load,” drivers stop trusting all of them.

Frequently Asked Questions