Contents
Key takeawaysWhat we have seenHow drift happensWhich metric appliesCounting usersInstallation flagsCustom bolt onsEnvironmentsMaintenance termsHow the audit runsContract terms to ask forKeeping a baselineCostly mistakesThird party supportWhat to do nextFAQPeopleSoft compliance is settled by four reconciliations: users against the contracted metric, enabled modules against the order form, environments against infrastructure terms, and maintenance against the original commercial terms. Run them on a schedule and an audit becomes a discussion of method.
- Drift comes from administration. User stores grow, installation flags get switched on, customizations reach into licensed modules and environments multiply, all without a purchase order.
- The contracted metric decides the count. Application User, Employee and the self service metrics each count a different population, and the audit outcome turns on which one your order form names.
- The raw user table overstates you. An unfiltered PSOPRDEFN extract routinely doubles the count you can support, so document your filters before anyone asks for data.
- Activation flags read as usage. A PS_INSTALLATION flag enabled for an unlicensed product is a finding waiting to be written, even if the product was never used.
- Bolt ons inherit license obligations. A customization that reads or writes a licensed module's records extends that module's user population to everyone the customization serves.
- A documented baseline settles audits faster. A position that is dated, reproducible, filter documented and signed off each quarter shortens audits and settles them for less.
This guide takes each of those reconciliations in the order an Oracle auditor tests them: user profiles against the contracted metric, activated modules against the order form schedule, environments against the infrastructure terms, and maintenance invoices against the original commercial terms. A company that runs all four on a fixed cadence can answer an audit letter from its own files.
The difficulty is that PeopleSoft falls out of compliance through day to day administration. No one buys anything, yet the position degrades every quarter. Read this alongside our PeopleSoft licensing white paper, the PeopleSoft third party support analysis, the Oracle knowledge hub and the Oracle Database licensing guide.
What have we seen in PeopleSoft license reviews in 2024 and 2025?
Metric definitions and module scope drove exposure far more than user growth did. I ran roughly 25 to 35 PeopleSoft compliance reviews in 2024 and 2025, and the risk in each was set by the Oracle PeopleSoft contract terms and by how Oracle License Management Services reads them. Three patterns came up again and again.
- Metric confusion. Mixing up the named user and Employee metrics overstated apparent exposure by 25 to 50 percent before we reconciled it.
- Flags without purchases. Installation flags and separately licensed options showed as enabled in most environments whose owners had never bought them.
- Accidental external users. Customer facing bolt ons had created external user populations that no order form had ever contemplated.
Across that work, the median reduction between Oracle's apparent exposure and the reconciled figure was 44 percent. Nearly all of the drift traced back to the four sources described in the next section.
How an EBS Estate Drifts Out of Compliance
How does a PeopleSoft environment drift out of compliance?
It drifts through four processes that run all the time, and none of them involves buying software. Each is invisible in procurement records and plain to see in system data, which is where an auditor looks first.
The four sources of drift
| Source of drift | Mechanism | Where the audit finds it |
|---|---|---|
| User store accretion | Joiners provisioned, leavers never removed, contractors sharing operator IDs | PSOPRDEFN and role membership tables |
| Module activation | Installation flags enabled during projects and upgrades, never reversed | PS_INSTALLATION product flags |
| Customization reach | Bolt ons reading and writing licensed module records for new populations | Custom pages, component interfaces, integration logs |
| Environment multiplication | Clones, sandboxes and warm standby instances created outside governance | Server inventories and database catalogs |
Every control in the rest of this guide addresses one of these four sources. A compliance program that does not name them is measuring last year's system.
Which license metric governs which PeopleSoft population?
The metric named in your original order form governs, even when Oracle's measurement output assumes a different one. PeopleSoft carries more metric variety than most Oracle applications, and applying the wrong definition can double an exposure or hide one.
The PeopleSoft metric catalog
| Metric | What it counts | Typical modules |
|---|---|---|
| Application User | Individuals authorized in PeopleSoft security with relevant permission lists | FSCM, ELM, CRM, Campus Solutions |
| Employee | The workforce defined in the contract, whether or not they touch the system | HCM core, self service deployments |
| Customer self service user | External customers granted portal access | CRM customer portals |
| Supplier self service user | External suppliers granted portal access | eSupplier Connection, supplier portals |
| Processor or server | Infrastructure running specific components | Integration and batch tiers on older paper |
What the Employee metric sweeps in
The definition in your ordering document controls, and the standard text is broad. It typically counts full time, part time and temporary workers, and it can extend to contractors and agents, for the organization named in the contract.
That last point is where companies get caught. If the contracting entity is the group parent, the count can reach affiliates that never log in, and an acquisition or divestiture changes the number without anyone touching PeopleSoft. Check the definition against the metric definitions in Oracle's applications price list, then against your own corporate tree.
Older PeopleSoft paper still counts
Many customers still hold license agreements signed with PeopleSoft Inc. before the Oracle acquisition, sometimes amended many times since. Those agreements carry their own metric definitions and audit terms. Pull the oldest document that grants each module and read its definitions before you accept the ones in a current Oracle price list.
How do you get to an accurate PeopleSoft user count?
Start from the fact that the raw operator table is not the answer. PSOPRDEFN holds every account ever created: people, service accounts, locked leavers and template users. The count you can stand behind is a filtered, documented subset reconciled to the contracted metric.
Which operator rows count
Oracle's opening position is usually that all of them do, because that is what an unfiltered extract shows. Your position rests on three filters, and each one holds only if it is written down and applied the same way every time.
- Account status. Locked and disabled accounts, and accounts belonging to departed workers, are not authorized users. Deprovision on a contractual clock.
- Real people. Batch, integration and template accounts are not application users, but each one needs a label and an owner, or an auditor will count it.
- Module scoped access. A user counts against the modules their permission lists reach, which you establish by joining the operator, role and permission tables. Department names prove nothing.
Where the data lives in PeopleTools
Every table you need is part of standard PeopleTools security, so your own team can run the extract without Oracle's scripts.
- PSOPRDEFN. One row per user profile. The ACCTLOCK field shows locked accounts, EMPLID links the profile to a worker record, and LASTSIGNONDTTM shows the last sign in.
- PSROLEUSER. Which roles each user profile holds.
- PSROLECLASS. Which permission lists each role grants.
- PSAUTHITEM. Which menus, components and pages each permission list authorizes. This is the table that ties a user to a licensed product.
- PSACCESSLOG. Sign in and sign out history, as far back as your purge policy keeps it. Useful for cleanup decisions, but it measures activity, which the metric does not license.
The reconciliation procedure
- Extract the operator population. PSOPRDEFN joined to PSROLEUSER and the permission list tables, with account status preserved.
- Apply and record the filters. Status, real people and module scope, with the filter logic saved alongside the output.
- Map users to modules. Permission lists to components to licensed products, so every user lands against a contract line.
- Compare to entitlement. Per metric and per module, producing a surplus or gap statement that someone signs.
- Remediate and rerun. Lock what should be locked, fix role drift, and rerun before the numbers go anywhere near Oracle.
Worked example: filtering 18,400 operator rows
Say a company answers an audit data request with a full operator export: 18,400 rows against a 12,000 Application User entitlement. Oracle's draft findings price the 6,400 user difference, and the settlement talk opens at seven figures. The table shows how the same data can reconcile once filtered, with illustrative counts.
| Step | Rows removed | Rows remaining |
|---|---|---|
| Raw PSOPRDEFN export | 0 | 18,400 |
| Locked or disabled profiles (ACCTLOCK set) | 3,650 | 14,750 |
| Open profiles of departed workers, matched on EMPLID | 1,180 | 13,570 |
| Batch, integration and template accounts, each with a named owner | 420 | 13,150 |
| People whose permission lists reach no licensed component | 1,310 | 11,840 |
| Position against entitlement | 160 under |
Nothing about usage changed between the first row and the last. What changed is who controlled the definition of a user, and whether the filters were documented well enough for Oracle to accept them.
What does module activation drift look like, and why does it cost money?
PeopleSoft records which products are enabled in the PS_INSTALLATION table, and a license review reads those flags first. Flags get switched on during implementations, upgrades and testing, and almost no one switches them off again.
The installation table problem
An enabled flag for a product you never licensed does not prove use, but it shifts the burden onto you to prove absence. Transaction tables, configuration data and permission lists then decide the argument.
The control is an annual sweep. Every enabled flag is mapped to an order form line, and every orphan flag is either justified in writing or disabled before it appears in someone else's spreadsheet.
The module audit procedure
- List enabled products from PS_INSTALLATION and the related option flags. In HCM they appear on the Products tab of the Installation Table page, and in FSCM on the Products page of Installation Options.
- Check for substance. Setup tables, business unit configuration and transaction volumes separate an idle flag from a live module.
- Check for access. If permission lists reach a module's components, users are licensable against it regardless of transaction counts.
- Reconcile to the schedule. Every live module to a contract line, and every orphan to a remediation action with a date.
- Mark the modules to drop. Licensed modules with no live use go on the renewal drop list with their evidence attached.
Do custom bolt ons create PeopleSoft license exposure?
Yes, when they touch licensed module records, and this is the least audited corner of most PeopleSoft systems. PeopleTools makes extension easy, and every extension inherits the license obligations of the data it reaches.
Three customization patterns and how a review reads them
- Custom pages over licensed records. A homegrown front end that reads or writes HCM or FSCM tables makes its users users of those modules, whatever the page is called.
- Component interfaces and integrations. Middleware pushing transactions into a licensed module acts for the people who originate them, which can pull an upstream population into scope.
- External facing extensions. A portal exposing PeopleSoft data to customers or suppliers creates an external population that belongs on a self service metric, outside your employee count.
The rule we apply is simple to state and slow to do. Map every customization to the module whose records it touches and the population it serves, then license it or redesign it on purpose. A bolt on that no one has mapped is an exposure someone else will price.
Which PeopleSoft environments carry license risk?
Fewer than the folklore suggests, and often different ones from those most teams watch. Under user and employee metrics, licensed individuals may generally use production and non production alike, so a test instance rarely needs its own application licenses. The risk sits in three places.
Where environment exposure sits
| Exposure | Mechanism | Control |
|---|---|---|
| The stack underneath | Database and middleware under each instance carry their own metrics, often per processor, per environment | Inventory every instance's stack against its own entitlements |
| Restricted use grants | Bundled technology licensed only to run PeopleSoft, such as WebLogic, Tuxedo or the Java runtime, reused over time for other workloads | Check every restricted use line against actual usage |
| Standby and clones | Warm standby running the software, and clones handed to consultants with fresh user populations | Classify each recovery setup on purpose and govern clone creation |
At the application layer the question is who was given access to each clone, and under which metric. The infrastructure question runs through the database licensing guide and the WebLogic support tier guide, because that is where money changes hands per environment.
The same test applies to Java. A Java runtime used only to run PeopleTools falls inside the PeopleSoft grant, while other applications on those servers need their own cover, as our Java licensing reference explains. If the database tier sits under an unlimited agreement, the ULA decision framework covers what happens at certification.
How should PeopleSoft maintenance be managed between audits?
Treat it as a contract with three moving parts: the 22 percent rate on net license value, an annual uplift that has reached 8 percent in recent renewal rounds, and the structure of the line items. Buyers forget the structure, yet it decides how much flexibility they have later.
Three contract points that matter
- Cap the uplift in writing at a low single digit figure for the full term, in the order form rather than in an email.
- Keep or win module level line items. A single bundled maintenance figure turns every future reduction into a full renegotiation, while itemized lines make it a deletion.
- Never let maintenance lapse by accident. Oracle bills reinstatement for the lapsed period at a premium, which turns an administrative miss into a six figure penalty for a large customer. The example below shows how fast it adds up.
Worked example: uplift and lapse on a $3,000,000 license base
Say your PeopleSoft licenses carry a net value of $3,000,000. At 22 percent, annual support is $660,000. The table compares three renewal years at an 8 percent uplift with a cap of 3 percent.
| Renewal year | 8 percent uplift | 3 percent cap |
|---|---|---|
| Year 1 | $712,800 | $679,800 |
| Year 2 | $769,824 | $700,194 |
| Year 3 | $831,410 | $721,200 |
| Three year total | $2,314,034 | $2,101,194 |
The cap is worth $212,840 over three years on this base, before any change in scope.
What a lapse costs
A lapse costs more than any uplift. Oracle's support policies charge a reinstatement fee of 150 percent of the last annual fee, prorated over the lapsed period, and then the next twelve months of support on top.
Six months lapsed on $660,000 means a $495,000 reinstatement fee plus $660,000 of support, or $1,155,000 to return. Our note on dropping Oracle support and reinstatement covers when a deliberate lapse can still make sense.
Why dropping a module is harder than it looks
Itemized lines make a reduction possible, but two rules in Oracle's support policies still apply to what remains.
- Repricing. If you terminate some licenses on an order, Oracle reprices support for the licenses left on that order at current list price minus the standard discount. The new figure cannot exceed what you paid for the whole order before, but it can wipe out most of the saving you expected.
- License sets. All licenses of one program, including its options, must sit at the same support level. You cannot drop support on 3,000 of your 15,000 PeopleSoft Human Resources Employee licenses and keep the other 12,000 supported.
Model the repricing before you announce a drop list. Renewal preparation belongs on the calendar about three quarters before the anniversary, alongside the reconciliations in this guide. The contract renewal strategy guide and our Renewal Program cover the negotiation itself.
What does a PeopleSoft license audit look for?
It looks for evidence in PeopleSoft's own security, installation and instance data, not in interviews or screenshots. An auditor who knows PeopleSoft works from that metadata, and the request list shows which findings are being drafted. If you know the sequence, you can prepare the counter evidence before you need it.
The audit sequence and the response at each stage
| Stage | What Oracle does | Window | Your response |
|---|---|---|---|
| 1. Notice | Audit letter under the agreement's audit clause | Day 0 | Acknowledge, confirm scope in writing, route everything through one owner |
| 2. Data request | Operator extracts, installation flags, environment list | Weeks 4 to 8 | Negotiate format and scope; supply filtered, documented data only |
| 3. Draft findings | Required counts per metric and module | Weeks 8 to 14 | Challenge metric application and filters line by line |
| 4. Commercial proposal | Back support plus a forward commitment, often cloud shaped | Weeks 14 to 20 | Counter on verified numbers; trade forward spend only for real value |
| 5. Settlement | Order form closing the matter | Weeks 20 to 26 | Lock scope release language, caps and line item structure |
What the scripts pull
Expect requests built around operator definitions and role membership, permission list reach, installation and option flags, and instance inventories. Login history is often requested too, although the contracts license authorization rather than activity.
None of that requires broad PeopleTools metadata access or a live connection for Oracle's team. Provide extracts, keep copies of exactly what you provided, and hold the working papers that explain every filter. If the commercial proposal leans toward a subscription move, read our Fusion Cloud Applications guide before you price it.
How to run the response
- One channel. Every document and every question flows through a named owner, with legal visibility from the first day.
- Scope discipline. The audit covers the agreements named in the letter and the entities they bind, and nothing else.
- Your data, your definitions. Supply the filtered position with its method, and keep raw exports in house.
- Independent review before submission. A check of the package by someone on your side often removes findings before they are ever written. Our guide to challenging Oracle audit findings covers the draft stage in detail.
What the audit team will say, and what to say back
| What you will hear | What to say back |
|---|---|
| "Send us the full PSOPRDEFN export and we will do the analysis." | We will send the filtered position with the queries and filter logic, per metric and per module. |
| "The product flag is on, so the module is deployed." | Here are the setup tables, transaction counts and permission list reach for that product. Show us the use. |
| "Your contractors count under the Employee metric." | Show us where our ordering document says so, for the entity named in it. |
| "The integration users make the whole upstream team licensable." | Name the component interface, the records it writes and the people who originate those transactions. |
| "A move to Oracle Cloud would close the findings." | We will discuss cloud separately, after the findings are settled on the numbers. |
Which contract terms reduce PeopleSoft audit exposure?
The terms that help most are the ones that fix definitions and limit scope before anyone measures anything. The standard Oracle audit clause gives 45 days written notice and 30 days to remedy a finding, and it requires you to run Oracle's measurement tools on request. Ask for more than that at every renewal.
- Metric definitions attached to the order. Quote the Employee or Application User definition in full, with the named entity, so a later price list cannot change it.
- Audit scope limited to named agreements and entities. This stops an audit of your PeopleSoft HCM agreement from turning into a review of every Oracle contract you hold.
- Extracts rather than live access. Agree in writing that you supply data files and that Oracle's team gets no system connection.
- Treatment of integration and service accounts. A sentence stating that system accounts are not Application Users removes a recurring argument.
- Itemized maintenance and a written uplift cap. Covered above, and worth restating in the settlement order.
- Release language in any settlement. The closing order should release past use for the programs and period reviewed.
Our note on redlining the Oracle audit clause gives sample wording for each point.
What makes a PeopleSoft compliance baseline hold up in an audit?
It holds up when it is dated, reproducible, documents its filters and carries a signature from someone accountable. A number with those properties forces an auditor to argue method rather than assert findings, and that changes the economics of the whole exercise.
The four records to maintain
- The user position. Filtered counts per metric and module, with the extraction queries and filter logic archived beside the result.
- The module map. Enabled flags, live modules, orphan flags and modules to drop, refreshed annually.
- The customization register. Every bolt on mapped to the modules it touches and the population it serves.
- The environment inventory. Every instance, its stack, its recovery setup and its user population, refreshed at each infrastructure change.
Refresh users quarterly and the rest annually, and always before an audit letter arrives. Our guide to internal Oracle license audits covers how to staff and schedule the work.
Which mistakes cost PeopleSoft customers the most in an audit?
The expensive mistakes happen in the first weeks, when data leaves the building before anyone has checked it.
- Sending the raw operator table. Once Oracle holds an unfiltered export, every filter you apply later looks like a negotiation tactic.
- Disabling flags during the audit. Make configuration changes before a letter arrives. A flag switched off mid audit invites questions about what else changed.
- Answering questions outside the letter's scope. An informal answer about another Oracle product can widen the review.
- Letting maintenance terms ride into the settlement. A bundled support line agreed under audit pressure stays with you for years.
Why running the scripts and truing up is the wrong default
The usual advice is to run Oracle's measurement scripts, accept the output and true up whatever it shows. We disagree. In most of the PeopleSoft reviews behind this guide, the raw output mixed metrics, counted locked and departed accounts, and treated idle installation flags as deployed products.
Script output is evidence to be read against the contracted metric. Reconciling it typically removed a quarter to a half of the apparent exposure before any negotiation began. Nothing in your contract says Oracle must be the party that interprets the data. Hold both sides to the definitions in Oracle's own contract library.
In PeopleSoft, the measurement script opens the conversation and the contract metric closes it.
Where does third party support fit a PeopleSoft contract?
It gives you negotiating weight, and sometimes it becomes the destination. Providers such as Rimini Street and Spinnaker Support price PeopleSoft maintenance at roughly half Oracle's rate, which makes a documented third party scenario useful in every renewal conversation, whether or not you switch.
The trade offs are real: frozen versions, no Oracle patches, and knock on effects across the database and middleware underneath. Our PeopleSoft third party support analysis covers who it suits and who it does not. For the neighboring legacy application, see the Siebel licensing guide.
Support dates do not force a decision. Oracle's published applications support chart shows Premier Support for PeopleSoft 9.2 through at least December 2037, so you can decide to stay or leave on your own calendar and on the numbers.
What to do next
- Find the paper. Original order forms, amendments and the exact metric definitions, before anyone touches system data.
- Run the filtered user reconciliation and archive the queries and filter logic with the result.
- Sweep the installation flags and resolve every orphan: justify it, disable it or license it.
- Build the customization register, mapping each bolt on to the modules it touches and the people it serves.
- Inventory environments and their stacks, including recovery setup and every restricted use grant.
- Set the cadence. Quarterly for users, annual for modules and customizations, and an independent review before anything is shared with Oracle.
- Test your support rate before the next renewal. Our benchmarking work and Benchmark Program compare your PeopleSoft support fees and uplift terms with what similar customers pay. Reconciliation and audit response run through our Oracle services team or a Vendor Shield subscription. Read about us or contact us to talk it through.
Frequently asked questions
Does Oracle still audit PeopleSoft customers?
Yes, actively, under the audit clause in the master agreement or the older PeopleSoft agreement. The audits also serve a sales purpose, because findings convert easily into Oracle Cloud proposals. That is why settlement offers so often arrive with a subscription attached.
How much notice does Oracle give before a PeopleSoft audit?
Under the standard Oracle Master Agreement audit clause, Oracle gives 45 days written notice. Older PeopleSoft Inc. agreements and negotiated amendments can differ, so read the clause in the agreement that actually grants your PeopleSoft licenses before you reply to the letter.
What does an auditor request first in a PeopleSoft audit?
Operator and role extracts, installation and option flags, and an environment list. Each request maps to a finding under construction: population against metric, flags against the order schedule, and instances against the infrastructure terms. Agree the file format and scope before sending any of it.
How should PeopleSoft users be counted for compliance?
Count by the metric in your ordering document, from an extract filtered for account status, real people and module scoped access. Keep the queries with the result. Oracle can argue with a documented filter, but it cannot easily dismiss one that is applied consistently every quarter.
Do custom modules built with PeopleTools need licenses?
A PeopleTools customization needs no license of its own, but it inherits the obligations of the records it touches. If it writes to a licensed module, its users become users of that module. If it faces customers or suppliers, it creates a self service population.
Can we drop PeopleSoft modules to cut maintenance?
Only cleanly when maintenance is itemized per module in the order form. A bundled line has to be renegotiated as a whole. Even with itemized lines, Oracle can reprice the remaining support on that order, so model the result before you give notice.
What happens if PeopleSoft maintenance lapses?
You lose access to patches, fixes and updates from the lapse date. Returning costs a reinstatement fee of 150 percent of the last annual fee, prorated for the gap, plus a new year of support. Let support lapse only as a deliberate decision.
Is third party support realistic for PeopleSoft?
Yes, for stable systems that can accept a frozen release, at roughly half Oracle's rate. Customers who stay with Oracle also benefit from pricing the option, because a documented alternative is what Oracle's renewal team prices against.
How long will Oracle support PeopleSoft?
Oracle's current lifetime support chart lists Premier Support for PeopleSoft 9.2 through at least December 2037, and Oracle has extended that date by a year at a time. The support date is not what should drive your plans, because audit exposure builds up long before any end of support.