What Is an Oracle EBS Read-Only User Licence?

Definition and Core Characteristics

An Oracle EBS Read-Only User Licence is a lower-cost licensing metric designed for users who require access to view, query, and report on transactional data within E-Business Suite but do not need the ability to create, modify, or delete records. This licence type applies exclusively to on-premises EBS implementations and represents a significant opportunity for cost optimization when properly implemented and documented.

The fundamental distinction between a read-only user and a full Application User lies in the responsibility profiles assigned to each user. A responsibility profile in Oracle EBS is a collection of functions, forms, and menus that define what a user can access and perform within the system. For read-only users, responsibility profiles must be configured to exclude all transaction creation, modification, and deletion capabilities.

Oracle's licensing model audits based on what the responsibility profile allows, not on what a user actually does. This distinction is crucial for compliance. If a responsibility profile includes any transactional capability—even if the user never exercises that capability—Oracle's licensing and audit teams classify the user as a full Application User and charge accordingly.

How Read-Only Licensing Qualifies

Responsibility Profile Requirements

To qualify for read-only licensing, a user must be assigned responsibility profiles that restrict them to the following activities:

• Inquiry: The ability to search, query, and view transactional records without modification
• Reporting: Access to pre-built and ad-hoc reports that extract and present data
• View-Only Forms: Forms configured in read-only mode where users can view details but cannot enter data
• Dashboard Access: Real-time visibility into key performance indicators and metrics

Critically, the responsibility profile must exclude all functions that enable:

• Purchase order creation, approval, or receipt
• Invoice creation, posting, or payment approval
• Inventory transactions (receipts, issues, transfers)
• General ledger journal entry creation
• Order entry and order fulfillment
• Payroll processing
• Any master data creation or modification (vendors, customers, items, accounts)

Qualification Steps: The UMX Audit Approach

Organizations seeking to rightfully classify users as read-only must follow a structured, documented process. The User Management Extension (UMX) module in Oracle EBS provides tools to enforce and validate read-only restrictions:

1. Responsibility Analysis: Run the FND_USER_RESP_GROUPS report to extract all responsibility assignments for every user. Document which responsibilities each user holds.
2. Function Audit: For each responsibility, use the FND_MENU to identify all functions available within that responsibility. Cross-reference with Oracle's transaction function definitions to identify any that enable data creation, modification, or deletion.
3. Read-Only Validation: Create a custom query or use Oracle's security audit tools to verify that no assigned responsibilities contain functions capable of creating, updating, or deleting records.
4. Form Configuration Check: For forms included in read-only profiles, confirm that form parameters are set to read-only mode, not update mode.
5. Documentation: Create an audit file or spreadsheet listing each user, their assigned responsibilities, and evidence that those responsibilities are restricted to inquiry and reporting only.
6. Quarterly Review: Establish a recurring process to validate that responsibility assignments remain read-only. Any new responsibilities added must be vetted before assignment.

Cost Savings and Financial Impact

Licensing Cost Differential

Read-only user licences typically cost 50–80% less than full Oracle EBS Application User licences. The exact discount varies by:

• Module (some modules offer more aggressive read-only discounts than others)
• Geography (pricing varies by region)
• Oracle licensing agreement type (ULA, PULA, OCS, CSI)
• Volume commitments

For example, if a full EBS Application User licence costs $5,000 per year, a read-only user licence might cost between $1,000 and $2,500 per year, representing savings of $2,500 to $4,000 per user annually.

Support Fee Multiplication: The 8% Uplift Impact

Beyond the initial licence cost, Oracle charges annual support fees equal to 22% of the licence value, increasing by 8% per year. This compounds significantly over time and amplifies the value of read-only reclassification.

Consider a scenario with 50 users currently licensed as full Application Users:

• Year 1: 50 users × $5,000 licence + (50 × $5,000 × 22%) support = $305,000
• Year 2: 50 × $5,000 licence + (50 × $5,000 × 22% × 1.08) support = $307,770
• Year 3: 50 × $5,000 licence + (50 × $5,000 × 22% × 1.08²) support = $310,651

If 30 of those users are correctly reclassified as read-only (at $1,500 per licence):

