Most comparisons of transportation software argue about features. For mid-market buyers the decisive difference is usually the meter, and Oracle publishes theirs in plain language. Oracle Transportation Management Cloud is licensed on Freight Under Management — a metric defined on the transportation value of tendered orders rather than on users, vehicles or transactions. That shape rewards some operations and penalises others, and which one you are has remarkably little to do with how complex your logistics actually is or how much of the software you use. If a large share of your movement happens on your own trucks, it is worth settling the metering question before an RFP goes out rather than during negotiation. Price it against your own freight mix.
The Meter Decides the Bill, and It Is Not Measuring Your Software Usage
What Freight Under Management is in Oracle's own words, what counts toward it, which operating profiles it suits, and the six questions to put to any vendor about how they meter — before the pricing conversation starts.
Freight Under Management, Defined
This is Oracle's own wording from their published Fusion Cloud Service Descriptions, and it rewards close reading.
"Hosted $M in Freight Under Management (FUM) is defined as one million U.S. dollars (or the equivalent amount in local currency stated in the order) of the total transportation value of tendered orders for all shipments for a given calendar year during the term of the Oracle Transportation Management Cloud Service."
— Oracle Fusion Cloud Service Descriptions
Two phrases carry the weight. Total transportation value means the meter runs on what the freight is worth to move, not on how many shipments you planned or how many people logged in. And all shipments means the base is broader than the invoices you pay, which is where mid-market profiles tend to get caught.
To be fair to the metric: value-based metering has genuine advantages. It does not punish you for adding users, sites or integrations, it is predictable to forecast from a freight budget, and for an operation whose complexity genuinely scales with freight spend it allocates cost sensibly. The problem is not that FUM is unreasonable. It is that it assumes a relationship between freight value and software value which does not hold for every operating profile.
What Counts Toward the Meter
Oracle's definition sets out what the FUM base includes, and the third and fourth items are the ones worth taking to your finance team.
The stated inclusions cover actual freight purchased by the customer, the cost of freight for shipments managed by the customer, transportation management services provided by the customer for its clients, and freight paid by third parties — with prepaid inbound shipments from suppliers given as the example. For a distributor with significant supplier-prepaid inbound, or a manufacturer hauling finished goods on its own fleet, a meaningful share of the metered base is freight for which no carrier invoice ever arrives. Confirm current terms in your own order document; service descriptions are revised.
Which Profile Are You?
The honest version of this comparison is not that one metric is better. It is that metrics have shapes, and yours either matches or it does not.
- Freight spend is large and genuinely purchased from carriers
- Planning complexity scales with that spend
- You want a metric that does not penalise adding users or sites
- Transportation is the business, not an overhead
- A large share of movement happens on your own fleet
- Significant inbound arrives prepaid by suppliers
- Goods are high value but the logistics are simple
- You are mid-market with a private fleet and modest lane complexity
The asymmetry worth naming: a value-based meter means two companies running identical software, with identical lane complexity and identical transaction volume, can pay very different amounts because one of them ships something expensive. That is defensible as a value-capture model and indefensible as a measure of what the software is doing. Both things are true at once, which is why the question is fit rather than fairness.
Work out what your metered base would actually be
Take your annual freight value, add supplier-prepaid inbound, add the notional value of what moves on your own fleet, and compare it with what you actually pay carriers. Most mid-market operations have never run that number. In thirty minutes we will run it with you — whatever you conclude about vendors afterwards.
Six Questions About Metering, for Any Vendor
These apply to us as much as to anyone else. A vendor who answers all six in writing is one you can budget against.
- What exactly is the unit, in writing?Not the price — the unit. A metric defined on value behaves completely differently from one defined on transactions, users or vehicles, and the definition is where the surprises live.
- Does the meter count things I do not pay for?Oracle's FUM definition includes freight paid by third parties and the cost of freight for shipments you manage. Whatever vendor you are evaluating, ask the equivalent question and get the answer in the contract rather than the call.
- What happens in a year when volume spikes?A value-based meter is a variable cost tied to commercial performance. A good year for the business can be an unbudgeted year for the software, and finance should know that before signing rather than at true-up.
- Which modules share the metric?Worth checking carefully. Oracle lists Transportation Management, Transportation Operational Planning, Fleet Management and Logistics Network Modeling all on the Freight Under Management metric — so the fleet module is priced off freight value too.
- What is the minimum commitment?Value-based metrics usually come with a floor. For a mid-market profile the floor often is the price, which makes the headline rate close to irrelevant.
- How does it scale downward?Easy to model growth, harder to model contraction. If you divest a division or move freight in-house, does the commitment follow you down?
The Mid-Market Fleet Profile, Specifically
There is a particular operating shape that fits value-based metering worst, and it is common enough in the mid-market to be worth describing precisely.
It looks like this: a manufacturer or distributor doing somewhere between fifty and a few hundred million in revenue, moving its own finished goods on a private fleet of perhaps twenty to a hundred and fifty vehicles, taking a significant portion of its inbound raw material on supplier-prepaid terms, and running a lane network that is stable, regional and genuinely not very complicated. Planning is a solved problem for this operation. Nobody is agonising over multi-leg optimisation.
What this operation has is high freight value and low freight spend, because it hauls its own product. Under a value-based meter it looks like a large customer. Under any measure of what the software is doing for it, it is a small one. The gap between those two readings is the commercial problem, and no amount of discount negotiation changes the shape of it — discounts move the rate, not the base.
If that description does not fit you, this page is probably not your argument. An operation purchasing most of its transportation from carriers, with real network complexity and planning value at stake, may well find the economics work — and in that case the architecture question from our OTM coexistence guide matters more than the pricing one.
The Licence Is Not the TCO
Metering decides one line. These decide the rest, and they are where most three-year models quietly understate the number. Swipe on mobile.
| Cost | What to ask about it | When it lands |
|---|---|---|
| Implementation and configuration | Usually the largest single line in year one and the hardest to compare, because scope differs by vendor. Ask for the assumed number of consulting days and what happens when that estimate is wrong. | Year one |
| Integration build and maintenance | Every interface is a thing somebody owns forever. Count the interfaces, then ask who maintains them when either system updates — this line is routinely costed once and then paid for annually. | Ongoing |
| Internal capability | A platform nobody on staff can administer is a consulting retainer wearing a software badge. Factor the cost of either hiring or retaining that capability, or accept the retainer honestly in the model. | Ongoing |
| Change management and training | Cheapest to do properly and most expensive to skip. A system people route around produces worse data than the spreadsheet it replaced, which makes the entire investment negative rather than merely disappointing. | Year one, then on turnover |
| The cost of being wrong | Rarely modelled and worth a line. If the platform does not fit, what does exiting cost — in migration, in contract term remaining, in rebuilt interfaces? A shorter commitment has real option value. | Risk-weighted |
None of this is specific to any one vendor — it applies to us as much as to Oracle, and a model that omits these lines for one supplier and includes them for another is not a comparison. The practical test: if a vendor’s business case contains only licence fees and claimed savings, ask them to add the four rows above and watch what happens to the payback period. It should still work. If it does not, better to find out now, alongside the rest of your operational record-keeping requirements.
How FleetRabbit Handles This
Four things, and the fourth is the one that keeps this an honest comparison rather than a replacement pitch.
A truck costs the same to track whether it is moving gravel or pharmaceuticals. Metering on the asset keeps the bill tied to the work the software actually does.
It is what the product is built around rather than an edge case the metric was not designed for — which matters most to exactly the mid-market profile that fits FUM worst.
Three vehicles free, then grow by vehicle. No value-based floor to clear before the software does anything useful.
If you run OTM for planning and settlement, keep it. The pricing question here is about the execution and observation layer, not about tearing out transportation management.
Questions Buyers Ask
What is Freight Under Management?
Oracle defines it as one million US dollars of the total transportation value of tendered orders for all shipments in a calendar year. The licence counts units of that value rather than users, vehicles or transactions — so the bill tracks what your freight is worth to move, not how much software you use. Confirm current wording in your own order documents. Work out your base.
Does FUM really include freight we did not pay for?
Per Oracle's published definition, the base includes freight paid by third parties, giving prepaid inbound shipments from suppliers as the example, as well as the cost of freight for shipments you manage. For a distributor with heavy supplier-prepaid inbound that is a material part of the number, and it is worth modelling before negotiation. Model it with us.
Does the fleet module use the same metric?
Oracle lists Fleet Management Cloud Service under the Hosted $M Freight Under Management metric, alongside Transportation Management, Transportation Operational Planning and Logistics Network Modeling. Worth knowing if your interest is primarily in your own vehicles rather than in purchased transportation. Compare against per-vehicle.
Is Oracle OTM a bad product?
No, and we would not make that argument. It is a mature, broad transportation planning and settlement platform and it is a reasonable choice for operations whose problem is transportation planning. This page is about whether the metering shape matches a particular mid-market profile, which is a different question from product quality entirely. Talk through the fit.
Can we negotiate the metric itself?
Rates are usually negotiable; metrics much less so, because they are defined in standard service descriptions rather than in your order. That is precisely why the metric matters more than the rate — a discount changes what you pay per unit, not how many units you are deemed to have. See a per-vehicle model.
What should we actually compare?
Build the comparison on your own three-year freight value projection, not on list prices. Include supplier-prepaid inbound, include own-fleet movement, and run a growth case and a contraction case. Most pricing surprises come from the base moving rather than from the rate. Build it with us.
Do we have to choose one or the other?
Usually not, and that is worth saying plainly. Plenty of operations keep OTM for planning and settlement and add an execution layer underneath it for what happens physically at the gate, the yard and the dock. That is a coexistence decision rather than a replacement one, and it is the cheaper project. Compare on one lane.
Settle the Metric Before You Argue About the Rate
FleetRabbit meters on vehicles rather than on the value of what they carry, treats own-fleet movement as the normal case rather than an exception, and does not require you to replace a transportation planner you are happy with.
Free for 3 vehicles · no value-based floor to clear