Ocean Freight Rate Management Software: Which Rate Is Actually Valid Today

Why the rate is never one number

A pricing analyst gets a request at 9:15am: 40 foot high cube, Ningbo to Rotterdam, ready in nine days, general cargo. She opens the shared drive. There are four carrier spreadsheets for that trade, one from March, two from April, and an amendment that arrived as a PDF from an account manager last Thursday. The March file has the lowest ocean freight. She does not know whether that rate is still valid, whether its destination terminal handling charge was superseded, or whether the amendment applies to this equipment type. She quotes anyway, because the customer wants an answer within the hour and will take it elsewhere if she is slow.

That quote is either wrong or lucky. When it is wrong, nobody finds out at quote time. They find out at invoice time, six weeks later, when the carrier bills a surcharge that was never in the sell price, on a shipment that has already moved, for a customer who agreed a rate in writing. The loss is small per container and it repeats across every shipment that used that stale sheet, which is how a trade lane quietly goes negative while the volume report looks excellent.

The structural reason this is hard is that an ocean price is a stack, not a number. Ocean freight per equipment type, terminal handling at both ends, bunker adjustment, low sulphur, security, documentation, congestion and peak season where they apply, and local charges that differ by port and sometimes by terminal within a port. Each component has its own validity window, its own basis of calculation, and its own habit of changing on a schedule nobody publishes to you usably.

Problem 1: the contracts arrive in a hundred shapes and none of them are data

Carriers send rates as spreadsheets with layouts that differ by carrier, by trade and sometimes by the individual who produced them. Amendments arrive as emails, as PDFs, as a revised tab in a workbook with no changelog. Freight forwarders receive the same from their own carrier partners and pass on something different again to their agents. Somewhere in that flow the meaning is clear to a human reading it and completely opaque to any system.

WiseTech CargoSphere and Catapult International are real rate management platforms built precisely for this and they are worth evaluating seriously. They store, distribute and expose rates and they do it far better than a shared drive. Their practical limit for a mid to large operator is the boundary: the rates land in their environment, and your quoting screen, your booking flow, your accrual and your invoicing live in yours. So somebody exports, somebody keys, or somebody builds an integration anyway, and the moment the rate leaves the tool it stops being validated. Xeneta answers a different and useful question, which is what the market is paying, but it is benchmarking rather than the store of what your specific contracts entitle you to. Freightos WebCargo is a marketplace with its own carrier scope, which is excellent for coverage and is not a home for your negotiated agreements.

What a custom build does: normalise into one internal model with a mandatory shape, then make ingestion the interesting part. This is one of two places where document extraction earns its cost: carrier rate sheets and amendment PDFs are read into proposed rate lines with lane, equipment, commodity scope, charge components and validity, and a pricing analyst approves or corrects them. Nobody keys a whole workbook. Corrections train the mapping for that carrier's format, and after a few cycles most sheets land with light review. The system remembers that this carrier calls it OTHC and that one calls it THC-O, which is a small thing that costs pricing desks hours every week.

Problem 2: validity is the question and nobody stores the answer

Which rate applies is a function of the date of the request, the date of sailing, the equipment, the commodity, the shipper, sometimes the named account, and whether an amendment superseded a line or only added to it. A shared drive answers none of that. A rate lookup that returns three candidate rates and expects a human to choose is only marginally better, because the human will choose the cheapest and hope.

What a custom build does: make validity a first class property with explicit supersession, so a lookup returns one answer with a reason and a reference to the contract line and amendment it came from. Where genuine ambiguity exists, it returns the ambiguity as an exception for pricing to resolve once, permanently, rather than silently every time. That reference matters far beyond quoting: when the carrier invoice arrives with a different number, you have the exact clause you relied on, which turns a negotiation into a correction.

Problem 3: surcharges are where the margin actually leaks

Ocean freight is the number everyone negotiates and watches. The stack around it is where quotes go wrong, because surcharges change on their own cycles, apply per container or per bill of lading or per weight depending on the charge, and vary by port pair in ways that are easy to generalise incorrectly. A destination charge modelled once for Rotterdam and applied to all north European ports will be wrong somewhere, every month.

