Turning MOU language into HR system rules: seniority, bidding, premiums

Reference article · 5 min read

A memorandum of understanding is written to settle a negotiation, not to configure software. It uses terms of art, cross-references other articles, and leaves some points deliberately unsettled. An HR or timekeeping system needs the opposite: testable conditions, a defined order of operations, and one answer for every case. Most of the difficulty in a workforce system build lives in that gap.

Closing it is not a matter of reading the contract faster. It takes a written rule inventory that sits between the agreement and the configuration, cites the article and section behind every rule, and gets reviewed, approved, tested, and versioned as settlements land.

Build the rule inventory before anyone configures anything

Work through each agreement article by article and record every statement that changes a number, a date, an order, or a notice. Keep one row per rule, with at least:

• Citation. Agreement, unit, article and section, and effective dates. If the rule actually comes from a side letter, settlement, arbitration award, or documented past practice, cite that.
• Population. Unit, classifications, locations, and employment statuses covered. Many disputes are scope disputes, not math disputes.
• Trigger and effect. The condition stated so it can be tested, and the rate, hours, accrual, bid order, or notification it produces.
• Precedence. What happens when two rules both apply, including whether premiums stack or the higher one controls.
• System owner. Which system holds the rule: HRIS, timekeeping, scheduling, payroll, or a manual process with a documented control.

Two disciplines matter more than the template: every rule traces to text someone can open, and every rule has a named owner in HR or labor relations who confirms it.

Seniority is rarely one field

Agreements often define several seniority clocks: total service, classification, department, and unit seniority, each with its own treatment of breaks in service, unpaid leave, part-time work, and transfer. Layoff, shift bidding, vacation selection, and overtime distribution may each use a different clock and a different tie-breaker.

List every seniority date the agreement implies, the events that adjust it, the exact tie-breaker, and how an error found years later gets corrected. A system that stores one generic seniority date and reuses it everywhere is quietly wrong in exactly the situations that produce grievances.

Bidding, notification, and premium stacking

Bid rules are procedures, not values, and easy to configure halfway. For each bid type, capture eligibility, order, posting or notice period, how long an employee has to respond, what happens when they do not, and whether a pass counts as a decline. Notification requirements deserve their own rows: a posting window or required advance notice is an enforceable term, and the evidence has to come out of the system.

Premiums and differentials need an explicit calculation order: the base each one applies to, whether it covers all hours or only hours worked in the condition, whether it counts toward overtime, and whether two can apply at once. Federal wage and hour law generally requires nondiscretionary premiums and shift differentials to be reflected in the regular rate used for overtime, and it treats certain law enforcement and fire protection work differently. These rules interact with state law and with the agreement itself, and they change, so treat the interaction as a question for counsel, not an analyst's configuration choice.

When language is ambiguous or two units differ

Ambiguity is normal. An analyst resolving it silently inside a configuration screen is not. Route each ambiguous rule through a short written interpretation request to labor relations, and record the answer, the date, and who gave it. If the parties do not agree, configure the interpretation that has actually been applied, flag the rule as disputed, and keep the result reportable and reversible so a later resolution can be applied cleanly.

When two units are treated differently for the same task, resist the urge to normalize. Keep the rules separate and attributed to their own agreements, even when that means near-duplicate configuration. A merged rule loses its citation.

Getting mid-contract changes and side letters in

Settlements arrive in bulk and often apply retroactively. Establish a standing intake rather than handling each as an emergency:

1. Labor relations sends every executed agreement, side letter, and settlement to a named intake point, including documents that look purely administrative.
2. Someone maps it to affected rows in the inventory and drafts the change, noting effective dates and whether retroactive recalculation is required.
3. It is built in a test environment and validated against sample employees spanning the affected classifications and schedules.
4. HR, payroll, and labor relations sign off on the results before production, and the inventory is versioned so any past pay period can be explained with the rules in effect then.

Test with hard cases rather than clean ones: an employee who changes classification mid-period, one on intermittent leave, one working out of class on a holiday callback.

What to ask vendors and put in the contract

• Ask how the product expresses conditional pay and bid rules: configuration, a rules engine, or custom code, and who can change each without a software release.
• Ask for a live demonstration of retroactive recalculation across a period with overtime and premiums, and how prior-period results are reproduced after a rule changes.
• Require configuration against your rule inventory, acceptance tied to your test cases rather than generic demonstrations, and an exportable listing of configured rules staff can compare to contract text without vendor help.
• Require a defined turnaround for negotiated changes, and confirm in writing whether that work is included or billable.

HQT works with state and local agencies on requirements definition and software for workforce systems where contract terms have to become rules a system can enforce.

Frequently asked questions