Most build-vs-buy conversations miss the actual question. Because ‘build’ isn’t one thing. And what you’re really buying isn’t software. It’s the evidence that your tax position was produced by a controlled process.
An ASX 100 tax team I worked with had been booking an unrealised FX loss on US-dollar intercompany loans as a permanent difference for three consecutive years. It should have reversed each balance date. The build had been in place four years. The person who wrote it had left eighteen months earlier. The reconciliation could not explain the discrepancy because it lived inside the same workbook that produced it.
That moment, at 10:47pm on a Tuesday in August, is where this conversation becomes concrete. Not at the tender. Not at the business case. At the moment the file breaks.
THE FOUR FLAVOURS OF BUILD
When a tax director says ‘we’re going to build it,’ four different things are usually in play. And none of them, in practice, includes a native lodgement pipeline to the ATO. The universal finishing move is the same: results are exported and rekeyed into an advisor’s tax return software. SBR2 is not something enterprise tax teams build. It is something they outsource by default.
The in-house custom build. Two to four engineers write bespoke code to classify GL data, run adjustments, and produce the return. It is the rarest of the four. When the architect leaves, the documentation goes with her. The next tax director inherits a codebase nobody can safely touch.
The EPM or CPM extension. Anaplan, OneStream, Workday Adaptive, or CCH Tagetik pressed into service as a tax platform. The hidden trap is ownership. The roadmap belongs to corporate planning, not to tax. Around Year 3, planning schedules a redesign for their own reasons. Your tax engine is a tenant in a building being renovated.
The ERP tax module. SAP, Oracle, or Workday has a tax submodule. Configuration runs fourteen to eighteen months, welded to a GL upgrade cycle. Every form change is a change-control request. IT prioritisation decides when your tax team gets the schema update they need in August. The answer is usually Q4.
The advisor-hosted stack. A Big Four or mid-tier advisor offers a ‘managed’ service: SharePoint site, an Alteryx flow, forty Excel workbooks, Power Automate flows to stitch them together, branded cover page. The commercial model is the tell. Annual invoicing, not a product licence. The advisor is selling hours wrapped as technology.
Four flavours. One common thread. None were designed ground-up for tax compliance. They are adaptations: of generic code, of financial modelling, of an ERP module, of a shared drive.
THE LAYERS YOU CAN’T SEE
When a tax team writes a requirements list, they describe today’s process with fewer defects. Import the GL. Classify accounts. Run adjustments. Produce the schedules. Lodge.
That is the visible ask. Below the waterline, four layers do the real work.
A tax ledger sitting alongside the general ledger. Every GL account classified: deductible, non-assessable, capital, or temporary difference. The translation between accounting and tax captured once, not from scratch every year. When a new account appears in August, it inherits the classification automatically.
Book-to-tax reconciliation as a live calculation. One reconciliation has to produce two outputs: the income tax returns, and the tax effect accounting disclosure under AASB 112. In one engagement I reviewed, the book-to-tax workbook ran to 74 tabs with 29 formula errors, none caught in-year, because the reconciliation ran inside the same workbook that produced the numbers.
Embedded controls. Role-based access so a preparer can’t approve their own work. Workflow enforcement so the return can’t progress until each stage is complete. Automatic logging of every adjustment with author, timestamp, and reason. The governance framework isn’t a PDF in a drawer. It is the shape of the system.
Atomic workpapers tied to defined adjustments. Not tabs inside a 74-tab master workbook. Each workpaper takes defined inputs, applies a single tax treatment, and emits a labelled adjustment. Versioned. Linked to the ledger. Survivable across staff turnover. When the senior manager who built the depreciation workbook leaves, the workpaper doesn’t leave with her.
None of these are features. They are the consequences of being designed for the problem. Any one of them can be approximated in a build. None can be reliably reproduced across five years of staff turnover, form updates, and technology shifts.
THE JUSTIFIED TRUST TEST
Justified Trust is how Australia’s largest taxpayers improve their standing with the regulator. High assurance means less scrutiny, faster reviews, and a cleaner relationship. The ATO tests it across four pillars. A purpose-built platform lifts the score on each one by design.
Pillar 1. Tax control framework and governance. High assurance requires segregation of duties as system behaviour, not policy. An immutable audit log, not SharePoint version history. A maker-checker workflow, not ‘Reviewed by’ in a cell comment. Slide decks and draft policies do not clear the bar. A purpose-built platform ships these as default behaviour. A build can ship them too, but only if the team prioritises governance on day one and keeps it current as roles and processes change.
Pillar 2. Tax risks the ATO has flagged to the market. Forty to sixty Taxpayer Alerts, Practical Compliance Guidelines, and Determinations issue each year. Each one needs to be assessed against the organisation’s positions, with the reasoning documented and retained. A vendor absorbs the relevant changes into the rule engine, tested and versioned, with the assessment logged. A build absorbs them as a project, scoped behind every other IT priority.
Pillar 3. Significant and new transactions. When the ATO asks how a material transaction was treated, the answer should be the workpaper that produced the adjustment. Labelled. Versioned. Linked to the source GL entries. A purpose-built platform produces that lineage automatically. The alternative is three weeks reconstructing the working from Slack threads and the memory of someone who has since left.
Pillar 4. Alignment between accounting and tax results. One reconciliation has to produce both the income tax returns and the tax effect accounting disclosure under AASB 112. This is the pillar builds most consistently fail on, because reporting and compliance run as two separate workstreams reconciled by memo under deadline pressure. A tax ledger makes them the same workstream.
Governance is the gating criterion for high assurance in both the Top 100 and Top 1000 programs, and most groups still sit below the top tier on the governance attribute. The tax functions that score Stage 3 are not the ones with the most elaborate policies. They are the ones whose systems produce the evidence as a by-product of doing the work.
WHAT THE BUSINESS CASE MISSES
The build goes live. The developer, EPM consultant, or Big Four advisor moves on. Now what? Two costs no build-vs-buy business case I have reviewed prices honestly.
Documentation atrophy. At handover, documentation reflects around 70 percent of the system. By Year 3, below 30 percent. Six change requests, four form updates, two personnel changes, a new cloud tenant. The answer to ‘why does this reconciliation behave this way?’ lives in a Slack thread from 2024.
No real SLA. When the return schedule breaks at 11pm the night before lodgement, who answers? A commercial vendor SLA is measured in hours. An in-house build SLA is measured in days. An advisor’s SLA is a relationship partner who doesn’t code.
THE HONEST EXCEPTION
There is one situation where a build is defensible in direct tax. A single-entity Australian investment company. No consolidation. No international limbs. A manager inside the team who codes, committed for three years. A CFO who treats the stack as strategic IP and funds its reinvestment.
When all three hold, the total cost of ownership is defensible and the governance surface fits inside one head. Inside every enterprise tax function I have reviewed in the last decade, exactly none match that list.
Transaction tax is different. GST, FBT, WHT, and payroll tax are linear, after-the-fact analytics on structured data. A workflow stack with an Alteryx flow and a macro-driven library is fit for purpose there. Match the tool to the shape of the work.
THE REAL QUESTION
This isn’t a build-vs-buy question.
It is a question about what a tax function is for. If the function exists to produce a return and absorb the operational risk of producing it, a build can be made to work. At a cost most organisations only calculate in hindsight. If the function exists to protect shareholder value through judgement and defensible positions, it needs systems designed for that work.
Most build-vs-buy conversations are framed around cost. That’s the trap. Build is rarely the cheaper answer once the maintenance compounds. The real choice isn’t cheaper versus better. It’s control versus outcome.
If the question is: how do we keep this in our hands? Sometimes the answer is a build.
If the question is: how do we do this well? The answer is almost never a build.
Only one of those protects shareholder value.
Tax teams don’t create value. They protect it. The right question isn’t whether your organisation can build tax software. It is whether building it is the best use of the time your tax team would otherwise spend protecting shareholder value.
For the vast majority of Australian enterprise taxpayers, the honest answer is no.
If you want to pressure-test your own situation, the Build Readiness Scorecard is a one-page assessment of the ten questions that predict which side of the line you are on. Score your organisation. Send it to the CFO. If you land under 50, the honest answer is buy.
