Transportation Management System Requirements: 2026 Guide
A practical checklist of transportation management system requirements for hauliers, covering planning, POD, integrations, KPIs and RFP questions.
The dispatch board is full, the port slot is moving, and finance is asking why last week's completed jobs still aren't invoiced. A driver has sent a delivery note through a messaging app, another POD is sitting in a cab, and nobody can confirm whether a container's free-time clock has expired. This is the operational reality behind transportation management system requirements. A long feature list won't fix it. The right system must connect planning, execution, container status, proof of delivery, billing, compliance, and performance data in one usable workflow.
The market is moving in that direction. One benchmark values the global transportation management system market at USD 18.50 billion in 2025, with a projection of USD 37.04 billion by 2030, representing a 14.9% CAGR from 2025 to 2030 (market benchmark for transportation management software). For mid-sized hauliers and container operators, that growth matters less as a market headline than as a buying signal. TMS software is becoming operational infrastructure, not a better-looking dispatch spreadsheet.
Table of Contents
Why Most TMS Requirement Lists Miss the Real Buyer Problem
The most common scoping mistake is copying an enterprise checklist into a mid-market procurement exercise. The list includes multimodal optimization, carrier procurement, control-tower dashboards, predictive analytics, and every integration the vendor has ever built. Meanwhile, dispatchers still retype jobs from email, drivers lack access notes, and finance waits for signed PODs.
A requirement only matters if it changes a decision or removes a bottleneck. The useful question isn't “Does the platform have visibility?” It's “Can the dispatcher identify every job at risk of missing a terminal appointment, see who owns the next action, and alert the customer before the failure becomes a claim?”
Start with operational evidence
Run three diagnostics before speaking to vendors.
Audit the last 30 days of exceptions. Review late collections, missed delivery windows, missing PODs, invoice disputes, duplicated jobs, vehicle availability errors, detention exposure, and manual customer updates. Don't rely on management summaries. Compare the dispatch board, driver messages, delivery documents, and finance records.
Attach a business consequence to every gap. A missing POD can delay invoicing, create a dispute, or force staff to chase a receiver. A missed terminal slot can create waiting time, rescheduling work, and customer dissatisfaction. You don't need a manufactured saving estimate. You do need to identify which failure consumes cash, capacity, or management attention.
Rank requirements by cash-cycle impact. Put POD capture, job completion validation, invoice readiness, and settlement controls near the top if late documents are restricting collections. Put advanced optimization lower if planners can already create workable routes but can't close completed jobs cleanly.
Practical rule: A requirement belongs in the RFP only when the buyer can name the operational decision it improves, the user who needs it, and the evidence that will prove it worked.
Industry guidance still provides a useful baseline. Gartner's TMS criteria cover planning, freight sourcing and procurement, visibility, execution, and analytics, including order intake, consolidation, mode and route selection, carrier selection, communications, and KPI measurement (industry coverage of Gartner's TMS criteria). Use those categories as a floor, then add the haulier-specific cash and container controls that generic templates often miss.
Requirements aren't a wish list. They're decisions about what the operation must be able to do reliably on a busy day.
Core Functional Modules a Mid-Market TMS Must Cover
A dispatcher experiences a TMS as a sequence of handoffs. An order arrives, the team validates it, assigns a vehicle, briefs the driver, monitors progress, collects delivery evidence, and releases the job for billing. If one stage sits outside the system, staff recreate the same information elsewhere.
The operational sequence
Order intake should accept structured data from email, customer portals, APIs, or manual entry without creating duplicate records. The system should preserve references, addresses, requirements, rates, delivery windows, and document attachments.
Planning needs a visual jobs grid with filtering by vehicle, driver, customer, status, terminal, and exception. A planner should be able to reschedule, reassign, and bulk-edit jobs without opening each record individually. If the demo only works with one clean job, ask the vendor to demonstrate a late vehicle, a cancelled slot, and a change affecting multiple jobs.
Driver briefing must put the practical instructions where the driver can use them. That includes route information, collection and delivery references, access restrictions, contact details, timing requirements, and container or seal information where relevant. A driver app that fails without a reliable connection is a production risk, so test offline behavior rather than accepting a verbal assurance.
Execution tracking should show planned versus actual milestones, current status, ETA, delay reason, and responsible user. Tracking isn't useful if it produces a map without an exception queue.
POD capture sits directly on the cash-conversion path. The driver should submit a legible document or digital POD from the mobile workflow, with timestamps and attachments tied to the correct job. Set an internal operating standard for prompt submission, then measure it. The buyer shouldn't settle for “drivers can upload documents” as the full answer.
Invoicing should identify completed, POD-supported jobs and flag missing references, mismatched quantities, rate discrepancies, or unresolved exceptions before an invoice reaches the customer. Settlement should reconcile expected and actual charges, support approvals, and preserve an audit trail.
| Module |
Minimum Acceptable Behavior |
Failure Mode if Missing |
| Order intake |
Capture structured job data and attachments without duplicate entry |
Re-keying, missing references, duplicate jobs |
| Planning board |
Filter, reassign, reschedule, and bulk-edit live jobs |
Planners work from stale spreadsheets |
| Driver briefing |
Deliver route, access, timing, and reference notes on mobile |
Missed instructions and avoidable calls |
| Execution |
Record milestones, ETA, delays, and owners |
Problems surface only after a complaint |
| POD capture |
Tie images or digital records to the correct completed job |
Billing waits while documents are chased |
| Invoicing |
Release supported jobs and flag exceptions |
Incorrect invoices and debtor disputes |
| Settlement |
Compare planned charges with actual costs |
Margin leakage and manual reconciliation |
Use this overview of transport management system modules to test whether a vendor's terminology maps to real workflows. The important distinction is between a module that exists in the menu and a workflow that survives a difficult operating day.
Container-Specific Requirements Beyond Generic Haulage
A pallet-load checklist treats a movement as an origin, destination, vehicle, and delivery event. Container operators deal with a different operational object. The job may depend on a booking reference, release order, terminal appointment, container number, ISO code, port status, and a free-time deadline.
A generic TMS often records the port as another stop. That's inadequate. A terminal visit is a slot-constrained event, and the consequences of delay can continue after the truck leaves the yard. The system must distinguish a haulage order from a release order, preserve the booking reference, and show the exact container associated with the move.
Minimum container data model
At job level, require fields for:
- Booking number, so the move can be matched to the customer or shipping instruction.
- Container number and ISO container code, so the physical unit and type remain unambiguous.
- Terminal or quay, including the relevant collection or delivery location.
- Free-time expiry, with a visible status and ownership for the next action.
- Release type, so dispatch understands whether the move depends on a release, booking, interchange, or another authorization.
- Slot appointment details, including the planned time, confirmation reference, and change history.
- Live ETA to the terminal, so the team can intervene before a slot is missed.
Demurrage and detention tracking shouldn't be buried in a notes field. The system should display the clock, connect it to the container and job, and generate an exception when the deadline is approaching or operational data is incomplete.
| Requirement Area |
Generic Haulage Assumption |
Container-Specific Need |
| Job identity |
Customer order and delivery reference |
Booking, release, container, and haulage references |
| Vehicle movement |
Pickup and delivery milestones |
Terminal slot, gate event, interchange, and quay status |
| Freight detail |
Goods, quantity, packaging |
ISO code, container number, seal, and release type |
| Time control |
Delivery window |
Free-time expiry plus detention and demurrage exposure |
| Visibility |
Vehicle or shipment location |
ETA to terminal and status across port-related events |
| Exception handling |
Late pickup or delivery |
Missed slot, unavailable release, gate rejection, or clock risk |
A container operator should reject any platform that can't show these fields in the dispatcher's working view. The container transport software architecture guide provides useful context for evaluating container-specific workflows, but the final test is operational. Give the vendor a real booking, a changed terminal slot, and a free-time deadline. Ask the team to manage the exception without creating a side spreadsheet.
Integrations and Data Exchange That Operators Actually Rely On
Integration discussions often become architecture theatre. Vendors talk about APIs and connectivity while the buyer fails to ask who owns the data, how often it moves, and what happens when the feed stops.
Use three tiers. The first protects finance, the second protects dispatch, and the third protects port execution.
Tier one protects the invoice
ERP and accounting connections include Sage, Xero, QuickBooks, SAP Business One, and Microsoft Dynamics 365 Business Central. Finance usually owns the master data, including customers, tax settings, nominal codes, rates, and debtor status. The integration should use a documented REST API, approved connector, or secure file exchange, with scheduled or event-driven updates.
At minimum, exchange customer and job references, invoice lines, tax data, currencies where applicable, credit status, payment status, and settlement adjustments. Without this connection, staff rekey invoices and finance struggles to reconcile debtor balances.
Tier two protects the daily plan
Telematics and driver systems such as Webfleet, Microlise, Trimble, and Geotab feed operational data. The operations team owns the working interpretation, even if the telematics provider controls the source platform. Use REST APIs, webhooks, or secure files, with frequent updates appropriate to the event. Minimum fields should include vehicle identity, driver identity, location, timestamp, ignition or movement status, ETA inputs, and relevant driver or vehicle alerts.
Customer and 3PL portals should exchange order creation, status milestones, ETA, exception reason, POD availability, and reference numbers through REST or SFTP. If the feed fails, dispatchers shouldn't revert to phone calls and scattered messages.
Tier three protects terminal execution
Port and EDI systems may include Portbase, Cargo Community System, EDIFACT IFTMIN, PortNet, and terminal appointment booking APIs. The external port or terminal often owns the data. Ask specifically whether the TMS supports the required message format, acknowledgment handling, error visibility, and slot status updates.
| Tier |
Integration Group |
Typical Systems |
Data Owner |
Protocol / Cadence |
Failure Mode if Missing |
| One |
ERP and accounting |
Sage, Xero, QuickBooks, SAP Business One, Business Central |
Finance |
REST, connector, or SFTP, scheduled or event-driven |
Duplicate rekeying and unreconciled balances |
| Two |
Telematics and driver apps |
Webfleet, Microlise, Trimble, Geotab |
Operations and fleet |
REST or webhook, frequent event updates |
Dispatch falls back to calls |
| Two |
Customer and 3PL portals |
Customer platforms and partner portals |
Operations or customer |
REST or SFTP, order and milestone events |
Manual status updates and document chasing |
| Three |
Port and EDI systems |
Portbase, Cargo Community System, PortNet, terminal APIs |
External terminal or port |
EDI, API, or secure file exchange, event-based |
Manual slot booking and opaque port status |
The dangerous gap is a TMS that integrates with finance but has no practical port connectivity. For a container operator, that can leave the most time-sensitive part of the job outside the system.
Security, Compliance and Road-Safety Evidence
A vendor's security slide isn't evidence. Procurement needs documents, system access, and contractual commitments that can withstand a customer audit or regulator inspection.
Require a current ISO 27001 certificate covering the specific TMS service, not merely the vendor's parent company. Ask for a published SOC 2 Type II report or equivalent assurance, GDPR-aligned processing terms, hosting details relevant to your organization, and a clear data retention policy. The contract should also address subprocessors, breach notification, data export, and deletion.
Evidence the operation can retrieve
Role-based access should separate dispatch, drivers, finance, customers, administrators, and subcontractors. MFA, encryption in transit and at rest, immutable audit trails, and controlled administrator access are baseline controls. Ask to see how the system records edits to rates, PODs, delivery status, invoices, and user permissions.
For operators affected by the EU Mobility Package, confirm how tachograph and driver-hours data is imported, downloaded, stored, and produced during an inspection. A TMS doesn't replace specialist compliance systems automatically. It must show exactly which data it handles and where another system remains authoritative.
ISO 39001 defines requirements for road traffic safety management systems and is a useful reference for repeatable, auditable safety processes (ISO's transport sector guidance). A TMS can support that evidence through driver behavior records, incident logs, training status, subcontractor qualification, vehicle checks, and links between safety controls and dispatched work.
A practical supply chain compliance resource can help structure the wider control framework. During vendor evaluation, ask each supplier to demonstrate evidence retrieval live. If producing an audit trail requires a support ticket, the control isn't operationally mature.
Deployment, Onboarding and Total Cost of Ownership
In 2026, implementation ease and pricing transparency should be baseline requirements, not special concessions for smaller operators. A mid-sized haulier shouldn't accept a long transformation program because the vendor offers more screens than the business can use.
Demand a named onboarding lead, a written scope, and a fixed go-live plan for the planning-to-invoice core. The vendor should provide a sandbox tenant for parallel running, documented import templates, role-based training, and a process for handling defects after launch. Ask what the customer must supply, because hidden internal work is still part of the project cost.
Build the real cost model
Price the system across a three-year horizon. Include licensing, integration work, data migration, training, internal project time, support tiers, device or connectivity costs where applicable, and the opportunity cost of delayed invoicing.
| Cost Line |
Year 1 |
Year 2 |
Year 3 |
Notes |
| Software licence |
Quoted amount |
Quoted renewal |
Quoted renewal |
State whether pricing is per vehicle, driver, job, or user |
| Implementation |
One-time amount |
None or change requests |
None or change requests |
Require a fixed scope and cap |
| Integrations |
Build and setup |
Maintenance |
Maintenance |
Separate native connectors from custom work |
| Training |
Initial delivery |
Refresher or new-user training |
Refresher or new-user training |
State what is included |
| Support |
Support tier |
Support tier |
Support tier |
Define response times and escalation |
| Internal time |
Staff allocation |
Change management |
Change management |
Include finance and driver adoption work |
| Exit and migration |
Contracted service |
Contracted service |
Contracted service |
Define export format and assistance |
Red flags include minimum commitments longer than 24 months, per-API-call charges, and onboarding billed at uncapped daily rates. Vendors should explain every variable cost before signature. A cheap licence with expensive integration work is not a cheap TMS.
KPIs, SLAs and the POD-to-Invoice Performance Loop
A dashboard full of metrics can still leave the cash cycle invisible. Define each KPI as an operational calculation with an owner, source, exception rule, and consequence.
On-time delivery needs a named appointment window. “On time” should mean the actual arrival or completion event falls inside the agreed window, not merely that the driver reached the general area.
POD turnaround should measure the elapsed time from delivery completion to scan or digital upload. Use the median rather than a selectively reported best case, and segment the result by driver, customer, job type, and subcontractor.
Invoice-to-cash should measure the period from accepted POD and invoice release to customer payment. This links dispatch behavior to finance outcomes. A POD that arrives late is not just a document problem. It delays the point at which the business can bill confidently.
A worked operating example might set 95% on-time delivery within a 60-minute window, POD median under 4 hours, and DSO under 38 days. Those figures are examples of KPI definitions, not universal benchmarks. The TMS must show how each result is calculated, who supplies the data, and what happens when the vendor's service misses its agreed threshold.
| KPI |
Definition |
Target |
Data Source |
SLA Response |
| On-time delivery |
Completion inside the named appointment window |
95% within a 60-minute window |
TMS milestone and appointment data |
Root-cause review and service credit if vendor data is unavailable |
| POD turnaround |
Median hours from delivery completion to uploaded POD |
Under 4 hours |
Driver app and POD timestamp |
Escalation for failed mobile workflow |
| Invoice readiness |
Completed jobs with required references and POD attached |
Define during contracting |
TMS job, POD, and billing records |
Correction plan for workflow defects |
| Invoice-to-cash |
Days from POD acceptance and invoice release to payment |
DSO under 38 days |
TMS and accounting system |
Finance review of disputes and integration failures |
For wider fleet controls, 2025 fleet safety and compliance tips can supplement the road-safety requirements above. Keep the measurement loop closed: delivery event, POD acceptance, invoice release, dispute status, and payment outcome should be traceable to the same job.
Sample RFP Language and Vendor Evaluation Questions
A good RFP forces a vendor to describe behavior under pressure. Replace “provides real-time visibility” with a testable clause: “The supplier must display planned and actual milestones, current exception status, and the timestamp and source of each update for every active job.”
Copy-ready clauses
- Data ownership: “All operational, customer, job, POD, invoice, audit, and configuration data created by the buyer remains the buyer's property and must be exportable in a documented, usable format.”
- Audit access: “The buyer must be able to retrieve user, status, rate, POD, invoice, and permission changes with timestamps and actor identity.”
- Integration service level: “Critical integrations must have an agreed availability target, monitoring, incident notification, and recovery process.”
- POD retention: “POD images and associated metadata must remain retrievable for the buyer's contracted retention period and exportable at termination.”
- Exit assistance: “The supplier must provide documented export, transition support, and reasonable cooperation with a replacement provider.”
Thirty questions that force useful answers
- Can the system capture orders from our required channels?
- Can planners filter the live jobs grid by vehicle, driver, customer, status, and exception?
- Can users bulk-edit or reassign jobs?
- Can the system preserve a full change history?
- Can drivers receive route, access, and reference instructions on mobile?
- Does the driver workflow operate when connectivity is unavailable?
- Can the system record planned and actual milestones?
- Can it flag jobs at risk before the appointment window is missed?
- Can drivers upload PODs directly against the correct job?
- Can finance see which jobs are invoice-ready?
- Can the system block or flag invoices with missing PODs or references?
- Can it reconcile expected and actual transport charges?
- Can it capture booking, release, container, terminal, and ISO code data?
- Can it display free-time expiry and detention or demurrage risk?
- Can it record terminal slot bookings and changes?
- Can it calculate or receive live ETA to the terminal?
- Which ERP and accounting systems have supported connectors?
- Which REST, webhook, SFTP, or EDI interfaces are available?
- Which party owns each exchanged data field?
- What happens when an integration fails?
- Can users see rejected messages and retry them?
- Can the system exchange POD and status data with customer portals?
- Does the service have ISO 27001 coverage for the TMS itself?
- Is a SOC 2 Type II report or equivalent available?
- How are MFA, encryption, roles, and audit logs implemented?
- How are driver-hours and tachograph workflows supported?
- Can the vendor show safety and subcontractor evidence retrieval?
- Who owns onboarding, and what is included in the fixed scope?
- Is there a sandbox for parallel running and user acceptance testing?
- What are the licence, integration, support, renewal, API, exit, and termination charges?
Weight the scorecard toward on-time performance, POD turnaround, invoice readiness, container status control, and ERP integration. Nice-to-have analytics shouldn't outrank the workflows that keep trucks moving and invoices defensible.
Mapping the Requirements to Logivo as a Worked Example
A practical evaluation of Logivo should start with the published operating scope, not a sales claim. Its transport management platform covers job creation, allocation, execution tracking, driver briefings, digital POD capture, and invoicing in a connected workflow. It also includes container-haulage workflows and practical AI support for document and data-entry tasks.
| Requirement Area |
Fit |
Notes |
| Functional modules |
Meets core scope |
Validate bulk editing, exception ownership, and offline driver behavior |
| Container specifics |
Relevant coverage |
Confirm the exact booking, release, terminal, and free-time fields required |
| Integrations |
Requires validation |
Confirm native ERP, telematics, portal, API, SFTP, and port connectivity |
| Security |
Contract and evidence check |
Request service-specific certifications, audit controls, retention, and processing terms |
| Deployment |
Designed for lower setup overhead |
Confirm scope, timeline, migration duties, training, and change-request pricing |
| KPIs |
Configurable starting point |
Test calculation logic for milestones, POD turnaround, invoice readiness, and cash data |
| RFP readiness |
Suitable for structured evaluation |
Require measurable answers and written commitments rather than feature descriptions |
A mid-market haulier should still validate three areas before signing: the exact container status model, the accounting integration and reconciliation process, and the behavior of the mobile workflow in poor connectivity. Treat this table as a starting assessment, not a substitute for live process testing.
Quick-Reference Checklist, Glossary and FAQ
Give this checklist to the operations manager, finance director, and dispatcher. Each question should receive a clear yes or no during a vendor demonstration.
Buyer checklist
- Functional core: Can the system create, plan, allocate, brief, track, complete, and bill jobs in one workflow?
- Jobs grid: Can users filter, bulk-edit, reassign, and identify exceptions without opening every job?
- POD: Can drivers submit signed or digital proof directly against the job?
- Invoice control: Can finance identify invoice-ready jobs and missing documents?
- Container control: Can the system store booking number, container number, terminal, release type, slot, and free-time expiry?
- Terminal visibility: Can dispatch see ETA and port-related exceptions in the same operational view?
- ERP integration: Can customer, rate, invoice, tax, payment, and adjustment data move without duplicate rekeying?
- Driver and telematics data: Can the system receive vehicle, driver, location, timestamp, and milestone data?
- Port exchange: Can it support the required API, SFTP, EDI, or appointment workflow?
- Security: Does the vendor provide service-specific certification, MFA, encryption, role controls, and audit trails?
- Compliance: Can the team retrieve driver, incident, subcontractor, and document evidence?
- Deployment: Is there a named onboarding lead, fixed scope, sandbox, migration plan, and training plan?
- Commercials: Are licensing, integrations, support, API use, onboarding, renewal, and exit costs itemized?
- KPIs: Are on-time delivery, POD turnaround, invoice readiness, and invoice-to-cash definitions written down?
- RFP protection: Do the contract and SLA cover data ownership, availability, audit access, retention, and transition support?
Plain-English glossary
TMS: Software that manages transport planning, dispatch, execution, visibility, documents, billing, and settlement.
POD: Proof of delivery, such as a signed delivery note, digital confirmation, timestamp, or attached delivery record.
EDI 204 and 214: Common electronic messages used to communicate transport tenders and shipment status events. Confirm the exact message formats your customers require.
ISO 39001: A standard for road traffic safety management systems, useful for structured safety controls and auditable evidence.
SOC 2: An independent assurance report about controls relevant to security and related service commitments.
Telematics: Vehicle and driver data, including location, movement, and selected operational signals.
Slot booking: A scheduled appointment for a vehicle to access a terminal, depot, warehouse, or other constrained facility.
Detention: A charge or exposure associated with keeping equipment outside the permitted period. Demurrage generally concerns equipment or cargo remaining within a terminal beyond the allowed period. Contract definitions vary, so configure the system to match the governing terms.
Frequently asked questions
How long does a typical mid-market rollout take?
The answer depends on data quality, integrations, process variation, and user readiness. For the planning-to-invoice core, require the vendor to propose a fixed, evidence-based go-live plan rather than accepting an open-ended implementation.
What's the smallest viable scope for a 20-truck fleet?
Start with order intake, jobs grid, dispatch, driver briefing, execution milestones, POD capture, invoice readiness, and accounting integration. Add advanced optimization and broader portal connectivity after the core workflow is stable.
How do we avoid scope creep during onboarding?
Write the minimum viable process into the statement of work. Name the required fields, integrations, users, reports, acceptance tests, and training outputs. Put every additional request through a priced change-control process.
When does building versus buying make sense?
Build only when your operating model is distinctive and you can fund long-term ownership, support, security, integrations, and upgrades. Buy when the process is common enough to use proven workflows, but insist on configuration and data access instead of expensive custom development.
Logivo offers a unified workflow for hauliers and container operators to plan jobs, brief drivers, capture digital PODs, manage container-related work, and connect completed jobs to invoicing. Visit Logivo to compare its workflow against your RFP, then test the three areas that matter most in your operation: POD turnaround, accounting integration, and container status control.