Air Cargo and Freight Forwarding Software: The Problems Off-the-Shelf Systems Cannot Solve

Why air cargo software makes or breaks a freight forwarder

Walk into any forwarder's ops floor at 4pm on a Thursday and you can see the software problem without asking a question. There are three screens open per person. CargoWise or Magaya or Descartes on one. A carrier portal on the second: Lufthansa Cargo's eBooking, or Emirates SkyCargo, or Cargolux, whichever airline has the space this week. And on the third, the thing that actually runs the business: an Excel file named something like CONSOL_JFK_FRA_WEEK32_v4_FINAL.xlsx, with a tab per consolidation and a column of house AWB numbers typed in by hand.

That spreadsheet exists because the forwarding system was built to record shipments, not to build them. Your operator is deciding which of eleven house bills go on the MAWB tonight, which slip to tomorrow's freighter, what the chargeable weight comes to after the dim factor, and what that does to the margin on a consol quoted three weeks ago at a rate that has since moved. None of those decisions live in CargoWise. They live in the operator's head and get typed into the system afterward as a record of a decision already made.

The leak is measurable. A 30-person forwarder doing 1,200 to 2,000 shipments a month typically has two to four people whose entire job is re-keying: commercial invoice into the customs entry, MAWB into the system, arrival notice into the tracking field, carrier status email into a customer update. At a loaded cost of $55,000 to $75,000 each, that is $150,000 to $250,000 a year of pure transcription. Add the errors: one wrong HTS code on an entry, one missed 24-hour advance filing, and you are paying a penalty plus the demurrage while the freight sits at the airline's warehouse. Then add the invisible one: the quote that took four hours to build because someone had to check three airline rate sheets and one Cargolux tariff PDF, and by the time it went out the shipper had already booked with the forwarder who answered in twenty minutes.

Problem 1: your AWB data model is somebody else's, and it does not fit your consols

Here is the scenario that breaks every off-the-shelf forwarding system I have seen. You run a co-load: your house bills, plus three house bills you took from a partner forwarder in Chicago, all riding on one MAWB you bought from Lufthansa. Two of those house bills are DG (Class 9 lithium batteries, UN3481), one is temperature-controlled pharma. The consol is split at Frankfurt: part goes on to Milan on a truck under a CMR, part flies onward to Tel Aviv on a different MAWB. Now: what is the actual margin on that consol, and who owes whom what?

CargoWise will let you record most of this. It will not let you model it the way you actually run it, because its consolidation and profit-share structures are fixed. When your co-load agreement with the Chicago partner splits net-net on the buy rate but you keep 100% of the origin handling and they keep the destination, you end up with a spreadsheet doing the settlement and a journal entry going back into the system. Magaya is lighter and cheaper but its consolidation module assumes a much simpler world. Descartes gives you strong messaging but not your commercial logic.

What a custom build does: it starts with a shipment graph, not a shipment record. HAWBs, MAWBs, co-load allocations, splits, re-consolidations, and onward legs are all edges. Each piece has its own weight, dim, DG classification, and commercial terms, and margin recomputes automatically at every level: per house bill, per consol, per lane, per partner, per month. When your operator moves a house bill off tonight's MAWB, the buy-rate allocation, the chargeable weight, and the P&L on both consols update in the same transaction. The build effort here is not the screens. It is getting the domain model right: chargeable weight rules, IATA rate structures with weight breaks, ULD-level pivots, and a settlement ledger that handles co-load profit share without a human in the loop. That model is the whole product. Everything else is a view onto it.

Problem 2: document handling eats your operations team alive

Every shipment arrives as documents, and almost none of them arrive as data. A commercial invoice as a PDF from the shipper. A packing list as a photo of a printed sheet. An MSDS for the DG. A certificate of origin. An arrival notice emailed by the airline as an HTML table. Your team reads them and types them into the entry.

The off-the-shelf tools have not solved this because they cannot. CargoWise has document capture, but it is template-driven: it works when your top ten shippers send consistent formats, and falls over on the eleventh. And your customer mix is the whole point. You have 300 shippers, and the long tail sends whatever their accounting system produces.

This is where AI genuinely earns its cost, and it is the single clearest ROI in this category right now. A document pipeline that takes any PDF, image, or email body and extracts a structured shipment object: shipper, consignee, line items with descriptions, HTS candidates, values, currency, Incoterms, package count, gross and dim weight, DG indicators. Not template-matched. Read. The model returns a confidence score per field, and you set the routing rule: above threshold it flows straight to the entry, below threshold it goes to a review queue where the operator sees the extracted value next to the highlighted source region in the document and confirms with one keystroke. On builds we have shipped, forwarders land at 80% to 92% of fields auto-accepted after the first few weeks of tuning against their real document mix. That does not eliminate the ops role. It turns a data-entry job into an exception-handling job, which is the difference between two people and five.

