PeopleSoft Licensing and Oracle Audit Exposure

How is PeopleSoft licensed?

PeopleSoft is licensed by application named users, where each individual authorized to use a PeopleSoft module holds a license whether they use it heavily or rarely. As with other Oracle applications, the count is of authorized people rather than active sessions, so dormant accounts and leavers who were never removed sit inside the licensable figure. The same named user discipline that governs E Business Suite applies here, and it is the first of two exposures a PeopleSoft deployment carries.

The broader compliance framework, including how application and database metrics interact, is set out in the Oracle license compliance guide. PeopleSoft is worth treating carefully because the second exposure, the database, is the one teams most often miss.

Why does PeopleSoft carry a database exposure too?

PeopleSoft carries a database exposure because the application stores its data in an Oracle Database that must be licensed under its own metrics, separate from the application user count. An audit examines both layers, and the database is where the larger number often hides, because Processor licensing on the underlying servers can dwarf the application user count once core factors and any enabled options are taken into account. A team that has carefully counted its PeopleSoft users but never checked the database licensing has only solved half the problem.

The database layer brings the full set of database risks with it: processor counting, options enabled by accident, and virtualization claims if the database runs on VMware or similar. These are the same mechanisms examined across the application estate in EBS in an Oracle audit, and they apply just as forcefully under PeopleSoft.

Is the PeopleSoft database full use or restricted?

Whether the database is full use or restricted is contract dependent, because some PeopleSoft agreements bundle a restricted use database license that may only be used to support the application, while others sit on full use database entitlements. This distinction changes everything about the database exposure. A restricted use license that is being used for purposes outside the application creates a finding, and a full use entitlement carries no such limit but must be counted against actual deployment. The only way to know which you hold is to read the ordering documents against your Oracle Master Agreement.

Getting this wrong in either direction is costly. Assuming restricted when you hold full use means you may over license, while assuming full use when you hold restricted means you may be using the database in ways your entitlement does not permit. Confirm the entitlement type before you count anything.

A worked example of the two exposures

Consider a PeopleSoft HR deployment with 900 authorized application users, cleaned to 620 genuine named users after removing leavers and duplicates. The application runs on a database hosted on two sixteen core x86 servers, which under the 0.5 core factor licenses as sixteen Processor licenses. The audit checks the 620 application users and the sixteen database Processor licenses as two distinct lines, and a shortfall in either produces a separate finding.

How do you reconcile both layers?

You reconcile both layers by counting the application named users after a clean of leavers and duplicates, counting the database independently under its own metrics, and confirming the database entitlement type against your agreement, so neither exposure is left unexamined. The application count follows the same discipline described in EBS user metrics and counting rules. The database count brings in processor and options checks. Done together, the two reconciliations give you a complete and defensible PeopleSoft position rather than half of one.

Your next step

A PeopleSoft deployment counted on only one layer leaves an exposure open for an auditor to find. An independent buyer side review counts the application users and the database separately, confirms the entitlement type, and reports the lowest defensible figure for both. Read the pillar guide for the full compliance framework.