The Rule Engine

Everything else in a timesheet product can be worked around. The rule engine cannot, and it is the least visible part in a demonstration.

What rules have to express

Overtime by threshold, daily, weekly, or both, with different rates at different bands.

Different thresholds by jurisdiction, agreement, contract type and pay grade — frequently all four at once.

Break rules: paid or unpaid, automatic or recorded, what an interruption does.

Premiums: night, weekend, public holiday, on-call, call-out minimums.

Rest period minimums between shifts and across a week, computed from actuals.

Week boundaries that differ by pay group.

Effective dating, so a rule change applies from a date without repricing history.

The questions that reveal the limits

Can two pay groups have different week start days? A surprising number of products cannot, and it is fatal for a multi-jurisdiction deployment.

Can a rule be effective-dated? Or does changing it recalculate everything?

Can rules be combined, where a night premium and an overtime band both apply? Which takes precedence, and is that configurable?

Who can change a rule — you or their consultant?

Is a rule change logged with a version, and is that version recorded against the entries it affected?

Can a closed period be recalculated under a corrected rule, preserving the original?

Six questions. Ask them with your own awkward rule and require a demonstration rather than an answer.

The discovery problem

Most organisations cannot list their own rules completely.

They live in payroll configuration, collective agreements, individual contracts, and one person's memory.

Do the discovery before evaluation, not during implementation, because the list determines which products are viable.

Expect contradictions, and expect to find rules nobody can justify. Resolving those is an organisational decision and it sits on the critical path.

Where products genuinely differ

Fixed engines handle a common set and nothing else. Cheap, fast to implement, and a hard ceiling.

Configurable engines express most things through settings. The usual middle.

Scriptable engines allow arbitrary logic. Powerful, and every rule becomes code somebody must maintain — which is a maintenance commitment disguised as flexibility.

Match the engine to your rule count. An organisation with four rules does not need a scriptable engine; one with forty cannot use a fixed one.

Testing it

Configure your three hardest rules yourself during the trial.

Run a period through to the export and check the classification per person.

Change one rule mid-period and see what happens to the already-calculated days.

If you cannot configure them without the vendor, that is the answer to how the next three years will go.

Match the engine to the rule count

A fit question rather than a quality one.

Four rules: a fixed engine is fine and will be faster to implement.

Forty rules across three jurisdictions: fixed is impossible, and configurable is the minimum.

Arbitrary logic: scriptable, and accept that every rule becomes code someone must maintain.

Count your rules before evaluating, because the count removes whole categories of product and saves the evaluation effort.

Configure your three hardest rules yourself

The trial task that predicts the next three years.

Not a demonstration of their example. Your rules, by you, in the product.

Run a period through to the export and check the classification per person.

Change one rule mid-period and see what happens to already-calculated days.

If you cannot do it without the vendor, that is the answer to who will be configuring it after go-live and what each change will cost.

Keep workflow logic traceable

External automation can hide another layer of rules. This workflow reference is a useful prompt to document where each transformation occurs.