Home/Field Notes/Payroll
Payroll 031

A Fast Formula Worked Example: Shift Premium Done Cleanly

Enough theory. Here's a real shift-premium formula pattern, why each part exists, and the trap that catches most people.

Let me show you a real one instead of hand-waving here. A shift premium: workers on nights get an extra percentage on their base rate. Sounds trivial, and the naive version breaks the first time someone changes rate mid-period.

Pull the inputs, don't hard-code them

The formula reads the base rate and the premium percentage as database items or inputs, never baked-in numbers. Hard-code 15% and you're editing the formula every time the union renegotiates. Read it from a value set and a single change updates everything.

Guard against the null

Every database item you fetch can come back empty, a new starter, a missing assignment detail. A formula that doesn't default its inputs will error mid-run and halt the payroll. One DEFAULT_DATA_VALUE line per input saves a 2am panic.

Return, don't calculate downstream

The formula's job is to return the premium amount as a clean result the element consumes. Keep the logic in the formula, keep the plumbing in the element. Muddle the two and nobody can trace where a number came from.

Real scenario: a client's shift formula hard-coded the rate and had no null handling. A mid-month pay rise plus one new starter with a blank field took the whole payroll run down. We rewrote it, inputs read from a value set, every fetch defaulted. Never fell over again. Simple discipline, but it's the discipline that keeps wages landing on time.

Facing this on a live programme? I work directly with client teams on Cloud HCM architecture, payroll and integration delivery.

Book a consultation