NHS SBS — Supplier Site derivation guidelines (AP Invoice & Supplier migration to Oracle Fusion)¶


Version	0.2 (draft)
Date	2026-05-28
Reviewer	(to be assigned — trust AP lead / SBS DM workstream lead)
Distribution	SBS DM team, trust finance leads, trust AP / Treasury, internal audit
Status	For review

Purpose. A reference for the Data Migration team covering general best-practice principles, NHS / SBS-specific risks, recommended derivation-rule hierarchy, and the questions the DM workstream should be able to answer before any open AP invoice is migrated. The immediate trigger is a DM-tool rule that derives Supplier Site from the legacy AP invoice's Supplier reference, which is unsafe for the reasons set out below.

1. Scope¶

Source: legacy non-Oracle finance system(s) — supplier master and AP invoices (open and historical).
Target: Oracle Fusion Cloud — Suppliers + Payables (AP Invoices), loaded via standard FBDI templates (SupplierImportTemplate.xlsm, ApInvoicesImportTemplate.xlsm, ExternalBankAccountImportTemplate.xlsm).
Platform context: SBS's Integrated Single Financial Environment (ISFE2) — a shared Fusion tenant with a shared chart of accounts and shared supplier master across NHS trust BUs, onboarded in waves. This shared model is the structural constraint that forces the multi-Site-per-supplier pattern this document is concerned with.
Audience: SBS DM team, trust finance leads, trust AP / Treasury, internal audit.

2. The core problem¶

Supplier and Supplier Site sit at two different grains, and conflating them silently corrupts payments:

Concept	Grain	What rides on it
Supplier	Header / party	Tax ID, header-level payment terms default, some Income Tax attributes
Supplier Site	Site record (BU-scoped via Site Assignment)	Remit-to address, remit-to bank account, pay group, invoice currency, tax registration, COS / VAT recovery defaults, IR35 / CIS attributes (at Site or Address), approval-routing inputs
Site Assignment	Site ↔ BU pairing	Liability distribution account lives here, not on the Site itself — relevant in ISFE2's multi-BU model

A legacy AP invoice's "supplier reference" almost always points to the vendor master, not to the specific remit-to / location used on that invoice. Deriving Site from the Supplier reference therefore guesses — typically by picking "primary pay site" or "first active site" — and silently mis-routes payments wherever the legacy system supported multiple remit-to addresses, factoring assignments, branch/depot codes, or BU-specific sites.

This is a defaulting rule masquerading as a derivation rule.

3. NHS / SBS-specific risks¶

The general problem is amplified by the operating context:

Multi-trust BU scoping under ISFE2. Supplier Site (via Site Assignment) is BU-scoped. A national supplier (NHS Supply Chain, AAH / Alliance Healthcare, PFI providers, major utilities, agency frameworks) has one Supplier record but many Site Assignments — one per trust BU. Deriving Site from the Supplier reference collapses trust-specific sites onto a "primary" one and routes one trust's payment to another trust's remit-to / cost centre / liability account.
Better Payment Practice Code (BPPC). NHS bodies publicly report against the 95%-within-30-days target (DHSC guidance, trust annual reports). Mis-routed or rejected payments degrade BPPC stats that appear in trust board papers.
UK GDPR / DPA 2018 and NHS DSPT. Supplier records for NHS often include sole-trader practitioners (locums, bank-staff agencies, interpreters) where the "supplier" is effectively a person. Wrong Site = wrong bank account = personal-data payment to wrong account = a reportable personal-data breach under UK GDPR Article 33, submitted via the NHS Data Security and Protection Toolkit.
VAT and COS recovery (s41 VATA 1994 / HM Treasury Contracting-Out Direction). NHS bodies recover VAT on a defined list of contracted-out services per the HMT COS Headings list. COS heading and recoverability is commonly configured at Site / Distribution level. Wrong Site can silently push transactions into the wrong COS bucket and misstate the trust's VAT return.
IR35 / off-payroll (ITEPA 2003 Chapter 10, in force for the public sector since April 2017). Public-sector engagers must determine deemed-employment status. PSC supplier records can carry the IR35 determination / tax treatment at Site or Address level. Defaulting Site here can mis-apply deemed-employment tax.
CIS (Finance Act 2004, Part 3). Estates / PFI / capital works withholding treatment is Site-attribute driven. Wrong Site = wrong CIS treatment = HMRC penalty exposure. Note also the parallel reporting obligations: CIS300 monthly returns for CIS, and RTI / off-payroll reporting for Chapter 10 — these are the UK equivalents of the "1099-style" supplier reporting some DM tools assume.
SBS shared-service blast radius. A bad derivation rule does not affect one finance team — it affects every trust on the wave, plus historical data feeding the NHS Provider Finance Returns / NHSE consolidation. Shared-service finance migrations have a track record of payment-routing defects of this kind; Supplier Site is a recurring root cause.

