The Excel list as a symptom: back office meets tax

In almost every team running withholding-tax reclaim, it shows up at some point: the parallel Excel list. It sits next to the specialist system, is opened in the morning, maintained in the evening, and holds what the system apparently does not capture. The first impulse of many projects is: get rid of it. We believe that is the wrong first impulse. The list is not a problem. It is a signal.

Anyone who bans the list without understanding why it appeared removes a symptom, not the cause. Next year it is back — in a different column structure, maintained by a different person.

The list as a signal, not a problem

A parallel list almost always grows out of a concrete pressure. Someone in the team has to make a decision and does not find the information they need in the specialist system — not in that form, not at that point, not linked to what belongs with it. So the list is built. It is tool and memory at once.

Anyone intervening here should first ask: which decision is made with this list? Which status is missing in the system? Which document has to appear where for the list to become obsolete? The answers show whether the specialist system has gaps, whether the processes have gaps, or whether both come together.

Three places where the list originates

In practice, the triggers can usually be traced to three places.

Deadline invisible

A reclaim has deadlines — depending on withholding-tax type, depending on recipient country, depending on the kind of claim. Miss a deadline, lose money. In the specialist system the deadline is often not visible as a concrete date, but as a rule behind a field. So the team keeps a list where the next deadline per case sits as a date. The list is nothing but a deadline calendar the system does not offer.

Missing document without an owner

A claim needs evidence. If a document is missing, the case sits idle — often for days, without anyone knowing it sits idle. The list tracks: case, missing document, who is supposed to obtain it. It is an open-item list for documents. That it is needed shows that the system stores documents but does not drive their status.

A status no one trusts

Even when the system tracks a status, some teams do not trust it. The reason is usually not distrust of the software, but experience: the status jumps without an obvious reason, it is not updated when a case moves on, it does not distinguish between “in progress” and “waiting for reply”. So the “real” status is maintained in the list. The list is a shadow status that appears because the system status does not guide action.

The interface as a grey zone

Often the real reason is not in the tax system itself, but at its interface to the back office or fund accounting system. There, fields are mapped: position, depository, income, currency, date. What is a clear entry in the accounting system becomes a value in the tax system that the business team has to interpret differently — or vice versa.

In this grey zone the problem often goes unnoticed. The business team does not see the mapping, development does not see the business logic. Both trust that the other side did it right. The list appears exactly here: it is the team’s attempt to check the mapping with their own eyes, because the system does not make it transparent.

From this follows an uncomfortable insight: at the interface it is no use if each side works cleanly on its own. It only helps if business team and development walk the mapping together — field by field, value by value, with examples from the real position book. That is effortful. But it is the only way to dry up the list at its source.

How to make the list obsolete

Anyone who wants to get rid of the list should not ban it but make it obsolete. Three steps have proven useful.

• First: find out which of the three gaps — deadline, document, status — is present in which form. Usually it is a mix, usually one dominates.
• Second: bring that gap into the system, in a way that makes it visible in the working day — not in a report, but where the case is worked.
• Third: keep the list for two more cycles, in parallel with the system, and log the deviations. Anyone who removes the list too early loses control over whether the system really took over.

The third step sounds inefficient, but it is decisive. In this phase the parallel list is no longer a symptom but a measuring instrument. It shows whether the system really closes the gap — or whether it merely shifted it.

How to measure whether it works

Whether the measure works can be read from three figures that are easy to collect.

• Claims on time: how many claims go out before the deadline? Does the rate rise, fall, or stagnate?
• Queries in the team: how often does someone have to ask a colleague because the status is unclear? If the number falls, the team trusts the system more.
• Parallel lists: how many are still there, in which form, maintained by whom? If the number falls, the system takes over. If it rises, the measure shifted the problem instead of solving it.

These three figures say more about the state of a reclaim process than any process documentation. Anyone who collects them regularly can tell whether a change really works — or merely looks different.

What the list says about the organisation

A parallel list is also a mood barometer. It shows where the team does not follow the system — and thus where the system does not follow the team. Anyone who takes that seriously learns more about the actual work than from any process description. The description says how it should be. The list says how it is.

Often the list also reveals an ownership question: no one feels responsible for the case, so someone keeps the list so the case does not sit idle. In that case the list is not only a tool but a stand-in for a role that has not been named in the house. Anyone who removes the list without naming the role shifts the problem into the next corner.

Anyone improving here should therefore ask two questions side by side: which gap does the list fill, and which role is missing in the house that made the list necessary in the first place? The first question yields a system improvement. The second yields an organisational decision. Both together make the list obsolete. Only one of them merely makes it smaller.

What we learn from this

The Excel list is not a sign that the team is stubborn. It is a hint that the system does not keep up with the working day at one point. Anyone who takes it seriously finds the gap. Anyone who ignores it finds it later — usually as a refund that came too late, or a deadline that was skipped.

If your team maintains such a list — or several — a first conversation is worthwhile. We look at which of the three places the gap sits and what it takes for the system to make the list obsolete.