Because the best software in the world is worthless if it never gets off the ground.
Here’s a story you’ve heard before.
A tax team spends months evaluating software. They run demos. They compare features. They build a business case, get budget approval, sign the contract. Everyone’s excited.
Eighteen months later, the software is half-implemented. The tax team is still using spreadsheets. IT is frustrated. The vendor is pointing fingers. And the CFO is quietly wondering why they bothered.
This isn’t a technology problem. It’s a change management problem wearing a technology mask.
The organisations that succeed at implementing tax software share a common trait: they treat the implementation as a transformation project, not a software installation. They understand that the hard part isn’t configuring the system — it’s rewiring decades of ingrained behaviour.
So what does a successful implementation actually look like?
DESIGN THE IMPLEMENTATION, NOT JUST THE SOFTWARE
Before you think about workflows or user interfaces, you need to design two things: the hard outputs and the operational process.
The hard outputs are straightforward — the tax return, the reconciliations, the workpapers, the lodgment file. These define what the system needs to produce. Map every report and deliverable your team currently creates, because each one represents a requirement the new system must meet.
The operational design is where most teams don’t think deeply enough. This is about how data flows into the system, who owns each domain, and what controls govern the process.
Think about it from a domain perspective. Fixed asset registers typically come from a single asset register system — so all entities should be loaded at once by the person who owns that domain, not separately by individual entity preparers. The same applies to accruals, provisions, intercompany balances, and any other data domain that crosses entity boundaries. When you design around domains rather than entities, you get consistency, you reduce duplication, and you assign clear ownership.
This operational design also needs to include the governance and control framework from day one. Don’t bolt on controls after go-live. Design them in: who can approve adjustments, what review workflows apply, where exceptions get escalated. If you get the operational design right, the software configuration follows naturally.
Your design also needs to account for the fundamental tension between tax reporting and tax compliance — because they operate under very different constraints.
Tax reporting is highly time-constrained. It demands greater rule automation, a sharper focus on the tax impact on reported results — effective tax rates, deferred tax movements, tax notes — and speed above all else. Tax compliance, by contrast, has a much greater focus on governance and evidence. More workpapers. More defensible positions. More documentation to support the numbers when the ATO’s Justified Trust review arrives.
This matters because the ATO’s Justified Trust procedures specifically require a reconciliation between your book and tax results — and that every material variance is understood and explained. An implementation that doesn’t design for this from the start will produce a system that handles the numbers but can’t defend them.
This is also where most implementations stumble on data. Tax teams assume their GL data is ready. It isn’t. Chart of accounts don’t map cleanly to tax categories. Historical data has inconsistencies. Multiple entities use different coding conventions.
The first month of any implementation should be spent understanding your data landscape. Map your chart of accounts to your tax return labels. Identify the gaps. Document the manual adjustments your team currently makes in spreadsheets — because those adjustments represent business logic that needs to be captured in the new system.
Ask a critical question early: can tax bases be attached directly to GL accounts, or are they generic blobs of numbers that are difficult to reconcile back to the ledger? This distinction matters enormously. If your tax adjustments sit as unattached lump sums with no clear link to underlying GL balances, you’ll spend every year reconstructing the bridge between book and tax. If they’re anchored to specific accounts, the reconciliation is built in.
This isn’t glamorous work. But it’s the foundation everything else sits on.
BUILD YOUR BRIDGE TEAM
Successful implementations need a bridge between two worlds: the tax team who understands the compliance requirements, and IT who understands the technical infrastructure.
Neither group can do this alone. Tax people don’t think in APIs and database schemas. IT people don’t think in Division 40 depreciable assets and Section 25-25 deductions.
You need at least one person — ideally two — who can translate between these worlds. Someone who understands why the tax team needs to see every journal entry that touches a particular GL code, AND why IT needs clear specifications for the data extraction.
This bridge person is your single most important implementation resource. They need more than just bilingual skills across tax and IT. They need a clear understanding of the target state — what the implementation looks like when it’s done — and the temperament to stay focused on that vision without getting bogged down in every edge case and minor issue along the way.
One practical habit that pays dividends: have this person keep an improvement log. Not every issue needs to be solved during implementation. Some are better addressed in a post-implementation iteration cycle. The log gives stakeholders confidence that their concerns have been heard, while preventing the implementation from stalling on non-critical refinements.
Protect their time accordingly.
PHASE IT. SERIOUSLY.
The temptation is to implement everything at once. All entities. All tax return labels. All adjustments. Full automation from day one.
Resist this.
Start with one entity. Your simplest one, not your most complex. Get the full cycle working — data extraction, classification, adjustments, review, lodgment. Learn from it. Then expand.
The organisations that try to boil the ocean end up with an expensive system that nobody trusts. The ones that start small and iterate end up with a system that actually replaces the spreadsheets.
The critical milestone in this phased approach is replication — the moment you successfully reproduce the existing tax return result in the new system for that first entity. Think of it like a piton in climbing: it locks in your position. You can’t fall back below it.
Replication matters beyond the technical proof. It’s the moment stakeholders see the system working with real data and real results. It transforms the project from a theoretical promise into tangible evidence. For the CFO, it’s proof the investment is delivering. For the tax team, it’s the first time they trust the system enough to imagine letting go of the spreadsheet. Don’t underestimate the psychological impact of this milestone — plan for it, celebrate it, and use it to build momentum for the next phase.
PLAN FOR THE PARALLEL RUN
For the first year, you’ll run both systems in parallel. This isn’t optional — it’s how you build confidence.
Your team will prepare the return the old way AND the new way. They’ll reconcile the differences. They’ll find the bugs and the edge cases. And slowly, they’ll start trusting the new system more than the old one.
Yes, this means the first year is more work, not less. Be honest about this upfront. The payoff comes in year two and beyond, when the parallel run ends and your team suddenly has weeks of their life back.
The parallel run is also where change management becomes real. Up to this point, the implementation has been a project involving a small team. Now it touches the broader tax function. People who weren’t involved in the design are being asked to change how they work.
This is where resistance surfaces. The team member who’s faster in Excel. The manager who doesn’t trust any number they can’t see in a cell. The experienced professional who feels the new system is questioning their competence rather than supporting it. Managing these reactions — with empathy, with training, with clear communication about why the change matters — is as important as managing the technology.
THE MEASURE OF SUCCESS
A successful implementation isn’t measured by go-live date. It’s not even measured by the day your tax manager stops opening the old spreadsheet — though that’s a satisfying milestone.
The real measure is what your team does with the time they get back. The insights they surface because they finally have capacity to think. The transfer pricing risk they spot early. The R&D claim they optimise because they’re not buried in data processing. The proactive advice to the CFO that shifts the conversation from “how much tax did we pay?” to “how should we be thinking about tax?”
And there’s a human measure too. A team that isn’t working punishing hours through lodgment season. People who love their work because they’re doing actual tax work — analysis, judgement, strategy — instead of wrestling spreadsheets until midnight. Professionals who go home at a reasonable hour instead of neglecting their families during the busiest months of the year.
Everything you do during implementation should be designed to accelerate that transformation. Not just the technology switch — the moment your team starts working the way they always should have been.
