HQ Statements - Balance Discrepancy

I have 42 accounts that will not close. They all have the same problem, and I cannot figure out how we got here...

Last month was our first month running statements from HQ instead of Store Ops. We imported customers into Store Ops in October. All customers had an account type of 90 Days Same as Cash. We started with HQ in January. Conincidentally, the first statements we ran in HQ were the first statements that should have triggered finance charges.

Finance charges were not assessed. My bookkeeper went in and adjusted 42 accounts to apply finance charges. Now these 42 won't close.

What's more, when you look at the Account Information tab for one of these customers, the entries look like this:

Date Transaction Reference Amount Run. Balance

3/14 Acct Pmt 1411 ($189) $0 2/15 Acct Pmt 1149 ($200) $189 1/24 Adjustment 3032 $20 $389 12/31 Adjustment 2431 $20 $369 11/22 Adjustment 1401 $20 $349 11/7 Adjustment 1034 $20 $329 10/7 Adjustment 139 $289 $309

See that last (well, first) entry? The imported balance was $289, but the running balance is off by $20.

The closing date is 2/24 and the closing balance is $169. The A/R balance on 2/24 is $189. Discrepancy. No statements.

How do I resolve this? The A/R balances are correct. The closing balances are wrong.

Anything you might offer would be greatly appreciated.

Tom

-- The worst words in business: "We''ve always done it that way"

-- Stop Fishing for eMail.

Reply to
Terrible Tom
Loading thread data ...

OK - I found a solution in a KB articlewhere I used a query to set LastClosingBalance to the expected A/R Balance.

Now - what caused the problem and how do I avoid it in the future?

"Terrible Tom" wrote:

Reply to
Terrible Tom

I am going to guess the accounts were out by the amount of the adjustment. Don't worry, you only have 42 accounts with this error - we found over 300 at one of our stores...

Why this happened is easy. The running balance values are STORED, not calculated. This makes sense to a point, but it is poor design really. I can see that you don't want to calculate the running balance on accounts that potentially have hundreds of transactions, but at the same time, once you start making adjustments, you really SHOULD recalculate the values in the running balance to ensure they are all correct.

We had the fun situation of having a couple of thousand accounts moved over, with their balances "sold" in. Unfortunately, when they were doing the data import they selected the wrong value to import :O but no-one realised for a couple of days. Obviously business carried on and there were transactions performed before the correct data was imported. It potentially would have been ok if the original data had been put through as a payment, then the correct data put through as a sale.

Anyhow, that is the best as I can understand it, if any> OK - I found a solution in a KB articlewhere I used a query to set

Reply to
ozzie

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.