Material is Copyright, VolResource - please contact if you wish to re-use it.
Skip to: Site menu | Main content | Accessibility

This version of VolResource is no longer being updated. Please use the revamped site instead:

To access the old pages for any reason (e.g. smaller file sizes):

and do check all information thoroughly.

Accountancy Software

Issues

Updated 6/11/00

Follow the trail

If you came to this page from a link external to VolResource, we suggest going back to the Intro page! If you just want to check out the software available, go to Packages round-up. Let us know if we have missed out your vital concerns - use our response page.


This page is based on a paper produced for Charityfair 96 - Accountancy Software Challenge, updated and extended. It covers:
- basic terminology
- why accounting in the charity/voluntary sector is different,
- why accounting packages can be a help, but aren't always,
- relevant trends and future developments in software,
- dilemmas in software choice.

TERMINOLOGY

Every software supplier tends to develop their own use of words which can cause some confusion when discussing facilities or ease of use. In SunAccounts for instance, a Journal refers to the normal way of entering data, while this would be an exceptional item in many other packages. We prefer to refer to the process of entering a complete accounting record (e.g. NatWest cheque for 50 made payable to Kim Bloggs, for summer playscheme expenses) as a Transaction.

Chart of Accounts is the accounts structure, made up of account codes and/or names, and may incorporate further analysis (e.g. into Projects, Departments or Funds). If you are used to a Cash Book or other manual record with columns, think of them as the column headings, with Project analysis etc. requiring separate books or ledgers. Codes are usually numeric with the sequence being important in creating reports and setting a logic (although in isolation such codes can be meaningless). Some people prefer to have alphanumeric codes to make them more memorable, but not all packages will support this. Also called nominal coding.

Trial Balance If you don't know what this is, for most packages you will need your auditor or other accounting expert to advise you on the Chart of Accounts and analysis issues.

Important charity finance terminology
- SORP (Statement of Recommended Practice). The accounting regulations as part of Charities Act 1993 brought this into effect from 1st March 1996 for all registered charities. This requires certain principles to be followed in compiling annual accounts. 'Minor' revisions due to be agreed summer 2000.
- SOFA (Statement of Financial Activity) under SORP replaces the Income and Expenditure Account (which was similar to, but not quite the same as, the Profit and Loss Account)
- Fund Accounting: Restricted, Unrestricted, Designated, Endowment.


WHAT COULD A PACKAGE DO FOR YOU?

ON THE PLUS SIDE
Improve reporting, and therefore financial management
The complexities of providing appropriate financial information to funders with the 'contract culture', mixed and multi-funded projects and so on have already pushed up the demands in reporting. Then add increasing pressure from new charity regulations and greater public exposure of 'poor management' at the same time as needing to get every last penny work to meet the demands on your organisation! A good accounts package implemented properly can make a massive difference.

Banish arithmetical errors

It is virtually impossible with most packages for them to get 'out of balance'. (However, processing transactions during a thunderstorm has managed this in my experience!) Reports should always add up, too.

Make record keeping more consistent
You can still enter a transaction against the wrong code, but a good package will reduce the possibilities and ensure that there is a reference and amount for every cheque or receipt. This does not eliminate all manual records, though. All vouchers will still need to filed, in a logical order, and details of what was entered to the package (and preferably by who if there are many operators) should be written on them too. This will help in tracking errors, in the audit and if disaster strikes, requiring re-entry of transactions.

Reduce audit fees
The above items should mean audit work is reduced, although how easy it is to extract detailed information from the package at the year-end will also make a difference (in either direction). And any hidden problems (see below) will count against this.

ON THE DOWN SIDE
Add another layer of mystification/hurdle to get over
Aren't finance matters bad enough without having to learn how to use a computer too? With packages like QuickBooks aiming clearly at the non-accountant, the problem is much reduced. However, it still helps that you have some idea about how your finances work, and what end-result you are expecting to get out of the system. If this applies to you, crack financial confidence first.

Hide problems
Computerisation by itself won't solve all accounting problems. If the person doing the books doesn't understand what cheques have been written for, or how to do a bank reconciliation, this won't help. The spurious authority of computer generated reports makes people more reluctant to challenge figures or ask what may seem a silly question. It is easy to produce SOME figures with an accounts package, but are they up-to-date, understandable, complete and based on reality?

Use scarce resources
See issues on cost. Buying, installing and setting up systems are obvious costs, but what about continuing support? Does this mean you have to pay for upgrades to keep up-to-date? Will you need expensive consultants if you change your organisation structure, to make the accounts fit?

Lock you into an unsuitable system
This is the one which should terrify you if you have started computerisation without adequate preparation. A badly set up system is worse than useless. It can make data entry complex, slow and inconsistent; reports misleading (without all the relevant data) and late; and mask the underlying problems, making them difficult to spot, clarify and correct. Huge sums of money can be lost, due to knock-on management inefficiency and in resolving the issue.

Make you dependent on software and hardware
Regular back-ups are essential, in case of computer failure, fire, theft, thunderstorm (see above) and sheer human stupidity. Make sure the package you select is easy to back-up, and institute a clear procedure immediately.
Once you've computerised, it is very difficult to go back to manual records if disaster strikes. You need to be able to get your accounts system reconstituted as soon as possible - do you have another machine you can use, or are you reliant on the insurers coughing up eventually?


HOW DOES THE VOLUNTARY SECTOR DIFFER?

