Building a Back Office Center of Excellence

Most back office centres of excellence are a renamed team. Someone in group finance is given a title, two analysts and a mandate to "drive standardisation across the entities", and eighteen months later the CoE produces a quarterly deck that the entities read politely and ignore. The processes are still different in every country, the automation pilots have not scaled, and the best people have moved on because the role turned out to be documentation. The pattern is common enough to be worth examining structurally, because a back office CoE either holds real decision rights over how processes work or it holds nothing. There is no useful middle position where a team with no authority persuades operational managers, whose bonuses depend on their own results, to adopt a standard that costs them short-term performance.

What a CoE is actually for

The honest definition: a CoE exists to hold capability that is uneconomic to replicate in every operating unit, and to own the standards that make cross-unit comparison and shared tooling possible. That gives it three legitimate functions and rules out several others. Process ownership. Someone must own the end-to-end design of order-to-cash, procure-to-pay, record-to-report and hire-to-retire, across entities — including the authority to say no to a local variation. Without that authority, the process design role is advisory and the standard is optional, which means it does not exist. Scarce capability. Automation development, data and analytics engineering, controls design, tax technology, systems configuration. These require skills that a single entity cannot justify hiring and cannot retain if it does, because the work is not full-time at entity scale. Performance visibility. Common definitions, instrumented metrics, comparable reporting. This is the function most often claimed and least often delivered, because comparability requires standardisation upstream — you cannot benchmark days-payable-outstanding across entities that define invoice receipt date differently. What a CoE is not for: executing transactions (that is a shared service centre, a different thing with different economics), owning outcomes it cannot influence, or existing as a career staging post. The conflation of CoE and shared service centre is the most common design error, because it produces a team that is both the transaction processor and the arbiter of process design — and processing volume always wins that argument.

The design decisions that determine whether it works

Decision rights, written down. Which decisions does the CoE make, which does it recommend, and which belong to the entity? Ambiguity here is not resolved by goodwill; it is resolved by whoever controls the budget, which is usually the entity. Write the split explicitly and have it signed by the CFO. Reporting line and funding model. A CoE funded by entity chargeback serves whoever pays most. A CoE funded centrally can hold a standard. Chargeback models look disciplined and produce capture. Staffing that is not a consolation prize. The CoE needs people who could hold senior operational roles, because the work requires credibility with operational managers. Staffing it with those who were available is the most reliable way to guarantee it is ignored. A small number of standards, seriously enforced. The failure mode is a 200-page global process manual that nobody reads. The alternative is a short list of non-negotiables — chart of accounts structure, master data definitions and identifiers, approval thresholds, key control points, metric definitions — with genuine local freedom everywhere else. Standardise the interfaces, not the working. Deliverables with dates. A CoE that delivers nothing operational in its first six months loses its mandate. Pick one process, one entity, one measurable improvement; deliver it; then use it as evidence.

Practical Guidance for CoE Design Consultation

• Write the decision rights split before hiring anyone. If the CoE cannot refuse a local variation, it is an advisory function — name it accurately and set expectations accordingly.
• Fund it centrally rather than by entity chargeback. Whoever pays sets the agenda, and standards funded by their subjects do not survive.
• Separate the CoE from the shared service centre. Transaction execution and process design in one team means volume pressure always beats design discipline.
• Limit non-negotiable standards to a page. Master data identifiers, chart of accounts, control points, approval thresholds and metric definitions; local freedom on everything else.
• Staff it with people the entities respect. Credibility with operational managers is the working currency, and it cannot be conferred by an org chart.
• Deliver one measurable operational win in the first two quarters. Evidence buys mandate; frameworks do not.
• Define metrics before measuring anything. Comparability requires agreed definitions upstream, or benchmarking becomes an argument about arithmetic.
• Build an explicit knowledge transfer obligation into every CoE engagement. Capability that stays in the centre creates dependency, which entities correctly resist.

The Regional Dimension

