When six people own the disputes, nobody does.

Finance teams tend to file disputes under billing accuracy, which is where they start but not where they matter. A disputed invoice is an invoice that will not be paid, and in commercial debt it is the most common reason a good customer with the money to pay you does not.

That reframing changes who should care. If disputes are a billing problem they belong to the team that issues invoices. If they are the thing standing between you and your cash, they belong to whoever is accountable for working capital, which is a materially more senior conversation.

It also changes what good looks like. A dispute process optimised for accuracy will investigate carefully and take as long as it takes. One optimised for cash resolves the undisputed portion immediately and argues about the rest in parallel.

Almost every business that has grown by acquisition has this somewhere. Disputes were tracked per branch in a spreadsheet, because at that size a spreadsheet was genuinely the right answer. Then somebody capable built something better, a database or a shared workbook, as a stopgap until the real system arrived.

The real system does not arrive. The stopgap runs for years, usually outliving the person who built it and often the problem it was built for. By the time anyone looks at it properly, it is load-bearing: it holds the only record of what is owed, what is contested and what was agreed, and nobody wants to be the one who turns it off.

Businesses that grew by acquisition have a harder version of it, because they inherited a ledger with every company they bought and nobody was ever funded to merge them. Producing a single view of what the group is owed means exporting from each one, reconciling formats that do not agree, and stitching the result together by hand. That is half a day of work, so it happens monthly at best, and by the time anyone reads it the number has moved.

The tell is not that the tool is old. It is that nobody can answer a simple question from it without exporting something first.

Here is the structural fault underneath most aged dispute queues. The branch or the site or the regional office pushes disputes to the credit team, on the reasoning that disputes block payment and payment is credit's job.

But credit cannot investigate an operational claim. They were not there, they have no access to the run sheet or the delivery record or the service history, and they have no standing to decide whether the work was done. So the dispute sits with someone who can chase it and cannot resolve it.

It gets worse at the point of refusal. If credit declines a claim, the first thing the customer asks is why, and the second is to argue it. Neither question can be answered by the person who declined it, so the argument goes back to operations anyway, with a damaged relationship attached.

You can hear the problem in the status updates. Three answers do most of the work in most businesses, and all three mean the same thing:

It is with the branch

Nobody at the branch has been told it is theirs, and nothing on their screen says so.

It is with credit

Credit cannot investigate it, and both sides of the conversation already know that.

Someone is looking at it

No one is looking at it.

The investigation has to sit with the people who did the work. The only question worth designing around is how it gets to them, and how anyone knows it arrived.

Give a dispute an owner and a clock, and put the resulting queue in front of the leadership team at a regular interval, and the numbers move. Not because anyone is forced to act, but because people can see what is sitting with them, and they can see that everyone else can see it too.

That is an uncomfortable thing to write down, because it sounds like surveillance. It is closer to the opposite. The reason unowned work goes unresolved is rarely that someone decided not to do it. It is that nothing distinguished it from the fifty other things with no deadline, and nobody could tell whether it had moved.

Two mechanisms do most of the work, and neither is sophisticated:

• One named owner per dispute, not a team and not a queue. If two people are accountable, the dispute is nobody's until it is escalated.
• Approval routed by value, so a small credit clears locally and a large one reaches whoever should be deciding it. The point is speed at the bottom as much as control at the top.

The second one has a consequence worth naming. Without a value ladder, credit notes get approved by whoever is nearest, which means some of them get approved without much scrutiny at all. That is not a dispute problem, it is margin leaving the business through a process nobody is watching.

The measure to run the queue on is not how many are open. It is net movement: how many cleared this week against how many arrived. A team closing forty and receiving fifty is going backwards while its effort looks impressive, and a backlog that has defeated six people working on it occasionally will usually fall to one person working on it properly, in months rather than years.

That is the uncomfortable arithmetic of the whole problem. The work was never too large. It was too diffuse.

Once disputes are captured against a reason rather than as free text, the queue stops being a backlog and starts being a diagnosis. Reason codes cluster. They also ebb and flow, which means the clusters are telling you about something that changed in the operation.

Most of those causes are not finance problems and cannot be fixed in finance. A recurring delivery dispute at one site is a conversation with the people doing the deliveries. A recurring pricing dispute is a contract that was loaded wrong, or a variation nobody told billing about.

Teams that work this way stop being surprised. They do not eliminate disputes, because a business of any size generates them continuously. What changes is that new ones are recognised as new, rather than disappearing into a pile that was already too big to read.

One failure deserves its own heading because it is so common and so cheap to fix. A credit is approved, correctly and promptly. It does not appear on the customer's next statement, because of where it landed in the billing cycle. The customer sees an unchanged balance, assumes nothing has happened, and escalates.

By the time it reaches someone senior, the dispute has been resolved for three weeks. Everyone involved is annoyed about a problem that no longer exists, and the relationship has taken a dent that the original error never would have caused.

Time is what turns a billing error into a grievance. Telling the customer the outcome the moment it is decided, rather than letting the next statement tell them, removes more heat than any amount of resolution speed.