Company Fiscal Yr-End is Feb 29/12.

A/R Aging is horribly off when compared to the A/R Control Account in G/L for February (but not for other months).

Investigation shows that if I run the A/R Aged Trial Balance Report and Calculate as of Feb 28, 2012 we get a total that is exactly $1,431.90 off from the G/L. Further investigation shows me that the company did exactly $1,431.90 of business on Feb 29. (The numbers should therefore balance.)

But the difference on the total for the Aging report between the two dates (Feb 28 and Feb 29) is more than $30,000 too low.
The G/L and A/R are off by $30,000+ comparing the A/R Aging Rpt and the closing G/L balance for Feb.

A/R is 9.0C (120224).
DIC returns clean data.

So what’s going on???

Hi, Samuel,

You're being careful to use 'Calculate as of' each time? I ask because 'Age as of' will also bring in future-dated tranasactions.

When you look at the control account for the end of February in the GL, are all source codes for AR or is there one or more that was created and posted in GL?

Yes - we used "calculate" each time.

And 100% of the transactions are from "AR" (We exported all the transactions to Excel to verify this).

Hi, Samuel,

Okay. You're backdating a report, so it will try to use the transactions that are in history. If some of the necessary transactions have been cleared, the report is only able to report on what is there.

Also, when you say that DIC is clean, in the Company Profile on the System Options tab, is the 'Check history during DIC' option enabled? If not, enable it and run DIC again to see if it reports any errors.

I ran the Aging report for Jan 31,2012 & as well for March 31, 2012. I compared these two reports to the G/L control account for AR and we are fine.
It is when I run the Feb 29 aging where we get the problem. (And note that Feb 29 is less than a month at this time.)

I enabled check history during DIC and reran the check. It completes with no errors.

Perhaps there is an issue with the Feb 29th leap year date functions..

I would not be surprised.

Samuel,

Can you look at this on a transactional basis, rather than a full amount basis, and determine exactly what transactions should be reported that are not being so for February 29th only?

You should also check that the fiscal calendar in Ledger specifies Feb 29 as the end of the period.

The fiscal calendar in Ledger for the 12th period is 2/1/2012 to 2/29/2012.

Transactional basis: Where would you suggest I look?

Hi Sam,

Could you ZIP the data and send it to me? (AR & GL).

Andrew:
I zipped the files and they are on their way to you.
Thank you.

No sign of them so far.

Hi Andrew:
Has there been a resolution to this issue? I'm going to visit a client this week where February 29 reporting will be involved.

Well, I got the data and hour or so ago, but Feb 29 was this company's year end and so the AR posting journal I need is not available. I'm waiting to see whether it can be provided.

There was a reason for the posting in the Adagio Notes about avoiding having February 29th as a business day. Has your client said there is a problem at their site?

Andrew:
Not at all. I just want to be prepared so I know what to consider in case of a discrepancy.

OK. The normal rules for tracking down a discrepancy prevail until something else raises its head.

OK. There's a problem with this report if it is backdated to February 29. With Sam's data, the general ledger value is correct, but the total at the bottom of the AR ATB is incorrect.

I've asked R&D to investigate the problem.

To close this thread...

As far as we can determine, this data had a Period End run on March 6, and then a Year End dated February 29. This meant that transactions are in history that would not have been moved if the Period End had been run on February 29.

This report uses the Last Period End date in the company profile to determine whether the report being requested is back dated or not. Since the Year End date matches the Report date, the transactions in history are not being inspected (and are therefore missed in the report).

If it is critical to get an ATB to tie back to Ledger, then you can change the Last Period End date in the AR company profile using GridView Read-Write, or run a Period End dated March 1. Both of these actions will cause the ATB report to inspect the transactions that have been moved to History.

As mentioned previously, all the accounting entries are correct, and it turned out that this had nothing to do with the February 29th date. It would happen regardless of the number of days in the month.

Andrew:
As you suggested, running a Period-End for March 1, 2012 does reset the ATB back to the correct values for a report as at Feb 29 (although I am not sure why).

I was unaware that the data had a Period-End performed on a date later than the Year-End date. (I am going to guess that this was done unintentionally by one of the users.)

I have to recommend you for delving into this matter, and for your detective work on this matter. Thank you for your assistance!