Start with the ordering document

Pull the entitlement list out of your Oracle ordering documents before you open a single report in the application. Not the module list the platform team keeps in a spreadsheet, and not what a sales rep summarised on a slide last quarter. The signed lines, with the metric and the quantity beside each one. On the last four Fusion Cloud ERP renewals I sat in, the finance lead and the ERP lead gave different answers about what was licensed, and neither answer matched the paperwork.

That list becomes your working sheet. One row per licensed line, the metric in the next column, hosted employee count or user count or whatever Oracle actually wrote, then the quantity. Leave three columns empty for the numbers you are about to go find. Everything after this point is about filling them with evidence instead of opinion.

Do this eight to ten months before the renewal date. Nine weeks out you are reacting to a quote someone else wrote. With most of a year you can run a full usage read, let the business units argue about it, and still have time to decide what you want. The same timing logic runs through how a multi-year renewal gets negotiated, and the usage evidence is what gives that conversation a floor.

Role assignments accumulate, sign-ins do not

The most common mistake I see is pulling the security report, counting how many people hold a role in a module, and calling that adoption. Role assignments pile up over years. They get bulk-loaded during implementation, copied into provisioning rules for new hires, inherited from a job role someone cloned in 2022 and never revisited. A count of assignments tells you what somebody once intended.

Go to login activity instead. Schedule the Import User Login History process so the data is populated at all, then run the Inactive Users Report over a rolling window. You want the last sign-in date per user, joined back to which module-specific roles that user holds. If a buyer has held Procurement Contracts Administrator for two years and last signed in to anything in March, the role means nothing.

Then go one level deeper, into transaction volume. OTBI subject areas will give you row counts per module over time. Count the objects that only exist because the module exists. Contracts created and amended. Supplier negotiations awarded. Project expenditure items costed. Asset additions posted. A module with fourteen transactions in eighteen months sits in a different category from one with fourteen thousand, and that distinction carries the same discipline behind what an unused license actually costs you, applied one module at a time.

Seasonal use is still use

The fastest way to embarrass yourself in front of a business owner is to declare a module dead because your sampling window was ninety days. Fixed Assets gets hammered at year end and then sits quiet for months. Statutory tax reporting runs on a calendar that has nothing to do with your review.

Pull eighteen months rather than one quarter, and plot volume by month instead of totalling it. The shape gives you the answer faster than the sum does. A flat line at zero across eighteen months means unused. Two tall spikes in January and July mean a module doing exactly what it was bought to do, on a schedule that missed your window.

Flag every seasonal module in the sheet with the month it peaks and the name of the person who runs that cycle. When somebody asks in the renewal meeting why you are keeping a module that four people touch, you want the answer ready in one breath. Four people touch it, they close the statutory books with it, and here is their calendar.

The bundle modules nobody ever implemented

There is a separate category, and it usually holds the real money. These are modules that arrived attached to a larger purchase, got an implementation phase on a roadmap slide, and then lost the funding fight to something louder. They show no usage because they have no configuration. No approval hierarchy, no business unit assignment, no integration, nothing.

They are easy to confirm once you look for the right signal. Check whether the setup tasks in the Functional Setup Manager offering were ever completed. Check whether any implementation project for that module ever closed a phase. Check the enterprise structures. An offering nobody opened in FSM has never been live, and no volume of role assignment changes that reading.

These modules survive renewal after renewal because nobody wants to say out loud that the project died. Every organisation I have worked with carries two or three of them, and an honest version of this exercise produces a retirement list alongside the renewal position.

Four hundred users on a module with one pilot

The clearest example I have run into came from a mid-size manufacturer. They bought Procurement Contracts as part of a 2023 bundle, sitting next to a Sourcing and Supplier Qualification expansion. The contracts module went live in one pilot business unit, a European division with about thirty buyers, and stopped there when the programme director left.

Three years later the entitlement line still carried four hundred users. Login history showed 27 people had ever authenticated into a Procurement Contracts task, every one of them in that division. Contract volume across eighteen months came to 312 records, and 289 of those arrived in a single migration load rather than from anyone doing work. The other 373 licensed users had never opened it. Not lapsed. Never.

Nobody concluded the module was worthless. The pilot division liked it and had a defensible case for keeping about thirty-five seats. What the data showed was a company paying for a rollout that never happened, and renewing twice without anyone putting those two numbers on the same page.

Turning a finding into a renewal position

Cancellation is rarely the right ask and often not available anyway. Oracle sells term subscriptions with quantities you can usually adjust at renewal and almost never in the middle of a term. The question you are really preparing for is what you want in exchange for 373 seats you can prove nobody used.

Three outcomes I have seen land. Reduce the quantity on the unused line while holding price on the lines you depend on. Trade the unused seats toward a module you genuinely want next year, after you have made the vendor prove it on your data. Or convert the shelfware into funded enablement with a committed go-live date and a checkpoint on the calendar. Any of those beats walking in with a general complaint about cost.

Write the finding per module in a short paragraph, giving the entitled quantity, then the measured usage with the exact window and the report it came from, then what you want. The part people skip after that is the internal conversation. Take the numbers to each module owner before the vendor meeting and let them challenge you. Half the time they will tell you about a rollout planned for next quarter that changes the picture, and you would much rather hear that from them than in front of the account team. Getting the reading right on your own paperwork, the same care you would bring to reading a licensing change carefully, is what makes the ask hold up under pressure.

So here is the question for your next renewal planning meeting. Can anyone in the room state, from a report rather than from memory, how many people signed into each licensed Fusion module last quarter? If producing that answer takes longer than a week, you have just found the first piece of work.