Defending an OTM Audit: What Oracle Examines in Your Transaction Logs

Oracle does not audit OTM by counting rows in a table; it reconstructs Freight Under Management from the transportation value of tendered orders in your logs. This page shows exactly where Oracle looks, how the count gets inflated, and how to reconcile measured volume against your contracted tier before a claim hardens.

Why an OTM audit is different from a processor audit

Most buyers who have been through an Oracle database or Java review expect the same drill: run a script, count a metric, compare to entitlement. An OTM audit does not work that way, and the difference is where your leverage sits. OTM's primary contract metric is volume-based, and in nearly every current Ordering Document that volume resolves to FUM (Freight Under Management). Oracle's Fusion Cloud Service Global Price List (July 16, 2026) defines one $M in FUM as one million U.S. dollars of the total transportation value of tendered orders for all shipments in a given calendar year. Read that carefully: the metric is a dollar value of tendered orders, not a raw count of shipment records.

That single distinction is the crux of every OTM defense. Oracle's Global License Advisory Services team (GLAS, formerly LMS, per SoftwareOne, May 10, 2023) cannot simply select from a shipment table and hand you a number. They have to reconstruct FUM from transportation values inside your transaction logs, and reconstruction always involves assumptions. Every assumption Oracle makes is a place you can push back. Before you engage on any number, read our breakdown of how Oracle counts OTM transactions so you can distinguish a shipment count from a FUM dollar figure in the same conversation.

FUM is a dollar value of tendered orders, not a row count of shipments. Every conversion from one to the other is an assumption you can challenge.

The log data Oracle actually reaches for

OTM carries a native audit trail that Oracle can activate to reconstruct object-level history. Per Oracle's OTM documentation (26B, March 5, 2026), auditing is enabled per business object through a contact assigned the Audit (AUD) communication method, and Business Process Automation gives a global audit spanning orders, rates, shipments, invoices, and bills from a single page. In an audit, Oracle wants access to those object types because tendered-order value has to be assembled from order and shipment records together.

The detail available depends on a configuration property. The glog.audit.beforeafter property (documented in the OTM SIG community) controls whether the Data Changes section of an Audit Trail Entry is populated. If it is OFF, you do not get change detail; if it is ON, you do. This matters because Oracle's reconstruction quality depends on what your environment was set to capture during the audit period, not on what Oracle wishes it had. You are not obligated to retroactively enable richer logging to make Oracle's job easier.