• Year 1: (20 × $5,000) + (30 × $1,500) + support = $195,000 + savings
• Year 2 onwards: Additional 8% annual support increases apply to the lower base, meaning savings multiply year after year

Over a 5-year period, correctly identifying 30 read-only users can save $250,000–$350,000 in licence and support costs, depending on the initial discount and support rate negotiated.

Module Availability and Limitations

Not all Oracle EBS modules support separate read-only licensing metrics. Oracle defines read-only user classifications at the module level, and availability varies:

• Full Support: Financials (GL, AP, AR, FA), Purchasing, Inventory, Order Management typically offer robust read-only metrics
• Partial Support: Human Resources and Payroll have limited read-only options; many HR inquiries require Application User licensing
• No Support: Some specialized modules (e.g., advanced supply chain planning) do not recognize read-only users and require full Application User licensing

Organizations must validate module-specific eligibility before claiming read-only status. A user accessing multiple modules may require full Application User licensing if even one module does not support read-only metrics.

Audit Risk and Compliance Exposure

Oracle LMS Audit Focus Areas

Oracle License Management Services (LMS) specifically targets under-classified users during audits. Read-only user claims face particular scrutiny because they represent significant cost avoidance. Audit teams look for:

• Responsibility Profile Mismatches: Users claiming read-only status but assigned responsibilities with transactional capabilities
• Customized Functions: Custom-built forms or functions that appear read-only but include hidden data-modification capabilities
• Form Mode Configuration: Forms set to edit mode despite responsibility descriptions stating "read-only"
• Lack of Documentation: Absence of evidence (audit files, responsibility matrices) supporting read-only classification
• Inconsistent Access Patterns: Audit logs showing users performing transactional actions contradicting their claimed read-only status

Common Audit Findings and Remediation

Based on historical audits, the most common read-only licensing findings include:

• Finding: User assigned "Accounts Payable Manager" responsibility, claiming read-only. Issue: AP Manager responsibility includes invoice approval and posting functions.
• Remediation: Reclassify as full Application User or create custom read-only AP inquiry responsibility excluding transactional functions.

• Finding: Custom invoice reporting form classified as read-only, but form parameters allow data entry.
• Remediation: Modify form configuration to enforce read-only mode or promote to full Application User classification.

• Finding: No documented evidence of responsibility analysis or approval chain for read-only classification.
• Remediation: Conduct retroactive audit and create responsibility matrix with approval signatures from business and IT leadership.

Practical Implementation Steps

Pre-Audit Preparation

Organizations should proactively implement the following to defend read-only user classifications:

1. User Responsibility Audit: Extract FND_USER and FND_USER_RESP_GROUPS data to map all current assignments. Use data tools or Oracle's Audit Trail module to pull this information.
2. Responsibility Function Inventory: For each responsibility assigned to read-only users, compile a list of all functions. Cross-reference with Oracle's delivered function definitions to confirm no transactional functions are present.
3. Form Access Validation: Test each form accessible to read-only users to confirm read-only mode enforcement. Document screenshots and configuration settings.
4. Responsibility Profile Documentation: Create a reference document describing each responsibility used for read-only classification, listing its allowed functions, and certifying its read-only nature.
5. Sign-Off and Governance: Obtain written approval from the Chief Information Officer (CIO) and Finance Director confirming that read-only responsibilities meet business requirements and comply with Oracle licensing terms.
6. Establish Change Control: Implement a process whereby any responsibility assignment changes (user additions, responsibility modifications) are reviewed by Compliance before implementation.

Ongoing Compliance Maintenance

Read-only licensing requires continuous oversight. Best practices include:

• Quarterly Responsibility Reviews: Run FND_USER_RESP_GROUPS reports quarterly to identify any responsibility changes or new assignments.
• Annual Responsibility Audit: Conduct a full responsibility function audit annually, comparing results to the prior year's baseline.
• User Activity Monitoring: Review database audit trails for any users performing transactional operations. If violations are found, immediately escalate and consider reclassification.
• Customization Tracking: Maintain an inventory of all custom forms and functions accessible to read-only users. When EBS patches are applied, re-test these customizations to confirm read-only enforcement remains intact.
• Support and Patch Coordination: Work with Oracle Support during patching cycles to ensure no responsibility or form changes inadvertently expose transactional functions to read-only users.

Module-Specific Guidance

