Oracle JD Edwards Prerequisite Products and Licensing: The Hidden Compliance Gap

What Are JD Edwards Prerequisite Products?

In Oracle's JD Edwards licensing framework, a prerequisite product is a software component that must be licensed before you are entitled to use the module that depends on it. Prerequisites are not the same as the functional modules themselves — they are infrastructure or foundation-level components that provide the underlying capabilities those modules draw upon.

The concept is documented in Oracle's JD Edwards EnterpriseOne Licensing Information User Manual, which specifies prerequisite relationships for every module in the product suite. The manual is comprehensive but dense, and organisations that rely solely on their sales team or Oracle account manager to define their licence obligations will frequently not be made aware of these requirements until an audit surfaces them.

The fundamental compliance rule is straightforward: if you are licensed to use Module A, and Module A requires Prerequisite B, then you must hold licences for Prerequisite B at the same user count as Module A. Holding fewer prerequisite licences than module licences, or holding module licences without prerequisite licences at all, creates a compliance gap that Oracle will measure and claim against.

The Core Prerequisites: What Every JDE Customer Must Know

The prerequisites that apply most broadly across JDE deployments — and therefore generate the most common compliance gaps — are the following.

System Foundation

System Foundation is the most universal prerequisite in the JDE licence structure. It is a prerequisite for all JD Edwards EnterpriseOne modules. Every organisation deploying JDE must hold System Foundation licences for every authorised user in their estate, regardless of which functional modules those users access.

This creates an immediate compliance risk for organisations that have expanded their JDE module set over time without ensuring that the System Foundation user count kept pace. If you originally licensed JDE for 100 users with the appropriate System Foundation coverage, and subsequently added 50 more named users through a supplemental order that focused only on the new module licences, you may have 50 users accessing JDE without the required System Foundation backing.

The remediation appears simple — purchase additional System Foundation licences — but the cost can be material if the gap has accumulated over several years, because Oracle will typically seek to recover the support fees on those missing licences retrospectively as part of an audit settlement.

Core Tools and Infrastructure

Core Tools and Infrastructure is also a prerequisite for all JD Edwards modules, mirroring the requirement for System Foundation. These two components are sometimes bundled or treated as a combined base licence in certain contract structures, but their separate identity in Oracle's licensing documentation means that both must be tracked and reconciled independently when validating a JDE licence position.

In practice, organisations that hold the correct System Foundation count often have the correct Core Tools and Infrastructure count as well, because the two were typically sold together in the same transaction. The risk arises when supplemental orders were processed in a non-standard way or when licences were migrated from an older contract structure without full attention to the component-level detail.

Service Management Foundation

Service Management Foundation is a prerequisite for two functional areas that are increasingly important in modern JDE deployments: Service Management and Capital Asset Management. Organisations that have licensed either of these modules need to ensure they hold Service Management Foundation licences at a user count at least equal to the users licensed for the dependent modules.

This is a frequent compliance gap because Service Management and Capital Asset Management are often added as afterthought extensions to a core Financials and Supply Chain deployment, and the implementation team may focus entirely on the functional module licences without flagging the prerequisite requirement.

CRM Foundation

CRM Foundation is a prerequisite for Case Management within JDE's customer relationship management functionality. Organisations that use JDE for service request management, customer case tracking, or helpdesk workflows need CRM Foundation licensed for all users who access those capabilities.

CRM-related JDE functionality is often a blind spot in licence reviews because CRM capabilities within JDE may be used by teams — customer service, field service, helpdesk — that are managed separately from the core ERP user community and whose licences may be tracked by a different IT or business systems team.

How Oracle Identifies Prerequisite Licence Gaps in Audits

During a JDE audit, Oracle's LMS team requests a structured data extract from the JDE environment. This typically includes user counts by module, system configuration data, and licence entitlement documentation from the customer's Oracle licence files. LMS analysts then cross-reference the module-level user counts against the prerequisite requirements specified in Oracle's internal version of the licensing documentation.

