By Mo Hussein

3 min read

On 3 October 2026 we found out that Templio, the timesheet and invoicing app we built for recruitment agencies, could overcharge day rates by up to 4p a day. A £475 day rate came out as £475.04. Over a five-day week that's £2,375.20 against the £2,375.00 everyone had agreed.

Four pence is nothing, until a client's finance team spots it and starts checking every other line. It was also one of five bugs in the money code that day, and every one of them had passed our tests.

How we found them

Our test suite was green the whole time. What found the bugs was a stress test: 24 awkward situations an agency could plausibly hit, from a lost reply from Xero to a night shift over the clock change. We read the code against each one and marked it fine, partly covered, or a suspected bug.

Eight came back as suspected bugs. Five were real, and three of those were serious.

The five bugs

  • Credit and reissue that didn't reissue. Crediting a client's invoice also credited the contractor's self-bill in full, so their pay could drop to £0 with no warning. The button promised a reissue that never happened, and the system then blocked regenerating the bill.
  • The lost reply. If Xero created an invoice but its reply never reached us, the retry hit a duplicate invoice number and stopped. That left a draft sitting in Xero while an admin could still email the client a second copy.
  • The stale approval. A manager could open a page of hours to approve, someone could change those hours in the meantime, and the approval went through on the new numbers. The manager saw 40 hours and approved 60.
  • The clock change. A 22:00 to 06:00 night shift was always counted as 8 hours. On the night the clocks go forward it's 7, and on the night they go back it's 9.
  • The day rate. Day rates were turned into an hourly rate and rounded, which is where the 4p came from.

Why the tests didn't catch them

Most of our tests checked one piece of code at a time, with the database swapped for a stand-in, and the end-to-end tests followed the happy path. So the tests confirmed what we already believed the code did. None of them lost a reply halfway, changed hours while someone else was approving them, or ran a shift across a clock change.

Every one of these bugs had also been through code review, which is the uncomfortable part. A test written by the person who wrote the code tends to share their blind spots.

What we changed

Each fix started with a test that failed on the bug, then the change that made it pass. Day-rate lines are now priced as days times the day rate, with no hourly step. Shift lengths are worked out in UK time, so a shift over the clock change gets its real length. An approval is tied to the exact version of the hours the manager saw. Crediting a client invoice now credits only that invoice and leaves the contractor's pay alone.

All of it was live the same evening. Before the one database change went to production, we took a snapshot so we could roll back if we had to.

What to ask your developer

If you're paying for software that touches pay, invoices or money owed, your own awkward cases are the best test plan you have. Write them down in plain English:

  • What happens if the accounting system takes the invoice but the confirmation never comes back?
  • What if someone edits the numbers while someone else is approving them?
  • What does a night shift over the clock change come to?
  • Does a day rate come out to the penny over a full week?

Then ask to see each one pass, and check that every button does what its label says. A developer who has thought about these will answer quickly. There's more on how we built Templio in our build notes on offline timesheets and the Templio case study.