AI Tax Transformation Starts With Redesign. Not a Tool Purchase.
EY's October 2026 survey: 91% of tax data sits in silos. The fix is not a smarter AI tool—it's a redesigned tax function built on a knowledge graph and clean data pipelines.
Editorial source review — November 1, 2026. This machine-generated article has been reviewed, but is not certified accurate. Source-backed corrections are incorporated where established. Other legal, survey and product claims may remain unverified; check applicable primary authorities before relying on a deadline or tax position.
Findings in the original version: EY's October 29 piece reports siloed-data / AI-readiness figures. “91% of tax teams report” is not interchangeable with “91% of tax data”. The claimed 40% close compression is not established by that item.
Every vendor in your inbox says their AI will transform your tax function. Most of them will automate your worst process and call it transformation. EY released its "Cutting Through the Noise" series on October 29, 2026. Their data point: 91% of tax teams report their data is stuck in silos, and 80% say insufficient AI-ready data is their top obstacle to transformation. That is not a technology problem. It is a design problem.
You cannot fix a siloed, manually-managed tax function by layering AI on top of it. You fix it by redesigning the function first — then deploying AI on the redesigned process. This post is about what that redesign looks like, why most organizations skip it, and what they lose as a result.
Why Automation Without Redesign Fails
There is a version of AI deployment in tax that every large consulting firm will sell you. You start with your existing provision process — Excel-heavy, manually reconciled, built around quarterly close rhythms. You connect a language model to your workpapers. The language model drafts your rate reconciliation narrative, flags a few line items that look anomalous, and generates a first-pass ASU 2023-09 disclosure. You save two days of analyst time per quarter.
That is not transformation. That is acceleration of a process that does not deserve acceleration.
The rate reconciliation narrative generated by the language model carries forward the same framing errors, the same inconsistent categorizations, the same imprecise descriptions of permanent differences that your analysts would have written manually. The AI produces them faster. The audit risk is identical. The CFO still does not know the current-quarter ETR until three weeks after close.
EY names this failure mode directly: "unleashing powerful AI on a function nobody has re-examined may yield acceleration rather than transformation, with flawed logic producing flawed answers faster." I have been saying the same thing to Clarity Tax clients since we launched. The sequence matters. Redesign first. AI second.
What the EY Survey Is Actually Telling You
When EY says 91% of tax data is stuck in silos, they are describing a structural architecture problem. The typical F500 tax department has provision data in one workpaper tool, compliance data in a different system, ERP transaction data in SAP or Oracle with inconsistent chart-of-accounts coding across subsidiaries, and historical filings in a document management system that is not computationally accessible. These are not connected. They are not consistently structured. They are not queryable by any intelligence layer — human or machine.
When 80% say insufficient AI-ready data is their top obstacle, they are describing the consequence of that architecture. You cannot run AI on data you cannot access. You cannot run AI on data that is inconsistently coded. You cannot run AI on data that lives in a PDF.
The firms selling you AI tools are not going to fix your data architecture for you. They will sell you a tool that works within your existing architecture and produce results that reflect the quality of that architecture. The responsibility for fixing the architecture sits with the tax leader — which means you.
The Redesign That AI Requires
I have built this redesign with dozens of tax departments over the last three years, and the architecture is consistent across industries and ERP environments. It has five components:
1. A single provision data store
All provision data — current and deferred, by entity, by jurisdiction — lives in one database-backed system, not distributed across subsidiary workpaper files. This is the prerequisite for every AI application downstream. At Clarity Tax, DisclosureIQ serves as this layer. For clients on existing provision platforms, the requirement is the same: a single authoritative store that is queryable without human intervention.
2. Consistent ERP transaction tagging
Every transaction in your ERP that creates a book-tax difference needs a consistent machine-readable tag. Not a description in a notes field. A coded classification that maps to your provision model's difference categories. This is the data standardization work that consulting firms underestimate and every AI vendor hand-waves past. It takes 60 to 90 days. It is not glamorous. It makes everything else possible.
3. A maintained tax knowledge graph
This is the component that separates deterministic AI from probabilistic AI in tax. A knowledge graph is a structured, version-controlled database of tax definitions, regulatory rules, jurisdiction requirements, and their relationships. It is what allows an AI system to classify a transaction correctly — not by guessing based on similar text, but by applying a defined rule from an authoritative source. Clarity Tax maintains 1.25 million semantic tax definitions in our knowledge graph. That is the foundation of DisclosureIQ's classification accuracy. No knowledge graph means no deterministic AI. You are left with probabilistic outputs you cannot audit trail.
4. Historical provision data in structured form
Anomaly detection — the most immediately valuable AI application in provision — requires historical baselines. Three to five years of structured provision data, stored in the same taxonomy as your current-period data. Most tax departments have this data. It lives in legacy workpaper files. Migrating it to a structured format is a one-time project that unlocks years of comparative analysis.
5. Real-time ERP integration, not batch exports
Monthly batch exports from your ERP to your provision model produce a provision that is always one month stale. Real-time integration — an API connection that pulls financial data as it is posted — produces a provision that is current. The current-quarter ETR becomes available within 24 hours of period-end posting. The year-end close timeline compresses by 40% in organizations that make this shift.
AI Fluency vs. AI Literacy — EY Gets This Right
EY draws a distinction in their October series between AI literacy and AI fluency. Literacy means you understand what AI does. Fluency means you can redesign a process around what AI does well. That distinction is the difference between a tax leader who buys a vendor's AI product and a tax leader who builds an AI-ready function.
Literacy gets you to the demo. Fluency gets you to the business case. The leaders I watch who are getting the most out of AI in tax are not the ones who attended the most webinars. They are the ones who asked the right question first: "What does our tax function need to look like for AI to produce reliable results — and what stands between us and that state?"
The answer to that question is always the same five-component architecture I described above. The path to it varies by organization. The destination does not.
What to Do Monday Morning
- Audit your provision data architecture. Is provision data stored in a single queryable system, or distributed across subsidiary workpaper files? If the latter, you have a one-quarter project ahead of you before any AI deployment makes sense.
- Map your ERP transaction tags. Pull a sample of 100 transactions from your ERP that created book-tax differences last quarter. What percentage have a machine-readable classification code? If fewer than 80%, your data standardization is the first priority.
- Ask your AI vendor one question. "Is your system deterministic or probabilistic for tax classification?" If the answer is probabilistic — if the system is using a language model to guess at classification — ask what the audit trail looks like. If there is no defined knowledge graph backing the classification, you have a documentation risk.
- Define your AI-ready state. Write down, in one page, what your tax function looks like when it is ready for AI: what data is available, how it is structured, where it lives. That document becomes your transformation roadmap.
- Budget for redesign, not just tools. The EY finding that 80% of organizations are blocked by data readiness is a budget allocation finding. The money needs to go to data architecture and process redesign first. Tools come second.
Ready to build the tax function that AI requires? DisclosureIQ is built on the architecture this post describes — deterministic classification, real-time ERP integration, a maintained knowledge graph. See what it changes.