Some costs announce themselves. A supplier raises prices. A wage bill goes up. Somebody has to sign something.
Others arrive a few hundred at a time, absorbed into cost of sale by people doing exactly what they should. Nobody signs anything. Nobody is told. By the end of the year the total is large enough to matter, which is roughly when somebody asks why margin is down.
Why this category stays invisible
Three things keep it hidden, all of them structural rather than anybody's fault.
- It has no owner. A refund sits with customer service, the error that caused it sits in operations, the process that allowed the error sits with whoever designed it years ago. Each party sees a fragment.
- Each instance looks reasonable. One refund is a cost of doing business. Two hundred refunds is a pattern. The difference is only visible if somebody aggregates them, which is nobody's job.
- It is recorded as the wrong thing. Rework rarely appears as rework. It appears as time, which appears as payroll, which appears as a fixed cost. The line item that would tell you is not in the accounts.
Sizing it without a project
Most businesses assume measuring this requires a piece of work. It usually requires one question asked in four places.
- What proportion of orders, jobs or cases required doing something twice?
- What is the annual value of refunds, credits and write-offs?
- How much time goes on chasing information that should already be present?
- What is declined, delayed or delivered late because something upstream was wrong?
None of those needs precision. A range from somebody who knows is enough to establish whether this is a rounding error or a serious number. In most established businesses it is the second, which surprises people.
Where to find the answers in systems you already pay for
You do not need anybody's help to get a first number. Most of it is already being recorded, just not in one place and not under a heading anyone reads.
| Where to look | What to pull | The calculation | What it tells you |
|---|---|---|---|
| Finance system: MYOB Advanced, NetSuite, Business Central | Credit notes raised per month, against revenue for the same month | Credit notes ÷ revenue = recorded leakage | The ledger's version. Treat it as the floor rather than the total |
| Payment gateway: Stripe, Square, Tyro | Refunds and chargebacks by month | Refunds ÷ transactions = return rate | Money returned outside the invoice run, which the ledger frequently misses |
| Ecommerce or order platform | Refunds broken down by reason | Count by reason code | Whether the cause is the product, the fulfilment or what the customer was led to expect |
| Service and CRM: HubSpot, Salesforce, Zendesk, ServiceNow | Ticket volume by tag, plus the reopened rate | Reopened ÷ closed = rework rate | A reopened ticket is rework wearing a different name |
| Job, project or practice system | Jobs where time was booked after the job was marked complete | Count of post-completion bookings | The cleanest rework signal most businesses already collect without realising |
| Workforce: Employment Hero, Deputy, Humanforce, UKG | Overtime concentrated in one team or one period | Overtime hours ÷ team hours | Where the absorption is actually landing |
These are standing metrics with alert thresholds rather than a one-off exercise. A calculation the reader has to remember to run is a calculation they will run once.
Two of those are worth pulling even if you do nothing else. Credit notes against revenue gives you the ledger's version. The reopened rate in whatever system handles enquiries gives you the version the ledger cannot see.
The one number to track from here
- Credit notes, refunds and write-offs as a percentage of revenue, monthly, across the last twelve months
- A flat line is a cost of doing business
- A line rising while revenue holds steady is a process problem that has not been named yet
The measure worth introducing if you do not have it
- First time right: the share of orders, jobs or cases that completed without being reopened, reworked or credited
- Most systems can produce it from data they already capture
- Set it as an internal standard at a level you would be willing to publish to a customer, then watch the gap between the standard and the actual. The gap is the finding
- Businesses that already run to a service level externally usually find they have never set one internally, which is where the divergence starts
Where your number will be wrong
- The ledger undercounts, every time. Refunds and credits have an account. Rework does not, because it shows up as payroll and payroll looks fixed
- So whatever total you arrive at, the real figure is that plus the hours
- That is the half nobody counts. It is usually the larger half
What sits underneath
Rework is almost always a symptom of something upstream, which is why attacking it directly rarely works. Tell a team to make fewer errors and you get more checking, not fewer errors.
The causes cluster in a few places:
- Information arriving incomplete, so somebody fills gaps by guessing
- A handover with no defined standard for what "finished" means
- A system that permits an invalid entry rather than preventing it
- Volume growing past the point where the informal version held
Each of those is fixable. None of them is fixed by asking people to be more careful.
This is worth saying plainly, because the instinct to address rework through diligence is strong. It feels like accountability. What it actually does is add a checking layer, which consumes more capacity while leaving the cause untouched. The error rate improves slightly. The cost goes up.
The half nobody counts
There is a second number sitting beside the first. It is usually larger.
Rework consumes capacity. Every hour spent redoing something is an hour not spent on work that would have earned. That opportunity cost never appears anywhere, because unlike a refund it leaves no record.
A business recovering four hundred hours a year of rework has not saved four hundred hours of wages. It has released four hundred hours of capacity it has already paid for. Those are different things. The second is worth considerably more.
Where the number usually lands
Two patterns show up often enough to be worth naming.
The concentrated version. Most of the cost sits in one process, frequently one that grew informally around a system that was never configured for it. Painful to look at, straightforward to fix.
The distributed version. Small amounts across many processes, none individually worth a project. Harder, because there is no single thing to point at. The fix is usually a standard rather than a build.
The distributed version is also the one businesses live with longest, precisely because no single instance ever justifies attention. It is the operational equivalent of a slow leak. Nobody calls a plumber for a drip. The bill arrives anyway.
Which one you have changes the response entirely, which is why it is worth establishing before committing to a programme of work.
What would your four answers be?
What proportion of jobs get done twice. What refunds and write-offs total in a year. How much time goes on chasing information that should have arrived complete. What gets declined or delivered late because something upstream was wrong.
You do not need precision. A range from the person who would know is enough to tell you whether this is a rounding error or a number worth a decision. In most established businesses it is the second. The surprise is usually the size.
The Free Health Check covers the areas these costs hide in, in about three minutes. If you want the number evidenced rather than estimated, a diagnostic is built to produce it.