Suggestion
Conrad,
Thanks for your email. I haven't forgotten about you either.
It sounds like your proposed upgrade would be able to handle the situation whereby there is a batch code for A/P checks and a different batch code for payroll checks.
I have another thought, I don't know if you may have considered this yet...it involves using the Solver Add-on in Excel. Let's say after running the reconciliation, there are a hundred and fifty reconciling items originating from the books and forty from the bank (just for sake of example) and lets say that you know that most of these book items represent sales (checks and cash) on the books which have been grouped together to make one daily deposit per day to the bank. And let's say that you know that the person compiling the deposits is very accurate but very busy and sometimes she only makes two or three deposits per week and sometimes up to a week late...would it be possible to incorporate the Excel Solver into your program such that it selects groups of reconciling items from the books (within a two week date range preceding a suspected bank item representing the total of the book items, let's say) and attempts various groupings of those items to try to solve for the exact amount of a bank reconciling item. And that it would do this for all bank items. This "extra step" would result in the knowledge that any remaining unmatched items represent entirely unbooked items as opposed to items which have been booked but at the wrong amounts.
I hope what I've laid out is clear and makes sense.
The product you have created addresses a need I have been thinking about for a number of years now, and if it could do what I have proposed, I think you could dominate this market niche and make a lot of money.
In a nutshell, I think the product should be able to do it's thing without so much "scrubbing" of the data beforehand. If one is going to do all that "scrubbing" beforehand, he might as well dive into doing the reconciliation "by hand" (using Excel as a "scratchpad") and could probably complete the rec, with a minimum of reconciling items, in as much time as it takes to scrub the data, run the program, interpret the results, re-scrub data and re-run program if necessary, and segregate the reconciling items into "non-booked" vs. "incorrectly-booked", all of which he would do as he goes along doing the manual reconciliation.
What do you think?
Mike
Thanks for your email. I haven't forgotten about you either.
It sounds like your proposed upgrade would be able to handle the situation whereby there is a batch code for A/P checks and a different batch code for payroll checks.
I have another thought, I don't know if you may have considered this yet...it involves using the Solver Add-on in Excel. Let's say after running the reconciliation, there are a hundred and fifty reconciling items originating from the books and forty from the bank (just for sake of example) and lets say that you know that most of these book items represent sales (checks and cash) on the books which have been grouped together to make one daily deposit per day to the bank. And let's say that you know that the person compiling the deposits is very accurate but very busy and sometimes she only makes two or three deposits per week and sometimes up to a week late...would it be possible to incorporate the Excel Solver into your program such that it selects groups of reconciling items from the books (within a two week date range preceding a suspected bank item representing the total of the book items, let's say) and attempts various groupings of those items to try to solve for the exact amount of a bank reconciling item. And that it would do this for all bank items. This "extra step" would result in the knowledge that any remaining unmatched items represent entirely unbooked items as opposed to items which have been booked but at the wrong amounts.
I hope what I've laid out is clear and makes sense.
The product you have created addresses a need I have been thinking about for a number of years now, and if it could do what I have proposed, I think you could dominate this market niche and make a lot of money.
In a nutshell, I think the product should be able to do it's thing without so much "scrubbing" of the data beforehand. If one is going to do all that "scrubbing" beforehand, he might as well dive into doing the reconciliation "by hand" (using Excel as a "scratchpad") and could probably complete the rec, with a minimum of reconciling items, in as much time as it takes to scrub the data, run the program, interpret the results, re-scrub data and re-run program if necessary, and segregate the reconciling items into "non-booked" vs. "incorrectly-booked", all of which he would do as he goes along doing the manual reconciliation.
What do you think?
Mike
Comments