The graveyard of tax technology is full of software that worked perfectly — and was never used.
Let me tell you about the most expensive spreadsheet in corporate Australia.
It belongs to a Top 100 ASX company. They spent over a million dollars on taxsoftware three years ago. The implementation took fourteen months. And today,their senior tax manager still prepares the company tax return in the sameExcel workbook she's used for the last decade.
The software works. The data feeds are connected. The workflows are configured.Nobody uses it.
This story repeats itself across the country, in companies of every size. Notbecause the software is bad, but because the implementation ignored the humanbeings who were supposed to use it.
Here are the patterns that kill tax software implementations — and how to avoidthem.
PITFALL ONE: STARTING WITH FEATURES INSTEAD OFPROBLEMS
Most implementations begin with the software. What can it do? How do we configureit? What are the settings?
Wrong starting point.
Start with the problems. Where does your team spend disproportionate time? Whichadjustments cause the most rework? Where do review comments cluster? Whichreconciliations keep people up at night during lodgment season?
When you start with problems, you implement with purpose. When you start withfeatures, you implement with hope. Hope is not a strategy.
PITFALL TWO: FORGETTING YOUR TEAM STILL HAS ADAY JOB
In most organisations — particularly smaller ones — the people leading theimplementation are the same people responsible for status quo compliance. Theydon’t get seconded to the project. They get the project on top of everythingelse. And when lodgment season arrives or a quarterly close demands attention,the implementation loses every time.
The solution isn’t to pretend this tension doesn’t exist. It’s to use itstrategically. Status quo activities can actually accelerate an implementationif you approach them with the right mindset. Cleaning up workpapers during thecurrent compliance cycle — with the new system’s requirements in mind — meansyou’re building implementation-ready data as a by-product of business as usual.Improving the allocation of tax bases at the GL account level in your existingspreadsheets makes the migration cleaner when it happens. Every smallrefinement to your current process is a head start on the new one.
Timing matters too. Plan implementation activity around your compliance calendar, notagainst it. Work backwards from key dates: you want the new system testedduring soft closes — interim reporting, quarterly reviews — not during the hardclose when stress is highest and tolerance for disruption is lowest. Give yourteam the best chance of engaging with the new system when they have the mentalbandwidth to learn, not when they’re already stretched thin.
PITFALL THREE: UNDERESTIMATING DATA QUALITY
Tax teams often discover, mid-implementation, that their GL data is messier thanthey thought. Account codes that should be consistent across entities aren't.Intercompany transactions don't eliminate cleanly. Cost centre structures haveevolved over years without anyone maintaining a master reference.
This isn't a flaw in the software. It's a truth the spreadsheets were hiding. Manualprocesses have a way of absorbing data quality issues — someone just"knows" that account 4310 in Entity A means something different fromaccount 4310 in Entity B.
Budget at least 30% of your implementation timeline for data cleansing and mapping. Itwill feel like too much until you're in the middle of it.
PITFALL FOUR: NO EXECUTIVE SPONSOR
Tax software implementations need air cover. There will be moments when ITpriorities conflict. When budget gets questioned. When the parallel run feelslike too much extra work and someone suggests "pausing" the project.
Without a CFO or Head of Tax who actively sponsors the project — not just approves thebudget, but shows up to steering meetings and removes blockers — theimplementation will slowly lose momentum until it dies of neglect.
PITFALL FIVE: BUILDING FOR PERFECTION INSTEADOF PROGRESS
Some tax teams want the system to handle every edge case before they'll use it foranything. The obscure foreign income offset calculation. The one-off capitalgains event from three years ago. The unique withholding tax treatment thatapplies to one entity in one year.
Meanwhile, 90% of the return — the straightforward revenue, expenses, depreciation, andstandard adjustments — could be running through the system tomorrow.
Perfect is the enemy of implemented. Get the core working. Handle the edge cases inphase two.
PITFALL SIX: TREATING IT AS AN IT PROJECT
This is not an IT project. It is a tax team transformation project that happens toinvolve technology.
When IT owns the project, you get technically sound software that doesn't match howtax people think. When the tax team owns the project with IT support, you get asystem that actually reflects the compliance workflow.
The tax team should own the requirements, the testing, and the sign-off. IT shouldown the infrastructure, the integrations, and the security. Blur these lines atyour peril.
THE COMMON THREAD
Everyone of these pitfalls shares a root cause: treating the implementation as atechnology exercise instead of a people exercise.
The software is the easy part. Changing how a tax team works — how they think aboutdata, how they collaborate, how they review, how they trust a system instead ofa spreadsheet — that's the real implementation.
Get the people part right, and the technology follows.