4. General data-migration derivation principles¶

These hold for any large ERP migration, NHS or otherwise. They are the principles the rule in question must be tested against.

Derive from the transaction, not the master. Site must come from fields on the legacy invoice (remit-to address, bank account ref, pay-to vendor code, branch/location code, matched PO) — never from the supplier record. If the legacy invoice does not carry a site-equivalent, that is a source data gap to remediate, not a derivation to invent.
One hop maximum, and every hop is a documented cross-reference (XREF). Legacy invoice field → XREF table → Fusion Site. No chained inference ("supplier → default site → BU"). Each XREF row has a named business owner who signs it off.
No "primary / first / default / active" fallbacks in derivation logic. These rules pass UAT and fail in production. Unmappable rows go to a reject bucket with a business owner — not to a default value.
Pre-validate at extract, not at load. Run the derivation in the source / staging layer and produce a coverage report (% deterministic, % explicitly signed-off exception, % silent default, % unmapped) before the DM tool loads anything. The bar for open payable invoices is 100% deterministic-or-signed-off-exception, 0% silent default. Genuine exceptions (sole-trader locums, one-time vendors, legacy records with no remit-to) are acceptable when they are named and signed for; what is not acceptable is the DM tool silently filling them in.
Site choice has money consequences — treat it as a controlled mapping, not a transformation. Remit-to bank is attached to Site. Wrong Site = wrong bank = wrong payee. This belongs in a signed-off mapping workbook owned by AP / Treasury, version-controlled, with a diff between cutover rehearsals.
Reconcile on liability + remit-to, not just on invoice count and value. Standard cutover recon catches totals; Site errors only surface when you reconcile liability distribution by BU and open-invoice remit-to by supplier. Add both to the cutover sign-off pack.
Open vs. historical invoices have different bars. Closed / historical invoices migrated for reporting can tolerate a documented "Site = HISTORICAL" bucket. Open invoices going to payment cannot — they need the real Site, deterministically derived.

5. Recommended Supplier Site derivation hierarchy¶

Replace any "derive Site from Supplier reference" rule with the following hierarchy. Evaluate in order. Every step sources from invoice-level legacy fields, never the supplier master. If a row falls past step 5, it does not load — it goes to an exception queue.

#	Source on legacy invoice	Resolves to Fusion Site via	Notes
1	Matched PO reference	Site inherited from the PO schedule on the already-migrated PO	Canonical path for PO-matched invoices; not a "lookup" — Fusion treats this as the authoritative source
2	Remit-to address ID / bank account ID	XREF table	Strongest signal for non-PO invoices; matches the money path
3	Location / branch / depot code	XREF table	Use where legacy system models multi-location vendors this way
4	Trust BU + Supplier	XREF, only if that Supplier has exactly one Site Assignment in that BU	Deterministic single-match only; not a default
5	—	Reject to AP exception queue, owned by the trust AP lead	Treat as source-data remediation, not DM-tool defaulting

The FBDI invoice row pairs VENDOR_NUM / VENDOR_ID (Supplier) with VENDOR_SITE_CODE (Site) on the same line — make this pairing explicit in the staging tables so reviewers can see Supplier-vs-Site at a glance.

Volume falling to step 5 is the size of the source-data remediation backlog — it is not a problem for the DM tool to "solve" by defaulting.

Site is the headline problem, but three adjacent areas fail in production for the same underlying reason — derivation from the wrong grain or unverified source. The DM team should treat each as a peer concern, not an afterthought.

Bank account migration (ExternalBankAccountImportTemplate.xlsm). Bank accounts are a separate FBDI object with their own validation: sort code / account number modulus checks, IBAN format, Confirmation of Payee (CoP) name-matching at the receiving bank, and screening against the OFSI / HM Treasury consolidated sanctions list. A correctly-derived Site pointing at an un-validated bank account still results in a failed or misdirected payment. Bank-account population needs the same coverage report as Site.
Supplier deduplication and n-to-1 merges. SBS migrations routinely consolidate duplicate supplier records across trusts onto a single shared master. The supplier-site XREF must be built after the dedup decisions are signed off, otherwise the Site mapping is built on sand. Show the dedup decision log alongside the XREF.
Approval routing. Site can drive AP approval rule selection (invoice approval hierarchies, hold reasons). A defaulted Site can route invoices to the wrong approver, not just the wrong bank. Confirm the approval ruleset's inputs and whether Site is one of them in the target config.
Cutover blackout / in-flight invoices. Document how invoices created in the legacy system during the cutover freeze are handled: re-keyed, deferred-then-loaded, or rejected. This is where defaulting rules get reintroduced under time pressure.