The second AI use here is the arrival notice and carrier status email. Airlines still send unstructured status updates to a shared ops inbox. A classifier that reads the inbox, matches the email to an AWB, extracts the event and timestamp, and writes it to the shipment timeline kills a whole category of manual work and makes customer tracking actually real time.

Problem 3: customs filing is where the money leaks and the fines land

The specific pain: you file ACE entries through a broker interface or a customs software bolt-on, and it is a separate system from the one holding the shipment. So the HTS code gets classified in one place, the entry gets filed in another, and the shipment record in CargoWise gets updated manually to say it cleared. When CBP issues a CF-28 request for information nine months later, someone spends half a day reconstructing what was filed from three systems and an email thread.

Off-the-shelf cannot fix this because customs is inherently jurisdictional and your mix is specific. If you move a lot of Section 321 de minimis e-commerce, your problem is volume and Type 86 filing. If you move pharma into the EU, your problem is ICS2 ENS data quality and the fact that the airline will reject your filing at 4am local time. If you handle Chinese origin goods, your problem is Section 301 exclusions and the classification defensibility of every line.

What a custom build does: it makes the entry a first-class object in the same system as the shipment, with a full audit trail. Every HTS classification decision records who or what made it, on what description, with what supporting document, and when. An AI-assisted classifier proposes a code from the invoice description with a confidence score and a rationale, the licensed broker approves it, and that approval is the record CBP sees nine months later. The system then pushes the entry via ABI, receives the status back, and writes the disposition onto the shipment timeline automatically. Same for ICS2 into the EU and pre-lodgement into the UK. On the compliance side, denied party screening runs on every new shipper and consignee at booking, not as a batch job nightly, and blocks the booking rather than flagging it after the freight is airborne. That is the difference between a control and a report.

Problem 4: quoting is slow, and slow quoting is lost freight

A forwarding salesperson gets an RFQ at 9am: 4 pallets, 1,850 kg gross, 2,400 kg chargeable, ORD to AMS, ready Friday, needs to land by Tuesday. To answer it properly they need the airline rate at that weight break, current fuel and security surcharges, the truck to ORD, the export clearance, the destination handling, and the target margin for that customer tier. Today that means opening rate sheets, checking a partner email for the destination charge, and doing the math in Excel. Two to four hours. The customer wanted an answer in one.

CargoWise has rate management, and it works if your rates live cleanly in it. They do not, because half your buy rates are ad hoc: a spot rate the airline gave you on the phone Tuesday, a soft block you bought for Q3, a partner's destination tariff that arrives as a PDF every quarter. So the rate table is perpetually stale, and your team quotes from memory and the sheet.

The custom build: a rate engine that ingests rates from wherever they actually come from. Airline tariff sheets and partner PDFs go through the same extraction pipeline as your shipping documents, landing as structured rate records with validity windows and weight breaks. Spot rates get captured in ten seconds from a mobile-friendly form when your ops manager is still on the call with the airline. Then quoting becomes a lookup: enter lane, weight, dims, service level, get the all-in cost with every charge line broken out and the margin already applied per customer tier, in under thirty seconds. Layer AI on top for the after-hours case: an inbound RFQ email is parsed, priced against the rate engine, and either auto-replied with an indicative quote inside a guardrail (only for known lanes, known customers, within a margin floor you set) or drafted for the salesperson to send at 7am. The forwarders we have built this for do not describe the win as efficiency. They describe it as winning freight they used to lose on response time.

Problem 5: your customer has no visibility, so your team is the visibility layer

Count the "where is my shipment" emails your team answers in a week. At 1,500 shipments a month it is typically 200 to 400. Each one is a person opening a system, finding the AWB, checking the last status, and typing a reply. Ten minutes each, conservatively, and it is the most senior people who get pulled in because the customers who ask are the customers who matter.

The off-the-shelf answer is a customer portal, and it does not get used. Not because portals are bad, but because the shipper's logistics coordinator already has six portals and will not log into a seventh. So they email you, and you are back where you started.

The build that works: push, not pull. Milestone-driven notifications on the events that actually matter to that specific customer, delivered on the channel they already use. Some want an email at departure and arrival. Some want a Slack message on exceptions only. Some want an EDI 214 or an API webhook into their own TMS or their NetSuite or their SAP, and if you can deliver that, you become genuinely hard to switch away from. The exception logic is the valuable part: not "here is every status", but "this shipment was offloaded at FRA and will now miss the Tuesday delivery, here is the recovery plan and the new ETA." That requires linking flight schedule data, your consol structure, and the customer's promised delivery date, which is exactly the join no off-the-shelf tool can make because it does not hold all three. The AI contribution here is the follow-up: drafting the exception notification in your account manager's voice, with the specific recovery action, so the customer hears about the offload from you at 6am rather than discovering it themselves at 2pm.

