Oracle EBS Projects Module Licensing Guide

Oracle EBS Projects: Module Structure and Licensing

Oracle Projects is not a single product — it is a family of EBS modules that together provide project management, project costing, project billing, project resource management, and financial reporting for project-driven enterprises. The core modules are Oracle Project Accounting (PA), Oracle Project Costing (PC), Oracle Project Billing (PB), Oracle Project Resource Management (PRM), and Oracle Project Job Costing (PJC). Each is licensed separately, and the distinction between them matters enormously for compliance.

Project Accounting (PA) is the foundational module: it handles project setup, work breakdown structure (WBS), project budgeting, and integration with Oracle General Ledger. Organizations that deploy PA alone — without separate licenses for PC, PB, or PRM — may still need those licenses if the functionality is accessible through PA's user interface. Oracle's position during LMS audits is that installed and accessible functionality requires a license, even if an organization did not intend to license that module separately.

Project Accounting (PA) Licensing

Oracle Project Accounting is the primary licensing vehicle for most organizations using EBS Projects. PA is licensed under the Named User Plus (NUP) metric, with Oracle requiring that all users authorized to access PA-related responsibilities be counted. This includes project managers who create and manage projects, accountants who process project costs and revenue, and any user who runs project-related reports or queries — including read-only roles.

One area of consistent audit exposure is the separation between project administrators (who may only set up project templates and maintain lookups) and active project users (who manage live projects and approve costs). Oracle does not distinguish between these roles for licensing purposes under NUP — both require a license. Organizations that have distributed project administration across multiple departments, with dozens of occasional users who rarely access the system, face the highest risk of under-licensing.

Project Costing (PC) vs. Project Accounting (PA)

A major source of confusion — and audit risk — is the boundary between Project Costing and Project Accounting. In older EBS contracts, Project Costing was a separate SKU distinct from Project Accounting. In later Oracle sales motions and some upgrade negotiations, Oracle consolidated these into broader suite licenses. If your contract was signed or renewed in the R11i era and not renegotiated since, the distinction between PA and PC may still be active in your contract and will be enforced in an audit.

Project Costing handles the collection, validation, and distribution of project costs (timecards, expense reports, supplier invoices charged to projects) to Oracle General Ledger. If your organization uses Oracle Time and Labor integrated with Projects to charge employee time to project accounts, and your contract lists only Project Accounting without Project Costing, you may have an unlicensed deployment. Oracle's USMM script identifies Project Costing module installation and active user responsibilities independently of Project Accounting.

Module	Primary Function	License Metric	Common Audit Finding
Project Accounting (PA)	Project setup, budgeting, WBS, GL integration	Named User Plus	Read-only users not counted
Project Costing (PC)	Cost collection, expense charging, timecard integration	Named User Plus	Deployed but not licensed alongside PA
Project Billing (PB)	Client billing, revenue recognition, invoicing	Named User Plus	Finance users assumed covered under PA
Project Resource Mgmt (PRM)	Resource scheduling, forecasting, utilization	Named User Plus	HR/resource planners not included in project licenses
Project Job Costing (PJC)	Job costing for manufacturing-adjacent projects	Named User Plus	Deployed in mixed manufacturing/projects environments

Project Job Costing (PJC) in Manufacturing Environments

Oracle Project Job Costing (PJC) sits at the intersection of the Projects and Manufacturing module families. It is used primarily in capital projects and engineer-to-order environments where project costs need to be tracked against specific manufacturing jobs. Organizations that run both Oracle Projects and Oracle Discrete Manufacturing need to be particularly careful about PJC — it is frequently deployed as part of initial implementations at manufacturing companies but overlooked in license reviews because it appears to be a subcomponent of either Projects or Manufacturing, when in fact it requires its own license entitlement.

For Oracle license optimization, organizations running PJC should specifically audit who has active responsibilities tied to PJC versus standard Project Costing functions. In many cases, the user populations overlap substantially, and rationalizing responsibilities can reduce the apparent license gap while maintaining operational functionality.

