Global Business Services: Where Business Central and D365 F&O Still Need Custom Work

Before Fintask, I joined a global automation project early in my career. That work led to winning the Global Business Solutions Innovation Award with Pfizer and a mention in Accountancy Ireland magazine. It wasn't a Fintask client engagement -- it's personal career background, and it's why this article is written with direct experience of what a centralised finance operating model actually requires, not just ERP-vendor theory. More on that on the About page.

A shared services centre (SSC) is a centralised function -- typically one location or a small number of regional hubs -- that runs standardised finance, HR or IT processes for multiple business units or legal entities within a group, replacing the finance team each entity used to run on its own. Global business services (GBS) is the same idea taken further: instead of separate centres per function, one governance structure runs finance, HR and IT shared services together, under shared metrics and often a shared technology stack.

For finance specifically, that means one centre running procure-to-pay (P2P), order-to-cash (O2C) and record-to-report (R2R) for every entity in the group, instead of each entity keeping its own AP clerk, credit controller and month-end routine. The pitch is standardisation and scale. The reality most GBS finance leaders live with is an ERP that was configured, one entity at a time, for the exact decentralised model the centre was built to replace.

The ERP gap -- the space between what an ERP records and what the actual finance process requires -- exists in every company. A GBS organisation feels it more acutely because the same gap has to be closed at scale, across entities, by a team that doesn't sit inside any one of them.

• One process, many entities. A single-entity AP team knows its 40 suppliers and how each one bills. A P2P tower serving 15 entities inherits 15 sets of supplier relationships, chart-of-accounts quirks and approval hierarchies -- and is measured on running them as one standardised process anyway.
• The ERP was configured entity-first. Business Central and D365 F&O both support multi-entity deployments, but workflow rules, approval hierarchies and reminder terms are configured per company or legal entity, not per process-across-entities. A GBS centre wants one O2C dunning cadence with entity-level exceptions; the ERP gives you N separate configurations that happen to look similar on the day they were built.
• Standardisation is the mandate, not a nice-to-have. A single-entity finance team can tolerate a slightly different process for one awkward customer. A GBS centre is judged on SLA adherence and unit cost per transaction across the whole portfolio, so every entity-level exception is a real cost to the model, not a shrug.
• The team doesn't own the exceptions. When something needs entity-specific judgment -- a local tax rule, a relationship-sensitive customer, a statutory quirk -- the GBS centre often has to route it back to someone at the entity, because that context was never centralised. Neither ERP has a native concept of "this needs to leave the centre and come back."

Tiered support is the standard way a GBS centre organises its own workload, borrowed from IT service management. L1 handles high-volume, low-judgment transactions against documented rules. L2 handles exceptions that need process expertise but not entity context. L3 -- often sitting back at the business unit, not in the centre at all -- handles anything that needs local knowledge: a tax authority relationship, a customer the sales director manages personally, a statutory filing quirk.

Service-level agreements (SLAs) formalise the deal between the centre and the business units it serves: invoices processed within a set number of days, disputes acknowledged within a set number of hours, a defined escalation path when the centre can't resolve something on its own. Process ownership sits in the centre -- one person or team owns the P2P process end to end, globally, rather than each entity's finance lead owning their own version of it. Neither ERP has a native object that represents any of this: no SLA timer, no tier field, no way to mark "this process is owned centrally but this specific exception belongs to the entity."

