A UAE Shared Service Centre can run every group entity's outbound invoicing through the same PINT-AE workflow. It cannot inherit the tax position accountability that belongs to each entity individually, and Chapter 11 of Real-Time Tax Transformation (forthcoming) is specific about why the standard functional RACI — tax defining treatment, IT configuring the mapping, operations generating transaction data — doesn't resolve the gap on its own once execution moves into a centralised SSC delivery model.
The functions a RACI assigns positions to frequently don't execute those responsibilities directly in a large organisation. They define them. Execution sits in an SSC processing order-to-cash, procure-to-pay and record-to-report on behalf of multiple business units and legal entities, built around efficiency and standardisation rather than the entity-specific governance boundaries a real-time tax environment requires. Understanding where the SSC sits in the RACI, and where the boundary between the SSC and the functional team opens a governance gap of its own, is a distinct accountability risk, not an organisational footnote.
Where the gap actually opens
The SSC is Responsible for the process; the functional team is Accountable for the tax position it produces. When the SSC's day-to-day execution reveals a scenario the treatment documentation never anticipated — a counterparty configuration the master data rules don't resolve, a transaction type nobody wrote a policy for — the question of who owns that gap is the failure this problem is really about. A concrete version of it: an SSC applying one VAT treatment uniformly across group entities whose individual registration circumstances actually differ. The SSC has executed its process correctly and consistently. The tax position for at least one entity is wrong, and the SSC's own service-level agreement was never written to catch it, because SLAs govern process throughput and turnaround, not the substantive accuracy of a tax treatment applied across entities with different facts.
The transmission layer sharpens this. In a large organisation the SSC is the function closest to the actual moment of transmission — closer than tax, closer than IT — because it operates the system feeding the ASP and receives the confirmation and rejection responses first. If the RACI doesn't give the SSC a defined role in exception triage, with a defined escalation path to tax when a rejection carries a treatment question rather than a data error, the exception sits with the SSC team until someone in tax discovers it at the next scheduled review. Under a real-time clearance model, that discovery cadence is too slow to matter.
What closes it
The practical answer Chapter 11 sets out is a named liaison accountability at the SSC boundary — a role specifically responsible for the translation between policy and execution, who consults the functional team when the SSC hits a scenario the policy doesn't resolve, and who ensures the SSC is consulted before a policy change reaches it as an unqualified instruction to update a field or apply a new rate. In most organisations this translation happens informally today, run by whoever has spent enough time in both environments to bridge them. A real-time correction window doesn't leave room for a process that depends on institutional memory and personal relationships. The liaison role needs to be written into the RACI before go-live, not discovered as a gap the first time a production exception has nowhere defined to go.