Raise everybody after the appraisal

"The appraisal is finished. Now the four-star people get twelve percent and a two-month bonus, the three-star people get eight percent and one month, and everybody's new salary starts from July."

What is really being asked

Two different things that the client thinks of as one: a bonus paid once, and a new monthly salary. The system handles those two very differently, and the honest headline is this:

Only the bonus half of the increment matrix is live. The increment percentage is recorded and read by nothing. Nothing raises anybody's salary by itself, and nothing writes a revised salary onto the payroll.

So the plan is: configure the matrix for the bonus, let the payout run the bonus, and do the salary increase deliberately by hand. Read this page before you promise the client an automatic increment.

What you need in place first

• A completed appraisal: sheets scored, and Calibration finished if the client calibrates. Calibration settles the scores; it is not an input to any payout arithmetic.
• Evaluation Increment Matrix - the score bands.
• Wage Type - an earning wage type for the bonus, direction Debit, indicator Earning. See an amount must print on the payslip but not be deducted for what the directions do.
• Recurring Payments and Deductions - because the new salary ends up here, typed.

Do this

1. Build the increment matrix. Open Evaluation Increment Matrix and add one line per score band. The bands sit on the 0 to 5 axis, which is the scale the appraisal produces, so they are expressed in score points, not percentages.

   A matrix line is a band, never a person. Nobody is named on this screen and nobody can be. Who the matrix applies to comes from the population on Performance Target Entity.

   Score from	Score to	Bonus % of basic
   4.50	5.00	200
   3.50	4.49	100
   2.50	3.49	50
   0.00	2.49	0

   The percentages in this table are an example. Take the real ones from the client's policy.

2. Fill only the fields that are live, and tell the client which the others are. On the matrix, the bonus percentage is read. These are not:

   • The increment percentage, from and to
   • The bonus-eligible tick
   • The promotion-eligible tick
   • The role placement
   • The maximum salary, or salary cap
   • The increment range and the target reference

   Every one of them is recorded and acted on by nothing. Some no longer exist in the system at all although a stale label still shows on the screen. Fill them if the client wants the policy documented in one place - that has real value - but never say they will do anything, and never build a client's increment process on them.

3. Run the payout for the bonus. Open Performance Payout for the cycle. It takes each man's settled score, finds the band it falls in, and computes the bonus from his basic salary and that band's percentage.

   Name the wage type the bonus is to be posted to. Then set the status to Approved or Posted.

   Both conditions matter. The payout writes its one-off payment document only when the status is Approved or Posted and a posted wage type is named. Either one missing means the figures sit on the screen and no money moves, with no warning that anything is outstanding.

4. Check the payment document it created. It is an ordinary Employee Additional Payment Or Deduction document, dated to one period, which is what makes the bonus pay once. You do not create it by hand. See a bonus is paid once, in one month only.

   If you have to correct something, know that moving the payout's status back deletes that document again. That is the clean way to undo a payout: move the status back, fix, and re-approve. Do not delete the payment document and leave the payout approved, or the next status change will have nothing to remove and the two screens will disagree.

5. Record the salary revision. Open Salary Revision, one line per man, with the old salary, the new salary and the effective date of 01-Jul-2026.

   Now the part to read twice: this screen writes nothing to any other screen. Its "Applied to Payroll" mark is a flag somebody ticks, not an action. Ticking it does not change a salary, does not reach the payroll, and does not reach the man's recurring salary record. It is a register of decisions.

6. Enter each new salary by hand on the recurring salary record. Open Recurring Payments and Deductions for each man, close the current line at 30-Jun-2026 and open a new one from 01-Jul-2026 at the revised figure.

   This is real work for five hundred men and there is no bulk route to it. Budget for it in the implementation plan rather than discovering it on the thirtieth of June. Then tick "Applied to Payroll" on the revision as your own record that the typing is done, which is the one honest use of that flag.

7. Run Payroll unposted for July and check a sample of revised salaries before anybody posts.

What cannot be done, plainly

Put this list in the implementation document and get it signed.

• Nothing raises a salary automatically. Not the matrix, not the payout, not the revision screen.
• The increment percentage on the matrix is not read by anything. If the client wants the system to compute a twelve percent rise, it cannot.
• The salary cap is not enforced. A revision above a grade's maximum is accepted silently.
• Promotion eligibility and role placement are recorded and read by nothing. A promotion is done on the Employee Organization Assignment by hand.
• Calibration is not a payout input. It settles the score that the payout then reads; it does not adjust money.

Where two clients differ

	Bonus	Salary increment
Is it computed	Yes, from the matrix band	No
Which screen does it	Performance Payout	You, by hand
What it writes	A one-period payment document	Nothing
Based on	Basic salary times the band percentage	The client's own working
What makes it happen	Status Approved or Posted, plus a wage type	Typing on the recurring salary record
Effort for 500 men	Minutes	Days

How you prove it worked

1. On Performance Payout, take one man, read his score, find his band on the matrix, and work the bonus out from his basic salary on paper. Compare. See the maths.
2. Confirm the payment document exists, is dated to one period, and carries the wage type you named. No document means the status or the wage type is missing.
3. Move the payout status back and confirm the document is gone. Then re-approve and confirm it returns. That round trip is the proof you can correct a mistake safely.
4. Run Payroll unposted and check the bonus appears once, on the right people, in the right period.
5. For the increment: count the men on the salary revision list and count the recurring salary records you have changed. Those two numbers must match, and nothing in the system will tell you when they do not. Check it before the July run, not after.
6. Run July unposted and compare one revised man's basic against the revision line to the rupee.

What will go wrong

• Everybody waits for the salaries to change by themselves. July is paid at the old rate for five hundred people, and the arrears land in August. The whole reason this page exists.
• The payout is left at a draft status, or no wage type is named, and no bonus document is created. Nothing warns anybody, so check for the document rather than trusting the screen.
• The increment percentage is filled in and demonstrated to the client as though it did something. It does not. Say so in the first workshop.
• The bonus payment document is deleted by hand while the payout stays approved. The two screens now disagree and the next status change cannot clean up. Always undo from the payout.
• "Applied to Payroll" is ticked before the typing is done, usually as a plan rather than a record. Then nobody knows which salaries are in and which are not. Tick it only after the recurring salary record is changed.
• A revision is entered above the grade maximum. Nothing stops it. If the client cares about caps, someone has to check them by eye.