Gulf group structures make the CoE case stronger and the execution harder, in roughly equal measure. The multi-entity reality is the starting point. A regional group typically comprises many legal entities across mainland and free zone jurisdictions in several countries, often assembled through acquisition and family-business consolidation rather than organic growth. Each arrived with its own ERP or accounting system, its own chart of accounts, its own approval customs and frequently its own finance leader with a long-standing relationship to the shareholder. The duplication is genuine and expensive — fifteen entities each running their own version of accounts payable — which makes the economic case for a CoE unusually strong. The governance case is unusually difficult for exactly the same reason: entity autonomy is often historical and personal, not structural, and a central standards function can read as a challenge to relationships that predate it. The regulatory divergence between jurisdictions sets a hard limit on how much can actually be standardised, and it is worth being precise about it. Payroll differs materially: wage protection system submission in the UAE, GOSI contributions in Saudi Arabia, end-of-service gratuity calculations that vary by jurisdiction and accrue with tenure, and nationalisation requirements — Emiratisation and Saudisation — with their own reporting and workforce composition obligations. Tax differs: UAE VAT and corporate tax, Saudi VAT with e-invoicing clearance that constrains when and how an invoice can be issued, withholding tax on cross-border service fees, and free zone entities with activity restrictions that limit what work can be performed for whom. A CoE that tries to standardise the process output will fail; one that standardises the data model, the control points and the metric definitions while allowing jurisdiction-specific execution will not. Bilingual master data is where a regional CoE can deliver its most defensible early win. Supplier, customer and employee records exist in Arabic and English with inconsistent transliteration, and the same counterparty appears several times across entities under different spellings. Establishing identifier-based master data standards — trade licence number, tax registration number, establishment card, IBAN as mandatory keys rather than names — solves a problem every entity recognises, produces measurable duplicate reduction, and creates the foundation for group reporting. It is also politically safe, because nobody defends duplicate suppliers. Two further notes. Talent economics favour the model: employment-linked residency makes turnover disruptive and tacit process knowledge fragile, so concentrating scarce capability — automation, tax technology, controls design — in a regional centre is more defensible here than in markets with deeper local labour pools, and Dubai, Riyadh and Cairo all support that concentration. But the nationalisation dimension cuts across it: a CoE that consolidates roles out of local entities may conflict with Emiratisation or Saudisation commitments, and the more durable framing is to build the CoE as a development and career-path vehicle for national talent in high-skill roles rather than as a headcount reduction mechanism. Finally, data residency now constrains design: if a Saudi entity's data cannot leave the Kingdom, a Dubai-based CoE can own the standard but may not be able to process the data, which argues for a federated model — central design authority, in-country execution — rather than physical consolidation.

The objection worth taking seriously

The strongest argument against CoEs is that they add a layer of coordination cost to solve a problem that better systems and clearer accountability would solve more cheaply. A group running one ERP instance with a common chart of accounts does not need a standards body to enforce consistency; the system enforces it. Much of what CoEs spend their time on — reconciling definitions, chasing entity compliance, producing comparative reporting — is work created by fragmentation that the CoE is not empowered to fix. Where the real problem is fifteen accounting systems, a CoE is a compensating control for an architecture decision, and an expensive one. The uncomfortable question worth asking before establishing one: would this budget deliver more if spent on consolidating the systems instead? There is also a fair criticism about centralisation's failure modes. CoEs drift toward designing for their own convenience, producing standards that optimise group reporting while making local operations worse — additional data fields nobody uses locally, approval steps that slow entity decisions, monthly submissions that consume a week of a small team's capacity. Entities' resistance to central standards is frequently rational rather than parochial, and a CoE that cannot distinguish legitimate local requirements from mere preference will either impose damage or lose credibility. The discipline that helps is simple and rarely applied: every standard the CoE imposes should name what it costs the entity and why the group benefit exceeds it. And a proportionality point. Below roughly five entities or a few hundred million in revenue, a CoE is usually two people and a title, and the same outcome is achieved more cheaply by giving one senior person in group finance explicit process-design authority and the time to use it. The structure matters far less than whether somebody has the authority to say no.

Common Questions

How is a CoE different from a shared service centre?

A shared service centre executes transactions at scale; a CoE owns process design, standards and scarce capability. They have different economics, different staffing profiles and different success measures, and combining them means processing volume pressure will consistently override design discipline.

What is the most common reason CoEs fail?

No decision rights. A team asked to drive standardisation without the authority to refuse a local variation, funded by the entities it is meant to govern, will produce documentation instead of change.

How should a CoE be measured?

On outcomes it controls: standards adopted and enforced, capability delivered to entities, measurable process improvements attributable to its work. Measuring it on group financial results creates accountability without authority, which is demoralising and uninformative.

Does AI change the case for a back office CoE?

It strengthens it, and it also changes what the CoE should be doing. AI capability is exactly the kind of scarce, fast-moving competence that no single entity can build or retain — prompt and workflow design, evaluation of vendor claims, quality monitoring, and the judgement about which processes are safe to automate. More importantly, the value depends on precisely what a CoE is supposed to own: consistent master data, documented process definitions, clear control points and agreed metrics. Organisations with fifteen different definitions of an approved invoice cannot deploy a single automation across entities, and pointing models at inconsistent data produces confident, divergent answers. Two governance responsibilities are newly urgent and naturally sit in a CoE: maintaining an inventory of where AI touches back office processes — including features vendors add without asking — and owning the quality monitoring regime, because sampled error rates and drift detection are specialised work that entity teams will not do well. The caution is that a CoE running AI pilots in a lab while entities process transactions manually is the old failure in new clothing: the test remains whether something shipped into production and someone measured it.

---

CoE Design Consultation — write the decision rights down first; a standards function that cannot refuse a local variation is an advisory team with an ambitious name.