Profit Centre and Segment Reporting Move Into ACDOCA

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom reports and interfaces that select directly from GLPCA or GLPCT still run against the compatibility views, but performance degrades badly at production volume because the view has to reconstruct PCA-shaped output from ACDOCA on every call; teams that never rewrote these against ACDOCA discover this at month-end close, not in unit test.
• Scheduled periodic jobs for the FI-to-PCA transfer, or for real-time integration of CO postings into PCA, either fail outright after conversion or, worse, keep running and post duplicate or empty entries because the target ledger they were writing into no longer exists in the old sense.
• Reconciliation reports built to compare GL balances against PCA balances become meaningless (they always match) but nobody removes them, and their continued presence in the close checklist wastes time and occasionally triggers false alarms when the compatibility view returns rounding differences.
• Segment-based balance sheets that previously worked only in a subset of company codes (wherever New GL segment splitting had been switched on) now apply everywhere, and postings that previously bypassed segment derivation entirely (batch interfaces, legacy z-transactions) start landing with a blank or default segment that nobody notices until the statutory segment report does not tie out.
• Authorisation objects built around the old PCA transaction codes stop controlling anything meaningful, because profit centre and segment values are now visible on any FI document display authorisation, which can expose data that was previously siloed behind PCA-specific access.

Migration actions

• Gate: activate document splitting with profit centre and segment set as zero-balance characteristics, and validate the splitting rule set against every document type actually used in production, including intercompany and clearing postings; this is a pre-conversion requirement, not a post-go-live tuning item.
• Gate: run the standard pre-conversion consistency checks between the GL and the existing PCA ledger and resolve every open discrepancy; unreconciled differences at this stage get frozen into the converted history and cannot be fixed later.
• Identify every custom report, extract, and interface selecting from GLPCA or GLPCT and rebuild it against ACDOCA fields directly rather than relying on the compatibility view for anything beyond ad hoc lookups.
• Deactivate or redesign the periodic PCA transfer and any real-time CO-to-PCA integration jobs; leaving them scheduled against a converted system produces errors or silent duplicate postings.
• Review every posting source that does not go through standard FI account assignment logic, including legacy interfaces and direct table loads, and confirm each one derives profit centre and segment correctly before conversion; these are the postings most likely to land with defaults nobody wants.
• Rebuild segment-based statutory reports and reconciliation checklists to reflect that PCA and GL reconciliation is now structural rather than a task, and remove the now-redundant tie-out steps from the close calendar.

Whose problem this is

Common pitfalls

• Assuming segment is automatically populated everywhere once document splitting is active; postings from non-standard sources, secondary cost allocations, or older custom programs often skip derivation entirely and post with a blank or default segment.
• Testing reconciliation and reporting on a small data set where the compatibility view performs acceptably, then hitting severe slowdowns in production volume once GLPCA-style queries have to reconstruct results from the full universal journal.
• Discovering during the pre-conversion consistency check that GL and PCA balances in the source ECC system have been quietly diverging for years due to timing gaps in the periodic transfer, forcing a cleanup project that was not scoped into the conversion timeline.
• Leaving the old FI-to-PCA transfer job or real-time CO integration job active after go-live, which either dumps or silently creates offsetting entries that inflate line item counts without affecting balances, making the problem hard to spot until someone investigates document volume.
• Adding segment as a reporting requirement after go-live rather than before, which means historical documents converted without a segment value can never be retrofitted, leaving a permanent gap in trend and comparative segment reporting.