FI-AA Data Migration into S/4 HANA: FINS_RECON 795 '&1: Line Items ANEP/ANEA differs from Totals ANLC'

The error message is self explanatory and points out to mismatch of asset postings line items values stored in ANEP / ANEA tables with totals values in ANLC table.

First of all, consider the FYs listed in error message, if older than 10 years, recommendation is to archive errored out data, which is advised by SAP according to SAP note 3038014, for example.

Second, error message points out to existing data inconsistencies between asset line items and totals values for concerned assets / FYs / depreciation areas. These may be due to mismatch in planned or posted depreciation values (NAFAP, NAFAG field values) between ANEP and ANLC, i.e. causing the consecutive mismatch in asset NBV in asset explorer and Asset Accounting reports (Asset Balances, Asset History Sheet).

To be more precise, planned depreciation amount that wasn't posted due to different reasons (program bug, depreciation key OR depreciation area set- up and etc.) in ECC won't be migrated to S/4 HANA into ANLC / FAAV_ANLC tables, while still be available in FAAV_ANLC_ORI which, in turn, will trigger the 795 error during data migration. So, technically, you still have the unposted values available in S/4 HANA and, if required, build a separate CDS view for retrieving data from FAAV_ANLC_ORI for your internal reporting purposes.

It is possible to utilize these standard RACORR* programs to rebuild FI‑AA DB entries in ECC. However, if the inconsistency is legitimate, i.e. existing unposted depreciation amounts from previous FYs, then any corrections applied will be overwritten once the consecutive Balance Carryforward (BCF) run is executed. In general, I would be very precautious with usage of any Asset Accounting correction programs as they might potentially alter the BCF amounts of closed FYs.

So, if the errors occurred for closed FYs and archiving is not possible, recommendation is to acknowledge and accept the errors (in MUJ or R25 segments of FINS_MIG_STATUS t-code), as any corrections would alter the financial reports for already closed FYs.

FI-GL and FI-AA Reconciliation Prior S/4 HANA Finance Data Migration

FINS_RECON 763: &1: reconciliation account & 2: total without asset assignment

Issue description: This is really a very generic error message usually pointing to mismatch between FI-GL and FI-AA entries, i.e. existing reconciliation issues in ECC are raised with this error message during data migration into S/4 HANA.

First step to address this error is to run ABST / ABST2 t-codes in your legacy SAP and, starting from there, proceed with correcting the mismatches G/Ls / Ledger wise.

There’s quite a number of SAP notes available on this topic, but I would recommend to start checking SAP note 69225, which will give understanding on the origin of differences and how to handle them.

Note that manual postings to asset reconciliation accounts, by unchecking reconciliation indicator via OAMK t-code, is acceptable and actually is recommended by SAP in above provided note.

Manual entries SHOULD NOT, as long as they reconcile FI-AA and FI-GL differences observed in ABST / ABST2 t-codes, cause any errors during data migration, especially FINS_RECON 763 one.

Root cause analysis & solution description: FI-GL and FI-AA reconciliation mismatch may be due to different reasons, mainly, these are due to bypassed Balance Carryforward run in non- leading Ledger in previous Fiscal Years. So, re-running these is a must to reconcile the differences in current Fiscal Year, but this needs to be verified from auditing perspective, as BCF re-run will ultimately alter the balances across non-leading Ledger for already closed Fiscal Years.

Manual validations of ending balances with beginning balances in a consecutive FY of affected G/Ls is a mandatory step to figure out which FY actually is having issues with BCF run. So validating FS10N / FAGLB03 with AR01, AR02 will have to be executed per each FY, per each Company Code, which may be very time consuming. But this is the only way to find out the real root cause of the differences.

Apart from BCF, differences between G/Ls and asset values needs to be validated case- by- case in order to proceed with the manual correction entries via ABF1 t-code (Ledger wise) or ABB1 t-code for adjustments in parallel currencies. Note that in ABF1 and ABB1 t-code, you will be debiting / crediting asset reconciliation accounts without asset specified as an account assignment object, which is OK and which is in line with SAP standard (refer to SAP note 69225).

So, the target is to reconcile FI-GL and FI-AA mismatches prior data migration in ABST2 and ABST, basically, if the report returns no data this means data is fully reconciled. Or you might still receive report output totaling differences to zero and when going back to the selection screen, MQ555 or MQ557 error will pop- up, which is fine, this just means that with following BCF run the differences will be reconciled (i.e. technically they occurred in current Fiscal Year and already reconciled).

Exception case: you MIGHT potentially encounter FINS_RECON 763 error message during S/4 HANA data migration, if the BCF run executed prior migration for the Company Code having alternative Fiscal Year Variant assigned (for example, FSV ‘V3’ assigned to Indian Company Codes). Basically, error will be raised due to non- representative Ledger, which is not supports Asset Accounting only partially. You will notice that postings through non- representative Ledger won’t have asset specified as account assignment object and BCF values carried forward accordingly. As a result, this will trigger the ‘false positive’ FINS_RECON 763 error message in data migration cockpit (FINS_MIG_STATUS t-code), as there’s no inconsistencies logged prior data migration in ABST2 or ABST. In this case, SAP suggests suppressing or change the status of the error message status to warning via OBA5 t-code. OR else proceed with implementing the SAP note:

SAP note 3753135

The note was actually released by SAP for addressing our absolutely unexpected FINS_RECON 763 case during data migration in PROD. How cool is that? :)

That’s about it!