If you read nothing else
Oracle JD Edwards is licensed on four models — Application User (named-user), Enterprise metrics (employees or revenue), Custom Application Suite, and Processor — and your compliance exposure is set by which one is written into your contract, not by how many people log in. Application Users list at roughly $4,600–$6,000 each, every module is licensed separately, and Oracle layers 22% annual support on the net licence value.
JD Edwards licensing looks simple and audits badly. The named Application User metric counts every individual authorised to use a licensed module — not concurrent users, and not just the people who log in — and each module carries its own user count. Layer in Enterprise metrics for HR and payroll, Custom Application Suite bundles, and legacy Processor grants, and most estates are a patchwork that was never reconciled against actual deployment. That gap is exactly what Oracle's licence reviews target. This guide decodes each metric, the 2026 list ranges, and the moves that keep a JD Edwards estate defensible and right-sized.
Key takeaways
- Application User counts authorised individuals, not concurrent sessions. Every person granted access to a licensed JD Edwards module needs a named Application User licence for that module — it is the most common metric in new contracts and the one most often under-counted (Oracle Global Price List, 2026).
- Every module is licensed separately. Financial Management modules list at roughly $3,500–$5,000 per named user and Manufacturing and Distribution modules at roughly $3,000–$5,000, so a user touching three modules needs three licences — the per-user headline understates the real cost (industry JDE price reference, 2026).
- Enterprise metrics license by business size, not by user. Oracle offers Enterprise Application User and employee- or revenue-based metrics for large estates and HR/payroll, covering everyone in scope whether they log in or not — simpler to administer but easy to over-buy if the business measure is inflated (Oracle JDE pricing models, 2026).
- Support is 22% of net licence value, every year. Oracle technical support runs at 22% of the net JDE licence fee annually and compounds with uplifts; on a stable 9.2 estate, third-party support can cut that line by roughly 50% (Oracle support policy, 2026).
- The back-licence claim is built on indirect and unreconciled users. Across 600+ Oracle engagements, the largest JD Edwards audit findings come from users licensed for the wrong module, indirect access through integrations, and named accounts never deactivated — not from concurrent overuse — Oracle Licensing Experts engagement benchmark, 2026.
01Recommendations by role
JD Edwards compliance gaps have owners. Here is where each role should push first before a renewal or a licence review.
CIO / IT Director
- Hold a single, current map of which JD Edwards modules are deployed against which licensed metric — most estates have never had one.
- Treat integrations as a licensing question: any system reading or writing JDE data may create indirect-access exposure.
- Use the 2037 support runway to negotiate from strength rather than reacting to a manufactured upgrade deadline.
Procurement / Vendor Management
- Benchmark the Application User and Enterprise list ranges independently before accepting Oracle's quote — module pricing is negotiable, not fixed.
- Push for an Enterprise metric only when the business measure is genuinely lower-cost than named users at your scale, not by default.
- Negotiate the 22% support line and any uplift cap at the same time as the licence, never afterward.
SAM / License Manager
- Reconcile named Application User accounts module-by-module against the contract; deactivate orphaned and duplicate accounts before any measurement.
- Document indirect-access paths — portals, middleware, reporting tools — and confirm each is licensed or carved out.
- Keep the ordering documents and metric definitions; at a licence review, Oracle's count stands unless you can challenge it with evidence.
CFO / Finance
- Model the full cost of a user: per-module licences plus the recurring 22% support, not the single per-user list price.
- Quantify the third-party-support option on a stable 9.2 estate — roughly half the support bill is a material recurring saving.
- Budget independent buyer-side review ahead of any renewal; the fee is a fraction of one back-licence claim.
02Decoding JD Edwards licensing
What is the Application User metric and how does it count?
The Application User metric is JD Edwards' named-user licence: it counts every individual authorised to access a specific licensed module, regardless of how often or whether they log in, and it is not a concurrent-user measure. If 400 people are set up to use Financial Management, you need 400 Financial Management Application User licences even if only 150 are active on any given day. Crucially, the count is per module — a user who works in General Ledger, Procurement and Inventory needs an Application User licence for each. This is the single most misunderstood mechanic in JD Edwards, and the reason named-user estates so often fail a licence review: the authorised population, not the active one, is the licensable number.
If your JD Edwards renewal is sized on "active users" or concurrent sessions, you are mis-counting the Application User metric. Oracle licenses authorised individuals per module — reconcile the full authorised population against each module before you sign, or the gap surfaces as a back-licence claim.
How are the JD Edwards module list prices structured in 2026?
JD Edwards is licensed module by module on Oracle's Global Price List, with named Application Users typically in the $4,600–$6,000 range depending on the module. As a working reference for 2026, Financial Management modules — General Ledger, Accounts Payable, Accounts Receivable, Fixed Assets — list at roughly $3,500–$5,000 per named user, and Manufacturing and Distribution modules — Inventory, Procurement, Manufacturing Management, Sales Order Management — at roughly $3,000–$5,000. Because every module is a separate line, the real cost per person is the sum of every module they touch, plus 22% annual support on the total. List prices are an anchor for negotiation, not a fixed cost.
When does an Enterprise metric beat named Application Users?
Enterprise metrics — Enterprise Application User and employee- or revenue-based measures — license JD Edwards on a business measure rather than per individual, covering everyone in scope whether or not they access the system. They make sense when your authorised population is large relative to the business measure: a manufacturer with thousands of named users across many modules may pay less on an employee metric than on summed per-module named users, and the administration is simpler. The trap is the reverse: if Oracle sizes the Enterprise metric on an inflated employee or revenue figure, you over-buy permanently. Model both before choosing, and never adopt an Enterprise metric just because it is easier to count.
Run the named-user total and the Enterprise-metric quote side by side at your real scale before deciding. An Enterprise metric is only a saving if your authorised, multi-module population is genuinely large — otherwise you are paying for headcount that never touches JD Edwards.
How does indirect access create a back-licence claim?
Indirect access is use of JD Edwards data through another application — a customer portal, middleware, a reporting tool or a bespoke integration — by people or systems that do not have a named JDE licence. Oracle's position is that the human or device ultimately consuming licensed JDE functionality must be licensed, even if they never open a JD Edwards screen. This is where the largest, most surprising audit findings come from: a web storefront that writes orders into JDE, or an analytics layer that reads JDE tables, can expose thousands of unlicensed indirect users. Map every integration and either license the path or carve it out contractually before Oracle does the counting.
"For each integration into JD Edwards, exactly who or what needs a licence, under which metric, and is batch or system-to-system access excluded?" Get the answer in writing in the contract — an unaddressed indirect-access definition is the gap most JD Edwards audits exploit.
What does Oracle's 22% support actually buy, and can you cut it?
Oracle technical support for JD Edwards runs at 22% of the net licence value annually and funds updates, fixes, tax and regulatory updates, and access to My Oracle Support. On a fast-moving estate that values continuous delivery, it is worth the line. On a stable, customised 9.2 estate that rarely takes new Oracle code, the same 22% buys little you use — and independent third-party support can deliver equivalent break-fix and tax updates for roughly half the cost while you stay on a release supported to 2037. The decision is not ideological; it is a usage-versus-cost calculation that most buyers never run.
Across 600+ Oracle engagements, JD Edwards customers on a stable 9.2 release who moved to independent third-party support cut their annual support spend by roughly 50% with no loss of break-fix or tax-update coverage — the single largest recurring saving available on a mature JDE estate — Oracle Licensing Experts engagement benchmark, 2026.
How do you keep a JD Edwards estate audit-ready?
An audit-ready JD Edwards estate is one where the authorised population, the licensed metric and the deployed modules reconcile to the contract at any moment. That means a current entitlement record, named accounts deactivated when people leave, a documented map of every integration and its licensing treatment, and a clean separation between the modules you bought and the modules people can reach. Run that reconciliation on your own schedule, not Oracle's, so any gap is fixed on your terms through a right-sizing or true-up you control — rather than discovered in a licence review and priced as a back-licence claim with leverage on Oracle's side.
03Metric or mistake: the choice that sets your exposure
Recognise the pattern
"Size it on active users"
Counting only people who log in undercounts the Application User metric, which licenses every authorised individual per module — the classic back-licence gap.
"Reconcile authorised users per module"
Count the full authorised population module-by-module, deactivate orphaned accounts, and match the total to the contract before any renewal or review.
"Take the Enterprise metric, it's simpler"
Adopting an employee or revenue metric without modelling it can lock in payment for headcount that never touches JD Edwards.
"Model both at real scale"
Compare summed named-user cost against the Enterprise quote at your actual population, and choose the lower defensible number — not the easier one.
Every JD Edwards licensing decision reduces to the same pattern: Oracle counts authorised users per module and chases indirect access; the buyer's job is to reconcile the real population, pick the right metric, and close the integration gaps before a review does it for them.
04JD Edwards licensing models: strengths & cautions
| Model | What it does for the buyer | Caution |
|---|---|---|
| Application User (named) | Precise, per-module licensing that fits defined user populations | Counts every authorised individual per module; under-counting drives back-licence claims |
| Enterprise Application User | Simplifies administration for large, multi-module estates | Priced on a business measure; an inflated figure locks in permanent over-buy |
| Employee / revenue metric | Covers all in-scope staff for HR and payroll without per-user tracking | You pay for the whole measure, including staff who never use the system |
| Custom Application Suite | Bundles a defined module set, often at a better effective rate | Scope is fixed at signature; adding modules later re-opens the negotiation |
| Processor (legacy) | Decouples cost from user count for high-population deployments | Rare in new deals; verify core-factor and hardware definitions still hold |
05Acronyms & definitions
- Application User
- Application User is JD Edwards' named-user metric, licensing each individual authorised to access a specific module, regardless of login frequency.
- Enterprise Application User
- Enterprise Application User is a metric that licenses JD Edwards across a large estate on a business measure rather than per individual.
- Custom Application Suite (CAS)
- Custom Application Suite is a licensed bundle of a defined JD Edwards module set, priced as a package rather than module by module.
- Processor metric
- The Processor metric licenses JD Edwards by the processing capacity running it, decoupling cost from user count; rare in new contracts.
- Indirect access
- Indirect access is use of JD Edwards data through another application or integration by users or systems without a named JDE licence.
- EnterpriseOne (E1)
- EnterpriseOne is Oracle's web-architecture JD Edwards ERP line; release 9.2 holds Premier Support to at least 2037.
- JD Edwards World
- JD Edwards World is the older IBM iSeries-based JDE product line, distinct from EnterpriseOne and still supported for legacy customers.
- Technical support (22%)
- Oracle technical support is the annual fee, set at 22% of net licence value, that funds updates, fixes and My Oracle Support access.
06Frequently asked questions
How is Oracle JD Edwards licensed in 2026?
JD Edwards is licensed on four models: named Application User, Enterprise metrics (employee or revenue), Custom Application Suite, and the legacy Processor metric. Application User is the most common in new contracts and licenses every individual authorised to use a module. Modules are licensed separately, and Oracle adds 22% annual technical support on the net licence value.
What is the JD Edwards Application User metric?
The Application User metric counts every individual authorised to access a specific licensed JD Edwards module, regardless of how often they log in. It is a named-user, not a concurrent, measure, and it is per module — a user working in three modules needs three Application User licences. Under-counting the authorised population is the most common source of back-licence claims.
How much does a JD Edwards user cost?
Named Application Users list at roughly $4,600–$6,000 each on Oracle's Global Price List, depending on the module — Financial Management around $3,500–$5,000 and Manufacturing/Distribution around $3,000–$5,000 per named user. Because modules are licensed separately, the real cost per person is the sum of every module they touch, plus 22% annual support. List prices are negotiable anchors.
What is indirect access in JD Edwards and why does it matter?
Indirect access is use of JD Edwards data through another application — a portal, middleware, reporting tool or integration — by users or systems without a named JDE licence. Oracle holds that the party ultimately consuming JDE functionality must be licensed even if they never open a JDE screen. It is the source of the largest, most surprising audit findings, so every integration should be licensed or carved out in writing.
Can I reduce my JD Edwards support cost?
Yes. Oracle technical support is 22% of net licence value annually. On a stable, customised EnterpriseOne 9.2 estate that rarely takes new Oracle code, independent third-party support can deliver equivalent break-fix and tax updates for roughly half the cost while you stay on a release supported to at least 2037. It is a usage-versus-cost decision worth modelling at every renewal.
Should I move to an Enterprise metric or stay on named users?
It depends on scale. An Enterprise Application User or employee/revenue metric simplifies administration and can be cheaper when your authorised, multi-module population is genuinely large relative to the business measure. But if Oracle sizes it on an inflated figure, you over-buy permanently. Model the summed named-user cost against the Enterprise quote at your real population before choosing.
What triggers a JD Edwards licence review or audit?
Common triggers include renewals, mergers and acquisitions, large deployment changes, and lapsed reconciliation. The findings, though, are predictable: users licensed for the wrong module, indirect access through integrations, and named accounts never deactivated. Running your own module-by-module reconciliation on your schedule turns a potential back-licence claim into a controlled right-sizing.
07Methodology & sources
Benchmarks in this paper draw on Oracle Licensing Experts engagement data across 600+ Oracle licensing, audit and negotiation projects, 2026. Pricing ranges and audit-finding patterns are anonymised aggregates from buyer-side advisory work; the metric definitions, support terms and product roadmap are taken from Oracle's primary JD Edwards and pricing documentation. We do not publish client names or fabricated deal counts.
Primary sources: Oracle, JD Edwards EnterpriseOne product page (2026); Oracle, JD Edwards EnterpriseOne Premier Support roadmap (2026); Oracle, Announcing JD Edwards EnterpriseOne Release 26 (2026).
Download this white paper as a PDF
Keep the four JD Edwards metrics, the 2026 module list ranges and the indirect-access checklist on hand for your next JD Edwards renewal or licence review. Use your browser's print-to-PDF to save a clean copy.
Download / Print PDF →08Related white papers
Renewing or being reviewed on JD Edwards? Reconcile before Oracle counts.
Oracle licenses authorised users per module and chases indirect access. Our independent advisors reconcile your real population, pick the right metric, close the integration gaps, and benchmark your module pricing and 22% support — buyer-side, before a licence review starts.
The buyer-side Oracle briefing
Monthly, independent intelligence on Oracle licensing, cloud pricing, audits and contract negotiation — written for buyers, never for Oracle.
Prefer to talk? Request a free Oracle licensing briefing or see how we cut an Oracle support bill.