Within the SAP Finance community it is common knowledge that the fixed asset solution operates on a subledger-to-ledger relationship with the General Ledger. Another item that is equally well known is that this relationship is held in place by a special type of GL account called a Reconciliation Account. Reconciliation GL accounts can not be directly posted to in the GL (i.e., FB01, FB50, etc.). Instead, the account gets its values only from the subledger that it is assigned to. In this way, the solution is setup so that the GL account will tie to fixed assets. You keep the GL summarized, and the details in the subledger… and they should both tie.
The online help covers this relationship with the GL here: Account Determination. It also has a special page about reconciling to the GL during the legacy conversion process: Reconciliation of Balances with General Ledger.
Here is the important flag on the GL account. The screen has changed slightly from ECC to S/4 but this particular field hasn’t. It’s the same as it’s always been.
Obviously, making sure that the two areas truly reconcile is super important. And based on what I said above, it should always be that way, right?
Guess what? They don’t always tie!
I’d estimate that about 25% of the customers we go to have a reconciliation issue of some type. That may seem surprising or like a terrible estimate but it’s even worse when you consider that most of those aren’t even aware of the reconciliation issue. They’re not checking to see if the two areas reconcile because they either 1) don’t pay much attention to fixed assets in general, or 2) assume it ties because of the Reconciliation Account concept mentioned above. “How could they not tie if we are using reconciliation accounts correctly?” is what I’ve heard a customer ask.
Why is this important?
Obviously, the nature of how the asset subledger fits into the total SAP Finance solution, as explained briefly above, is predicated on a concept that the two sides tie out. The detailed asset specific activity is in the subledger yet not everyone is concerned with them. Some general finance users may only be concerned with the balances so the GL is the appropriate place for them to review and analyze financial information. But no matter where you’re working at within SAP, you expect the data to be correct and fully reconciled. In short, the system should be accurate.
What typically causes this?
There are a few reasons.
The most frequent, by a long shot, is an incorrect legacy conversion process. I’d estimate that over 90% of the asset reconciliation issues I come across are because the legacy takeover process wasn’t correct nor validated at the time of go-live. Sometimes it’s as simple as the correct balances being loaded but with the wrong date. Other times someone loaded some detail records after the fact but forgot to update the GL. Other times it’s the reverse that happens. It usually happens after the bulk of the data has been loaded into both sides, and then some errored records are fixed/loaded into the subledger. Go-lives can be hectic and when you’re adjusting a few records for the legacy conversion, it’s possible to forget about the other side of the process.
The validation for the asset legacy conversion is frequently not done correctly. Unlike other financial areas, we have multiple depreciation areas to tie out and some of them are in alternative currencies. I’ve seen customers have area 01 USD tie to the GL but the parallel areas don’t tie. Again, it’s because they most likely didn’t book the values correctly in the GL. One way that this reconciliation transaction ABST2 helps prove is whether or not the legacy conversion was done correctly for all areas, and all currencies.
The other culprit is that it’s possible to remove the reconciliation account ID from the asset GL accounts. Doing so changes them to normal GL accounts which means that the ledger-to-subledger is no longer enforced. At that time, someone can make a direct FI posting to the account, then go back and re-activate the reconciliation indicator as if nothing ever happened. This can cause a reconciliation issue and some people exploit it frequently. See below.
There is a third way in ECC to make a posting to the GL account (not to the subledger) but with the recon flag still set. SAP delivers this capability to assist in the legacy conversion process but that doesn’t mean someone can’t execute it after go–live and mess up the values between the two ledgers. This tcode no longer exists in S/4HANA.
Any other causes?
The section above lists three ways that are either process or configuration oriented. However, there are another two ways that can cause reconciliation issues from a technical perspective.
The first way that I can think of that causes a reconciliation issue is due to a system bug of some kind. We all know that they can happen… even SAP knows that. I can’t think of any specific examples though I seem to recall situations around making postings to prior years or reversing entries. But no matter the reason, a software bug may cause the values between the two ledgers to not sync. SAP is usually quick to solve these and has a long list of correction programs to make the necessary adjustments if a normal posting (FB50 or ABSO) isn’t possible. In my opinion, these are easily handled because they are SAP’s responsibility, not mine.
The second is some form of ‘direct table update’. I’m referring to someone directly going into a table and changing a field value at the database level. This can be done either via a custom ABAP report or via debugger at the Table Browser (SE16/SE16N). It’s easily possible to change an amount field on the asset or in an FI line item using one of these two methods. As the years go by, more and more people are making updates like these… I think there is less concern or fear about this rogue approach and any of the negative implications that could come up.
I will usually look for evidence of the second example but the first one can be very hard to find. The good new is that they aren’t frequently the reason for a reconciliation issue. The majority of the time, either someone got cute and opened up a backdoor (the recon indicator) to make a posting, or the data was never converted accurately.
What’s the Solution?
I’ll cover that in the next blog.