Fund Balances and Asset Accounts

Hello ACCOUNTS program advisors. I’m having a discussion with a new user, who is switching to ACCOUNTS from the program Aplos. Aplos does one thing that ACCOUNTS does not do, which is track which amounts in each asset account (like a bank account or investment account) belongs to each fund. The user is having trouble seeing how he can do without that feature, seeing as how ACCOUNTS does not do that at all.

To be clear, this is a situation where the user does not have separate bank accounts for each fund. I know some of you may do that, but as I have discussed with some of you before, I see no real need for that.

My view is that in ACCOUNTS, you know two relevant things: how much total is in each asset account, and what each fund’s current (implicit) balance is. As you may recall, what we call the implicit balance is what shows up as the current fund balance on a Balance Sheet, or Fund Income Statement.

The user is concerned about having an expense that needs to come from a fund, that might exceed the amount of money in that fund in his bank account, even though there is enough in an investment amount to cover it. However, the bank account total is sufficient for the expense.

My argument is, it just doesn’t matter. In my not so humble opinion, there are only two questions to be asked (relevant to the accounting, at least) about an upcoming approved expense that will be from a specific fund. First, is there enough in that fund’s balance. Second, is there enough cash on hand in the bank.

If there’s not enough in the fund balance, you either can’t spend the money, or you put the fund into a negative balance, or you get approval for an inter-fund transfer (which may not require actually moving any money around in bank accounts, unless you keep separate bank accounts for each fund) to cover it.

If there’s not enough in the cash on hand in the bank, you need to cash in some investments (or wait for them to come due so their funds are available), get that money into the bank, and then you will have enough.

But I just can’t see how any questions of which funds’ income made up the current bank and investment account balances needs to come into this (or any other) question.

Can any of you think of anything I’m missing here, or alternatively back me up from your experience? Thank you in advance for any comments.

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!

ACCOUNTS Marketing Flyer

Hi ACCOUNTS advisors. I’m taking a course on copywriting (writing for sales, marketing, etc.) and my current assignment is to write a 2 page sales letter, pamphlet or flyer. I’ve put together one for ACCOUNTS, with the main emphasis being on it solving fund accounting problems that traditional programs like QuickBooks don’t solve.

I’d be interested in any thoughts any of you have – Kwame and I like it, but of course we have a biased view as the creators of the program!

You can see it at Two page ACCOUNTS flyer.

You are also free to use this if you think anyone would be interested! I also have a 2-page flyer for both DONATION and ACCOUNTS, and another one for only DONATION, if they would be of any use to any of you.

 

ACCOUNTS User List on the Web

Hello ACCOUNTS beta testers and advisors.

I’m wondering whether any of you would be willing to be listed on a User List page, like the one for the DONATION program at http://www.software4nonprofits.com/userlist.htm.

What we list there is the person’s name and/or organization name, usually the general location (city or town and state or province) and optionally contact information (email address or phone number) if you are willing to be contacted for a reference for ACCOUNTS.

If you would be willing to be listed on such a page, please let us know, with the information you would like to have listed on it.

We are also of course also always grateful for additional testimonials for ACCOUNTS, which get listed on the Testimonials page on the website, at http://www.software4nonprofits.com/accounts/testimonials.htm. You can email anything you would be willing to have published to us. Testimonials are usually followed by your name and organization name, optionally your position there, and the organization’s general location. We do not generally put contact information on the Testimonials pages.

Thank you for considering this.

Changing Bills with Bill Payments in ACCOUNTS

Hello ACCOUNTS advisors and beta testers. Long time no blog!

I realized in the course of a support issue recently that ACCOUNTS allows you to modify bill transactions (entered with “Enter Bills”) for which you already have bill payments (entered with “Pay Bills”) recorded.

While I think it makes perfect sense to be able to correct the splits on such a bill, changing the amount seems rather more questionable, since it will then presumably no longer match the amount of the bill payment (assuming it was a payment of the entire bill, not a partial payment).

So I’m wondering which change should be made to this ability to edit bills with bill payments on them:

1. Don’t allow the total amount of the bill to be changed. (In that case, to change it, you would first have to delete the bill payment, make the change, then re-enter the bill payment.)
2. Allow the total amount to be changed, but warn the user before saving the change that “There is already a bill payment on this bill in the amount of $xxx.xx. Do you really want to change the amount of this bill?”, or words to that effect.
3. Same as #2, but also warn them about this as they are entering the window for editing that bill.

What do you think? I think Kwame and I are leaning towards #3, but are definitely open to other views. Thanks.

Memos on Transactions

Hello again ACCOUNTS advisors. Long time no communicate!

Someone has raised a question about memos on transactions. He was concerned when memos he entered on transactions (such as say a direct purchase entered on a bank account register window) didn’t show up with the counter account’s details for that transactions in a report such as Reports -> Details -> Transactions by Account.

The reason for this is that memos are attached to splits lines in transactions, not the transaction itself. Each transaction includes at least two splits (a debit and a credit, technically). With a purchase entered on a bank account’s register window, the memo you enter on the register window itself gets associated with the split line for the bank account (the credit), but no memo gets associated with the expense account you enter (the debit). You can fix that, by opening up the splits window and entering a memo there, but obviously that is extra effort.

