Technology Stack for Tax Compliance Operations
Every tax calculation, every provision entry, every compliance filing begins with a transaction recorded somewhere in an ERP or source system. SAP, Oracle, JD Edwards, Microsoft Dynamics, and Workday are where revenue is recognized, invoices are generated, and intercompany movements are recorded. They are not tax systems. They were never designed to be. Tax departments that treat them as close enough are building on a foundation that will eventually give way.
The structural problem runs deeper than most implementations acknowledge. Chart-of-accounts configurations are built to serve financial reporting requirements, not tax categorization logic. Account codes that satisfy a CFO's consolidation view don't map cleanly to the jurisdictional categories a tax engine needs for a correct determination. In multi-entity businesses, this compounds fast. A group operating across several jurisdictions typically runs multiple ERP instances, each configured differently, each producing subledger data in a format slightly inconsistent with the others. Invoices and purchase orders live in subledger tables that are never automatically reconciled to the general ledger at the granularity tax functions actually require. It is a quiet dysfunction, visible only to the people doing the work, and invisible to everyone making the decisions.
Deloitte's integration practice addresses this directly, building dedicated work around connecting VAT, GST, and global trade requirements within SAP, Oracle, and JD Edwards configurations. That a firm of that scale treats ERP configuration for tax purposes as its own service line is evidence enough of the difficulty involved.
Oracle Cloud EPM Tax Reporting reduces part of this burden by automatically collecting data from ERP and subledger systems. But automation propagates whatever the source produces, faithfully and at scale. The underlying configuration of those source systems still determines whether what gets collected is accurate and complete. Getting the source layer right is not preliminary work. It is the work.
Why the integration layer is the most overlooked part of the stack
Most tax departments manually re-enter data between their provision and compliance systems. This is not a fringe practice. It is a widespread operational reality, and it is the single most consequential structural failure in the average tax compliance stack.
The integration layer, comprising ETL tools, APIs, and cloud data hubs, does not generate executive enthusiasm. It doesn't calculate a tax rate or produce a return. It moves data reliably from one layer to another without human intervention. That function is unglamorous, and unglamorous functions are chronically underinvested in. The cost of that neglect surfaces at period close, under deadline pressure, when reconciliation surfaces a discrepancy no one can immediately explain and an auditor is already waiting.
Data entered twice accumulates version drift. The figures underpinning a provision calculation and those feeding a compliance filing diverge, often invisibly, until a reconciliation exercise surfaces the gap weeks after the work was supposed to be done. Manual handoffs fracture the audit trail. Period-end close becomes a firefighting exercise instead of a controlled verification. Thomson Reuters ONESOURCE Data Hub and Data Flow exist specifically to eliminate this re-entry by creating persistent, automated bridges between tax applications. But those tools only solve the problem if an organization is willing to dismantle the manual workarounds that have, for years, quietly absorbed the risk in place of something better.
In Deloitte's 2024 webcast polling, 41% of respondents identified data gathering and wrangling as their most significant Pillar Two administrative burden, placing it ahead of the actual calculations. That finding is not specific to Pillar Two. It is an integration failure, repeated at scale, now visible because a regulatory deadline has removed the option of muddling through.
Tax engines and determination — what indirect tax calculation actually requires
A tax engine does one thing with precision: given a transaction, it determines what tax applies, at what rate, in which jurisdiction, under which exemption rules. That determination must happen in real time, at the moment of invoice generation, and it must reflect current law. The complexity that justifies a purpose-built engine is not theoretical.
A business selling across multiple US states faces thousands of distinct rate and rule combinations. Jurisdictions change rates and exemption classifications continuously; product taxability determinations vary by state and sometimes by county. Add cross-border transactions and the calculation surface expands to include VAT and GST treatment, place-of-supply rules, and customs considerations. No ERP-native tax module has the rule content depth or update velocity to handle this reliably at scale. Anyone who has watched a tax team maintain rate tables in spreadsheets across forty states knows exactly how that ends: quietly and badly, discovered during an audit rather than before it.
The leading indirect tax engines, Vertex O Series, Avalara, and Thomson Reuters ONESOURCE Indirect Tax, each integrate with major ERP systems and provide continuous rule content updates as part of their service model. The content update function is not a minor feature. Maintaining jurisdiction rules in-house is practically untenable once a business crosses a meaningful jurisdictional threshold. The decision is really about which engine's content coverage and integration model fits a specific transaction profile well enough to trust.
Avalara's December 2024 acquisition of Brazil-based Oobj extended its e-invoicing capability to six Latin American countries. Indirect tax engines are absorbing e-invoicing capability, and the line between tax determination and compliance submission is beginning to blur in ways that will reshape stack configuration over the next several years.
One thing that gets papered over once a tax engine is running smoothly: an engine receiving incomplete or inconsistently structured transaction data will produce incorrect determinations regardless of how current its rate content is. The accuracy of the determination layer is bounded entirely by the quality of the source layer feeding it.
Provision and direct tax reporting — where complexity concentrates
Provision is the process of calculating a company's current and deferred income tax obligations for financial statement purposes. It is distinct from compliance filing, but it sits upstream of it, and the quality of provision work determines the reliability of the return. The platforms built for this, Thomson Reuters ONESOURCE Tax Provision, Oracle EPM Tax Reporting, CCH Tagetik, are organized around multi-entity consolidation, uncertain tax position management, and return-to-provision adjustments. Oracle EPM Tax Reporting additionally handles controversy management, R&D credits, and transfer pricing data collection within a single workflow, which reflects how much complexity now concentrates at this layer.
The provision-to-compliance handoff remains the most error-prone transition in the direct tax workflow, and the reason is structural rather than procedural. Provision is prepared under financial reporting deadlines; compliance filings follow tax authority deadlines. Different timelines, frequently managed by different teams, often without a shared data model. The reconciliation between the two defaults to a manual exercise, and manual exercises at this stage carry real risk: the kind that shows up in restatements and penalty notices.
For Pillar Two specifically, KPMG identifies SAP PaPM, SAP Analytics Cloud, Oracle EPM, CCH Tagetik, and AMANA GTC as tooling options. These are extensions and overlays on existing provision infrastructure. That matters because it means Pillar Two compliance is being constructed on architectures not originally designed with its demands in mind. The underlying requirement, consolidated effective tax rate calculations across every jurisdiction where a group operates, demands a level of data granularity that most provision tools were not originally built to produce. Whether the adaptations in place are actually sufficient is a question each organization needs to answer honestly, not optimistically.
What Pillar Two actually demands from the stack — and where most stacks fall short
Pillar Two, the Global Minimum Tax, applies to multinational groups with consolidated revenue above €750 million. It became effective in many jurisdictions on 1 January 2024, with variations by country. Any jurisdiction where a group's effective tax rate falls below 15% triggers a top-up levy, collectible by the parent jurisdiction or another designated group member. The compliance output required is the GloBE Information Return: jurisdiction-level effective tax rate data aggregated across entities sitting in separate ERPs, maintained on separate ledgers, with provision work completed in separate systems.
What this reveals about the stack is specific and uncomfortable. Companies whose ERPs were not configured to capture the data points the GloBE computation requires face retroactive enhancement work under a live regulatory deadline. Groups that built their provision workflows on spreadsheets cannot produce the required granularity; the spreadsheet approach was never designed to handle disaggregated jurisdiction-level effective tax rate calculations across a group of any meaningful size. Integration layer failures don't merely create inefficiency under Pillar Two. They become filing failures, with the legal and reputational consequences that follow.
Thomson Reuters has observed that companies with integrated tax technology platforms are better positioned to meet Global Minimum Tax compliance deadlines, and practitioner experience bears that out. PwC's Pillar Two Engine produces GloBE Information Returns and local tax forms in XML and identifies discrepancies between GIR calculations and Qualified Domestic Minimum Top-up Tax rules. That tool exists because current provision platforms, even sophisticated ones, weren't built to produce exactly what this regulation requires. Pillar Two is functioning as a forcing function for stack rationalization, and organizations that have yet to integrate their data flows are discovering the gap under conditions that don't permit a measured response.
Real-time reporting mandates and what they require from the e-invoicing layer
More than 40 countries now require real-time invoice reporting through Continuous Transaction Controls, a model in which invoices flow to tax authorities at the moment of issuance rather than in monthly or quarterly batches. E-filing is active across more than 120 countries. The submission layer is no longer optional infrastructure in most major markets.
The live mandates are specific. Belgium's mandatory B2B e-invoicing requirement took effect 1 January 2026, using Peppol BIS 3.0 and UBL 2.1 formats. Poland's KSeF system becomes mandatory from February 2026 under a clearance model, where every invoice must receive tax authority approval before it is legally considered delivered. France's mandate applies to large and medium enterprises from 1 September 2026. These are legal requirements with defined technical specifications and enforcement consequences.
The EU's VAT in the Digital Age directive, adopted 11 March 2025, mandates digital reporting requirements for B2B intra-EU transactions from 1 July 2030. The runway is longer, but the harmonization implications are significant for any business currently managing country-by-country e-invoicing solutions in isolation. The European Commission projects that ViDA will reduce VAT fraud by up to €11 billion annually and lower compliance costs for EU traders by more than €4.1 billion over ten years.
Real-time CTC mandates require the e-invoicing layer to maintain a live channel to tax authority APIs, transaction by transaction. Format compliance, whether Peppol, UBL, or country-specific XML schemas, must be handled at the point of invoice generation; it cannot be managed as a downstream reformatting exercise. Avalara's acquisition of Oobj illustrates how indirect tax engines are absorbing e-invoicing capability in direct response to this architectural pressure. For businesses operating across multiple jurisdictions, maintaining bespoke country-specific connectors internally is operationally unsustainable. The mandates themselves have made the argument for a managed e-invoicing layer that abstracts country-specific format and submission complexity.
How AI fits into the stack — and which layers it is actually changing
AI is not a replacement for the layers described above. It is being applied within and across them, and the question worth asking is which tasks it is practically changing, as opposed to which tasks are being marketed as addressable in principle. The marketing has gotten significantly ahead of the operational reality, and conflating the two is how tax departments end up investing in capabilities that don't move the needle on their actual compliance burden.
Per the 2025 BDO Tax Strategist Survey, cited by Vertex, 50% of respondents were using AI to generate summaries of complex regulations for internal executive review, and 49% were using it to highlight trends or patterns in data to support reporting and planning. These are augmentations of existing analytical work. The operational use cases already embedded in practice are more granular: sorting general ledger entries into tax codes, flagging unusual transactions before a return goes out, extracting data from trial balances and invoices in combination with robotic process automation, and reading new legislation to surface relevant credits or rule changes. Useful, real, and firmly short of transformative.
The near-term development that warrants serious attention is agentic AI: autonomous systems capable of functioning as compliance analysts, researchers, and workflow managers under human supervision. Wolters Kluwer describes CCH AnswerConnect as freeing up to 3.5 hours per week per practitioner and increasing client capacity by up to 55%. For statutory reporting specifically, agentic workflows are expected to automate document creation, data mapping, and adaptation to jurisdictional rule changes in near real time. Tax departments actively exploring AI and generative AI tools rose from 28% in 2024 to 42% in 2025, and 88% expect more AI integration within one to five years, per the Thomson Reuters Institute Corporate Tax Technology Report, 2025.
What tends to get left out of these conversations: tax authorities are deploying AI too. Over 70% now employ it in compliance and taxpayer services, per PwC citing OECD data. HMRC's Connect tool generated £4.6 billion in additional tax for 2024/25, a 35% increase over the prior period. An AI-assisted examination operates at a different level of precision and speed than a traditional audit. The data quality and audit-readiness standards required to respond have already risen. Most tax departments are treating that as a future concern. It is not.
Cloud deployment and what the shift away from on-premises means for stack decisions
On-premises solutions still held the largest overall market share at 52% in 2025, per Precedence Research. The transition is incomplete. The direction, however, is not in question. The cloud segment of the tax technology market is projected to grow from approximately $11.97 billion to $47.16 billion by 2035, per Market Research Future.
The reasons this matters for stack architecture are practical. Cloud platforms receive continuous regulatory content updates, including rate changes, jurisdiction rule changes, and format updates, without requiring IT deployment cycles. For a compliance function managing obligations across dozens of jurisdictions with continuously evolving rules, the operational gap between a patch cycle and an automatic update widens with every new mandate. API-first cloud tools integrate more readily with adjacent layers; on-premises tools frequently require custom middleware that creates maintenance debt at precisely the integration points that matter most. Real-time reporting mandates are essentially incompatible with on-premises batch processing architectures. The CTC model assumes a live, persistent connection to external systems. That assumption and on-premises architecture cannot coexist indefinitely.
The migration itself is a first-order stack challenge. Moving from on-premises ERP or provision tools to cloud equivalents is not a lift-and-shift operation. It requires decisions about data model alignment, integration redesign, and in many cases a period of parallel operation during which both environments must be maintained simultaneously. Organizations that navigate this well treat it as an architectural project with tax operations leading requirements definition, not receiving the output after IT has already made the consequential decisions. The stack decisions made during a cloud migration tend to persist for a decade or more. The ones made by default rather than by design are the ones that become the most expensive to revisit, usually at the worst possible moment.
