Most tax automation projects succeed at the high-volume end of the tax function and fail at the low-volume end — the Tax Orchestration Curve™ explains why that failure pattern is structural, not accidental.
Picture a tax function's full range of activity plotted against two things: how much volume moves through it and how much complexity each item carries. Data extraction, validation and reconciliation sit at one end — high volume, comparatively low complexity, the kind of repetitive work automation was built for. Tax determination, interpretive judgement and reporting sit at the other — low volume, but complexity that peaks exactly where the volume thins out. The Tax Orchestration Curve™ names this shape directly: volume is highest where complexity is lowest, and complexity is highest where volume is lowest. The two move in opposite directions across the same function.
The reason automation projects fail is that most are built to address only one end of that curve. A pitch built around "automating the tax function" is usually, on inspection, a pitch about the high-volume end — extraction, matching, reconciliation — because that is where automation's return is easiest to demonstrate and the technical problem is comparatively tractable. What it does not address is the low-volume, high-complexity end, where a determination requires judgement that cannot be reduced to a rule set applied uniformly across every transaction. A tax function that automates the volume end and stops there has solved the part of the problem that was already the least risky, and left the part that generates penalty exposure, audit findings and defensibility gaps exactly as manual, exactly as inconsistent and exactly as dependent on institutional memory as it was before the automation project began.
The Curve's practical claim is that orchestration — not automation on its own — is what closes the gap between the two ends. Orchestration means designing the handoffs between people, data, process and technology so the high-volume end runs with minimal human involvement and the resulting output feeds directly into the structures that support the high-complexity end, rather than the two operating as separate initiatives that happen to share a budget line. A tax function that has built genuine real-time tax governance — structured master data, a defined escalation model, a Continuous Controls Environment™ that catches issues before transmission rather than after — has already built the orchestration logic the Curve describes, even if nobody used that term for it. Automating the volume end on top of that foundation extends a working model. Automating the volume end without it produces a faster version of the same unmanaged complexity, arriving at the same unresolved judgement calls with less time to catch them before they transmit.
This is the same argument agentic AI adoption in tax makes from a different angle: the enterprises that get genuine value from AI in their tax function are not the ones that bought the best model, they are the ones that had already done the governance work — data structured at source, escalation tiers defined, decision rights assigned — that the high-complexity end of the curve requires regardless of which technology executes the high-volume end. A business evaluating its next automation investment should ask which end of the curve the investment actually reaches, and whether the orchestration connecting the two ends exists yet or is still assumed to build itself once the automation is switched on.