How to Reconcile Fixed Assets to the G/L (Part 3)

Blog Series:
How to Reconcile Fixed Assets to the G/L (Part 1)
How to Reconcile Fixed Assets to the G/L (Part 2)
How to Reconcile Fixed Assets to the G/L (Part 3)
How to Reconcile Fixed Assets to the G/L (Part 4)

Continuing with the AA-to-GL Reconciliation topic, it’s time to talk about a few other tools that can help you get out of this.  If you’re thinking it’s just ABST (Yes, I’m covering it) and nothing more, then I have some good news.  SAP delivers additional programs via OSS that are quite helpful.

What comes after ABST2?

After you run ABST2, it’s a good idea to run transaction ABST for any GL account that came up in ABST2.  Similar to ABST2, ABST has two main program steps.

First, it confirms that the asset line items total up to the asset summary values.  Basically, it’s comparing the amounts in tables ANEP and ANEA, and then making sure they reconcile to the aggregate values in ANLC.  If they don’t match then it will output the offending differences.

After that is done, it performs a check on the GL level.  It the asset amounts are fine, it will evaluate the FI document and do a similar comparison between the line item amounts and those on the corresponding assets.

ABST Example

Here is the selection screen for ABST. This is an old program so everything below is self explanatory.  Because GL Account 160030 came up when I ran ABST2, I’ll run it for that company, year, and account (and area 01).

Here is the output and it’s a small list.  Smaller is better in this case.

I see two errors above.  The first row indicates that we have a manual posting to the asset reconciliation account.  The message is technically complaining that there is a line item on the GL account that is not an asset posting (which would be designated by an ‘A’ account type.  This one is an ‘S’ which indicates that it’s a normal GL posting).  If I drill into the document hyperlink, the FI document pulls up.  I can see immediately that the line item to the 160030 account is in fact an ‘S’ line item.  That means a manual GL posting was made to this account directly in the GL and not through the FI-AA subledger.  Whoops!

To confirm, if I click on the document header I can see that the [Reference Transaction] says BKPF.  Again, this indicates that the posting was made through the GL and not through FI-AA.  If you look at the first screenshot, you can also see the BKPF value in the Reference Procedure column as well.

Backing up to the ABST output, the second message indicates that the asset line items don’t total to the asset aggregate value.  This is ultra-rare but I’m just trying to showcase what the program can pick up on.  If I go to the asset explorer, it confirms that the line item on the asset is for $84,000 but the total value is $85,000.  That’s another problem to solve.

If I go to the last message, it also confirms that the line item in FI-AA (for $84,000) is different from what is in the GL ($85,000).  If I click on the FI document, I can see that the posting was a legitimate FI-AA subledger posting based on the account type ‘A’ and that the Asset Value Date and Transaction Type fields are populated.

And the document header shows that the Reference Transaction is an asset generated one, AMBU in this case.

This means that the posting to the GL is fine…  it was generated by the asset subledger, but we need to fix the line item amount and change it to $85,000.  Again, that’s another problem to solve.

Other Helpful Programs

OSS note 364878 has three additional programs that are helpful in narrowing down the situation if you have a widespread problem.  The programs are RACORR131, RACORR132, and RACORR134. 

NOTE:  I’ve made some slight changes to the selection screen and output for each of these programs so they’ll look different in your system if you use SAP’s version.  No updates are being made by these programs (they’re just analysis reports) and the core logic of the programs haven’t been changed so the end result isn’t any different… mine just look a bit better.

First, let’s talk about the most useful which is RACORR131.  This program will compare the amounts in the asset line items versus the GL line items and list any that are different.  The program doesn’t run very fast so you should run it period-by-period and account-by-account until you’ve found the incorrect documents.  Obviously, this should be done after you’ve used ABST2 and ABST to identify the years and accounts that are not reconciling. 

Here is the output.  It shows the same two FI documents we saw earlier.  The advantage here is that it returns the list of FI documents if ABST doesn’t find them and lists the amounts.  This is easily downloaded into Excel if necessary.

RACORR132 is a much simpler and quicker program.  It sums up the asset postings for a give account and period range.  This number can then easily be compared to the GL balance at FAGLB03. 

Below is the output.  Like I said, this is a simple program but if you want/prefer to manually do a comparison for a given period (range) of asset transactions without worrying that the asset reports (which have their own built-in logic which might yield a different result) then this is a useful tool.

RACORR134 is helpful in finding out if manual postings have been made to the GL account.  This program will evaluate all of the line items in an account and output the documents that do not have an asset number in them.  For every normal asset posting, the asset number (ANLN1 and ANLN2) are part of the line item in BSEG.  If these are not populated, than it is not an ‘A’ account type posting and therefore indicates that a manual posting was made.

Below is the same $15,000 manual posting from document 100000004 that we saw earlier.  I note that the posting key is 40 (for a GL posting) but it’s possible for it to be a 70/75 but still have an issue where the ANLN1/ANLN2 fields aren’t populated in the GL line item. 

Let me explain some more about the ‘Asset’ and ‘Subasset’ fields in the output and the explanatory note at the bottom of the report.  These two field values, if populated and I rarely see them populated, are coming from the PO line items in table EKKN.  This report is showing you, for a very isolated capital process regarding capital POs (again, which aren’t used much these days) the asset number from the corresponding PO.  This is a suggestion only.  It’s not showing you the value of the ANLN1/ANLN2 fields in BSEG… the idea being that for a capital PO, if the PO has asset 100003-0012 but the FI line item is blank, then it’s logical that the FI line item for this document should be 100003-0012.  But again, most people don’t use capital POs anymore because the best practice in this area is to use a project to capture capital costs.

Next?

The next blog will cover how to stop this from happening.