Sage 100

A new controller, unfamiliar with Sage, inherited a mess from the previous employee, and he's unhappy with the seeming lack of control from bank rec. The balance in bank code maintenance is *radically* different than the balance in the GL account. Apart from overriding the amount in bank code maintenance, are there other ways that the two can become out of sync?

1. Bank rec integration to a module occured after processing began in that module 2. The customer runs transactions journals through GL and they don't post them BR 3. Someone use DFDM and didn't know what they were doing 4. End-users posts transaction to a default bank code, not always the correct one (like always using A when they should use B or C

You can also enter transaction directly to bank rec. that will throw if off.

What Moira and Ron said

-5. Someone enters a check run or cash receipts with documents dated in one month but uses a different month for the G/L posting date.

OK, now, can anyone explain why there is a ""separate"" bank code amount that isn't forced to stay in sync with the GL account balance? I have this guy throwing how wonderful QB is in my face. I want him to understand the benefit of, or at least the rational for, why Sage 100 is structured like this.

TL/DR - There is no ""why."" Don't sell him on the bank rec module. :-/ Back in the day, I had all of my bank codes hitting the same G/L account. It works but it makes the bank rec process a little tricky in different ways. Couldn't do it with more than three or four accounts, actually. QB does do some things fairly well, bank recs being one of them, but there are other systems out there that do it at least as well. The downside is that the Sage bank rec module is pretty low-rent: I don't like it. But it's a useful utility if you get used to its quirks, listed above, and if you crack the whip on it to make it work.

Remind the new controller in QB you can _erase_ transactions from bank rec and every where else. Forensic proof exists that QB is the leading software in use in corporate fraud. That should shut him up pretty fast.

@MoiraGoggin It's called ""fraud friendly.

The current balance isn't necessarily supposed to match the current balance in the cash account. If there are uncleared items, it should match the cash balance as far out as you can go date-wise for the cash account. If they are on a calendar year, look at the balance at 12/31/2017. Assuming they don't have anything posted to future years, that number should match the current balance in BR (unless he messed with it). If it's still off, backup your BR folder, rebuild the BR files, then run the ""Recalculate Account Balances"" utility in BR. If the reconciliation is off after that, it's probably something that was posted to the cash account through GL, or something posted to BR that did not post to GL. If he's so fond of QB, just have him adjust any differences to a ""MIsc. Customer"" account. 9 out of 10 times, when I convert a new client from QB to Sage, there's always some huge, unexplained AR or AP amount, that gets carried over year to year. No one ever knows where it came from, or why its there. :)

Prospect on QB: ""Why do I want an audit trail?"" Me: ""So your AP clerk can't do to you what you do the IRS"" Prospect on QB: ""oh...

The explanation I give is that back in the day a company could have a bank rec module without general ledger and general ledger without bank rec. This has always been my assumption of the reason it is designed the way it is. Also, if memory serves, the bank rec instructions indicates the bank code balance and gl balance are not always connected. I can tell you in most cases my training is to see that these always match.