The reason I designed it this way is that I think expecially for complex transactions with multiple splits, you might want a different memo on each split line, to better explain that particular line. (Plus, other programs seemed to do it that way too.)

The user who brought this to my attention has made a suggestion, which I’m considering, and want your opinions on. The suggestion is that when you enter what is apparently an overall memo for the transaction (because it is the one entered directly on the register window, or on a special purpose data entry window like Write Cheques, Enter Deposits etc.), but you don’t enter other memos for the counter account(s) / splits, that memo should get automatically copied to the other splits lines of the transaction.

I see this happening at the point that you choose to save any such transaction. If this change was made, there would also be one-time fixup of your existing data done by the new version of the program, to make it be like that. I.e. when the first split line in a transaction (which is the one you entered on the register window etc.) has a memo, copy that memo to any other splits lines in the  same transaction that are current empty.

Your thoughts? Any drawbacks? Thanks.

Indenting of Amounts in ACCOUNTS Reports

Hello again ACCOUNTS advisors.

I’ve had a user complain that she didn’t at all like the way the dollar amounts are indented in reports such as the Income Statement or Balance Sheet, to show the sub-account levels. She would have preferred all of the amounts to line up perfectly vertically. (She was fine with the indenting of the account names.)

I designed it with the indenting because I think it better allows you to see what adds up to what – everything that adds up to the same total below it is lined up, but things that add up to subtotals are indented to the left a bit.

Please let me know if you have any significant preference one way or the other for the two designs – amounts indented by sub-account level, or completely lined up. Or, if you feel it would be important to provide an option to the users to have it either of the two ways.

Thanks!

Building Fund and Mortage Payments

Hello again ACCOUNTS advisors.

I had a question from a user in a church yesterday, which has a Building Fund, and a mortage on their church building. As usual, the mortgage payments are made up of a principal component (which reduces the long-term liability account balance for the mortgage) and an interest expense component.

She was hoping that the principal component would reduce her Building Fund balance, but of course it doesn’t, because in my design only income and expense accounts can be linked to fund accounts. (The interest component would of course reduce the Building Fund balance, because its account would be linked to the Building Fund account.)

In some ways I can see what she is thinking. If $1,000 has been donated to the Building Fund, to help pay the mortage payments, and an $1,000 mortgage payment is then made (perhaps composed of $100 principal and $900 interest), one might indeed expect the Building Fund balance to be reduced by that $1,000, since the money was spent.

Does anyone have any bright thoughts on either how to explain why this is not appropriate, or how to make it happen in terms of what the splits on the transaction could be? I’m afraid that I don’t.

Thanks.

ACCOUNTS drop-down lists of accounts

Hello again ACCOUNTS advisors and beta testers.

There’s something about the design that I’ve been wondering about, that I’d like your opinions on.

In drop-down lists of accounts, such as in the register windows, the Write Cheques window etc., the account names are indented according to whether they are top-level accounts, sub-accounts or sub-sub-accounts. However, no parent accounts are shown, because it’s only accounts that have no sub-accounts themselves that can have transactions posted against them, and thus only those accounts are shown in the drop-down.

This could be considered to be misleading, because if you (say) have a top-level account (call it A) that has no sub-accounts, and the next account in the drop-down list is a sub-account (call it B) of a different top-level account that isn’t shown (call it C), the indenting makes it look like that sub-account B is a sub-account of A, rather than of C that isn’t shown.

So, I’m wondering whether I should stop indenting account names in drop-down lists, unless there’s a case where all accounts are being shown in that drop-down list, not just ones that you can post transactions to. (I’m not sure there is such a case in the program so far.)

Opinions? As always, you can reply to this post online, or just email me your thoughts. Thank you.

ACCOUNTS version 1.04 testing – Memorized Transactions

Hello again ACCOUNTS beta testers and advisors.

I am preparing to release version 1.04 of ACCOUNTS, which has a number of fixes and improvements. The most relevant changes since version 1.02c (the last announced release) are:

• Added Memorized Transactions capabilites in the register windows, through right-click menu options. You can memorize everything except bills and bill payments entered with the special features for Enter Bills and Pay Bills, and your Opening Balances transaction.
• Added the Database -> Delete All Transactions menu option (for optional use after initial testing).
• Added Reports -> Details -> Transactions by Payee / Description.
• Added right-click menu options in the register for Edit Bill and Edit Bill Payment.
• Added a “Name for Cheques” field in the Vendor details, which is what gets printed on cheques if it is present and different from the Vendor’s Name field.
• Journal Entries and Opening Balances transactions displayed on a register window are now basically non-editable, except with the right-click menu options are Ctrl+E.

If those of you with a bit of time and the interest could try this version out and let me know what you think (positive or negative!) about the changes and your testing experience, it would be greatly appreciated, and hopefully ensure that the official version I will release to all users will be as bug-free and well-designed as possible.

You can get this beta test version, as usual, from http://www.software4nonprofits.com/accounts/pretest.htm.

Thank you.