Fixing the Cause, Not the Payment
Correcting a wrong payment takes an hour. Correcting what produced it takes ten minutes and is skipped in the relief of having fixed the visible thing.
Nobody elseif the person who does this is away
Correcting a wrong payment takes an hour and produces visible relief. Correcting whatever produced it takes about ten minutes and is routinely skipped, because by then the urgent part is over and everybody has moved on.
The practical lesson in “Fixing the Cause, Not the Payment” is that payroll depends on a sequence somebody can explain. When a small team reviews review this first-party product note for attendance point system, the useful role is to organise time and project evidence before approval, with proportional settings and a clear correction route for employees.
The result is the same error, next month, with somebody now watching for it.
Additional context for “Fixing the Cause, Not the Payment” is available from Atlassian work-management resources. A sound review distinguishes general practice from the rules and records that apply to one employer.
Why the cause gets left
Because the correction feels like completion. The person has their money, the conversation is finished, and the thing that caused it is an abstraction about process in a week that has other work in it.
| Kind of cause | Test | Fix |
|---|---|---|
| A setting | Same inputs would repeat it | Change it, then check who else |
| A process gap | It depended on being busy | Change the schedule, not the intention |
The two kinds of cause
A setting — something configured wrongly in the software, which repeats identically and affects anybody it applies to.
A process gap — an input that never arrives, a step that is skipped under pressure, a deadline nobody else keeps.
The first is quick to fix and easy to find. The second is the one that actually produces most errors.
Finding which it is
Ask whether the same inputs next month would produce the same result. If yes, it is a setting. If the error depended on somebody being busy, it is a process gap.
Fixing a setting
Change it, then check whether anybody else is affected by the same setting. A rate, a threshold, a pay element configured wrongly for one person is frequently configured wrongly for several.
Then check whether it has been wrong for previous periods, which is a much larger question and sometimes an uncomfortable one.
Fixing a process gap
Harder, because the honest fix is usually a schedule change rather than a resolution to be careful.
Moving a cut-off, reducing what has to arrive, putting a step in the written sequence, giving a reminder a different trigger — these work. Intentions do not.
The fix that is not a fix
"I'll remember next time." It is offered sincerely and has no effect, because the conditions that produced the error — being busy, being late, being interrupted — will recur unchanged.
Writing it in the sequence
Any fix that is not written into the run sequence will survive about three months. The sequence is the only place a change to how payroll is done actually persists.
The ten-minute review
After anything goes wrong: what happened, would the same inputs produce it again, what one change prevents it, where does that change get written.
Four questions, once, while it is fresh.
Doing it while it is fresh
The week after is too late. The detail that matters — which step was skipped and why — is remembered for about two days and then becomes a general impression.
Looking back
Whether the error has already happened and gone unnoticed. An underpayment found this month may have occurred for three months, and the person did not notice because the amount was small.
This is the question nobody wants to ask and the one that matters most.
When the honest answer is the schedule
A surprising share of payroll errors trace back to the run being compressed, which traces to inputs arriving late, which traces to a cut-off only one person was keeping.
That chain is worth following to its end rather than stopping at the first mechanical cause.
Recording the pattern
Over a year, a short log of errors and causes shows whether the business has one recurring problem or twelve unrelated ones.
It is almost always one.
What good looks like
A business where the same payroll error does not happen twice. Not one where no errors happen, which is not available to anybody running this with one person and four hours a month.
Why the relief is the dangerous part
The moment the person has their money, the pressure disappears entirely. Nothing in the business is now demanding attention, and the cause — which has not changed — competes with ordinary work and loses.
That is why the ten-minute review has to happen immediately rather than being scheduled. Anything scheduled for next week is being scheduled against a deadline that no longer exists.
The log that shows the pattern
Date, what happened, cause, what changed. Four columns, one line per incident.
Over a year it answers a question nobody can answer from memory: whether this business has one recurring problem or a series of unrelated accidents. It is almost always the former, and the log is what makes that visible.
Symptom, cause, and the ten minutes after
The payment is the symptom, the setting or the schedule is the cause, and the ten minutes after the relief is when the difference is made.