понедельник, 5 октября 2026 г.

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

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:

Article content
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!


Комментариев нет:

Отправить комментарий