Lesson 6 of 6
Central payments and beyond
10 min
Listen to this lesson
Replication gives finance one ledger. Central Payments gives it one place to pay and collect. When it is activated for a source system and company code, open items replicated from that source are processed only in the central system: payment runs, incoming payment clearing and dunning happen centrally, and the source items are cleared technically so nobody pays them twice.
How Central Payments works
- Activation is per combination of source system and source company code.
- New invoices posted after activation are cleared technically in the source and managed centrally.
- Clearing status does not flow back to the source: the source shows the item technically cleared, the central system shows the real payment.
- Historical open items posted before activation must be technically cleared separately; SAP provides programs for this (for example
FINS_CFIN_HISOI_CLRin the central system; the older source-sideFIN_CFIN_TECH_CLRis marked obsolete). Check the current notes for your release. - Deactivation is generally not supported, so activation is a one-way decision per company code.
The transition is the risky part. Between replicating historical open items and clearing them technically in the source, the same invoice exists as open in two places. A source payment run in that window would pay what the central system will also pay. Programs therefore block payment in the source for historical items, and SAP describes a note-based option to set a payment block on legacy items centrally until they are cleared. Test the window explicitly.
- Week -2FreezeLast source payment run for the company code; payment blocks on remaining items
- Day 0ActivateCentral Payments active for EP1 and 1710
- Day 0Historical itemsTechnical clearing of historical open items, reconciled count and amount
- Day 1First central runCentral payment run with a small, checked proposal
- Week +1Steady stateDaily central runs; source payment programs locked for 1710
What else moves to the center
| Process | Central option | Watch out for |
|---|---|---|
| Supplier payments | Central payment runs and bank communication | Bank accounts, payment methods and formats configured centrally |
| Customer collections | Central incoming payments and clearing | Lockbox or bank statement rules mapped to central customers |
| Dunning and correspondence | Central dunning and correspondence | Customer-facing letters use central data; check forms per company |
| Taxes | Some tax reporting may have to run centrally | Restrictions exist for VAT and withholding tax reporting; check before activating |
| Close and group reporting | Central close, Group Reporting on the central ledger | Close only after reconciliation is signed |
Withholding tax and tax reporting deserve their own analysis: once payments are made centrally, reports that depend on payment data move too, and SAP documents restrictions. A US company code like 1710 with 1099 reporting needs a test that the central system produces the same 1099 data the source used to produce.
What would you do?
On activation day, the count of historical open items technically cleared in EP1 for 1710 is 4,812, but 4,826 items were replicated as open centrally. What should the cutover team do before the first central payment run?
What goes wrong in testing
| Risk | Test |
|---|---|
| Duplicate payment in the transition window | Try to pay a historical item in the source after the freeze; it must be blocked |
| Clearing not reflected in source reports | Agree which reports users must stop using in the source |
| Bank files wrong for the central system | Send test payment files to each bank before activation |
| Tax reporting gaps | Run tax and 1099 reports centrally for a test period and compare |
Central Payments tests that matter most.
Beyond payments
Once the central ledger is trusted and payments run centrally, more of finance can move: Group Reporting on the central ledger (sap-fin-308), cash management with central bank statements (sap-fin-207), and a central close. Each step concentrates more control in the central system and makes the source books less important. The end point many programs aim for is converting or moving the source logistics into the central system, so that the central system becomes the only ERP. In the what-if, Contoso would have reached the same single system it has now, later and with more steps, but with finance benefits earlier.
Each step also changes what must be tested. Group Reporting on a central ledger depends on mappings being right for trading partners; central cash management depends on bank statement rules that use central customers and suppliers; a central close depends on reconciliation being signed before the close begins. Treat each as its own release with its own sign-off.
A sensible activation order starts small. In the what-if, Contoso would have activated Central Payments first for 1810, the smaller distribution company with fewer suppliers and one bank, run two payment cycles, reconciled them, and only then activated 1710. The first cycles would use small proposals that a person checks line by line before release: right supplier, right bank details, right amount, nothing already paid in the source.
- Central Payments is activated per source system and company code and is generally irreversible.
- Source items are cleared technically; the central system pays and clears for real.
- Historical open items need separate technical clearing and reconciliation.
- Test the transition window, bank formats and tax reporting before activation.
Check your understanding · not graded
Lesson check
1. At what level is Central Payments activated?
2. What happens in the source to an invoice posted after activation?
3. Why is the transition window the riskiest part?
4. Why is a careful readiness check needed before activation?