7. Questions the SBS DM team should be able to answer¶

Put these to the DM workstream in writing. Each is a gate, not a discussion point.

Coverage report. For the latest mock load, of all open AP invoices, what percentage of VENDOR_SITE_CODE values were populated from a deterministic XREF vs. back-filled by the DM tool's derivation logic vs. routed to exception? Show the split by trust BU and by supplier.
Multi-BU national suppliers. For every supplier that exists in more than one trust BU, show that the derived Site is correct per-BU. Any supplier appearing in >1 BU with only one derived Site is a defect.
Tax attribute impact. What is the rule's behaviour for COS heading, VAT recoverability, IR35 determination, and CIS status when Site is defaulted? If those attributes ride on Site or Address, the default is silently changing tax treatment — quantify the population affected.
Open-invoice exception path. What is the reject / exception path for open AP invoices where Site cannot be derived deterministically from invoice-level fields? Defaulting open AP invoices to a guessed Site fails BPPC and DSPT — show the path that does not.
Named accountable owner. Who in each trust finance team is the named signatory on the supplier-site XREF? In an SBS shared-service migration this must be the trust DoF or delegate, not the DM-tool configuration.
Reconciliation pack. Does the cutover reconciliation pack include liability distribution by BU and open-invoice remit-to by supplier, in addition to invoice count and value totals?
Historical vs. open treatment. Are closed / historical invoices loaded with a distinct "HISTORICAL" Site treatment so they cannot be paid? If not, what stops a historical invoice being picked up by a payment run on a defaulted Site?
Bank accounts and screening. Show the same coverage report for ExternalBankAccount records: modulus-validated, CoP-matched, OFSI-screened. What is the rule when CoP returns a mismatch?
Supplier dedup decisions. Show the dedup decision log used to build the supplier master. Was the Site XREF built before or after dedup sign-off?

8. FBDI verification check¶

The Oracle invoice FBDI exposes VENDOR_SITE_CODE as the Site key, paired with VENDOR_NUM / VENDOR_ID as the Supplier key on the same row. The single most informative artefact the DM team can produce, for each mock load, is:

Of N open invoice rows, X were sourced from a deterministic XREF on an invoice-level field, E were routed to a signed-off exception bucket, Y were silently filled by the DM tool's derivation logic, Z were rejected.

That X : E : Y : Z split is the audit-trail question internal audit and the trust's external auditors (typically Grant Thornton or Mazars for NHS bodies) will ask. The target is Y = 0.

9. Audit, governance, and sign-off¶

The supplier-site XREF is a controlled document, owned by trust AP / Treasury, signed off by the trust Director of Finance (or delegate), and version-controlled across cutover rehearsals.
The DM tool's derivation rules are subject to change control — not configured locally and not changed between mock and go-live without re-sign-off.
Both internal audit and the trust's external auditors should see the coverage report and the reject-queue ownership before cutover sign-off.

9.1 Sign-off matrix¶

Artefact	Owner	Signatory at each mock	Signatory at go-live
Site derivation rule hierarchy	SBS DM lead	SBS DM lead + trust AP lead	Trust DoF (or delegate)
Supplier-site XREF	Trust AP / Treasury	Trust AP lead	Trust DoF (or delegate)
Supplier dedup decision log	Trust AP / Treasury	Trust AP lead	Trust DoF (or delegate)
Coverage report (Site, bank, dedup)	SBS DM lead	SBS DM lead + trust AP lead	Trust DoF (or delegate) + internal audit
Reconciliation pack (liability by BU, remit-to by supplier)	SBS DM lead	Trust AP lead	Trust DoF (or delegate) + internal audit

10. Summary — the single ask¶

Replace the "derive Site from Supplier reference" rule with the hierarchy in §5, produce the coverage report defined in §8 at every mock load, and route everything that cannot be deterministically derived to the trust AP lead's exception queue per §5 step 5. Everything else in this document supports that one change.