The Excel list as a symptom: back office meets tax

Almost every team that runs withholding-tax reclaims ends up with one: the parallel Excel list. It sits next to the specialist system, gets opened in the morning and updated in the evening, and holds what the system apparently does not capture. Many projects want to get rid of it first thing. We think that is the wrong first move, because the list shows where the team is missing something.

If you ban the list without understanding why it appeared, you only remove the symptom. Next year it is back, with different columns and kept by a different person.

What the list stands for

A parallel list almost always grows out of concrete pressure. Someone in the team has to make a decision and cannot find the information in the specialist system in a usable form, at the right moment, or linked to what belongs with it. So they build a list, which serves as both tool and memory.

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 both.

Three places where the list originates

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

Deadline invisible

A reclaim has deadlines that depend on the withholding-tax type, the recipient country and the kind of claim. Miss a deadline and you lose money. In the specialist system the deadline often does not show up as a concrete date; it is a rule behind a field. So the team keeps a list with the next deadline for each case, which amounts to 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, and nobody notices. The list records which case is waiting for which document and who is supposed to get it. It is an open-items list for documents, and it is needed because the system stores documents but does not move their status forward.

A status no one trusts

Even when the system tracks a status, some teams do not trust it. Usually that comes from experience with the system: the status jumps for no obvious reason, it is not updated when a case moves on, and it does not distinguish between “in progress” and “waiting for reply”. The team then keeps the “real” status in the list, a shadow status that exists because the system status does not tell anyone what to do next.

The interface as a grey zone

Often the real cause sits at the interface between the tax system and the back office or fund accounting system. That is where 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 the other way round.

In this grey zone the problem often goes unnoticed. The business team does not see the mapping, development does not see the business logic, and each assumes the other side got it right. This is where the list appears: the team checks the mapping with their own eyes because the system does not make it visible.

So at the interface it is not enough for each side to work cleanly on its own. The business team and development have to go through the mapping together, field by field and value by value, with examples from the real position book. It takes effort, but it is the only way to remove the reason for the list at its source.

How to make the list obsolete

Instead of banning the list, make it unnecessary. Three steps have worked for this.

• First: find out which of the three gaps (deadline, document, status) is present and in what form. Usually it is a mix, with one gap dominating.
• Second: bring that gap into the system so it is visible in daily work, where the case is handled, and not in a report.
• Third: keep the list for two more cycles alongside the system and log the deviations. If you drop the list too early, you can no longer check whether the system has really taken over.

The third step sounds inefficient, but it is decisive. In this phase the parallel list works as a measuring instrument: it shows whether the system closes the gap or has only moved it.

How to measure whether it works

Three figures, all easy to collect, show whether the change is working.

• 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 is taking over. If it rises, the change has only moved the problem.

These three figures say more about the state of a reclaim process than any process documentation. If you collect them regularly, you can tell whether a change actually works or only 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 so where the system does not fit the team’s work. Taking that seriously teaches you more about the actual work than any process description, because the description says how things should be and the list says how they are.

The list often points to an ownership question as well: nobody feels responsible for the case, so someone keeps the list to stop the case from sitting idle. In that situation the list stands in for a role nobody in the organisation has named. Remove the list without filling that role and the problem just moves somewhere else.

Anyone fixing this should therefore ask two questions side by side: which gap does the list fill, and which missing role made the list necessary in the first place? The first question leads to a system improvement, the second to an organisational decision. Only both together make the list obsolete; one alone just makes it smaller.

What we learn from this

The Excel list rarely means the team is stubborn. Usually the system does not match the working day at one point. Take the list seriously and you find that point. Ignore it and you find it later, usually as a refund that came too late or a missed deadline.

If your team keeps one or more lists like this, a first conversation is worthwhile. We look at which of the three places the gap sits in and what the system needs so the list is no longer necessary.