Centralized procurement in D365: global address book + shared vendors

Multi-legal-entity enterprises standing up centralized procurement on D365 Finance face a recurring master data problem. The same vendor gets purchases from multiple LEs, each with its own currency, tax rules, and approval hierarchy. Without discipline, the same vendor ends up configured three or four times - different addresses in each LE, different contact emails, different payment terms that don't actually reflect the contract.

Teams reach for custom sync services or per-LE vendor duplicates. Neither is necessary.

The wrong answers in procurement design

Configure separate vendor records per LE with custom sync. Adds a custom integration service between LEs to keep vendor data aligned. The service becomes a dependency that has to be maintained, monitored, and upgraded indefinitely. Every field addition requires integration changes.

Route all requisitions through manual intercompany transactions. Avoids duplicating vendors but shifts the pain to operations. Every cross-LE purchase becomes a multi-step manual process. Procurement teams resist; shadow-procurement workarounds appear within a month.

Enable procurement categories per LE and consolidate via Excel Power Query. Looks simple in design but means spend visibility lags behind transactions by whatever the reporting cycle is. CFO asks for "current total spend with Vendor X" and waits for a manual refresh.

The pattern that scales

The global address book plus centralized procurement features in D365 F&O.

What each piece does:

Global address book is the party-based master data layer that sits above legal entities. Each vendor is a party in the global address book with one canonical record. The party is released to each LE that transacts with it, with per-LE vendor metadata layered on top (payment terms, posting profile, default financial dimensions).

Centralized procurement allows one LE to purchase on behalf of another. The purchasing LE issues the PO, receives from the vendor, and then inter-companies the goods or services to the requesting LE. Standard feature, configured at the purchasing-LE level.

Shared vendor governance - new vendor requests route through a central procurement workflow. The vendor is created at the party level, then released to LEs with approval. No vendor exists in any LE without central approval.

Global address book discipline

The rules that keep global address book clean:

• One party per legal entity of the supplier. Same vendor in multiple countries may be multiple parties if they have separate tax IDs and legal identities; if it's the same legal entity selling globally, one party.
• Address hierarchy on the party - primary address, alternate shipping addresses, branch offices all hang off one party.
• Contact records at the party level where the contact works across LEs, at the vendor-release level when contact is LE-specific.
• Duplicate detection rules configured at party creation to prevent the same vendor entering twice.

Without discipline, the global address book becomes the same mess as per-LE records with extra steps.

Per-LE vendor configuration

What stays LE-specific:

• Payment terms - contracted per LE, reflecting local currency and payment-cycle norms
• Posting profile - accounting treatment per LE
• Default financial dimensions - different LEs may have different cost-center default for the same vendor
• Bank accounts - vendor might have one US bank for USD payments, one EUR bank for European payments
• Purchase approval hierarchies - per-LE because policies differ

The party data (name, address, tax registration) stays at the global level. The operational behavior stays per-LE. Both are automatically consistent because they're one object with layered attributes.

Approval hierarchies per LE

Centralized procurement doesn't mean centralized approval. Each LE configures its own approval workflow based on:

• Purchase amount thresholds (may be in local currency, converted)
• Requester's organizational position
• Commodity category (office supplies vs IT hardware vs capital equipment)
• Vendor classification (existing vendor vs first-time vendor)

The workflow is LE-local. The vendor record is global. The PO knows which LE it's from and applies the right workflow.

Intercompany trade for shared purchasing

When LE A buys on behalf of LE B:

1. LE A's buyer issues the PO to the vendor
2. Vendor ships to LE A's receiving point (or directly to LE B per drop-ship configuration)
3. LE A creates the receipt and invoice against the PO
4. Intercompany trade creates the paired LE B transactions automatically - intercompany PO at LE B, GR at LE B, invoice posting
5. LE A and LE B settle through intercompany accounts

Standard functionality. Configured once per LE pair at setup.

Reporting against centralized spend

With shared vendor master, cross-LE spend reporting is a query, not a consolidation project. Power BI over the shared vendor tables, financial dimensions cutting across LEs, and Procurement analytics workspaces surface:

• Total spend per vendor across all LEs
• Commodity spend across the enterprise
• Vendor compliance metrics (cycle time, PO accuracy)
• Savings achieved via negotiated rates applied centrally

All of this works because the vendor is one record.

What ships with the pattern

A working centralized procurement architecture has:

• Global address book populated with vendor parties
• Duplicate detection rules configured at party creation
• Shared-vendor governance workflow for new vendor requests
• Per-LE release with LE-specific operational configuration
• Centralized procurement configured where one LE buys for another
• Intercompany trade configured for LE pairs
• Approval workflows per LE fitting local policy
• Analytics consuming the shared vendor data

The feature existed before the requirement. Getting the architecture right is about using it correctly, not extending it.