Both ERPs are capable multi-entity platforms. The friction isn't a defect -- it's a mismatch between what they were designed to model (an entity's finance process) and what a GBS centre needs to run (one process, instrumented and routed across many entities).

Business Central's companies and D365 F&O's legal entities are each configured independently: number sequences, approval workflows, reminder terms, dimensions. A GBS centre wants to define one P2P workflow once and apply it everywhere with documented, minimal per-entity variance. The ERP's natural unit of configuration is the entity, so "one process, many entities" has to be built and maintained as N near-identical configurations -- which drift apart over time unless someone actively governs them, and usually nobody's job description says they do.

Native approval workflows in both ERPs route within an entity, to users provisioned in that entity's own security context. A GBS centre's task queue needs to route across entities to whichever analyst or tier is free and qualified, then escalate to the right business-unit contact when it hits an L3-class exception -- a routing model closer to a service desk than a finance module. Neither ERP ships that out of the box.

Native financial reporting in both ERPs is built around the legal entity: a trial balance, an aged debtors report, a purchase ledger, per company. A GBS centre is managed on service-line productivity -- AP invoices processed per FTE this week, O2C days sales outstanding across the whole portfolio, R2R close-task completion rate -- cut by process, not by entity. Getting that view natively means exporting N entities' worth of reports and reassembling them by process by hand, which is exactly the manual reassembly this whole pillar exists to eliminate.

To be direct: Fintask has not delivered a GBS or shared-services transformation platform for a client. This isn't a case study dressed up as one. What we have built, in production, is the exact architecture pattern a GBS centre needs -- aimed at a different label. Three production builds, each honestly framed for what it actually was, and what it maps onto in a GBS context.

For a US insurance services firm we built an AR collections platform chasing $11.8M open across 7,700+ invoices, from ~2,500 individual claims adjusters spread across 1,200 carrier customers. This wasn't built for a GBS organisation -- it was one company collecting from many payers. But the shape is the GBS pattern exactly: one centralised team running one standardised process against a large and varied set of counterparties, with a tiered escalation model (four tiers, analyst to executive) and counterparty-level exceptions handled without breaking the standard cadence for everyone else. A P2P or O2C tower inside a GBS centre needs precisely this: standardised rules for the volume, a defined and auditable path for the exceptions, and one risk-scored queue instead of an inbox per relationship. Full detail in the Business Central AR automation guide.

For a Norwegian equipment rental group we built a Gold layer on Microsoft Fabric with tables explicitly structured for entity-aware reporting -- revenue by entity, exposed through a Gold SQL endpoint that both Power BI and an AI collections agent read from daily. That build served one Business Central tenant, not a multi-entity GBS estate, but the underlying requirement is identical to what a GBS reporting layer needs: business-shaped tables that can be sliced by process or by entity on demand, instead of native ERP reports that only slice one way. See the Microsoft Fabric for finance teams guide.

For a Canadian industrial safety distributor we built an AP invoice-matching pipeline against Infor CloudSuite Distribution -- deterministic PO/SKU/unit-of-measure matching per supplier, an AI fallback for the genuinely inconsistent cases, and a single controlled write path back into the ERP once an invoice is fully matched and approved. Not a GBS build either. But a P2P tower serving many entities faces the same problem multiplied by entity: every entity's suppliers bill slightly differently, and the fix isn't looser matching, it's per-relationship rules with a shared exception queue -- exactly the pattern this build runs. See the AP automation for Business Central and D365 F&O guide.

Extending that pattern from a single entity to a GBS centre means adding five specific things on top of it -- none of them exotic, all of them absent from both ERPs natively:

• An entity dimension on every record, everywhere. Tasks, exceptions, SLA timers and activity logs need to carry entity as a first-class field, not an ERP company code buried in a lookup -- so the same data can be sliced by process for the centre's own KPIs and by entity for the business unit it serves.
• SLA timers as data, not a spreadsheet someone updates. Time-to-acknowledge, time-to-resolve and breach status need to be computed fields the centre and the business units can both see live, feeding the same structured activity trail this pillar's other builds already produce for collections and matching.
• Tier-aware routing. A task queue that knows which tier a given exception needs, routes L1-resolvable work to whoever's free in the centre, and escalates L3-class exceptions to a named business-unit contact -- with the SLA clock still running while it's outside the centre's hands.
• Entra ID roles mapped to the GBS org chart, not the ERP's. Process owner, L2 analyst, business-unit approver and executive sponsor are GBS roles, not ERP roles -- role-based access in the automation layer should mirror the delivery model, not the entity security groups the ERP happens to use.
• The ERP stays read-only wherever the process allows it (as in the AR pattern), with one controlled write path where posting is genuinely required (as in the AP pattern) -- the same rule this pillar applies everywhere, now instrumented per entity instead of per company.

The honest read, consistent with the rest of this pillar: if your GBS centre's process variance across entities is genuinely low and a generic workflow tool's configuration options cover it, that's the faster and cheaper route, and we'd say so directly in an assessment. The custom route earns its cost when the variance is real -- different entities, different supplier bases, different statutory quirks -- which describes most GBS centres above a handful of entities.

If you're running or building a GBS or shared-services finance function on Business Central or D365 F&O, three questions determine what to build first: how many entities sit under the centre today, and how much of their process variance is real versus just historical drift; do SLAs between the centre and the business units exist anywhere outside a spreadsheet; and where does your reporting currently break -- by entity when you need it by process, or the reverse?

Those are exactly what our AI readiness assessment works through. For the deterministic-plus-exception-queue pattern this article draws on, see the AR automation and AP automation guides; for the entity-aware reporting layer, see Microsoft Fabric for finance teams; for the broader pattern across this pillar, see ERP finance automation.