Because the prerequisite mapping is formally documented in Oracle's own user manuals, there is limited scope to dispute the existence of the requirement. The audit conversation typically focuses on whether the gap exists (usually confirmed by the data extract) and the magnitude of the claim Oracle attaches to it. This is where independent advisory support is valuable: the gap itself may be difficult to dispute, but the commercial terms of the remediation — the price of the missing licences, the retrospective support calculation, and any penalties — are all negotiable.

The Retrospective Support Fee Problem

When Oracle identifies a prerequisite licence gap, it does not simply require the organisation to purchase the missing licences at today's price. Oracle typically also claims retrospective support fees for the period during which the organisation was using the prerequisite software without holding the required licence. Under Oracle's standard support terms, annual support fees escalate at 8% per year, so the retrospective calculation compounds over time.

For an organisation that has been running with a System Foundation gap for three years, the retrospective support claim could represent a substantial multiple of the cost of the missing licences themselves. This is why proactive licence reviews — conducted before Oracle initiates an audit — consistently deliver better financial outcomes than reactive responses to audit letters.

Checking for Prerequisite Gaps: A Practical Approach

Organisations that want to validate their JDE prerequisite licence position without waiting for an Oracle audit can follow a structured internal review process.

Step 1: Extract the Current Module List from the JDE System

Pull a complete inventory of all JDE modules that are deployed and accessible in your environment. This is typically available through JDE's P9861 application (Software Licensing) or through the system tables that record licensed functionality. The key output is a definitive list of every JDE module your organisation is technically running.

Step 2: Map Against the Oracle Licensing Information User Manual

Cross-reference each active module against the prerequisite table in Oracle's JD Edwards EnterpriseOne Licensing Information User Manual for your version of JDE (Release 9.1.x, 9.2.x, or later). The manual is publicly available on Oracle's documentation portal. For each module, identify every prerequisite product it requires and note the required licence count relationship (typically 1:1 user count).

Step 3: Extract Your Contracted Entitlements

Pull a complete inventory of the licences you hold from your Oracle contract documentation — the original purchase orders, supplemental orders, and any migration agreements. For each product, note the licence count and the effective date.

Step 4: Compare and Gap-Analyse

For each module with prerequisites, compare the prerequisite licence count you hold against the module licence count. Where the prerequisite count is lower than the module count, you have a compliance gap that needs to be addressed. Where you hold the prerequisite licences but have not been tracking them separately from the main module, document that explicitly as evidence of compliance for audit purposes.

Step 5: Remediate Proactively

For any gaps identified, the choices are: purchase the missing prerequisite licences, reduce the user count for the dependent module to match the available prerequisite cover, or restrict access to the relevant functionality. Proactive remediation before an audit allows you to negotiate the commercial terms — particularly the retrospective support question — from a position of good faith rather than under audit pressure.

Licence Migration and Prerequisite Gaps

A particularly common source of prerequisite licence gaps is the licence migration process. When Oracle migrates a customer from one contract structure to another — for example, from a legacy pricing model to a current one, or from a JD Edwards World contract to a JD Edwards EnterpriseOne contract — the migration agreement must explicitly address every prerequisite requirement.

In practice, migration agreements are often drafted with primary focus on the functional module licences and may not carry over prerequisite entitlements with the same precision. Organisations that went through major contract migrations years ago and have not since conducted a detailed component-level licence review may be sitting on prerequisite gaps that have been present since the migration itself.

Reviewing migration agreements — which are often stored in contract archives rather than active licence management systems — is a necessary step in any comprehensive JDE prerequisite compliance review.

What Redress Compliance Can Do

Redress Compliance provides specialist JD Edwards licence position reviews that address prerequisite compliance as a defined workstream. Our process is systematic: we extract the full module and user count data from your JDE environment, map it against the Oracle prerequisite documentation for your specific JDE version, compare against your contracted entitlements, and produce a gap analysis with commercial impact assessment.

Where gaps are found, we support the remediation strategy — whether that involves purchasing missing licences, renegotiating the commercial terms of remediation with Oracle, or restructuring access to eliminate the compliance exposure. Our approach is buyer-side: we are not Oracle's advisors, and our recommendations are not shaped by Oracle's commercial interests.