Roster and cost, one report, both footed

Headcount without cost is a list, and cost without headcount is a total nobody can act on. This report holds both, row by row, and its third view, plan against the HR system, is what keeps the headline number honest.

Note: Workforce, the people-planning part of Planning, Oracle's budgeting and forecasting module, holds a roster of employee-job rows and the money attached to each. This page is the report that ties heads to cost, and keeps both footed.

The whole module is mapped on the Planning index.

RuleKeep requisitions visible as rows, export components as columns, and reconcile the roster to the HR system nightly.

Neverreport compensation as one blended number. The 486.3M is only useful because it decomposes to people and components on demand.

◆ The three views, roster, cost by component, and plan against HR.

The two numbers this report ties together, both footed on the objects page: headcount 4,880, which is 4,806 active plus 74 open requisitions, and total compensation 486.3M across salary, benefits, employer taxes, and additional earnings.

The report's three views
Roster	One row per employee-job with entity, grade, FTE, and status. The 74 requisitions appear as rows with no person yet, which is what makes hiring visible in the plan instead of implied by it.
Cost by component	The same rows with the money as columns: salary, each benefit, each tax, each earning. A benefits increase of 1.2M resolves to the entities and grades that drove it, because the components came through the export as columns, not as one blended number.
Plan against HR	The roster beside the HR system's extract, keyed the same way. Rows in the plan with no person in HR, and people in HR missing from the plan, are the two lists that keep 4,880 honest.

One caution carried from the rules page: loads set Headcount to 1 and the payment factor to 100% unless values were loaded. A roster report is where those silent defaults become visible, one more reason it runs nightly rather than at quarter end.

THE USE CASE, SIMPLIFIED

The problem: Headcount and compensation live on separate screens, and tying a cost change to specific people takes an afternoon.

What we build: The employee-job rows export nightly with every component, salary, benefits, taxes, earnings, as columns.

What you get: The 486.3M explains itself: any cost movement resolves to the people and components that moved it.

Comp variance meetings starting from a blended total?

We export the employee-job rows with every component as a column, nightly, and any cost movement resolves to the people who moved it before the meeting starts.

Talk to us

Terms on this page

requisition rows: Open positions as rows with no person. Hiring made visible.
components as columns: Salary, each benefit, each tax, separately. The decomposition.
the two lists: Plan rows without people, people without plan rows.
nightly: Because silent defaults surface the morning after the load.