Best Practices In Software Selection

There are good methods and bad methods for selecting accounting software.  First and foremost, the decision process has to be a collective effort.  Many individuals must have input into and take responsibility for the overall process.  Management must be fully aware of both the financial commitment and time required to implement a new system.  And, unless you truly understand your business processes, there is no way you can implement a new system that can benefit your business.  The following best practices are tested and proven.  Use these steps as a guideline allowing changes to fit your organization.  When this process is used, you are ensured a higher level of satisfaction from your new accounting solution. 

Project Team

Accounting software selection is not a one person task.  Representatives should be selected from multiple departments to oversee the evaluation and selection process.  However, the team should have only five to seven members.  It is proven that larger groups are unwieldy and difficult to manage.  If desired, larger companies may establish committees of this size for each functional area.

At a minimum, the following areas should be represented on the Project Team:

 Senior Management

While it is not required that senior management lead the team, it is required that senior management be represented.  This individual gives the team authority to act decisively when necessary and provides a management perspective to the team.


Obviously, knowledge of accounting practices and company procedures is required when selecting a new accounting system.  This person should be familiar with current accounting procedures and able to approve changes. 


Every company operates a little differently.  The purpose of a new accounting system is not just to improve accounting, but to improve and integrate the procedures and processes of the entire business.  A new system should never be selected without involving those individuals that make the business go.  In services, this is a Project Manager.  In distribution, this includes purchasing and inventory.  In manufacturing, representatives of purchasing, inventory and shop floor management should all be included.  

Sales and Customer Service

Lead management, prospecting, sales processes, estimating, quoting and customer service should all be considered when selecting a new system.  This sales and customer service representative should be able to provide insight into these processes.  

Information Technology

Believe it or not, new systems are chosen without regard to current technologies and outdated infrastructure.  While the representative of IT should be willing to consider alternate platforms, the foundation of the accounting system is crucial to its long-term success.  The solution must be adaptable and expandable with changes in the business.  To consider a system built with outdated tools and technologies is suicide.  Would you consider a DOS solution today?  Furthermore, the IT representative will be able to advise the team as to the requirements and investment in infrastructure and support of the new system.    

Ultimately, the Project Team must convince management of their recommendations and management must be willing to make the commitment.  Although the team is rarely the final decision maker, members must feel that management will listen to and act upon their recommendations.  If team members feel that their considerations do not matter, then do not waste the time or money on the Project Team.  One of the foremost causes of cost overruns, delays and shortcomings when implementing new applications is a lack of acceptance by the end user.  The first step in achieving buy in and significant savings on the total project is a knowledgeable and committed Project Team. 

Requirements Analysis

How can anyone select an application if they do not know what the application should do?  Even if you have been with the company for twenty years and you know exactly what is needed, the minimum requirements should be documented. 

Requirements analysis involves everyone documenting what they do and how they do it.  Usually, a consultant or a member of the team interviews the appropriate people and documents the business process.  Alternatively, each person documents their responsibilities as part of their job description and the team summarizes the responses.  The problem with this alternate approach is that it is time consuming and the new system frequently changes the process anyway. 

Either way, the requirements are then prioritized.  Mission critical tasks (those that have a financial impact) should be identified.  Those processes that are mission critical, or extremely labor intensive, and are not necessarily the same as another companyís process, must be identified and documented.  It is not necessary, or even worthwhile, to spend much time on standard processes such as accounts payable payment selection.  That the payments are selected based on discount date, approved by the controller from the payment preview report, printed and electronically signed is sufficient.  Some requirements are also listed as nice to have, but have no financial impact on the business or the selection of a new system. 

The result is a rough workflow diagram of how information is processed through your business.  Some workflows will be developed in more detail, so that they can be revised.  This analysis results in an improved process for the new system.  This is the perfect time to reengineer and optimize your processes.  When you discover that the same task is being done three times by three different people, that process should be changed.  In fact, this is frequently the justification for the effort. 

The end result of the Requirements Analysis is a definition of the requirements for the new system.  This document defines what your business needs from an application in order of importance.   During the analysis, you should also gather samples of every form (checks, invoices, pick tickets, etc.), and every report.  Identify any renegade systems.  (Excel spreadsheets and Access databases used to supplement the current system.)  Determine if the system or report is really necessary.  This is the opportunity to eliminate duplication of effort. 

Talk with Representatives of your Current Accounting System 

Obviously, if your current accounting system is a custom solution or discontinued product, this is a moot point.  But if you have a relationship with your current accounting solution provider, it is a good idea to share your issues and needs with them and give them an opportunity to submit a recommendation for solving your problems.  If it is an option, keeping your current system is usually cheaper, easier, and less disruptive on your organization.  If the problem is your consultant, then consider replacing them with a new consultant that works with your product.  Many times the problem is that the current consultant simply is not, or is not capable of, taking care of the client.  An upgrade and training might solve the problems for much less. If you are dissatisfied, and conversations with your consultant have not helped, then contact the software manufacturer directly. They may be able to introduce another consultant in your area. 

Define a Budget and Milestones 

The first task for the Project Team is preparing a preliminary budget and determining milestones with completion dates. 

It is important to establish what you think you can afford to spend.  Ask yourself the value of a new system if it could accomplish all of your objectives.  Look at the investment over a reasonable period of time.  A new accounting solution will only pay for itself over three to five years.  If you could hire an employee that could accomplish all of your objectives, what would that employee be worth to you?  Discuss other possible implications of changing applications, including investments in infrastructure and the commitment of resources.  It is not prudent to venture forward if you do not have the funds and resources available to do so. 