What this costs and how long it takes

These bands come from Digital Heroes delivery experience across 2,000+ projects, not from a market survey.

A focused first release for a forwarder runs $60,000 to $130,000 over 12 to 16 weeks. That buys the shipment and consol data model, AWB and HAWB management, the document extraction pipeline with a review queue, one carrier integration, and either the rate engine or the customs entry flow. Not both. You pick the one bleeding worse.

A full platform is $150,000 to $400,000 phased over 6 to 12 months: the above plus multi-carrier integrations, ABI or ICS2 filing, co-load settlement, customer notifications and API, and accounting integration.

What pushes you toward the top of the band in this category, specifically:

Customs filing certification. Building to ABI or ICS2 is not a weekend integration. There is a certification process, a test cycle with the authority, and a real timeline you do not control. Budget 6 to 10 weeks of calendar time and expect it to be the long pole. Multiply per jurisdiction.

Carrier integration count. Every airline is different. Some have decent APIs. Some give you Cargo-IMP or Cargo-XML messaging over a legacy channel. Some give you a portal and nothing else, which means scraping or manual capture. Each carrier is 1 to 3 weeks. Ten carriers is a quarter of your budget.

Migrating out of CargoWise. Your history is in there and getting it out cleanly is real work. Open shipments, rate tables, customer records, and the accounting linkage. Plan for a parallel-run period where both systems are live, because you cannot flip a forwarder overnight without dropping freight.

Dangerous goods and pharma. If you handle DG or GDP-regulated pharma, the validation and audit trail requirements add scope that does not look like much on a wireframe and is meaningful in the build.

Accounting integration. Freight accounting has its own gravity. Job costing, accruals against estimated buy rates, and the reconciliation when the airline's invoice arrives three weeks later at a different number than you accrued. Connecting that to NetSuite or Sage or QuickBooks properly is 3 to 5 weeks and is where projects quietly overrun.

Build versus buy: the honest line

Stay on the off-the-shelf tool if you are under roughly 400 shipments a month, running one or two trade lanes, and your customs work goes through an outside broker. CargoWise at that size is a reasonable deal even at its licensing model, and your constraint is sales, not software. Building against a business that small is a way to spend $100,000 automating a process you have not stabilized yet. Magaya is the right call for a smaller forwarder who wants something usable this quarter. Fix your process first, then automate it.

Build when these show up, and they show up together:

Your differentiator is something the system cannot express. A co-load model, a specific vertical service like pharma lane control or AOG parts, a partner network with unusual economics. If the thing your customers pay you for lives in a spreadsheet next to your forwarding system, you have your answer.

You have three or more people whose job is re-keying. That is $180,000 a year, forever, and it is the cheapest part of the cost. The expensive part is that those people are your throughput ceiling.

Your licensing plus modules plus per-transaction fees are pushing past $80,000 to $120,000 a year and rising with your volume. At that point a build has a payback window you can put on one page. Note that CargoWise publishes its licensing model publicly and it is volume-linked by design: growing costs you more forever, which is the opposite of what a system should do.

You have been told "that is not how the system works" three times about the same workflow. That is the signal. The vendor is not wrong and will not change, because their product is built for the median forwarder and you are not it.

The position I will take: most forwarders under $20M revenue should not build, and most forwarders over $50M revenue with a real vertical specialization are already losing money by not building. The middle is a judgment call that comes down to one question: is your operating model something you would defend, or something you inherited?

How to choose a developer for air cargo and freight forwarding software

Ask them to model a co-load on a whiteboard before you sign anything. Give them the scenario: your house bills plus a partner's, one MAWB, a split at the hub, DG in the mix, profit share on the buy rate. If they draw a shipments table with a parent_id column, they have not built this before. The domain model is where these projects succeed or fail, and it is visible in the first hour.

Ask what they have actually integrated. Not "we do integrations." Which airline, which message standard, Cargo-XML or Cargo-IMP or a REST API, and what broke. Anyone who has done it has a story about a carrier whose test environment did not match production. Anyone who has not will say it is straightforward.

Ask how they handle the customs certification timeline. The right answer includes the word "parallel": they start the ABI or ICS2 certification process early and build the rest of the system alongside it, because the authority's calendar is not yours. If they scope it as a two-week task at the end, they will miss.

Ask who owns the code and get it in writing, along with the repository access, the infrastructure, and the deployment pipeline. This system will run your operation for a decade. You should be able to hire a different team on any given Monday and hand them the keys. If a developer will not agree to full ownership and a clean handover package, the conversation is over, whatever else they are good at.

And ask for the reference who left. Every serious shop has one project that went sideways. What they learned from it tells you more than the three happy references will.