REPORTING AND ANALYSIS
Tracking Restricted Funds and reporting in SOFA rather than Profit and Loss format are key needs for registered charities, while project or grant management and measures of success not reducible to a 'bottom line' are common complexities. Concentrating on Cost of Sales and Gross Profit before Overheads in reporting structures, typical in accounts software, is not a helpful approach. What flexibility is there in report formats, and/or what facilities to produce reports to charity requirements?
To be able to report on Funds, projects etc.. it is necessary to have been able to have analysed the transactions to this level of detail, preferably as you enter them. Are there facilities to do this, outside of the basic account codes, or do you have to have a very long chart of accounts, which is difficult to manage and familiarise?
Can the package meet the SORP requirements, and can reports during the year reflect the principles where appropriate? This requires good analysis facilities to feed into the report 'extraction' routine. Or in practice, do you produce monthly management accounts in a way which makes sense to your budget managers and only want to produce to SORP format at the year-end, in which case getting the precise layout is less important.

COMPATIBILITY
Import facilities: There are a number of packages around dealing with specialist income areas: covenants, membership, relationship fundraising, rent accounting, investments. Transferring data directly to the accounts prevents errors in re-keying as well as saving time. However, you may not want a 'live' link, as it is good practice to do checks on data brought in to the accounts package from elsewhere (e.g. membership income by batch controls).
Export facilities: This is closely linked to reporting. If a package has enough analysis available, but not the reports, a spreadsheet (or possibly database) can solve this as long as the data can be transferred to it easily. This can also be useful in building cash-flow projections and 'what-ifs' around changing budgets or establishing new projects.

SALES
Credit control and sales invoicing are generally much less important. Some packages have limited options - will grant income have to be entered as a paid Sales Invoice, or as an 'exceptional item' through a journal?

VAT
VAT is not relevant to the majority, but is often a compulsory feature - work-round required (suggestions: ignore this data item; if not allowed to, treat everything as zero rated or exempt).
Where VAT is relevant, organisations often have to deal with 'partial exemption', where only some VAT on expenditure can be reclaimed. This means that VAT on central costs can only be claimed in proportion to VATable activities. Generally, an adjustment outside the accounts package will have to be made before the VAT return is completed.

COST
Commercial companies have finance as a central concern, so accounts software can easily be seen as an investment. For the charity trying to squeeze every drop of benefit from its income, this is harder. Also, resources to buy new, higher specification, computers are becoming scarcer for many smaller groups. There are less likely to be in-house computer or finance experts, increasing costs where the package requires a lot of setting up.


TRENDS

Utilities such as wizards incorporated with spreadsheets and databases make it tempting and quite easy for small organisations to do all their accounting and reporting within these, without the cost of an accounts system. The downside comes when dealing with growth and changes of personnel - such an approach may be unable to cope or impossible to understand, with resulting disruption and costs of starting again from scratch. Usable package start at 99, making this problem avoidable, although unexpected growth may still require upgrading software (and probably hardware if you need to get into the high-end client/server arena).

Crystal Reports, a powerful but fairly inexpensive (from approx. 100) report designer, provides extended capabilities for many packages. It can link data from a variety of databases and bring it onto one sheet, but does require a knowledge of the source data structure and is likely to be overwhelming to the novice.

Developments in Job costing/project management add-ons could help in project accounting, but can be complex to set up and use, and so tend not to be suitable for use by project workers looking to manage their own costs.

Looking ahead

With continuing efforts to topple Sage from its dominant market position, and the gradual exploitation of connectivity and 32-bit benefits of Windows, analysis and reporting should continue to improve gradually for the cheaper packages. Data 'warehousing' and web technology are also likely to have an impact. For larger organisations, centralisation of information into database 'warehouses' with access via web intranets is already starting to happen.

Sage reckons it will take up to10 years for small businesses to move to 'online' processing and filing of data - with the accounts package no longer sitting on your machine, but accessed via a (customised) web browser. Other suppliers have already demonstrated practical use of XML web-based protocols to do electronic processing of orders, invoicing and payments, which could quickly replace EDI (Electronic Data Interchange) whose cost and complexity has limited it to the big boys. Getting this to work initially could make those 5 page Y2K questionnaires previously required by large institutions, before you invoice for a single publication, seem trivial.

Put the two (warehousing and web) together, and perhaps we are looking at outsourcing large parts of the finance function for the smaller voluntary organisation as the way forward. Another possibility is a revolution in inter-action with branches or supporters, with summary monthly accounts potentially easily accessed.


STRIKING THE BALANCE

There is a dilemma of balancing cost, ease of use, underlying strength of software company and product, and facilities written specifically for the sector. The latter don't come cheap, although Kubernesis provides real value for money if you are happy with its lack of pretty screens, and they and Blackbaud can give good phone support on charity accounting problems. How important is SoFA reporting, if you only use this format at the year-end? Or do you really need to track balances on Funds during the year?

The newer written-for-Windows packages, such as Access, provide impressive facilities for the money and have used the operating environment to good effect. If you understand what you are trying to get out and hence can put together an effective chart of accounts and analysis structure, they will serve well. On the other hand, the security of a product from world accounts software leader Sage may be a deciding factor, and any problems in using the fundraising or member management modules are unlikely to hit the core accounting activity.

 

Now you have got here, how about look at The Selection Process? Or the round-up of packages?