User Counting for Oracle Projects Modules

The NUP metric for Oracle Projects creates compliance risk in several specific user categories that organizations consistently undercount. Project managers are the obvious licensed users, but the following populations are equally required to be licensed and equally likely to be missed:

• Timecard submitters — employees who submit project time via Oracle Time and Labor that integrates with Projects. Oracle treats these users as Project Costing users even if they never directly access the Projects module.
• Expense report submitters — employees who submit expense reports charged to project accounts via Oracle Internet Expenses. Same logic applies.
• Project approvers — managers who approve project costs, budgets, or timecards in a workflow capacity are considered licensed users of the relevant Projects modules.
• Finance and accounting staff — users who run project-to-GL reconciliation reports or post project journal entries are considered Project Accounting users.
• Report-only users — users with access to Oracle Applications reporting tools (Oracle Discoverer, OTBI, or custom Oracle Reports) who run project-related reports. Oracle considers these users as having access to the underlying module.

This breadth of user populations means that a mid-size professional services firm with 500 employees and a Projects deployment may have licensing obligations that extend well beyond the 20–30 core project accountants who use the system daily. The true licensed population often reaches 150–250 users once timecard submitters and expense filers are included.

Oracle Projects and Integrated Timekeeping Systems

Many organizations use third-party time tracking systems (Kronos, SAP Time, or standalone web applications) that feed time data into Oracle Projects via integration. Oracle's position on these integrations has evolved through various audits — generally, Oracle does not require users of third-party systems to hold Oracle Projects licenses unless they also directly access the Oracle Projects UI or have Oracle responsibilities assigned. However, the integration boundary must be clearly documented and demonstrable during an audit.

If your organization uses Oracle Time and Labor (a separately licensed EBS module) to capture time and route it to Projects, every OTL user who charges time to projects is considered a Projects Costing user for licensing purposes. Organizations that did not originally license OTL and Projects together, but later integrated them through an implementation project, frequently have unlicensed OTL users showing up in LMS audit data. Review our Oracle EBS licensing guide for detailed guidance on how integrated module deployments affect license counts.

Audit Preparation for Oracle EBS Projects

If your organization receives an Oracle LMS audit notification and you are running EBS Projects, the immediate priority is to run an internal assessment before Oracle deploys the USMM script. Key steps include: identifying all active Oracle user accounts with Projects-related responsibilities, mapping those responsibilities to specific Projects modules (PA, PC, PB, PRM, PJC), comparing the resulting list against your Oracle contract to identify coverage gaps, and reviewing integration points that may extend the licensed user population.

Our Oracle compliance review service includes a full EBS Projects module assessment as a standard deliverable. We use the same discovery approach Oracle's LMS team uses — because our advisors ran those LMS engagements — and deliver a clear gap analysis that lets you remediate compliance issues on your own timeline, before Oracle formalizes its findings.

For additional context on managing LMS audit risk across the full EBS platform, explore our Oracle licensing white papers. Not affiliated with Oracle Corporation — all analysis is independent and entirely buyer-side.

Reducing Oracle Projects License Costs

The most effective license reduction levers for Oracle Projects are responsibility rationalization, integration architecture review, and suite contract consolidation. Responsibility rationalization involves systematically removing Oracle user responsibilities that are no longer needed — common after organizational restructuring, system upgrades, or when employees change roles. Many EBS environments accumulate years of unused responsibilities that inflate audit exposure without delivering business value.

Integration architecture review focuses on whether third-party integrations are feeding data into Oracle Projects in a way that triggers license obligations. In some cases, redesigning integration flows to use Oracle-side service accounts rather than individual user sessions can reduce the user population that Oracle considers licensable. This requires careful design review and contractual verification, but can produce meaningful cost savings over a full NUP license population. Contact our team for a confidential Oracle EBS Projects license assessment.