When a PINT-AE invoice hits an ambiguous VAT treatment, the question that matters is not what the correct answer is — it's who has the authority to decide it before the invoice transmits.
Under the old compliance model, that question rarely needed a formal answer. Tax reviewed positions in batches, ahead of a periodic return, and an ambiguous treatment could sit on a working list until someone with the right seniority looked at it. Real-Time Tax Transformation (forthcoming) is direct about why that arrangement no longer holds: once a transaction transmits within hours of the underlying business event, the correction window the old model depended on is gone at the exact moment it matters. The authority sees the position before the enterprise's own review cycle would have reached it. An escalation path improvised in the moment — the exception lands with whoever is available, and gets resolved or passed up based on instinct rather than a documented threshold — was tolerable when there was time to catch the mistake later. It is not tolerable when there is no later.
The book sets out decision ownership across three tiers, defined in advance rather than worked out when an exception arrives. The first tier is operational: exceptions the billing team or AP processor can resolve on sight, because the correction is factual and does not touch the tax position itself — a missing field value, a TRN that needs confirming against the registry. The second tier is the tax escalation level: a rejection reason code pointing to a classification issue, a transaction type the standard playbook does not cover, a credit note linkage that cannot be verified against the original invoice. These require a named tax professional's judgement, inside the correction window, not at the next scheduled review. The third tier is external advice — a genuine regulatory ambiguity, a novel transaction type with no established treatment — with the threshold for reaching it set in advance, not decided case by case.
What makes an escalation model operational, rather than a policy document nobody consults, is three things defined before an exception arrives: the specific conditions that move a case from one tier to the next, named by rejection code, value threshold or transaction type rather than left to "when in doubt"; a named role with the documented decision right at each tier, with a deputy covering absence; and a time window for resolution at each tier, built into the process rather than calculated on the fly. An escalation model that names who decides but not the window they have to decide in has solved only half the problem.
The link to tax position defensibility is where this stops being a process nicety. An ad hoc decision, resolved by whoever happened to answer and recorded nowhere but an email thread, is a weaker position to defend under audit than one made against a pre-agreed escalation framework with a documented decision record. India's GST e-invoicing experience — the world's largest implementation — puts a number on what happens without that framework: roughly 80% of notices enterprises received were system-triggered and preventable, positions produced by automated systems operating without a governance architecture that made them defensible. A RACI that names a decision owner for each tier, before the invoice transmits, is the difference between an escalation the enterprise can point to and one it has to reconstruct after the fact.