What a custom build does: model each charge component with its own basis, currency, validity and applicability rules rather than flattening the stack into an all in figure. Currency deserves specific attention: charges are quoted in several currencies and converted at a rate whose timing you must define and defend, and inconsistent conversion timing between quote and invoice is a quiet and permanent margin leak that almost nobody measures. The build should hold both the sell stack and the expected cost stack for every quote, so margin is known at quote time rather than discovered in a monthly report.

Problem 4: the quote and the booking are strangers

A quote goes out as a PDF or an email. It is accepted verbally or by return email. A booking is then created in a different system by a different person, who re-enters what they believe was agreed. Any drift between the two is a dispute in waiting, and it always favours whoever kept better records, which is usually the carrier.

What a custom build does: make the booking a state change on the quote rather than a new record. The agreed rate stack is carried forward and locked, and the accrual posts from the same object. When the carrier invoice lands, the three way reconciliation of quote, booking and invoice is automatic and only exceptions reach a human. Forwarders who do this typically get their first real measurement of per shipment margin, and typically find a small number of accounts and lanes are far worse than the average everyone was managing to.

Problem 5: allocations and commitments are managed on faith

Contracts carry commitments in both directions: minimum quantity you promised, allocation the carrier promised, sometimes tied to rate levels or rebates. Tracking against those commitments is normally a quarterly panic assembled from shipment reports, at which point it is too late to steer volume.

What a custom build does: track commitment progress continuously against actual bookings, and put it in front of pricing where decisions are made. When you are behind on a commitment with two months left, that changes which carrier you quote today. When a carrier is not honouring allocation, you have a dated record instead of a feeling, which is worth real money at the next negotiation.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A focused first release, meaning a normalised rate model with component level surcharges, validity and supersession, assisted ingestion of carrier sheets, and a lookup surfaced to your pricing and sales teams, runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding automated amendment ingestion at scale, quote to booking continuity, allocation and commitment tracking, margin reconciliation against carrier invoices, and a customer or agent facing quoting portal runs $200,000 to $450,000 phased over 7 to 12 months.

What pushes the number up in this domain: the number of carriers and trades, since each carrier's format and each trade's charge conventions are separate work. Multi currency, which sounds like a checkbox and is not once you define conversion timing. Agent networks, if overseas offices quote from the same store with their own margins. Integration into your existing forwarding and accounting platform, usually the largest single line. And publishing rates outward, since an external quoting portal is close to a second product.

What holds it down: start with your top two trades and your top four carriers. That typically covers the large majority of quoted volume and proves the model before you industrialise ingestion.

Build versus buy, plainly stated

Buy if you run a small book on a handful of lanes with two or three carriers and one person who knows every agreement. A rate distribution subscription plus a disciplined spreadsheet is cheaper and faster and will not fail you at that size. Buy also if your operations platform already includes a rate module you have never properly configured, since configuring what you own beats building what you do not.

Build when two or more of these are true. You quote more than roughly 400 shipments a month and quoting speed is costing you business. You cannot answer which rate is valid for a given lane today without a person checking a folder. Your invoices routinely contain surcharges that were never in the sell price. You have more than one office quoting from different copies of the same rates. Or you cannot state per shipment margin without a monthly exercise, which means you are managing a spread you cannot see.

Our position: rate management sold as a standalone product solves storage and distribution, which is genuinely half the problem. The other half is that the rate has to arrive intact inside your quote, your booking, your accrual and your invoice check. That half is integration with your specific systems, it is the half where the money leaks, and no vendor will ever own it because it is not their software on either end.

How to choose a developer for rate management work

Ask them to model a surcharge before they model a rate. If they treat the stack as an all in number with a breakdown for display, they have built a price list and not a rate system, and every invoice reconciliation you attempt afterwards will fail.

Ask how supersession works. An amendment that replaces two lines and leaves eleven intact is the normal case, not the edge case, and a system that overwrites a whole contract on upload will lose history you need when a shipment from last quarter is queried.

Ask about currency conversion timing explicitly. The right answer names when the rate is struck for quoting, for accrual and for settlement, and acknowledges they may differ. A developer who has not thought about it will introduce a leak you will not notice for a year.

Ask what they have integrated. Your forwarding operations platform, your accounting system, carrier booking channels and any agent network are separate problems. Make them name specific systems and interfaces rather than describing integration as a capability.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. Your negotiated rate data is commercially sensitive as well, so be equally explicit about where it is stored and who can access it.