New Asset Accounting Becomes Mandatory in S/4HANA

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Any custom Z-report or interface that reads ANEP, ANEK, ANLC or ANLP directly for depreciation or APC values needs revalidation; these tables may now be compatibility views computed on top of ACDOCA, and direct joins that worked at ECC volume can perform poorly or return unexpected results.
• Month-end procedures built around a periodic reconciliation posting run to sync FI-AA with the G/L become obsolete; teams that keep running that step out of habit either find it blocked or find it does nothing useful, and lose the false sense of security that step used to provide.
• Delta depreciation area configuration used for parallel valuation has to be redesigned as separate real depreciation areas mapped to ledgers; any authorisation profile, variant, or batch job scoped to the old delta areas needs rebuilding.
• Document splitting becomes stricter because every asset posting must balance per ledger; postings that previously slipped through with an unbalanced delta now fail or generate correction entries that finance does not recognise.
• Asset under construction settlement and investment support postings that depended on delta area logic need functional redesign, and controllers who reconcile AUC to project or internal order data find the numbers land differently.
• The technical clearing account introduced for integrated asset acquisitions is unfamiliar to AP teams and shows up as an unexplained line in acquisition documents if nobody briefed them on it beforehand.

Migration actions

• Run the readiness check activities for Asset Accounting early, well before the technical conversion window, to surface inconsistent depreciation area to ledger assignments while there is still time to fix them functionally.
• Inventory every delta depreciation area in use and decide, area by area, which accounting principle and ledger it maps to as a real depreciation area; this decision belongs to finance, not to basis.
• If New Asset Accounting was never activated in the ECC source system, treat this as a full activation project inside the conversion scope, including test depreciation runs and reconciliation sign-off before cutover, not after.
• Identify custom code and interfaces touching FI-AA tables and reclassify them against the compatibility views; performance-test them against production-like volumes, not sandbox volumes.
• Review and rebuild authorisations, background job variants, and month-end close checklists that reference the old periodic reconciliation posting run or specific delta area technical names.
• Brief AP and asset accounting teams on the technical clearing account behaviour for direct capitalisation before the first live acquisition posting, with a worked example document.

Whose problem this is

Common pitfalls

• Teams assume the technical conversion program migrates delta area logic automatically into an equivalent ledger design; it migrates the data, not the design decision, and a poor mapping carried over from ECC just gets carried over again.
• Custom depreciation run variants and batch schedules built around the old periodic reconciliation step keep executing after go-live with no error, quietly doing nothing, which masks the fact that nobody redesigned the close checklist.
• Low-volume UAT hides the performance impact on custom reports hitting the compatibility views; the first real month-end depreciation run at full asset volume is where response times and job runtimes actually get tested.
• Document splitting failures on asset postings often first appear in test as isolated 'edge case' errors and get ignored, then recur across an entire asset class at production month-end because the underlying ledger balancing rule was never fixed.
• The technical clearing account line item gets flagged by AP as an error because nobody explained it, and a well-meaning support consultant reverses or reclassifies it, which then breaks the asset capitalisation reconciliation for that document.