The 3am payroll

We once shipped a backdated payroll at 3am because a customer in Brazil needed to pay their team.

They were new to Bloccpay, and their pay day had already passed by the time they were set up. Their people were waiting to be paid for a period that was, as far as the system was concerned, in the past. Payroll software is built to look forward. The next pay date is worked out from the last one, deadlines come before pay days, and nothing expects to be asked to pay for yesterday.

That night the job was narrow: get that one payroll out, correctly, for a date that had gone. It went out. Then came the part nobody sees, which is turning a 3am fix into a feature that works for the next customer without me awake to run it.

Making the past a date the system accepts

The first piece was a setting our operations team can use to give a new business a pay date in the past. The rule for reading it is the important part. Before a business’s first payroll, a stored date is used exactly as it is, so a backdated date is honoured. After the first payroll, a stored date counts only if it is a real pay date on the business’s schedule and comes after the last payroll. Anything else is worked out again from the last payroll.

That rule exists because a date in the past is dangerous. Allowed everywhere, it becomes a way to pay a period twice. Allowed only before the first payroll, it does the one thing it was for.

Telling people what is happening

A backdated payroll does not behave like a normal one, so it should not read like one. When the pay date is before today, the system knows the payroll is backdated at approval. The business’s confirmation says it will be processed immediately, not on a date that has gone, and our team is told so someone is watching it.

Letting the business do it themselves

The last step was taking us out of the loop. A new business that has missed a pay day can now see that cycle on its dashboard and run it. I wrote its tests as sentences, because each one is a promise to a customer:

• It offers the cycle before the next payroll, builds exactly that one, and then offers nothing.
• It offers nothing to a business with no payroll schedule, or one that is not approved, and refuses to build.
• It offers nothing once the business has a payroll, and nothing before the missed pay day has come.
• It pays each person in full, pro rata, or nothing, by their start date against the period.
• It builds one payroll when two requests arrive at once, and refuses the second.
• It lets a viewer see the cycle but not run it, and shows a stranger nothing.
• It puts the schedule back when there turns out to be nothing to pay.

The two-requests test is the one I care about most. A nervous business owner double-clicks. Two tabs are open. Without that test, a backdated payroll is a way to pay a team twice.

Replaying three years of nights

Dates are where payroll bugs hide, so I stopped trusting single examples. I wrote a test that replays the nightly payroll job over three years, across 120 schedules, with the same rule the database has: one payroll per business per date. Among the cases it holds is one we found the hard way: a schedule paying twice a month on the 1st, with Friday payments on, could stop paying altogether. The fix and the replay went in together, and the replay stays in the test suite.

What 3am taught me

The 3am fix served one customer. The work after it serves every customer who joins after their pay day, and none of them will know it was ever hard. That is what I mean by building for people and not just problems. You answer the person in front of you that night. Then you build it so nobody has to be awake the next time.