On the other hand, remember that this is a preliminary budget and not set in concrete. The budget and the milestones will mature quickly as the team finds answers to questions and completes their initial discovery work.  Although the initial budget should define what the business is willing, or able to spend, it is almost always lower than the actual costs.  Within a short period of time, depending on the scope of the project, you will know what may be required. 

Milestones help keep the process on course.  Most businesses have seasons when the business cannot be interrupted.  For example, a public accountant would not put in a new tax application in March or April.  So plan around these periods and schedule accordingly.  Keep in mind that every business wants to implement their new system at the beginning of a new fiscal year.  Thus, year-end implementations require more notice for consultants. 

Having a preliminary budget and milestones prepared will be helpful as you negotiate with consultants and VARs. 

Consider a Consultant  

Most people go through the process of selecting core accounting application software no more than three times in their entire career, and usually fewer than that.  Depending on the size of your company, the scope of the solution needed, your knowledge, and the available time of you and your staff, hiring a consultant can be a good move.  It allows you to capitalize on the consultantís expertise and experience while minimizing the time required from your staff. 

The selection of a consultant should be carefully considered.  An experienced consultant can assist you in preparing your Requirements Analysis and Request for Proposal.  This person may not be the same person who assists you after a product is selected and you need technical expertise in the implementation process.  Initially, you will want a consultant that is familiar with your industry and is unbiased.  This person is bringing experience and expertise to help you ask the right questions, follow the right steps and prepare your written documents.  Once the product is selected, you will want someone who is experienced with the product and has implemented it several times to assist you and represent the best interest of your company. 

However, there is no such thing as an unbiased consultant.  Every independent consultant, software representative, or public accounting firm is prejudiced based on their experience and the products with which they are familiar.  Even if you never participate in the implementation of a product, a good consultant follows up with their client and evaluates their services.  If the client is satisfied, then they are more likely to recommend that solution to their next client.  Frankly, an honest consultant with in-depth knowledge of several products is more likely to recommend an appropriate solution than one that has never implemented a system.  They already understand the pitfalls in the process.  No consultant, no software vendor, wants a dissatisfied client. 

Do Your Homework 

The next task for the Project Team is to learn what features and functions are available.  Begin by making a list of all of the products that might meet your needs.  Include all the products you have heard or read about, products listed in industry publications, products listed on the Internet, etc.  If possible, talk to others in your industry, including your competitors, and find out what they use. 

Build a spreadsheet or database to tabulate key information for each product.  For example, include information for modules, cost, platform, customization capabilities, bar coding, etc.  The objective here is to focus on only the most important issues.  Do not be blinded by insignificant shortcomings that have no economic benefit.  This matrix will facilitate sharing information with others in the ultimate decision.

Begin by tabulating a list of the features and facts that impress you about the company and the product.  For example, you may list key awards, local support, or a feature from which your company would really benefit. Add to this list as your evaluation continues.

Once you have fully researched the market and have a complete list, eliminate any obvious poor choices.  Start to eliminate candidate products because of platform, missing functionality, or because of cost if outside your reach.  But do not eliminate on price alone.  Though higher end solutions may seem expensive, their features may actually give you a higher return on your investment.

Selecting the right package is primarily a process of eliminating the wrong packages.  Keep the list, in case someone asks later why a specific vendor was not considered.  Generally, you can eliminate many products at this stage and continue to eliminate products throughout the entire process.

As you are reviewing potential candidates, you have the advantage of Internet research. Do not simply visit the vendorsí web site.  Search using the Internet Search Engines for reviews, articles, and comments made by the media and users.  Many of the vendors have downloadable trial versions you can prototype before buying the product, as well as case studies and references you can verify.

You now have a solid list of requirements and potential packages that meet those requirements. 

Request for Proposal (RFP) 

Small companies interested in entry level accounting solutions such as Peachtree or QuickBooks should not consider an RFP.  However, mid-size to large companies should proceed.  If nothing else, RFPís force the company to formally define and describe what is expected from the software vendor.  If you decide an RFP is not required, at least use the Requirements Analysis to present a formal document to your software vendor that defines your expectations. 

The RFP should allow a vendor to respond with a few pages, not a volume of column fodder.  Encourage use of brochures and other standard material, rather than a lengthy list of software requirements.  The vendorís response should allow the team to narrow the list of potential packages to two or three without a lengthy detailed analysis of the response.  Concentrate on platform, adaptability, and cost.  Then focus on those functions that are unique and mission critical to your business.  If the package was not a good fit, you would not have sent them the RFP in the first place.


Now invite only the top two or three vendors to demonstrate their product.  If you review more than two or three packages, all the packages meld together and become a blur.  Each will seem to have all the features offered by the other.  You can only absorb a limited amount of information.  

While you are interested in an overview, you must concentrate on those unique features specific to your business.  Provide a list of the features and functions that you want demonstrated to each vendor.  Expect them to ask you extensive questions about your company and your needs.  Require the use of live software to demonstrate the product, preferably with your data.  Each vendor should be able to do this in between 4 to 8 hours. 

Do not meet with any vendors prior to completing the Requirements Analysis.  You do not know what to ask for until you know what you need! 


Talking with and visiting current users will provide you insight as to how others are using the product.  Users are normally happy to share their experience.  We also recommend different people in your organization call their peers in the reference company. For instance, the IT professional will ask different questions than the controller or the manufacturing floor supervisor.  If each talks with their peers and shares them with the team, better decisions can be made.


Often the decision of which solution to choose is based on the process of elimination.  If you have followed all the steps above, you should be ready to make a qualified informed decision.  Keep your documentation.  Make sure that all communications, including the vendorís response to the RFP are part of the agreement you are signing.  Make sure that milestones and objectives are clearly defined in the Statement of Work (SOW) so that everyone knows what is expected.

~ Top