At first glance, accounting seems like a pretty simple application. There are debits, credits, depreciation and amortization, and lots and lots of journal and adjusting entries. Of course, everything looks simple until you actually have to do it.
And then there is accounting for nonprofit entities. It doesn't even look simple at first glance. Under Section 501, there are numerous subtypes of nonprofits ranging from federal credit unions (501(c)(1)) to local chambers of commerce (501(c)(6)). And while most (but not all) of these subtypes have to file Form 990, the way that income and expenses are reported can vary greatly, which often means that while nonprofit accounting software is a vertical, within that specialization are often even more closely defined sub-vertical offerings. Accounting software that is suitable for a municipality is probably not going to be as good a fit for a small nonprofit day care center.
Still, the market for more-or-less generic nonprofit software remains strong. Vendors of nonprofit accounting have pretty much locked down major features years ago, so yearly updates tend to be bug fixes and tweaks to the user interface. The most important change is the move to the cloud with Software-as-a-Service and hosted applications. For many smaller nonprofits, the availability of cloud-based accounting is a game-changer. For a set fee, it allows a small nonprofit without much, if any, capital budget to be able to implement a much more expensive accounting system (and possibly donor management or other specialized nonprofit software) than they would be able to afford to run on in-house equipment.
Still, many nonprofits prefer to have their software running in-house and on their equipment, and there are plenty of choices regardless of which they prefer.
WHERE DO YOU START?
Helping your nonprofit clients decide on what accounting system to use isn't quite the simple task it might seem. You're actually "the man in the middle" (regardless of gender). On one side, you need to be able to help your client make up a realistic list of requirements. On the other side, in many cases you are going to have to work with a value-added reseller or independent software vendor who often is trying to sell your client something that might not be the best fit.
The key to a successful acquisition and implementation is to have a structured approach to helping your client understand where the risks are in the process.
And, as counterintuitive as it might seem, oftentimes the best place to start is at the end - with the staff who are going to be using the system. The reason for this is simple. When you start with the board or executive director, odds are that you are going to get a punchlist of everything under the sun. This often includes reports that will never get looked at ("But we want them just in case"), ad hoc reporting capability (even if the most likely users won't have a clue on how to use this feature), and other esoteric features.
Having the potential for sophisticated capabilities is great, but only if the people who will be exercising those capabilities actually have the capacity to work the application. All of us at one time or another have known that a software application, be it accounting or word processing, has the ability to perform a function, but figuring out how to actually accomplish it took minutes or hours of searching documentation on the Internet.
This usability factor is even more critical when dealing with nonprofit clients, as in many cases they tend to have high turnover. So while a particular fund accounting or financial management application may be moderately easy to use, you need to make sure that training for new users, or users that are moved to new positions and other responsibilities, is available on-demand or as close to it as possible.
MAKE YOUR OWN CHECKLIST
Many of the vendors listed in the sidebar offer white papers on what to look for in choosing a nonprofit system. Almost all of these are targeted toward your client, not you, though if you have the time to go through them you are sure to pick up some good ideas. But almost all of them focus on features.
To get you started in making up your own checklist for those critical client meetings (and the VAR/ISV meetings after that), here are some of the vulnerable areas responsible for many installation failures.
Pick the right application: As mentioned above, nonprofit software is a vertical application that frequently has ever more specialized variations. While it's possible in some cases to shoehorn a client into a generic nonprofit financial management system, it often makes more sense to steer them to a system specifically designed for their type of entity. For example, municipalities and health care organizations have very different accounting structures and needs.
Bring the IT department into the decision: Assuming that the nonprofit actually has an IT department, they are often left out of the decision process. Management just assumes that the IT staff will be able to handle whatever is decided at the executive level. In most cases, that's not a good decision. It's the IT department that is going to be the first line of support for both the hardware and software, and the first place that the client's users are going to turn to for help. Making them stakeholders in the acquisition process, whether the application is going to be run on new or existing hardware or in the cloud, is almost always a good idea.
Consider who will be using the system: In many instances, software is chosen based primarily on features. The expectation is that users within the organization will quickly come up to speed on the operations they need to perform. Sometimes that proves to be the case. Other times, not so much. In an acquisition and implementation project, you and your client need to take a very close look at who is going to do what. Not budgeting for time required for training and/or customization can throw a major wrench into the gears.
Educate your client sufficiently: Given that senior management is almost always part of the decision and implementation process, we sometimes assume that, because they understand how their entity functions, they will also understand how a software application fits into their operations and workflow. While you certainly don't want to give your client the impression that you think they are incompetent, keep in mind that you are part of the process because of your specialized knowledge. Make it plain that you mean no insult, but don't assume that your client knows what you do. It's much better to explain something to your client that they may already know than to assume that they have necessary knowledge that they actually lack.
Budget correctly: Acquisition and implementation take time and money. So do ongoing operations. Having a lackluster or informal time line for the selection and implementation of any application, much less one as complex as nonprofit accounting, is almost a guarantee that the project will stretch out beyond any reasonable expectation of completion. "Time is money" may be a cliché, but it's also a truism. If you are familiar with project management techniques like Critical Path Method and Gantt charts, use them.
Also, when you sit down with your client to work out the time and money budgets, don't let them forget to include budgets for ongoing maintenance and training. They don't want to go through an expensive implementation and bump up against a budgetary brick wall subsequently when a staff member leaves and their replacement needs to be trained.
And, since the implementation is likely to be mission-critical, have them consider bringing on temporary staff to take over more mundane tasks to free up other staff who may be required to help out on the project.
Finally, help your client to realize that the software they select and implement has to find that delicate balance of being suitable and affordable for the present, yet still have the capability of being usable five or even 10 years down the road.
Be realistic about what the system can accomplish: It's not easy to convince a client that they actually need a feature when they feel they can do without it. Sometimes the client wants to load up on features or options that just load down the system and budget without providing significant benefits. Other times, a client will become so fixated on the here-and-now that they fail to give proper weight to what will be required even a short time in the future. Few of us haven't had a client who has said that deadly phrase, "We'll deal with that when we have to."
Lyndy Januszewski, managing consultant in Illinois-based Sikich LLP's technology practice, offers this cautionary tale: "We had a client that was a little bit overzealous. They got an idea in their head early on in the project and kind of stuck with it, do-or-die. It was a health care association with many, many legal entities. Typically when you have many legal entities, it requires a separate database for each entity for tracking purposes. I made an offhand comment during the scoping process that they latched onto. They said, 'We would really like to streamline the process of managing all of these entities.' They wanted all of the companies to be on the same database. They stuck with this during the whole process. We brought up, 'How are you going to handle this? And that?' but they were so taken with the idea of a single database that they just clung to it."
"We foresaw that there would be an issue on how to assure that the right company paid its own invoices, and that 1099s issued at the end of the year were correct," Januszwski continued. "The client's response was, '1099s are something we deal with only once a year. At that time, we can just split out the values. It won't be a big deal.' Of course, year-end is always a chaotic time, and it was their first year on the new system. And it was exactly the worst time to find out that the system as configured couldn't easily produce a report that broke out the figures they needed to produce the 1099s accurately for each entity. This was a problem that could have been avoided."
Chose the right VAR/ISV: Once you and your client have narrowed down the features they need and estimated a timeline for implementation, you and they have to select a VAR that you will work with to actually proceed with the installation and implementation.
Don't assume that because a software vendor recommends a VAR that they are going to be the right partner to work with. Get recommendations from the software vendor and, if at all possible, people in organizations similar to that of your client who have experience with the VARs that you are considering.
Randy Johnson, executive vice president of K2 Enterprises, added a caveat about dealing with VARs who offer multiple nonprofit applications: "Watch for conflicting agendas in the sales process. Some sales organizations are so focused on fundraising that they will oversell the accounting portion of a project to get your fundraising business. If your client is going to also implement donor management, make sure that the Web site integration for donations is something that their Web team can support."
Make sure you find out as much about the specific team that will implement the application and provide ongoing support. Ask about their backgrounds, education and experience. Don't be afraid to insist that your client interview and pass on a VAR's team members. For an application implementation project to go smoothly, the VAR's team is going to have to work closely with your client's staff.
Keep in mind that the relationship between your client and the VAR is usually going to be a long-term one - unless you plan on providing training and ongoing support at the completion of the installation. You can't guarantee that a VAR is going to be a good fit for the client and project, but if you and the client ask around and don't get realistic (and positive) reviews, it's probably best to consider a different VAR.
AVOIDING THE POTHOLES
Making the right choices is critical to a software installation that's successful over the long run. And this process is a partnership that possibly includes the VAR or ISP that you and the client will be working with. But initially, it's going to be you and your client. One resource that both of you will find useful are societies and organizations that your client belongs to. Regardless of what kind of nonprofit they are, odds are they belong to one or more organizations where they can network with other users who have needs similar to their own. Recommendations and - perhaps even more important - horror stories are valuable sources of information that should definitely be considered as a resource during the process of helping your client select and implement a software system that will meet their needs and their capabilities now and for the long term.
NONPROFIT SOFTWARE VENDORS
Abila Nonprofit Online and Abila MIP Fund Accounting
Abila Inc.
www.abila.com/solutions
Accufund for Nonprofits AccuFund Inc.
www.accufund.com
Denali Fund Accounting
Cougar Mountain Software
http://cougarmtn.com/
CYMA Not-For-Profit Accounting
CYMA Systems
www.cyma.com
The Financial Edge
Blackbaud Inc.
www.blackbaud.com/fund-accounting/
Fund E-Z Nonprofit Accounting
Fund E-Z Development Corp.
www.fundez.com/
GMS Grant Management System
GMS Inc.
www.gmsactg.com
Intacct Nonprofit Accounting
Intacct Corp.
http://us.intacct.com
Microsoft Dynamics
Microsoft
www.microsoft.com
Netsuite Nonprofit Financial Management
NetSuite Inc.
www.netsuite.com
QuickBook Premier Nonprofit Edition and QuickBooks Online Nonprofit
Intuit Inc.
http://quickbooks.intuit.com
CenterPoint Fund Accounting
Red Wing Software Inc.
www.redwingsoftware.com
Serenic Navigator
Serenic Corp.
www.serenic.com
Traverse Not-For-Profit
Open Systems Inc.
www.osas.com/industries/not-for-profit
