The number moved and no row explained it

Here is a failure that is almost impossible to notice from the floor. A manager opens somebody's profile and the hours for the month read eight higher than they did yesterday. They go to the timesheet to find the extra shift. It is not there. Not archived, not pending approval, not under another date — not there.

Nobody has made a mistake. The two screens are answering different questions, and only one of them is filtered the way you would assume.

Two screens, two questions

A timesheet list is normally scoped by venue: show me the cards belonging to this kitchen. That is the right rule for a list — a hall with nine traders in it should not have one trader reading another's rota.

A profile total is scoped by person: add up every hour this individual worked. Also right, and for a good reason. Somebody who covered a Saturday at the unit next door still worked those hours and still gets paid for them, so a total that quietly dropped them would short somebody's wages.

Both rules are defensible. Put them side by side and you get a number that can move for a reason the screen beside it cannot show you.

Why this is worth your attention

We found this in our own product, on the route that creates a timecard. It named the person in the body of the request rather than in the address, and every other route in that file checked whose employee you were touching while that one did not. So a card could be written against somebody at another business, charged to the venue of whoever wrote it. Their hours went up. Their employer's own timesheet showed nothing, because the row was filed under somebody else's kitchen.

The hours fed the figure that pay is calculated from. There was no status filter on that sum either, so an unapproved card counted exactly like an approved one. It is fixed, and it is the kind of fix that has to be tested by actually trying the thing rather than reading the code: we wrote the attack, got a success, applied the check, got a refusal, then removed the check again to make sure the test complained.

What to do when a figure moves unexplained

Do not reconcile it in your head. Three questions, in this order.

What exactly is each number counting? Not what the label says — what the report is filtered by. Per venue, per person, per company, per date range, and on which date: the shift's date or the date it was entered.

Is anything excluded from the list that is included in the total? This is the specific trap. Approval states, archived rows, rows belonging to another site, rows outside the window the list defaults to. A list with a default filter and a total without one will always eventually disagree.

Can you make the number move on purpose? Add one known card and watch both screens. If the total moves and the list does not, you have found the boundary, and you now know which screen to trust.

The general shape

A list and a total on the same subject should be derived from the same filter, or the screen should say out loud that they are not. "Hours worked at this venue" and "hours worked" are both useful figures, and neither is wrong — but if your profile shows one and your timesheet shows the other, and both are labelled hours, somebody will one day pay a wage bill they cannot reconstruct.

If you run payroll off a screen, it is worth asking your supplier which filter is on it. Not whether it is correct. Which filter.