Diagnosis
How to build an issue tree for a tax technology problem
Most tax technology problems arrive as a sentence, not a structure: “our VAT returns take too long”, “the determination engine keeps getting it wrong”, “the ERP data is bad”. An issue tree turns that sentence into a set of branches that can each be proved or disproved, so the team stops arguing about opinions and starts closing questions.
7 min read
Start from a question, not a symptom
Write the top of the tree as a single question with a decision attached: “What is driving the 11-day close for EU VAT, and what would bring it under five?” A symptom (“the close is slow”) has no natural branches. A question with a target does — every branch is a candidate explanation that either accounts for the gap or does not.
If you cannot state the number you are trying to move, you are not ready to draw the tree. Go and measure first.
Make the first cut mutually exclusive
The first level should split the problem in a way where no branch overlaps another and nothing important is left out. For close-cycle problems, a cut that holds up in practice is: data arriving late, data arriving wrong, treatment logic failing, review capacity, and system throughput.
- Late data — source systems post after cut-off, or intercompany files land in the last two days.
- Wrong data — tax codes, ship-from/ship-to, VAT IDs, or currency fields fail validation.
- Treatment failures — rules, mappings, or exemptions produce the wrong result even on clean data.
- Review capacity — a single reviewer, a single approver, or an unbalanced regional split.
- Throughput — batch windows, extract performance, or a manual step in the middle of an automated chain.
Attach evidence to each branch before going deeper
Every branch gets three things: the test that would confirm it, the data source for that test, and the person who runs it. A branch with no test is a hypothesis you have decided not to check, and it should be pruned rather than carried.
This is where issue trees usually fail in practice. Teams keep expanding levels because expansion feels like progress, and the tree becomes a taxonomy rather than a diagnostic. Two levels with evidence beat four levels without.
Size the branches before you fix anything
Once tests come back, put a number against each confirmed branch: days of delay, error rate, hours of rework, exposure in the affected jurisdiction. This is the point where the tree earns its keep, because it usually shows that one or two branches hold most of the gap and the rest are noise the organisation has been complaining about for years.
Convert the surviving branches into work
The output of an issue tree is not a diagram — it is a shortlist of causes with sizes attached, ready to be prioritised. Carry only the sized branches into the backlog, and keep the tree as the record of what you ruled out, because that record is what stops the same debate reopening two months later.
Where this comes from
This note condenses Structure with MECE and evidence and pairs with the Issue tree working tool.
More field notes
Alignment
A RACI that actually works on tax technology projects
Why RACI charts stall tax and compliance projects, and how to build one that resolves decision rights instead of listing job titles.
Decisions
Scoring tax software vendors without fooling yourself
How to build a weighted vendor scorecard that resists demo bias, vendor-supplied criteria, and the pull of the incumbent.
Framing
Framing a recommendation with SCQA so executives can decide
The four-part structure that turns a long analysis into a one-page recommendation an executive can act on in a single reading.