What an Oracle EBS Read-Only User Licence Is and How It Differs from Full-Use Application User, Eligible Modules and Restrictions, Pricing and Cost Savings (50–80% per User), How to Assign and Enforce Read-Only Access Through EBS Responsibilities, Common Misclassification Risks and Audit Findings, Read-Only vs Concurrent and Employee Metrics, Compliance Checklist for Read-Only Deployments, Optimisation Strategies to Maximise Read-Only Licence Usage, and the Full Governance Framework That Keeps You Audit-Ready
An Oracle EBS Read-Only User Licence is a specialised, lower-cost licence type that grants a named individual view-only access to specific Oracle E-Business Suite modules. Users with a read-only licence can log in, view data, run inquiries, and generate reports — but cannot create, modify, or delete transactional data. This licence exists exclusively for on-premises EBS environments (Oracle's SaaS cloud ERP uses a different subscription model). For the complete EBS licensing framework, see the Oracle EBS Licensing Guide. For the hub of Oracle licensing resources, see the Oracle Licensing Knowledge Hub.
Read-only licences are priced significantly lower than full-use Application User licences — typically 50–80% less per user per module. For organisations with large populations of executives, auditors, analysts, and managers who only need to view EBS data, the savings can be substantial. However, Oracle enforces strict rules: read-only users must be technically restricted to inquiry-only responsibilities, and any user who performs even a single transactional action requires a full-use licence.
| Dimension | Read-Only User Licence | Full-Use Application User Licence | Cost Impact |
|---|---|---|---|
| Access scope | View, query, report, and inquire only — no create, update, or delete | Full transactional access — create, edit, delete, approve | Read-only users cost 50–80% less per module |
| Eligible roles | Executives, auditors, analysts, controllers, compliance staff, view-only managers | Operational staff — data entry, processing, approvals, administration | Correct classification saves $1,500–$4,000+ per user per module |
| EBS responsibility requirement | Must be assigned inquiry-only or reporting responsibilities | Standard responsibilities with full functional access | Misassigned responsibility = full-use licence required in audit |
| Pricing (illustrative) | ~$500–$1,500 per user per module (varies by module) | ~$3,000–$5,000+ per user per module (varies by module) | 50–80% reduction per qualifying user |
| Audit treatment | Oracle verifies responsibilities match read-only restrictions | Oracle reclassifies read-only users to full-use if responsibilities allow transactions | Reclassification = back-pay difference + retroactive support fees |
| Minimum requirement | At least one user per module must hold a full-use licence | No minimum restriction | Cannot use read-only licences exclusively for any module |
Oracle EBS licensing is driven by responsibilities — the functional access profiles assigned to each user account. A read-only user licence requires that the user is assigned exclusively to inquiry, reporting, or view-only responsibilities. If the user's responsibility profile allows any transactional capability (even one they never use), Oracle treats them as a full-use Application User. For a detailed guide to EBS responsibilities and licensing, see Oracle EBS Licensing Basics.
| Read-Only Access Component | What It Permits | What It Prohibits | Enforcement Mechanism |
|---|---|---|---|
| Inquiry responsibilities | View records, search data, navigate forms in read mode | Creating, editing, or deleting any records | EBS responsibility design — forms open in query-only mode |
| Report generation | Run standard and custom reports; view output | Running processes that modify data (concurrent programs that update records) | Restrict concurrent request group to read-only reports |
| Dashboard/BI access | View dashboards, KPIs, and summary data | Drilling down into transactional forms with edit capability | OA Framework page function restrictions |
| Approval workflow | Viewing approval status is permitted | Approving, rejecting, or reassigning workflow items — this is a transaction | Remove all workflow approval functions from responsibility |
| Export/download | Exporting data to Excel or CSV for analysis | Uploading data back into EBS (e.g., WebADI loads) | Remove upload/import functions from responsibility |
The critical distinction is that Oracle audits licence classification based on what the responsibility allows, not what the user actually does. A user assigned a responsibility that permits data entry — even if they have never entered a single record — requires a full-use licence. For the complete module-level breakdown, see Licensing Oracle EBS Modules and Suites.
Not all Oracle EBS modules support a separate read-only licence metric. The availability depends on how Oracle has defined the licensing for each module or suite. For the full module list and pricing, see Complete Oracle EBS Application Module List and Oracle EBS Price List.
| Module Category | Read-Only Licence Available? | Typical Read-Only Use Cases | Restrictions / Notes |
|---|---|---|---|
| Oracle Financials (GL, AP, AR, FA) | Yes — inquiry responsibilities available for all core Financials modules | Finance controllers reviewing balances; auditors examining journal entries; executives viewing financial dashboards | Approval of journal entries or invoices = full-use licence required |
| Oracle Purchasing / Procurement | Yes — purchasing inquiry responsibilities | Budget holders reviewing PO status; auditors reviewing procurement data | Creating or approving purchase orders = full-use licence |
| Oracle Order Management | Yes — order inquiry functions | Sales managers reviewing order status; customer service viewing order history | Often licensed by order-line metric — check if user-based read-only applies |
| Oracle HRMS | Limited — HRMS typically uses Employee metric, not user-based | HR managers viewing employee records | Employee metric counts all employees regardless of access level — read-only savings may not apply |
| Oracle Manufacturing (WIP, BOM) | Yes — manufacturing inquiry | Plant managers reviewing work orders; quality staff viewing BOM data | Releasing or updating work orders = full-use licence |
| Oracle Projects | Yes — project inquiry responsibilities | PMO staff reviewing project budgets; auditors examining project costs | Entering time, expenses, or budget changes = full-use licence |
The read-only licence is one of the most significant cost optimisation levers in Oracle EBS licensing. The savings come from the price differential between full-use and read-only licence types, multiplied across the population of users who only need view access. For EBS pricing details, see Oracle EBS Price List.
| Scenario | Full-Use Users | Read-Only Users | Full-Use Cost (per Module) | Read-Only Cost (per Module) | Annual Savings |
|---|---|---|---|---|---|
| Finance department — 50 operational + 30 view-only managers | 50 | 30 | 50 × $4,000 = $200,000 | 30 × $1,000 = $30,000 (vs $120,000 at full-use) | $90,000 savings |
| Procurement — 25 buyers + 15 view-only budget holders | 25 | 15 | 25 × $4,000 = $100,000 | 15 × $1,000 = $15,000 (vs $60,000) | $45,000 savings |
| Manufacturing — 40 operational + 20 view-only plant managers | 40 | 20 | 40 × $3,500 = $140,000 | 20 × $900 = $18,000 (vs $70,000) | $52,000 savings |
| Projects — 30 operational + 25 PMO/audit view-only | 30 | 25 | 30 × $3,500 = $105,000 | 25 × $900 = $22,500 (vs $87,500) | $65,000 savings |
| Combined total | 145 | 90 | $545,000 | $85,500 (vs $337,500) | $252,000 annual savings |
Beyond one-time licence fees, read-only licences also reduce annual support costs (typically 22% of licence value), creating compounding savings year over year. The 90 read-only users above would save approximately $55,000+ per year in ongoing support fees alone.
Read-only licence misclassification is one of Oracle's highest-yield audit findings. Oracle's LMS (License Management Services) auditors specifically look for users classified as read-only whose EBS responsibilities grant transactional capabilities. For Oracle audit defence guidance, see Oracle Audit Defense Service. For the LMS collection tool analysis, see Oracle EBS Usage Analysis: LMS Collection Tool.
| Misclassification Risk | What Happens | Oracle's Audit Finding | Financial Exposure | Prevention |
|---|---|---|---|---|
| Responsibility allows transactions | User assigned a responsibility with create/edit functions even though they only view data | Reclassified as full-use Application User — difference billed + retroactive support | $2,000–$4,000 per user × number of affected users + 22% annual support backdated | Audit every responsibility assigned to read-only users; remove all transactional functions |
| Approval workflow access | User can approve invoices, POs, or journal entries through workflow notification | Approval is a transaction — user requires full-use licence | $2,000–$4,000 per user | Remove AME/workflow approval functions from read-only responsibilities |
| Self-service access overlap | User has both a read-only EBS responsibility and an Employee Self-Service responsibility with update capability | Any transactional responsibility on the same user account disqualifies read-only classification | Additional licence cost for ESS module | Separate user accounts or ensure ESS responsibilities are truly read-only |
| WebADI upload capability | User can open WebADI templates that upload data into EBS (e.g., journal entry upload) | Upload is a transaction — full-use licence required | $2,000–$4,000 per user | Remove all WebADI upload functions from read-only responsibilities |
| Custom responsibility creep | Over time, IT adds functions to a read-only responsibility to accommodate ad-hoc requests | Responsibility no longer qualifies as read-only — all assigned users reclassified | Potentially dozens of users reclassified in a single finding | Lock down read-only responsibilities; require change approval for any modification |
Oracle EBS uses several licence metrics beyond Application User. Understanding where read-only fits in the broader licensing framework prevents confusion and audit exposure. For the full comparison of EBS licensing models, see Oracle EBS Licensing Guide 2026 Edition. For concurrent licensing, see Managing Oracle EBS Concurrent Licensing.
| Licence Metric | How It Works | Read-Only Option? | Best For | Key Risk |
|---|---|---|---|---|
| Application User (Full-Use) | One licence per named individual authorised to access the module — regardless of usage frequency | Yes — read-only variant available at lower cost | Organisations that can clearly separate transactional vs view-only users | Every authorised user must be licensed — even infrequent or occasional users |
| Application User (Read-Only) | One licence per named individual with view-only access — no transactional capabilities | This IS the read-only metric | Executives, auditors, analysts, controllers, compliance staff | Responsibility must be strictly inquiry-only; any transactional function disqualifies |
| Employee Metric | Based on total number of employees in the organisation — not individual user access | No — employee metric counts all employees regardless of access level | HRMS, Payroll, Benefits — enterprise-wide HR modules | Even employees who never log in are counted; no read-only savings possible |
| Revenue Metric | Based on organisation's total annual revenue — enterprise-level pricing | No — revenue metric is access-agnostic | Very large enterprises wanting unlimited EBS usage without user counting | Revenue growth increases licence cost automatically |
| Concurrent User | Based on simultaneous active sessions — not named individuals | No separate read-only concurrent metric exists | Legacy deployments; specific modules where concurrent is still available | Oracle's standard position is Application User, not concurrent — availability is limited |
Correctly implementing read-only access requires careful EBS configuration. The technical enforcement must be airtight because Oracle audits assess what the user can do, not what they actually did. For EBS technology and customisation licensing, see Oracle EBS Customised Database Technology.
| Implementation Step | What to Configure | How to Verify | Common Mistake |
|---|---|---|---|
| 1. Create dedicated read-only responsibilities | Build custom responsibilities that include only inquiry forms, view-only pages, and reporting functions | Test each form and function — verify no create/edit/delete buttons are accessible | Copying full-use responsibility and 'disabling' functions — some functions may remain accessible |
| 2. Restrict concurrent request groups | Assign a request group containing only read-only reports and queries — exclude all update/load programs | List all programs in the request group; verify none modify data | Including concurrent programs that run data updates (e.g., 'Import Journals', 'AutoInvoice') |
| 3. Remove approval workflow functions | Exclude all AME (Approvals Management Engine) and workflow notification functions from read-only responsibilities | Test that read-only users cannot approve, reject, or reassign workflow items | Leaving workflow notification access — even viewing notifications may include approve buttons |
| 4. Lock down menu structure | Create a custom menu that exposes only inquiry and reporting menu items | Navigate the full menu tree as a read-only user; verify no transactional paths exist | Inheriting a parent menu with hidden transactional submenu items |
| 5. Disable personalisation capability | Prevent read-only users from using OA Framework personalisation to expose hidden regions or functions | Verify personalisation is disabled at the responsibility level | User personalises a page to expose edit buttons not visible in the default layout |
| 6. Document and audit quarterly | Maintain a register of all read-only responsibilities; audit quarterly for function creep | Compare current responsibility functions against baseline; investigate any additions | Never reviewing responsibilities after initial setup — functions accumulate over time |
Oracle's LMS audit scripts collect user data and responsibility assignments from your EBS system. The auditors then compare each user's assigned responsibilities against the licence classification to identify mismatches. For the full audit defence framework, see Oracle Audit Defense Service. For EBS-specific audit preparation, see Oracle EBS Usage Analysis: LMS Collection Tool.
| Oracle Audit Check | What LMS Examines | Common Finding | Your Defence |
|---|---|---|---|
| Responsibility-to-licence mapping | Every function and form accessible via each user's assigned responsibilities | Read-only users with responsibilities that include transactional forms — reclassified to full-use | Pre-audit: run the same LMS scripts internally; verify every read-only user's responsibilities are strictly inquiry-only |
| Concurrent program access | Which concurrent programs each user can submit through their request group | Read-only users with access to programs that modify data (even if never run) | Restrict request groups to reporting/query programs only; document exclusions |
| User account activity | Login history, last login date, sessions per user | Inactive accounts counted as licensed users (whether full-use or read-only) | Deactivate inactive accounts before audit; show evidence of regular cleanup process |
| Shared/generic accounts | Accounts used by multiple people (e.g., 'FINANCE_READER') | Each person behind a shared account requires a separate licence — Oracle counts individuals, not accounts | Eliminate all shared accounts; assign individual user IDs to every person |
| Cross-module access | Whether a single user has responsibilities across multiple modules | Read-only licence must be held for each module accessed — not just one global read-only licence | Verify that read-only licences cover every module the user can access |
For understanding how Oracle counts EBS users in audits, see Application User Licensing for Oracle EBS. For EBS licensing FAQs including audit scenarios, see Oracle E-Business Suite Licensing FAQ.
Organisations that proactively manage read-only licence classification can achieve significant cost reductions. For Oracle licence management and optimisation, see Oracle License Management Services. For contract negotiation support, see Oracle Contract Negotiation Service.
| Optimisation Strategy | How It Works | Expected Savings | Implementation Effort |
|---|---|---|---|
| User access review and reclassification | Audit all full-use Application Users; identify those who only view/query data; reclassify to read-only with proper responsibilities | 20–40% of full-use users may qualify for read-only — savings of $2,000–$4,000 per user per module | Medium — requires responsibility redesign and user communication |
| Responsibility redesign | Create purpose-built read-only responsibilities for each module; remove all transactional functions; deploy to qualifying users | Enables read-only classification for maximum number of users | Medium-High — requires EBS functional consultant effort |
| Approval workflow separation | Move approval actions to a dedicated full-use user or create a separate approval responsibility | Avoids full-use reclassification for users who only need to view + occasionally approve | Medium — workflow redesign required |
| BI/reporting tool deployment | Provide view-only users with access through external BI tools (OBIEE, Power BI) instead of direct EBS login | May eliminate the need for EBS read-only licences entirely for some users | High — requires BI infrastructure investment |
| Contract negotiation for read-only pricing | Negotiate favourable read-only licence pricing during contract renewal; bundle read-only users into volume deals | Additional 10–25% discount on read-only licence prices beyond standard list | Low — negotiation at renewal/purchase time |
| Account cleanup automation | Automate deactivation of inactive users; integrate with HR offboarding; reduce total licence count | Eliminates 10–20% of unnecessary licences (both full-use and read-only) | Medium — requires HR/IT integration |
For cloud migration considerations, see Running Oracle EBS on Azure and Licensing Oracle EBS on AWS.
| # | Action | Owner | Timing | Key Outcome |
|---|---|---|---|---|
| 1 | Inventory all EBS user accounts: extract full user list with assigned responsibilities, licence classifications, and last login dates | EBS DBA / SAM | Quarterly | Complete visibility into who is using what |
| 2 | Identify read-only candidates: analyse user activity to find full-use users who only perform queries, reports, and views | SAM / EBS Functional | Quarterly | 20–40% of users may qualify for read-only reclassification |
| 3 | Design read-only responsibilities: create dedicated responsibilities with inquiry-only functions for each module | EBS Functional / IT | Once (then maintain) | Technically enforced view-only access that withstands Oracle audit |
| 4 | Restrict concurrent request groups: ensure read-only responsibilities can only submit reporting/query programs | EBS DBA | At responsibility creation; reviewed quarterly | No transactional concurrent programs accessible to read-only users |
| 5 | Remove approval workflow access: strip all AME and workflow approval functions from read-only responsibilities | EBS Functional / Workflow Admin | At responsibility creation | Approval is a transaction — removing it protects read-only classification |
| 6 | Reclassify qualifying users: assign read-only responsibilities and update licence records | SAM / EBS Admin | After responsibility design and testing | Immediate cost reduction — $2,000–$4,000+ per user per module |
| 7 | Clean up inactive and duplicate accounts: deactivate departed employees; consolidate duplicate IDs; eliminate shared accounts | EBS Admin / HR | Monthly | Reduces total licence count by 10–20% |
| 8 | Run pre-audit LMS scripts internally: execute Oracle's LMS collection tool on your own systems; review output for misclassifications | EBS DBA / SAM | Annually; immediately upon audit notice | Catch misclassifications before Oracle does |
| 9 | Document read-only restrictions: maintain a register of all read-only responsibilities, the functions they include/exclude, and the users assigned | SAM / EBS Functional | Ongoing | Audit-ready documentation that demonstrates compliance |
| 10 | Negotiate read-only pricing at contract renewal: push for maximum discount on read-only licences; negotiate volume tiers for large read-only populations | Procurement / SAM | At every contract renewal or new purchase | Additional 10–25% discount on read-only pricing beyond list |
For expert Oracle EBS licensing guidance, Redress Compliance provides independent advisory through our Oracle License Management Services, Oracle Audit Defense Service, and Oracle Contract Negotiation Service.
An Oracle EBS Read-Only User Licence is a lower-cost named-user licence that grants view-only access to specific E-Business Suite modules. Read-only users can log in, view data, run inquiries, and generate reports but cannot create, modify, or delete transactional data. It exists exclusively for on-premises EBS environments.
Read-only licences are typically 50–80% less expensive than full-use Application User licences for the same module. The exact price varies by module, but the difference is typically $1,500–$4,000+ per user per module, making read-only classification a significant cost optimisation lever.
Users who only need to view data, run queries, and generate reports qualify for read-only licences. Typical roles include executives, auditors, analysts, finance controllers, compliance staff, and managers who review data but do not enter or modify transactions. At least one user per module must hold a full-use licence.
Oracle EBS licensing is driven by responsibilities — the functional access profiles assigned to each user account. A user qualifies as read-only only if all assigned responsibilities are strictly inquiry-only. If any responsibility allows transactional functions (even if never used), Oracle treats the user as full-use.
No. Approval is a transactional action under Oracle's licensing rules. If a user can approve, reject, or reassign workflow items, they require a full-use Application User licence. To maintain read-only classification, remove all workflow approval functions from read-only responsibilities.
Yes. Oracle's LMS audit scripts collect user data and responsibility assignments. Auditors compare each user's assigned responsibilities against their licence classification. If a read-only user has responsibilities that allow transactional functions, Oracle reclassifies them as full-use and charges the price difference plus retroactive support.
Oracle reclassifies misclassified users to full-use Application User and charges the licence price difference (typically $2,000–$4,000 per user per module) plus retroactive annual support fees (22% of licence value) for the period of misclassification. For 20+ misclassified users, exposure can exceed $100,000.
No. Read-only licence availability depends on how Oracle has defined licensing for each module. Most user-based modules (Financials, Purchasing, Manufacturing, Projects) support read-only variants. However, modules using employee metrics (HRMS, Payroll) count all employees regardless of access level, so read-only savings may not apply.
No. Oracle requires at least one full-use Application User licence per module in use. You cannot licence a module with only read-only users. The read-only licence is designed for additional users beyond the operational staff who perform transactions.
Create dedicated read-only responsibilities with inquiry-only forms, restrict concurrent request groups to reporting programs only, remove all workflow approval functions, lock down menu structures, and disable OA Framework personalisation. Test thoroughly and audit quarterly to prevent function creep.
Read-only is a named-user licence type with restricted access scope at lower cost. Concurrent licensing counts simultaneous active sessions rather than named individuals. There is no separate read-only concurrent metric. Oracle's standard position for EBS is Application User licensing, not concurrent.
Analyse user activity logs: look for users who only execute queries, reports, and inquiries with no transactional activity. Review job roles to identify executives, auditors, analysts, and managers. In most organisations, 20–40% of EBS users may qualify for read-only reclassification.
Always reclassify proactively before an audit. Cleaning up user classifications and implementing proper read-only responsibilities before Oracle audits gives you a defensible compliance position and captures cost savings immediately. Reclassifying during an audit is more difficult and invites scrutiny.
EBS read-only licences are on-premises only. When migrating to Oracle Fusion Cloud ERP, the SaaS subscription model replaces on-premises licensing entirely. Read-only distinctions do not carry over. However, during a dual-run period, you maintain existing EBS licences (including read-only) alongside the cloud subscription.
This article is part of our Oracle EBS Licensing Guide pillar. Explore related guides:
Redress Compliance has helped hundreds of Fortune 500 enterprises — typically saving 15–35% on Oracle renewals, ULA negotiations, and audit defense.
100% vendor-independent · No commercial relationships with any software vendor