Beyond the audit trail, OTM's Transaction Logs dashboard records inbound and outbound shipment exchanges, including success or failure status, and each transaction carries an External Transaction ID and a Type (Inbound or Outbound) (Oracle IoT Fleet Monitoring docs). OTM also exposes major objects (order base, order release, item, location, shipment, tracking event, trade transaction) through REST (OTM 21A What's New), and it maintains built-in metric persistence that stores current-hour average, maximum, and count statistics (OTM 22A What's New). Oracle knows these surfaces exist and will ask for exports from them. The exports are not the metric; they are raw material Oracle converts into a FUM estimate.

How the count gets inflated, and where it breaks

In our practice we see the same over-count patterns in OTM audits repeatedly. The recurring theme is Oracle treating every logged shipment event as a countable, value-bearing tendered order. That is where the number breaks.

• Failed and cancelled transactions counted. The Transaction Logs dashboard flags success or failure. A shipment that failed to tender, or was cancelled and re-created, can appear as multiple log rows for a single economic event. Oracle's raw pull will not strip these unless you make it.
• Duplicate inbound and outbound pairs. A single shipment often generates both an inbound and an outbound transaction (External Transaction ID with Type Inbound and Type Outbound). Counting both double-counts the shipment.
• Internal or test transactions. Non-production domains, test tenders, and template records inflate counts if the audit period export is not filtered to production, revenue-bearing traffic.
• Transportation value assigned where none exists. FUM is value of tendered orders. Zero-value moves, no-charge legs, and internal transfers carry no transportation value but generate log rows. Counting rows instead of summing value overstates FUM.
• Indirect and integration traffic double-booked. Users accessing OTM through third-party ERP integrations are licensable (Reveal Compliance, Nov 24, 2024), but integration-generated transaction rows are not automatically new tendered orders. Oracle sometimes treats integration chatter as incremental volume.

The financial stakes are real because OTM subscriptions are not small. Independent pricing observations put annual fees from tens of thousands for small implementations to hundreds of thousands for large enterprises (SelectHub, 2026), with an illustrative range of roughly $50,000 for a basic small-business deployment up to $500,000 or more for a complex global operation. Gartner Peer Insights (May 20, 2026) confirms shipment volume as a core cost driver. Note that Oracle does not publish per-$M FUM unit rates; those come only from your own Ordering Document, so any tier-cost math must start from your quote, not a list assumption.

In our experience the initial OTM claim is dominated by counted rows Oracle never reconciled to actual transportation value. That gap is your settlement.

Reconcile measured volume against your contracted tier

Your defense is a controlled reconciliation, not a data dump. The goal is to move Oracle off a raw event count and onto the contractual definition of FUM. Build your own number first, from the same logs Oracle will request, and be ready to show the deductions.

• Anchor to the contract definition. Pull the exact FUM wording from your Ordering Document or Oracle Master Agreement. Definitions on the price list are revised periodically, so verify against your signed document, not the current published list. If your metric is Named User Plus rather than FUM, compliance is measured at peak Hosted Named Users per calendar month, a completely different exercise.
• Rebuild FUM from value, not rows. Sum the transportation value of successfully tendered orders per calendar year. Exclude failures, cancellations, duplicates, test domains, and zero-value moves. Document each exclusion with the log field that supports it.
• Isolate inbound/outbound double counts. Map External Transaction IDs so a single shipment resolves to one economic event, not two.
• Segregate indirect access. Separate ERP-integration traffic from human user activity so Oracle cannot conflate the two metrics. Our note on counting carriers and fleet users in an OTM deployment covers how external and machine access should and should not be counted.
• Check the bundled stack. Restricted-use licenses for Fusion Middleware, Analytics Publisher, and Oracle Database are limited to supporting OTM functionality (Reveal Compliance, Nov 24, 2024). Confirm nothing in your stack has drifted into full-use territory. See the database and integration licensing hiding under your OTM stack for the exposure map.

Once you have your reconciled FUM against your contracted tier, you know whether you are actually over, and by how much. In our engagements the reconciled figure is routinely a fraction of Oracle's opening position. Atonement Licensing (Dec 9, 2025) reports an average initial Oracle claim of 4.2 times the eventual settlement, a 76% reduction from opening claim to final number. OTM audits fit that pattern precisely because the opening claim rests on unreconciled counts.

Your rights during the audit, and the methodology lever

The single most valuable point in OTM defense is that the agreement grants Oracle an audit right but rarely mandates Oracle's specific tools, scripts, or data collection methodology (Oracle Licensing Experts Audit Guide, March 25, 2026). You have the right to propose an equivalent methodology that satisfies Oracle's information needs. Use it. Propose that Oracle assess FUM from a value-based reconciliation you produce, rather than from a raw event export Oracle interprets. This is where the row-count-versus-value distinction becomes an actual negotiating position.

You also hold standard audit rights: to have legal counsel or independent advisors present at all audit meetings; to redact commercially sensitive data not directly relevant to license compliance; to challenge audit scope; and to dispute findings and present counter-evidence before any claim is finalized (Oracle Licensing Experts Audit Guide, March 25, 2026). Notice periods run 30 to 45 days across agreements (Redress Compliance, April 1, 2026), and the process typically runs three to nine months from notice to findings. The moment a letter lands, follow our first 30 days response for an Oracle audit letter and set scope before you hand over a single export.

The contract gives Oracle the right to audit. It does not give Oracle the right to dictate how FUM is measured. That is your methodology lever.

Timing: why the audit landed when it did

OTM audits are rarely random. The most reliable trigger is an approaching agreement, ULA, or support renewal, with GLAS engaged 6 to 18 months before a major renewal to build compliance leverage (Oracle Licensing Experts, March 25, 2026). Published frequency for a major Oracle account is roughly one formal audit every three to four years (Oracle Negotiations, Dec 28, 2025). M&A is a separate trigger: acquisitions where Oracle products sit in both entities can force license reconciliation and volume re-counting under change-of-control terms (Oracle Licensing Experts, March 25, 2026).

If your audit is renewal-timed, treat the audit and the renewal as one negotiation, not two. A reconciled FUM number is also your right-sizing baseline for the next term. Read negotiating an OTM cloud renewal and capping uplift alongside this page, and if you are weighing deployment models, OTM on-premise versus cloud at freight scale shows where the metric behaves differently. For the full metric picture across the suite, the OTM and GTM licensing guide is the anchor, and GTM-specific exposure sits in Oracle Global Trade Management licensing.

What to do now

• Extract your FUM definition from the signed Ordering Document, not the current price list, and confirm whether your metric is FUM or Named User Plus.
• Build your own value-based FUM reconciliation from the audit trail and transaction logs before Oracle proposes a methodology.
• Insist on your right to propose an equivalent methodology and to reconcile value rather than accept a raw event count.
• Strip failures, duplicates, inbound/outbound pairs, test domains, and zero-value moves, and document each exclusion.
• Verify restricted-use bundled components (Middleware, Analytics Publisher, Database) have not drifted to full use.
• If the audit is renewal or M&A timed, run it as a single negotiation and use your reconciled number as the right-sizing baseline.

Related advisory: the full topic guide.

Frequently asked questions

Does Oracle count OTM shipments or dollar value in an audit?

Neither directly. The contractual metric in most Ordering Documents is FUM (Freight Under Management), defined per Oracle's Global Price List as one million dollars of total transportation value of tendered orders for all shipments in a calendar year. Oracle reconstructs that dollar value from your transaction logs. A raw shipment row count is not the metric, which is why every conversion from rows to FUM is a point you can challenge.

Which OTM logs does Oracle request in an audit?

Typically the Audit Trail Management output across orders, shipments, invoices, and bills, the Transaction Logs dashboard for inbound and outbound events, and REST object exports for order release, shipment, and tracking data. Whether change detail is present depends on your glog.audit.beforeafter setting during the period. These exports are raw material, not the FUM figure, and you are not required to retroactively enable richer logging.

How much can the initial OTM audit claim be inflated?

Across Oracle audits generally, the average initial claim runs about 4.2 times the eventual settlement, a 76% reduction, per Atonement Licensing (Dec 9, 2025). OTM claims fit this pattern because opening numbers usually rest on unreconciled event counts that include failures, duplicates, inbound/outbound pairs, test data, and zero-value moves. Reconciling to actual transportation value routinely collapses the number.

Can we control how Oracle measures FUM?

To a significant degree, yes. The audit clause grants a right to audit but rarely mandates Oracle's specific tools or data collection methodology. You have the right to propose an equivalent methodology that meets Oracle's information needs, which means you can insist on a value-based reconciliation you produce rather than a raw log export Oracle interprets.

What triggers an OTM audit?

The most reliable trigger is an approaching subscription, ULA, or support renewal, with Oracle's GLAS team engaged 6 to 18 months ahead to build leverage. M&A activity is a separate trigger where change-of-control terms can force volume and entity re-counting. Major accounts see a formal audit roughly every three to four years.

Does third-party ERP integration create OTM license exposure?

Indirect access through third-party ERP integrations is licensable, so integration-connected users can require licensing. However, integration-generated transaction rows are not automatically new tendered orders. Segregate machine and integration traffic from human user activity and from FUM value so Oracle cannot conflate the metrics.