Rules for Incrementing Cheque Numbers

Hello ACCOUNTS advisors. We have a somewhat subtle design question we’d like opinions on.

It’s about how, when you use Write Cheques, the “next” cheque number is supposed to appear in the Cheque # field as the default. The same should happen when you are in the Number field in a Register window, and press the “+” key.

Our original design for how that worked was that it found the highest cheque number you had used in that bank account in the last 13 months (plus in any post-dated cheques) and showed a number one higher than that. However, a major problem was discovered with that, for organizations that get new cheques numbered back starting at 1 after they pass (say) 999. In that case, it would keep trying to prompt you to use cheque number 1,000, which you don’t have.

So in version 1.14b, released in February 2013, we changed how it comes up with that next cheque number. The new rule was that it would use a number one higher than the number of the latest-dated cheque in that bank account in the last 13 months (including any post-dated cheques).

That worked well for most users, until recently when a user had written a post-dated cheque number 874 for quite a while in the future, then wrote a number of cheques with current dates and of course higher cheque numbers after that. While all of then had numbers higher than 874, the program would always suggest number 875, because it was the latest-dated cheque in that bank account (although it was in the future).

So, what is the right solution? One thought would be to ignore post-dated cheques when looking for the latest-dated cheque. But that will end up prompting you for the same cheque number (874 in that case) when you go to write the very next cheque after that post-dated one, because it would only see 873 in the past. Of course, once you had entered an 875, everything would be OK again.

So, here’s a possible solution, partly suggested by the user who’s having this problem. Have a configuration field, probably in Maintenance -> Main Options, labelled something like “When suggesting the next cheque number, ignore previous numbers higher than: ____”. And set the rule back to the old way: always suggest the number one higher than the highest cheque number in that bank account in the last 13 months (or in the future), as long as it’s not higher than that configured number, if it has been filled in.

This resolves the problem that we made the change in version 1.14b to fix, because if you have wrapped your cheque numbers around from 999 to 1, you just set that configuration number to some reasonable number like 500, and it will not suggest any higher numbers.

And it resolves the problem that the current user is having, because he won’t set that value, and it will prompt for a number higher than any number (past or post-dated) he has used yet.

There’s one remaining problem that I can see – what happens if you set that configuration to 500, and then reach cheque # 500 again? My thought is that if you manually enter cheque # 500 (or any higher number) when that configuration value is set, the program gives you a message about that, and tells you to clear that configured value so as not to have further problems. That should be safe, because the program only looks back 13 months to figure out the correct next number to use, and it’s hard to imaging that any of the previous run of cheques that were numbered 500 or higher would be within the last 13 months, if it wrapped around at 999. (At least, not for the sizes of organizations that are likely to adopt ACCOUNTS.)

One other tiny thought relates to what would be acceptable values for that configuration setting. If someone entered 1, because they didn’t understand the setting, the program would then always suggest number 1! So I think there should be a minimum value, which the user would be warned if they tried to set the configuration lower than. Perhaps 100?

Any thoughts? Anything we may have missed? Thank you in advance for your comments!

5 thoughts on “Rules for Incrementing Cheque Numbers

  1. I was never part of an organization that would have run into an issue with cheques starting over at #1. The previous number would have always been more than 13 months in the past. It appears that enough users did have issues for you to make changes for though. I am happy you’re thinking about a creative solution to cover all the issues users can run into. I believe you have thought of all the scenarios. Although, if an organization was using a great number of cheques, they could simply let them run to 9999 instead of 999 and they’d never have an issue. Of course, making the changes in the program is the best way to make everyone happy. We all know happy customers make for good advertising. 🙂

  2. I think we may have figured out a better solution, based on Googling for what QuickBooks does (and some interpretation).

    ACCOUNTS tracks both the date you enter for any transaction, and the actual date and time at which it was entered into the program (which I call the “entry date”). I think what the program should do is find the last-entered cheque number, by entry date, and offer one higher than that as the next cheque number.

    This solves the post-dated cheque followed by current-dated cheque(s) problem, because the last cheque you entered should have the highest number.

    It also solves the problem of wrapping the cheque numbers around back to 1 (or whatever) because as soon as you manually enter cheque number 1, it will be the one with the last entry date, and the next one will default to number 2.

  3. It’s interesting that this topic of discussion should come up at this time as I’ve just started to have an issue where ACCOUNTS was showing cheque number 2942 as the next available number, but I had recently already written cheques 2943 through 2947. NORMALLY, I wouldn’t likely run into this issue, but as I mentioned to you before Dan, I am still running ACCOUNT concurrently with Quickbooks until this year-end, at which point I intend to use ACCOUNTS exclusively. I couldn’t switch yet since I had a lot of triple-cheque sheets which are not compatible with ACCOUNTS. I will be placing an order very soon for new cheques since I’m almost out. Good timing. Anyway, since the cheques have been generated by Quickbooks up to this point and I make matching entries in ACCOUNTS, I’ve encountered a few cases where I missed an entry and had to enter one after the fact. This is where I think I messed up a few times and keyed in the wrong cheque date or something (by a few days). In any case, I ASSUME this issue will eventually clear itself once I enter more cheques this week. Can I expect that behaviour?

    To your point of using the last cheque entry date, I believe that would be most helpful, even though it doesn’t work for my bizarre entries of late.

    One other item to consider though. I wonder how many other users have BOTH printed cheques AND manual cheques to enter. We use both, and the manual cheques have been 3 digits for 33 years. The printed cheques have been 4 digits since I began using them several years ago. Hmmm, simply switching entirely to printed cheques isn’t that convenient since I share the duties with another individual and hand-written cheques are the easiest option when he covers for me in my absence.

    • Yes, even with the current setup your issues should resolve fairly shortly. The new method I’m proposing will still have some minor issues if you enter cheque numbers out of order.
      If you have two different runs of cheque numbers being used you are going to be out of luck, as you will definitely have to manually switch each time. However, if you are entering a few in a row from either set, it should work after the first one is entered.

  4. We have just released version 1.30 of ACCOUNTS, which now uses the method described in the comment above – suggesting a cheque number one higher than the most recently-entered one in that account. Thanks to those who helped us think about this.

Comments are closed.