Why Generic ERPs Break on Freight Job Costing
Generic ERPs assume one charge head per job. Freight has many, across currencies, which is where the margin quietly disappears.
The short answer
Generic ERPs model a sales order: costs known at order time, margin settled on completion. A freight shipment is the opposite — a container for costs arriving over weeks from third parties, in different currencies, against charge heads rather than line items. The mismatch is structural, so no amount of configuration fixes it.
Key points
- A generic ERP models a document. A freight job is a lifecycle that stays queryable as one object.
- Costs arrive after the sale from carriers, CHAs and transporters, so true margin is unknown for weeks.
- Charge heads, not line items, are the atomic unit — each with its own buy rate, sell rate, currency and supplier.
- Multi-currency in freight is per charge head, not per document, which most ERPs cannot represent.
- The failure shows up as a parallel spreadsheet, not as an error message.
Freight forwarders evaluating an ERP usually get told the same thing: it handles job costing, every ERP does. Then implementation starts and something goes wrong that nobody can quite name. Here is the specific reason.
What does a generic ERP think a job is?
A standard ERP models a sales order. It has a customer, line items, a total, a cost of goods, and it closes. Costs are known at or near the time of sale, and the margin on a completed order is a settled number.
Freight does not work like that. A shipment is a container for costs arriving over weeks from parties who were not present when the job was quoted.
The four structural mismatches
| Mismatch | What the ERP assumes | What freight actually does |
|---|---|---|
| Timing of costs | Cost known at order time | Carrier, CHA, transporter and demurrage invoices arrive over weeks |
| Unit of costing | Line item with quantity and price | Charge head with its own buy rate, sell rate, currency and supplier |
| Currency | One currency and rate per document | A different currency and rate per charge head, on different dates |
| Shape of the record | Documents referencing each other | One lifecycle object, queryable end to end |
Costs arrive after the sale, from third parties
You quote the customer on day one. Then the carrier invoices, then the CHA, then the transporter, then a demurrage charge nobody expected. Your true margin is unknown for weeks. A generic ERP wants a cost figure at line level at order time, so implementers put an estimate in and reconcile in a spreadsheet. Every forwarder I have spoken to has that spreadsheet.
Charge heads are the atomic unit, not line items
Ocean freight, THC, BL fee, documentation, customs duty, detention, storage, transport. Each has its own buy rate, sell rate, currency, tax treatment and supplier. Each needs comparison of quoted versus actual, individually, because that comparison is the entire management report. Generic ERPs give you a line item with a quantity and a price. Charge heads are not quantities and prices.
Multi-currency is per charge head, not per document
The buy is in USD, the sell in AED, the customs duty in local currency, and each was incurred on a different date at a different rate. Most ERPs apply one currency and one rate per document. Booking a single job with charges in three currencies then requires either multiple documents — breaking the job as a unit — or manual conversion, which destroys the audit trail.
A job is not a document, it is a lifecycle
Quote, booking, pickup, customs, sailing, arrival, delivery, invoice, settlement. Costs, documents and profit expectations attach at different stages, and the job must remain queryable as one object throughout. Generic ERPs model documents that reference each other, not a lifecycle object.
How does this actually surface?
Never as a crash. It surfaces as:
- Nobody can tell you the real margin on a job until someone rebuilds it by hand.
- Operations keeps a parallel spreadsheet, because the ERP cannot show a shipment as one thing.
- Finance and operations quote different numbers for the same job in the same meeting.
At that point the ERP has become a data entry burden on top of the spreadsheet that is doing the actual work. That is the real cost, and it is invisible in any evaluation checklist.
What should you test before you buy?
Take one genuinely messy past shipment — multiple currencies, a cost that arrived six weeks late, a charge you disputed and partly recovered.
- Ask the vendor to enter it in a live demo, not a prepared one.
- Ask them to show the actual margin on that job.
- Ask for quoted versus actual on every charge head, individually.
- Require all of it without leaving the system or opening a spreadsheet.
Most demos will not survive this. The ones that do are worth your time, whether that is a purpose-built freight product or a custom build. The point is not which you pick — it is that a checklist tick against "job costing" tells you nothing.
For the general version of this argument, beyond freight, see AI-native ERP vs bolting AI onto old software.
Frequently asked questions
- Why does job costing fail in a generic ERP for freight forwarding?
- Because a generic ERP expects costs to be known at or near the time of sale, and freight costs arrive over weeks from third parties who were not present when the job was quoted. The ERP wants a cost figure at line level at order time, so implementers enter an estimate and reconcile later in a spreadsheet. That spreadsheet becomes the real system.
- What is a charge head in freight job costing?
- A charge head is a single cost or revenue component of a shipment — ocean freight, THC, BL fee, documentation, customs duty, detention, storage, transport. Each carries its own buy rate, sell rate, currency, tax treatment and supplier, and each needs quoted-versus-actual comparison individually. That comparison is the entire management report, and a line item with a quantity and a price cannot represent it.
- Can multi-currency be handled by a standard ERP for freight?
- Rarely, because in freight the currency varies per charge head rather than per document. The buy might be in USD, the sell in AED and the customs duty in local currency, each incurred on a different date at a different rate. Most ERPs apply one currency and one rate per document, so a single job with three currencies forces either multiple documents — breaking the job as a unit — or manual conversion, which destroys the audit trail.
- How do I test whether an ERP can really handle freight job costing?
- Take one genuinely messy past shipment: multiple currencies, a cost that arrived six weeks late, a charge you disputed and partly recovered. Ask the vendor to enter it live in a demo and then show the actual margin, with quoted versus actual on every charge head, without leaving the system. Most demos will not survive this.
- Do I need a freight-specific ERP or a custom build?
- Either can work, and the choice matters less than the test. A purpose-built freight product may already model jobs, charge heads and lifecycle correctly. A custom build gets there by design. What does not work is a general-purpose ERP with a checklist tick against job costing, because that tick tells you nothing about whether the underlying data model can represent a shipment.