Financials Module (GL, AP, AR, FA)

The Financials module offers the broadest read-only support. Users accessing General Ledger, Accounts Payable, Accounts Receivable, and Fixed Assets for inquiry and reporting can be classified as read-only if their responsibility profiles restrict them to inquiry, report submission, and analytical access. Key responsibilities for read-only classification include: "GL Inquiry Responsibility," "AP Inquiry Responsibility," and "AR Inquiry Responsibility."

Purchasing and Inventory

Purchasing and Inventory also support read-only classifications for users performing procurement analysis, stock-level inquiries, and purchase order reporting. However, the moment a user requires approval authority or the ability to receipt goods, they require full Application User licensing.

Order Management and Order Fulfillment

Order Management has limited read-only support. Sales order inquiry users may qualify for read-only status, but order fulfillment (picking, packing, shipping) typically requires full Application User licensing due to the transactional nature of those operations.

Oracle License Agreement Considerations

Read-only user licensing differs based on the Oracle License Agreement type in force:

• ULA (Unlimited License Agreement): Once a ULA is signed, the organization has unlimited use of licensed products. Read-only reclassification does not reduce ULA cost; however, it supports defensibility in audits and demonstrates licensing discipline.
• PULA (Perpetual Unique License Agreement): PULAs are perpetual licences with annual support fees. Read-only reclassification directly reduces ongoing support obligations and defends against Oracle's retroactive uplift claims.
• OCS (Oracle Cloud Services): OCS is Oracle's on-premises subscription model. OCS contracts often allow user-count flexibility; reclassifying to read-only can reduce user counts and qualify for renewal discounts.
• CSI (Cloud Software Subscriptions): CSI contracts vary; review your specific CSI agreement to confirm read-only classification is recognized.

Organizations operating under ULAs should still pursue read-only reclassification for defensibility, even if it does not immediately reduce costs.

On-Premises vs. Cloud Considerations

Oracle EBS read-only user licensing applies only to on-premises EBS environments. Organizations running Oracle Cloud ERP (the SaaS replacement for EBS) operate under a different subscription licensing model that does not recognize read-only user metrics. Users in Oracle Cloud ERP are licensed based on application access type (e.g., Standard User, Functional User, Read-Only User) under a distinct commercial structure.

For on-premises EBS environments, read-only licensing remains a critical cost optimization avenue. For EBS-to-Cloud migration projects, organizations should anticipate different licensing costs post-migration and budget accordingly.

Negotiation and Audit Resolution

If an Oracle audit disputes read-only classifications, organizations should:

1. Provide Documentation: Submit responsibility matrices, function lists, form configuration screenshots, and governance sign-offs demonstrating read-only intent and enforcement.
2. Reference Oracle Licensing Terms: Cite Oracle's own licensing agreement definitions of read-only users and the specific Oracle metrics applied to your EBS version.
3. Offer Technical Validation: Propose that Oracle's technical team re-test the responsibility profiles and form configurations to confirm read-only enforcement.
4. Engage Licensing Counsel: If disputes persist, escalate to Oracle's licensing negotiation team and consider engaging third-party licensing advisors (such as Redress Compliance) to mediate resolution.

Key Takeaways

Read-only user licensing in Oracle EBS represents a legitimate, material cost optimization opportunity for organizations maintaining on-premises E-Business Suite installations. The combination of lower upfront licence costs (50–80% savings) and reduced annual support fees (22% of licence value, increasing 8% annually) creates substantial financial impact over a multi-year period.

However, read-only status is not self-declared. Oracle's licensing model audits responsibility profiles for transactional capability, not user intent. Qualification requires documented evidence that responsibility profiles exclude all data creation, modification, and deletion functions. Organizations must conduct responsibility audits, validate form configurations, document governance approval, and maintain ongoing compliance oversight.

Oracle LMS auditors specifically target read-only user claims, viewing them as high-risk for under-licensing. The most effective defense is proactive, transparent documentation of responsibility analysis and read-only enforcement—conducted before an audit begins, not in response to audit findings.

For organizations currently claiming read-only status without formal responsibility audits, the time to remediate is now. For organizations with properly classified read-only users, the investment in ongoing compliance review pays dividends through defensible audit positions and reduced licensing obligations.