Every tax team has a Sarah.
She knows which GL accounts map to which return labels. She knows why the depreciation schedule doesn’t reconcile to the fixed asset register, and why it doesn’t matter. She knows that Entity 7 has a different year end, that the R&D claim requires a manual adjustment in Q3, and that the dividend frankings need to be traced through three intercompany steps before they hit the consolidated return.
She knows all of this because she built the process. She has been running it for years. None of it is written down in any way that someone else could follow.
Key person dependency is not a personnel issue. It is a structural one. It is a measure of how much institutional knowledge lives in someone’s head versus in the systems and processes around them. For most tax functions, that measure is dangerously high.
THE TWO-SIDED RISK
Every tax function runs on a mix of explicit knowledge and tacit knowledge. Explicit is what is captured in your systems, your documentation, your processes. It exists independently of any individual. Tacit is the judgement calls Sarah makes without thinking about them. The override on the Entity 3 property revaluation. The Melbourne controller’s late intercompany workpaper. Which numbers on the return the ATO always asks about. Tacit knowledge is acquired through experience, almost impossible to document comprehensively, and it walks out the door when the person who holds it leaves.
The ratio between explicit and tacit is the single best measure of operational resilience. Every decision about operating model and technology either converts tacit to explicit, or it does not.
The obvious risk is that Sarah resigns. That is not the actual risk. Key person dependency does not require Sarah to leave. It only requires her to be unavailable. Annual leave during a filing deadline. Parental leave. Illness. A restructure that spreads her across two roles. A promotion that pulls her out of the detail.
In a team of five, key person dependency often means three people can do the work, one can review it, and one actually understands it. Remove that one and the other four are following a process they cannot explain, making adjustments they cannot justify, producing a return they cannot defend. That is the risk the board never sees. Not because it is hidden but because it does not have a line item. It is not in the risk register. It is not in the audit committee paper. It is just there, quietly compounding, until something forces it into the open.
Sarah knows this too. At first the recognition feels good. After that, indispensability becomes a cage. She cannot take real annual leave because she will be interrupted. She cannot accept the promotion that takes her out of the detail because no one else can hold the detail. She cannot be ill on filing day. The role she made hers has become the role she cannot leave.
That cost is invisible in the organisation’s risk register too. It shows up in the senior tax person who declines a step-up “for now.” The parental leave shortened by three weeks. The illness worked through. The career capital that does not accrue because the role does not allow her to develop the breadth executives later expect.
The two sides are the same problem. Tacit knowledge that lives in one person harms the institution and the person. Converting it to explicit knowledge releases both.
WHY MOST OPERATING MODELS COMPOUND IT
The operating model your tax function runs determines where tacit knowledge concentrates and how fast.
Fully manual, in-house. Maximum concentration. Every decision, every workaround, every undocumented adjustment lives with the people who do the work. The spreadsheets contain data. The people contain logic. Most Australian tax teams are small enough that one or two people hold the entire institutional memory.
Co-sourced. The dependency shifts but does not shrink. The external adviser’s senior manager who “knows your account” becomes the new Sarah. When she rotates off (and she will, because that is how professional services firms work) the same problem reappears in someone else’s organisation, where you have even less visibility into it.
Outsourced. The dependency is transferred entirely. You no longer have a key person problem inside your tax team. You have one inside your provider. Someone internally still needs to understand enough to brief the provider, review their output, and answer questions the ATO directs at the company. That person becomes your new Sarah, with less context because they are not the one doing the work.
Technology-enabled. The only model that structurally converts tacit to explicit. But only if the technology is designed for it. Most is not.
There is a layer none of these models capture cleanly: organisational process knowledge. Tax compliance does not start when data enters the platform. It starts with which report you run from the ERP, which version (because the standard report does not include the reclass entries), who in finance owns the intercompany reconciliation, what format the FX workpaper arrives in. This process knowledge lives in Sarah’s head, in emails she can search, or in a checklist last updated three years ago. A platform that stores data and calculations but not process is solving half the problem.
WHY TAX SOFTWARE OFTEN MAKES IT WORSE
Purpose-built tax compliance software, the tools designed specifically for corporate tax, often does very little to reduce key person dependency. In some cases it makes it worse.
Not because the software does not work. It does. These platforms calculate correctly, produce returns, handle multi-entity consolidations, and lodge electronically. The vendor maintains the logic, which removes one category of tacit knowledge from the equation.
But the interfaces create a new category of dependency that is just as dangerous. Most dedicated tax compliance platforms accumulated features and configuration options over decades. The result is software that is powerful but opaque. Operating it effectively requires months of training. Understanding what is happening beneath the surface requires years.
Four specific problems:
Import opacity. What data came in from the GL and what was adjusted inside the platform? The boundary is not visible. The person who configured the import knows. A new team member, or an ATO analyst, sees numbers without context.
Adjustment traceability. Adjustments happen across worksheets, mapping tables, override fields, configuration layers, calculation modules. The person who built the process knows the path. Everyone else navigates a system where the logic is distributed across screens that do not surface it coherently.
Outcome legibility. Can a reviewer trace a number on a return label back through the system to the originating GL entry without being a power user? In most dedicated tax platforms the answer is no.
Confidence in completeness. When the calculated balance does not agree with what is being posted to the GL, where do you start looking? Answering this requires deep product knowledge. Sarah is the only one who can tell whether the platform produced the right answer. The system does not validate itself. Sarah validates the system.
A system that requires expert knowledge to verify its own accuracy is not a control. It is a risk wearing the uniform of a control.
These platforms have replaced “Sarah knows the tax rules” with “Sarah knows how to use the software.” The tacit knowledge has not been converted to explicit knowledge. It has been relocated from the tax process to the application process. The dependency is the same. Only the subject has changed.
WHAT ACTUALLY REDUCES KEY PERSON DEPENDENCY
Converting tacit to explicit requires the system to absorb what currently lives in people’s heads. Not just data. Not just calculations. Logic, process, and context.
A rules-based system embeds the logic in the platform. Classification rules, adjustment methodologies, treatment of each account, defined once, applied consistently, maintained as rules change. When Sarah leaves, the logic stays.
A transparent interface makes the system legible to someone who was not there when it was configured. Clear delineation between imported data and internal adjustments. Visible adjustment trails that do not require platform expertise to follow. One-click traceability from the return label back to the originating GL line.
Built-in validation removes the “how do I know I used it right” problem. When the system shows in a single view what was imported, what was adjusted, how those adjustments flow to the return, and where anything does not reconcile, the confidence question is answered by the platform, not by the operator. The system validates itself.
An embedded process layer stores the organisational knowledge alongside the tax knowledge. The extraction instructions. The upstream dependencies. The review checklists. The “here is who to call when Entity 7’s data is late.” Visible to whoever picks up the work next.
None of these features are technically exotic. They require a design philosophy that prioritises legibility over flexibility, transparency over configurability, and institutional resilience over individual power-user capability.
OPERATIONAL RISK, ON THE REGISTER WHERE IT BELONGS
Key person dependency in tax does not stop the business. It corrodes it. That makes it an Operational Risk concern, sitting one level below the continuity-grade risks the audit committee reviews.
Could you take your existing Operational Risk register to the audit committee and explain how key person dependency in tax is documented there? Not in abstract terms. In specific terms. If your senior tax manager left tomorrow, how many weeks would it take to reconstruct their tacit knowledge? How many return positions would be at risk of error? How many ATO queries could the remaining team answer without calling the person who left?
For most organisations the honest answer is uncomfortable.
Run the simulation. Take your most recent income tax return. Give it to someone on the team who was not the primary preparer. Ask them to explain how three specific numbers were derived, from GL through to return label, without help. Time it. Every question they ask Sarah is tacit knowledge that has not been converted.
Run the retrospective. The eight questions below reflect the standard lines of enquiry the ATO pursues with Top 100 and Top 1000 taxpayers. If you have not been through a formal review yet, use them as a simulation.
1. Can you demonstrate how a specific deduction was calculated, from the originating transaction to the return label? Not just the answer. The trail. Could someone other than the primary preparer walk the ATO through it?
2. Can you explain the basis for the tax treatment of a material adjustment from what is in the system, rather than from memory?
3. Can you show who reviewed and approved each material position on the return, and when, without searching email?
4. Can you reconcile the tax expense in the financial statements back to the underlying tax calculations, and can someone other than the senior tax manager do it without guidance?
5. If the ATO queried a prior-year position, could the current team reconstruct the basis for it, regardless of who was in the role at the time?
6. Can you show how data moved from source systems into the tax platform with nothing lost or altered, from automatic visible reconciliation rather than manual checks?
7. Can you identify every manual adjustment made outside the system and confirm it was captured in the final return?
8. If your tax team changed over entirely, could the new team produce next year’s return to the same standard using only what is in the system and the documented process? This is the ultimate test. The gap between no and yes is the dependency, measured in weeks and risk.
Score each one honestly. Could anyone on the team answer it, or only Sarah? The ratio of “anyone” to “only Sarah” is your key person dependency expressed in the language your board already uses. It belongs in the Operational Risk register. Not as a placeholder. As a quantified risk with a remediation path.
The pattern to watch for: if the answers depend on navigating to specific screens, knowing which module to check, or understanding configuration choices that are not self-evident, that is application-layer tacit knowledge. The platform is part of the dependency, not the solution to it.
The solution is not hiring a backup Sarah. It is building a tax function where tacit knowledge is systematically converted into explicit knowledge. Embedded in the rules, visible in the interface, stored in the process, and accessible to whoever needs it next.
That is not a technology preference. It is an operational risk decision.
.png)
.png)
