Freight forwarding is one of the most documentation-heavy, integration-intensive, and operationally complex industries in existence. A single international shipment touches customs authorities, carriers, ports, warehouses, banks, insurers, and the shipper — each with their own systems, data formats, and communication requirements.
The software that manages this complexity is either very good or very painful. Most freight forwarders I've spoken to over the years experience it as the latter.
This post is a practical guide to freight forwarding software — what the core features actually are, where the hard technical problems live, when off-the-shelf solutions stop working, and what building custom freight software actually involves.
What freight forwarding software needs to do
At its core, freight forwarding software is a coordination and documentation platform. It needs to manage the movement of goods across multiple parties, geographies, and handoffs — while generating the documentation each party requires.
The minimum viable feature set for a modern freight management system:
Shipment management
The central object in any freight system is the shipment — a consignment of goods moving from origin to destination. Shipment management covers:
- Shipment creation with origin, destination, cargo details, and service requirements
- Status tracking through every stage: booking, pickup, origin handling, transit, customs, delivery
- Document generation and management: bill of lading, air waybill, packing list, commercial invoice, certificate of origin
- Exception management: delays, damage, customs holds, routing changes
- Event timeline: a full audit trail of every status change, document update, and communication
Rate management and quoting
Freight pricing is complex. Rates vary by carrier, service level, origin/destination pair, cargo type, weight, volume, and time of booking. A functional quoting system needs:
- Carrier rate management: importing and storing rate cards from multiple carriers
- Automated quote generation based on shipment parameters
- Margin management: applying markup to carrier rates to generate selling rates
- Spot rate handling: one-off rates for shipments outside standard rate cards
- Quote comparison: showing multiple carrier options at different price/service trade-offs
Carrier and vendor management
Freight forwarders work with multiple carriers, agents, trucking companies, and port handling firms. The system needs to manage:
- Carrier profiles with contact information, service areas, and performance data
- Agent network management for overseas destinations
- Purchase order and cost tracking against each vendor
- Invoice reconciliation: matching vendor invoices to expected costs
Customs and compliance
This is where freight software gets genuinely hard. Customs requirements vary by country, cargo type, and trade lane. At minimum:
- Customs entry preparation: HS codes, valuation, country of origin
- Document management: certificates, permits, licenses
- Duty and tax calculation
- Integration with customs authorities (HMRC in the UK, CBP in the US, etc.)
- Sanctions and compliance screening
Financial management
- Customer invoicing: generating invoices from actual charges incurred
- Accounts payable: managing payments to carriers and vendors
- Profit and loss by shipment: tracking margin on individual shipments
- Currency management: handling multi-currency transactions
Reporting and analytics
- Shipment volume and revenue by lane, carrier, client, and time period
- Exception rates and delay analysis
- Carrier performance metrics
- Client reporting: generating client-specific reports on their shipments
Where freight software gets technically hard
Having built logistics software, I can tell you that the features above sound straightforward until you actually build them. Here's where the real complexity lives:
Carrier integrations
Every carrier has its own API — and most of them are not good. Legacy carriers often have EDI-based integration (Electronic Data Interchange, a 1970s data exchange standard that is still widely used in shipping). Modern carriers have REST APIs, but they vary enormously in quality, documentation, and stability.
A freight forwarder working with 10 carriers has 10 different integration problems. Some will require EDI. Some will have unreliable APIs that break without notice. Some will have APIs that are technically functional but return inconsistent data formats. Some will have no API at all and require screen-scraping or manual data entry.
The integration layer is always more expensive and time-consuming than it looks in a project proposal.
Customs system integration
UK customs (HMRC/CDS), US customs (CBP/ACE), and EU customs each have different electronic filing systems. Getting data into these systems — and getting responses back — is a significant technical integration project. The systems are often old, the documentation is often poor, and the consequences of errors are serious (customs delays, fines, cargo holds).
Most freight forwarders handle customs through specialist software (like Descartes or CargoWise) or customs agents rather than building direct customs filing capability. This is usually the right call — customs compliance software is a specialist product category and building it from scratch is rarely justified.
Multi-modal complexity
Freight moves by sea, air, road, and rail — often on the same shipment. Each mode has different documentation requirements, different carrier relationships, and different tracking mechanisms. A system that handles ocean freight gracefully may not handle air freight or road freight without significant additional development.
Data quality and standardisation
The shipping industry runs on data from dozens of sources — carrier track and trace, port systems, customs authorities, GPS tracking. This data is inconsistent, incomplete, and often delayed. Building a system that presents clean, accurate shipment status when the underlying data is messy is a significant engineering challenge.
Document generation
Freight documents — bills of lading, air waybills, customs declarations — have specific legal and formatting requirements. Generating them correctly, in the right format for each country and carrier, is more technically demanding than it appears. A bill of lading for an FCL ocean shipment looks different from an LCL bill. An air waybill has different fields from a sea waybill. HAWB vs MAWB. Express release vs original documents. The edge cases accumulate quickly.
Off-the-shelf freight management systems
There are established freight management systems in the market. The major players include:
Cargowise One — The dominant enterprise platform for large freight forwarders. Extremely comprehensive, extremely complex, and extremely expensive. Mid-market and small forwarders typically find it too complex and too costly.
Descartes — Strong on customs and compliance, used by forwarders who prioritise regulatory coverage. Good customs filing capabilities.
Magaya — More accessible for mid-market forwarders. Covers the core FMS requirements without the enterprise complexity of CargoWise.
WiseTech Global products — A family of logistics software products targeting different segments.
Freightware, Logisuite, and others — Mid-market and SME-focused FMS products.
The challenge with all of these is the same challenge with any off-the-shelf enterprise software: they were built for the average freight forwarder, and your operations are not average.
Common complaints from freight forwarders about off-the-shelf FMS:
- Quoting workflows don't match how they actually price shipments
- Client portal doesn't give clients the visibility they're asking for
- Reporting doesn't produce the metrics they actually need
- Integrations with specific carriers or systems aren't supported
- The system is designed for one mode (typically ocean) and handles other modes poorly
- Cost and complexity scales poorly as the business grows
When to build custom freight forwarding software
Custom freight software is the right answer when:
You have a specific service proposition that standard software can't represent. If your differentiation is a specific pricing model, a unique service type, a proprietary routing approach, or a client experience that no off-the-shelf product delivers — build custom.
Your client requirements exceed standard platform capabilities. Enterprise clients increasingly demand custom integrations, specific data feeds, white-labelled portals, and reporting that off-the-shelf products don't produce. If winning or retaining significant clients requires capabilities your FMS can't deliver, the ROI calculation often favours building.
You're building a freight technology product. If your business model involves licensing technology to other freight forwarders or logistics companies — rather than just using software for your own operations — you're building a product. Off-the-shelf software is not the foundation for a product company.
Integration requirements are too specific. If you have specific carrier relationships, customs systems, or third-party integrations that standard platforms don't support, the cost of working around those gaps often exceeds the cost of building the integration properly.
What custom freight software development actually involves
If you've concluded that custom software is right for your situation, here's what the build actually looks like.
Discovery phase (4–6 weeks)
This is the most important investment in the project. A thorough discovery phase involves:
- Mapping every operational workflow in detail
- Identifying every external system the software needs to integrate with
- Documenting document requirements by trade lane and cargo type
- Understanding reporting and analytics requirements
- Defining user types and permissions
- Auditing existing data that needs to be migrated
Skipping or shortening discovery is the most common reason freight software projects fail or go significantly over budget. The complexity of freight operations means that surface-level requirements always hide significant depth.
Core platform build (16–28 weeks depending on scope)
The minimum viable freight management system — shipment management, basic carrier integration, document generation, invoicing — typically takes 16–24 weeks with a professional agency.
A full-featured platform with multi-modal support, customs filing integration, advanced rate management, and client portal typically takes 28–40 weeks.
Carrier integration project (ongoing)
Carrier integrations should be treated as a separate, ongoing project — not as a fixed-scope component of the initial build. Each carrier integration has its own timeline and complexity. Treating them as a separate workstream with separate budgeting is more realistic than bundling them into a fixed-price initial build.
Technology choices
Modern freight software is typically built as a web application. Common stack choices:
Backend: Node.js or Python for most platforms. Python has advantages for data processing and EDI handling. Node.js has advantages for real-time tracking updates and API performance.
Frontend: React or Angular for the operational UI. Freight management interfaces are data-dense — lots of tables, filters, status updates. Both frameworks handle this well.
Database: PostgreSQL for operational data (shipments, quotes, invoices). Potentially a document database for unstructured cargo and customs data.
Message queuing: For handling carrier tracking events asynchronously — critical for platforms that receive real-time tracking updates at volume.
EDI handling: Either a specialist EDI middleware layer or custom EDI parsers depending on the number and complexity of EDI integrations required.
Typical cost ranges
Mid-complexity custom freight management system (sea and air, 3–5 carrier integrations, client portal, basic customs support):
- South Asian agency: £40,000–£90,000
- Eastern European agency: £70,000–£150,000
- UK agency: £150,000–£300,000+
Timeline: 20–32 weeks.
These ranges assume well-defined requirements. As always, poor requirements add 20–40% to both timeline and cost.
What to look for in a development partner for freight software
Freight software is specialist territory. Not every software development agency is equipped to build it well. When evaluating partners:
Ask about logistics or freight experience specifically. Generic software agencies can build almost anything, but an agency that has built freight or logistics software before understands the domain complexity without needing to learn it on your project.
Ask how they handle EDI. EDI is a specific technical skill that not all developers have. If the agency has a blank expression when you mention EDI, they're not the right partner for a freight forwarder with legacy carrier relationships.
Ask about customs integration approach. Customs is complex enough that most agencies recommend integrating with specialist customs software rather than building filing capability. That's usually the right answer. An agency that proposes to build direct customs filing from scratch without a very compelling reason should be questioned.
Ask for logistics references specifically. Not general software references — logistics or freight references. An agency that has built a warehouse management system or a transport management system has relevant experience. An agency whose entire portfolio is e-commerce or SaaS products may not.
Muhammad Nabeel is the co-founder of Teamseven, a software development agency specialising in logistics and supply chain software. We've built freight, warehouse, and logistics management systems for clients across the US, UK, and Australia since 2017. Get in touch if you're evaluating a custom freight management system.
Building a freight system for an Australian business?
We have a dedicated page covering how we work with Australian logistics and transport companies:
Custom software development for Australian businesses →
Working with a UK freight forwarding operation? We built i-mve for the UK logistics industry: