Oracle meters Transportation Management primarily on Freight Under Management, not headcount, which means your carrier portal, 3PL client book, and inbound prepaid freight can inflate the bill without a single new login. This page shows exactly where external users and EDI integrations create licensable exposure, and the contract language that caps it.
Oracle meters Transportation Management primarily on Freight Under Management, not headcount, which means your carrier portal, 3PL client book, and inbound prepaid freight can inflate the bill without a single new login. This page shows exactly where external users and EDI integrations create licensable exposure, and the contract language that caps it.
Most OTM buyers walk into renewal with a spreadsheet of logins. That spreadsheet is close to worthless, because Oracle does not primarily meter Transportation Management on people. The Oracle Fusion Cloud Service Global Price List (July 16, 2026) defines a Hosted $M in Freight Under Management unit as one million U.S. dollars (or local currency equivalent) of the total transportation value of tendered orders for all shipments for a given calendar year during the term of the service. That is a value metric, not a seat metric, and it is indifferent to whether the tender came from a planner in your office, a carrier accepting through the portal, or an EDI 204 arriving at 2 a.m. Staying on-premise does not get you out of it either: the Oracle Technology Global Price List (August 3, 2026) restates the same $M FUM definition, including freight for shipments managed by you where you are not purchasing transportation on clients' behalf. The structural risk is that FUM is not one line item. Transportation Sourcing, Transportation Operational Planning, Logistics, Transportation Cooperative Routing, Logistics Inventory Visibility, and the GTM options are all metered on $M in Freight Under Management, so a single restatement of your FUM base re-prices the entire stack simultaneously, not one module. Test environments and additional storage sit on separate "Each" and "Hosted Month" metrics and behave differently. Then there is the term asymmetry: the standard Oracle Cloud subscription term is three years, so your FUM baseline is frozen at signature while your carrier network, 3PL client book, and acquisition pipeline keep moving. Read our Oracle transportation and logistics cloud licensing guide for how the metrics interact across the suite. The action is simple: before you count a single user, build a defensible FUM model and get the counting rule written into the ordering document.
One FUM restatement does not re-price one module, it re-prices every metered line in the OTM stack at once.
The expansion happens in one sentence of the price list, and it contains three separate additive clauses. FUM includes the combined total of (1) actual freight purchased by you, plus (2) the cost of freight for shipments managed by you, plus (3) any transportation management services provided by you for your clients. Clause two catches managed freight where you never touch the invoice. Clause three is the one that converts a 3PL or an internal shared-services logistics organization into a much larger licensee, because every client shipment you plan, tender, or track lands in your base even though the client is paying the carrier. But the highest-value trap is the follow-on rule: freight paid by a third party is also included, and Oracle's own worked example is inbound shipments from suppliers to you on prepaid freight terms. That is the clause that breaks the standard scoping method. Buyers almost always size FUM off a single freight-spend GL account, because that is the number finance can produce in an afternoon. Prepaid inbound never appears in that account. It sits inside landed cost of goods, buried in supplier invoices, invisible to the transportation P&L, and entirely licensable. Take a shipper with 400M in outbound freight spend and 120M in inbound prepaid arriving on supplier terms. The correct base is 520 FUM units, not 400, a 30 percent understatement that compounds across every FUM-metered module in the order. The same arithmetic applies if you also plan 80M of client freight as a 4PL. Our breakdown of how Oracle counts OTM volume covers the adjacent overage mechanics.
| FUM component | Typical source | Included per price list |
|---|---|---|
| Outbound purchased freight | Transportation GL account | Yes, clause 1 |
| Inbound prepaid supplier freight | Landed cost inside COGS | Yes, third-party paid example |
| Managed freight, not purchased by you | Shipment records only | Yes, clause 2 |
| Client freight planned as 3PL or 4PL | Client contracts, not your AP | Yes, clause 3 |
| Illustrative total: 400M + 120M | 400 FUM assumed | 520 FUM licensable |
Two counting decisions matter more than the rate. First, define whether FUM is measured on tendered order value or paid freight cost, and get that word choice fixed in the ordering document, because tendered value on cancelled or re-tendered loads can double-count. Second, cap the treatment of third-party paid freight, either by excluding prepaid inbound below a stated threshold or by agreeing an annual true-up with a banded ceiling rather than open-ended restatement. Model your own inbound prepaid book now, in dollars, before Oracle models it for you at renewal.
User counting has not gone away in Oracle Transportation Management. It has migrated to the estate most buyers stopped watching: the on-premise and legacy OTM installations, the embedded database underneath them, and the integration layer bolted onto both. Oracle's Named User Plus definition is authorization-based, not usage-based. A license is required for each individual authorized to use the programs, and the metric does not measure actual usage, concurrent sessions, or frequency. If a person has the right to access, they need a NUP whether they log in daily, monthly, or once a year. Read that against a typical carrier portal user table, where accounts accumulated over a decade of onboarding are almost never disabled after a carrier is deselected or acquired, and the arithmetic gets ugly fast. In audits I have worked, dormant-to-active ratios of three or four to one in the SERVPROV domain are unremarkable, and every one of those enabled records is a defensible NUP claim for Oracle.
The second bite is non-human. Oracle counts server-to-server integrations, middleware batch processes, monitoring agents, ETL tools, and application integration layers as requiring separate NUP licenses unless they are operated directly by a licensed named user. In an OTM estate that means EDI VAN connectors, carrier API gateways, visibility-provider pollers, rate-engine callouts, and whatever your data team pointed at the OTM schema for reporting. Do not assume the public price list governs your position. Advisory sources describe OTM as historically offered under both user-based and transaction-based models, and the current price lists point to Freight Under Management, but your entitlement is whatever your ordering document says, not whatever Oracle publishes this quarter. Pull the original ordering document and any amendments, confirm the metric in writing, and if you hold a mixed estate, map which environments sit on which metric before you touch the migration question covered in our comparison of [OTM on-premise versus cloud licensing at freight scale](oracle-otm-on-premise-vs-cloud-licensing-cost).
This is the contested ground, and it turns on a single paragraph of Oracle contract text. The canonical language, visible in an Oracle USA software license agreement filed with the SEC and substantially unchanged in current definitions, says three things in sequence: a Named User Plus is an individual authorized to use the programs regardless of active use; a non-human operated device is counted as a NUP in addition to all authorized individuals if that device can access the programs; and if multiplexing hardware or software is used, the number of users must be measured at the multiplexing front end. Applied literally to a shipper running OTM behind a carrier portal, that reads as an instruction to count every carrier dispatcher who touches the front end, not the portal service account. Then, in the same paragraph, comes the sentence every buyer should have laminated: automated batching of data from computer to computer is permitted. That sentence is the whole defense.
Automated batching of data from computer to computer is permitted, and that single sentence is what separates a nightly EDI feed from a multiplexed user population.
The distinction I argue in audit rooms is between a data exchange and a user population. A nightly EDI 204 tender, a 214 status feed, and a 210 invoice batch moving between your OTM instance and a carrier's TMS over a VAN or AS2 connection is computer-to-computer batching. No human at the carrier is authorized to use OTM, no human sees an OTM screen, and no OTM session is created per carrier employee. That is a factual position, and it is defensible if your architecture actually matches it. Where it collapses is when the same carrier also has portal credentials, or when the integration is synchronous and human-triggered rather than batched.
Oracle's audit position runs the other way. LMS treats NUP as extending through intermediary applications, arguing each end user still requires a license absent a separate arrangement, and indirect access is one of the most misunderstood and materially expensive areas of Oracle audit exposure. Auditors will chase the daisy chain: a carrier dispatcher hits their own TMS, which calls Oracle Integration Cloud, which calls the carrier portal, which reaches OTM. Under the daisy-chain pitfall doctrine, those indirect users are frequently unlicensed and Oracle will say so. The analogy they reach for is e-commerce: a website with a single application login and thousands of users behind it means all those users require licensing, which is precisely why processor licensing exists as the alternative. An 800-carrier portal is structurally identical to that fact pattern, and pretending otherwise in a defense meeting wastes your credibility.
OTM does not blend external parties into your operational user pool. It segregates them architecturally: service providers live in the SERVPROV domain, and each carrier, broker, or drayage provider you set up in the operational domain gets a corresponding user ID in that domain so it can log in, accept tenders, and post status events. That table is the de facto audit artifact. In twenty five years of Oracle engagements, the first extract an LMS or GLAS reviewer asks for on a user-metered OTM estate is not an HR headcount, it is the SERVPROV user list with creation and last-login timestamps, because it is authoritative, exportable in minutes, and it is your own data. The design assumption baked into OTM is a single carrier contact per service provider, which compresses the count neatly: 800 carriers, 800 IDs. The pattern most practitioners actually deploy does the opposite. Provisioning CARRIER1-USER1, CARRIER1-USER2, CARRIER1-USER3 and then letting the carrier self-assign additional IDs to dispatchers turns 800 service providers into 3,000 authorized individuals, every one of them licensable under Oracle's authorization-based Named User Plus rule regardless of whether they logged in once last fiscal year. Dormant does not mean free. On the device question, Oracle's contract language counts a non-human operated device as a NUP in addition to authorized individuals, but a human operating a device is one human user, not a device plus a user. A driver scanning a barcode at delivery is one user. A telematics unit posting GPS pings with no human at the keyboard is a device, and it is countable. See our Oracle transportation and logistics cloud licensing guide for how these definitions interact with the FUM stack.
| Portal object | Typical count at 800 carriers | Counting treatment |
|---|---|---|
| SERVPROV records in operational domain | 800 | Not a user by itself |
| Single-contact SERVPROV user IDs (Oracle design assumption) | 800 | 800 NUP if user-metered |
| Self-assigned dispatcher IDs (common practice) | 2,400 to 3,200 | Each is an authorized individual |
| Driver mobile app / barcode scanner sessions | 1 per driver | One human user, not device plus user |
| Unattended telematics or ELD feed | 1 per unit | Non-human device, separately countable |
| EDI VAN or API gateway service account | 3 to 8 | Contest as automated batching, not multiplexing |
Run the self-assessment yourself, before Oracle scopes it, because the arithmetic only moves in one direction once an auditor owns the model. Three workstreams, roughly two weeks of effort on a mid-size estate. First, rebuild FUM from tendered order value rather than the freight GL account. Your GL captures freight you paid. Oracle's definition captures the total transportation value of tendered orders including inbound supplier shipments on prepaid terms and any freight you manage for clients, which means a shipper with a heavy inbound prepaid book routinely understates by 15 to 25 percent without a single fraudulent entry. Pull it from OTM shipment records, not accounts payable. Second, extract the SERVPROV user table with last-login dates and classify: active, dormant, duplicate, terminated. Third, inventory every non-human connector that touches OTM: EDI VAN endpoints, carrier API gateways, visibility pollers from your real-time tracking provider, and TMS-to-ERP middleware. Name each one, name its owner, and record whether it moves data in scheduled batches or synthesizes an interactive session for a downstream human. That distinction is the whole indirect-access argument, and it is easier to make with an inventory than with a memory. Where a peak Hosted Named User metric applies, remember that compliance is measured on the peak number at any point in each calendar month, so peak-season carrier onboarding in October is measured at its October peak and never amortized across the quiet spring.
Size the money before you decide how hard to fight. Take a 40,000 FUM baseline. A 20 percent understatement is 8,000 FUM. Because Sourcing, Operational Planning, Logistics, Cooperative Routing, and any GTM options are all metered on the same $M FUM unit, one restatement reprices every module line simultaneously, then multiplies across a standard three-year term. Model it as unit price times 8,000 times the number of FUM-metered lines times three, and add Oracle's backdated-usage claim if the restatement lands mid-audit rather than mid-negotiation. Our breakdown of how Oracle counts OTM transactions shows where the overage clauses compound. Do this quietly, in a privileged workstream, and bring the number to the table as your position rather than discovering it in Oracle's spreadsheet.
Sequence this work so the cheap, high-yield items land before Oracle asks a single question. First, pull the SERVPROV domain user table this quarter and disable every carrier ID with no login in the trailing twelve months. Under Oracle's authorization-based Named User Plus definition, a dormant account with access rights is still licensable, so deactivation is the only defense that survives a scripted extract. Second, rebuild your Freight Under Management figure from tendered order value rather than the freight-spend GL account, and show inbound prepaid supplier freight and 3PL client-managed volume as separate, labeled lines. Oracle's price list explicitly includes both, and in our negotiation experience the GL-based method is the single most common source of a mid-term restatement demand. Third, get two clauses into the ordering document itself, not the SOW: an explicit permission for automated batching of data from computer to computer covering EDI 204, 214 and 210 flows plus API integrations, and a written FUM inclusion and exclusion schedule naming which freight categories count. Without the schedule, every module metered on FUM (Sourcing, Operational Planning, Logistics, Cooperative Routing, GTM options) re-prices simultaneously off one disputed number.
Under the Cloud FUM metric, carrier portal access is not separately licensed because the meter is freight value, not headcount. Under on-premise or legacy user-based terms, Oracle's Named User Plus definition is authorization-based, so every enabled carrier ID in the SERVPROV domain is arguably licensable regardless of how rarely it is used. The practical defense is to negotiate explicit language treating the carrier portal as an interface rather than a user population, and to disable dormant carrier accounts before an audit.
Yes. Oracle's FUM definition explicitly includes the combined total of actual freight purchased by you, the cost of freight for shipments managed by you, and any transportation management services you provide for your clients. A 4PL or a shipper running managed transportation for affiliates is buying FUM units on volume it never pays a carrier for directly. Model client volume separately at contract signature so you can argue for a distinct tier or a cap.
Yes, and it is the most commonly missed component. Oracle's price list states that freight paid by a third party is included in the FUM total and gives inbound shipments from suppliers on prepaid terms as the example. Buyers who scope FUM from their own freight-spend GL account routinely understate the base by the entire inbound prepaid book, which surfaces as a restatement at renewal or audit.
They can, but the contract gives you a defense. Oracle's standard license text counts non-human operated devices as Named Users and requires counting at the multiplexing front end, yet the same paragraph states that automated batching of data from computer to computer is permitted. A nightly EDI 204, 214, or 210 batch feed fits the batching language; a real-time API gateway fronting hundreds of carrier sessions is closer to multiplexing. Get the batching permission restated in your OTM ordering document rather than relying on a 2007 template.
Compliance is determined by the peak number of Hosted Named Users at any given time during each calendar month of the services period. Averaging across the year is not permitted, so a Q4 peak-season onboarding of temporary carrier or fleet users sets your compliance level for that month. Plan seasonal provisioning against the peak rule, or negotiate a stated seasonal allowance.
No. The Oracle Technology Global Price List carries substantially identical FUM language, defining one million USD of total transportation value of tendered orders for all shipments during the license term, including freight for shipments you manage without purchasing transportation on clients' behalf. The deployment choice changes the cost curve and the support mechanics, not the definition of what gets counted.
Oracle licenses cores times a core factor, not raw cores. The 0.5 x86 factor, the worked counting, the virtualization trap, and where the factor does not apply.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
