FI / FICOarchitect

FICO Accounts Payable Part 4: Enterprise AP Architecture, Migration and Governance

Key takeaway

Design AP for many entities: business partner and CVI, shared service center models, invoice automation and supplier networks, centralized payments (paying company code, in-house cash), migration of open items and supplier data, and controls that keep AP clean.

Explanation

📌 KEY POINTS
✅ Business partner with CVI is mandatory; supplier master quality decides AP quality.
✅ Shared service centers standardize invoice processing and payments across company codes.
✅ Centralized payments: a paying company code can pay for other company codes (payments on behalf).
✅ Migration: open items, supplier master, bank data and balances with reconciliation to GL.
⚠️ Migrating duplicate or inactive suppliers carries problems into the new system.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 covered invoices. Now architecture.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MASTER DATA

BP/CVI, governance (MDG or central team), dual control.

━━━━━━━━━━━━━━━━━━━━
▶ 2. OPERATING MODEL

Shared service center, invoice automation (OCR, supplier network).

━━━━━━━━━━━━━━━━━━━━
▶ 3. PAYMENTS

Central paying company code, bank connectivity, payment factory options.

━━━━━━━━━━━━━━━━━━━━
▶ 4. MIGRATION

Clean suppliers, open items per company code, reconciliation.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CONTROLS

Segregation of duties, duplicate checks, KPIs (days payable, first-time match).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Assess supplier data quality.
Define AP operating model.
Plan migration and reconciliation.

✅ CHECKPOINT: migrated open items equal legacy balances per company code.

Code example

ABAP Code

===== MIGRATION FLOW =====Supplier cleansing → BP load (CVI) → bank data verification → open item load (migration cockpit) → GL reconciliation → sign-off ===== CENTRAL PAYMENTS =====FBZP: paying company code for company codes 1010, 1020 → intercompany clearing postings ===== KPIs =====Days payable outstanding | first-time match rate | duplicate payments | invoices per FTE

Real project scenario

A multinational manufacturer centralized payments in one paying company code but had not planned intercompany clearing. Intercompany balances grew unnoticed until quarter-end. Adding automatic intercompany clearing accounts and monthly reconciliation fixed it.

Common mistakes

Migrating dirty supplier data.
No reconciliation.
Ignoring intercompany effects.
Weak controls.
No KPIs.

Best practices

Cleanse before migration.
Reconcile per company code.
Plan intercompany.
Enforce SoD.
Track KPIs.

Interview angle

Questions: "How do you migrate AP?", "What is a paying company code?", "How do you design an AP shared service center?"
Strong answer: BP/CVI, operating model, central payments, migration with reconciliation, controls and KPIs.

Practice this lesson

Quick check

1. What should be done with supplier master data before migrating to S/4HANA?

2. Which KPI shows the share of invoices that pass matching without manual intervention?

3. A central paying company code pays invoices for other company codes. What must be planned?

Interview questions

1. What is a Business Partner (BP) with the Supplier role in SAP, and why does S/4HANA require this model instead of the classic vendor master transactions?

Answer it in your own words first, then compare.

2. What is the role of Business Partner Grouping and its linked number range configuration when creating a Supplier in S/4HANA, and how does this determine whether the vendor account number is assigned internally or externally, and stays synchronized with the classic vendor account group used by MM?