Accountancy Software Introduction - Contents
- 1 Starting points
- 2 Accountancy Software Issues
- 3 Terminology
- 4 What could a package do for you?
- 5 How does the voluntary sector differ?
- 6 Trends
- 7 Striking the balance
- 8 Selecting Accountancy Software
Community Accountancy Projects are useful resources, where they exist. One of the most active is Community Accountancy Self-Help (CASH) which operates in west London. Its web site includes a variety of factsheets which may be helpful.
- Sage Charity User Group. Sage Line 50 (which used to be called Sterling) is perhaps the most widely used in the sector, with Line 100 less popular but growing (perhaps for the membership and other useful add-ons available). The User Group is independent but serviced by Intelligent Solutions, who are specialist Sage Solutions Dealers. See Suppliers for contact details.
- Sun User Group. Special Interest Group of Charity Finance Group – see Helplines/Professional bodies.
- Great Plains Dynamics. Charity User Group run by Tate Bramald – see Accounts Packages.
The Charity Finance magazine/Kingston Smith IT survey, undertaken April 1999 and published July with the magazine, found that Sage had over 40% of the accounts software market for those with turnovers up to £5 million, but no distinction was made between the rather different Line 50 and Line 100 Sage products (or indeed Instant Accounting). Sun was predominant in the £5 to £10 million range (over 30%), with a good showing in even larger organisations. Pegasus got an overall 6% share. On the other hand, 46% used none of these product ranges (no other packages mentioned in the survey report). Microsoft Excel spreadsheet facilities were used by a quarter to produce management accounts (as opposed to financial accounts used for audit purposes etc.) but Sun users didn’t need to resort to such ‘add-ons’.
Accountancy Software Issues
This section (previously a separate page on the old site) 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.
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.
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.
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.
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 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.
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.
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.
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.
Selecting Accountancy Software
A REALISTIC APPROACH TO SOFTWARE SELECTION FOR THE SMALLER ORGANISATION
Some updating from original 1996 version.
Basics Allow yourself enough time for the process. Read this document through, and come up with a draft timetable. Then add time for slippage (sickness, holidays, staff changes etc.), and some more for luck!
1 What are you trying to achieve?
1.1 Look at our criteria (on Checklist), and decide how relevant they are. Look at reporting and analysis in particular.
1.2 Think about SORP issues if you are a registered charity. How do you want to handle the more tricky areas – will you leave it all to the auditor at the year-end? If not, here are some items to chew on:
i) Allocation of (eg) bank interest across Funds – is this significant, and do you want to do it within the accounts, or export it to a spreadsheet first?
ii) Is the SOFA of importance? Will you (or your auditor) be making so many year-end adjustments (eg via an ETB) that the SOFA produced by the accounts package won’t help?
1.3 What are the problems with your current accounts system (manual or computerised)? Make sure you address these in the approach, but don’t solely concentrate on them. You need a rounded view of where you are going as well as where you are coming from.
1.4 Compile your list of needs, and be clear what is essential, and what can be worked round.
2 How much can you afford?
2.1 Be realistic, but do view it as a relatively long-term investment, which can pay back repeatedly in years to come, by being able to use your finances better. Include future maintenance costs in the assessment.
2.2 Don’t forget to look at initial and future training. Perhaps you can use an existing training budget here.
2.3 Check that the proposed software will run on your hardware adequately. This includes when importing or exporting data, which tends to require more memory. If you have to upgrade, cost this, and add in extra to allow room for growth and increasing expectations.
3 A standard, voluntary sector or bespoke package?
3.1 Software written specifically for the voluntary sector may meet your needs most effectively. But be aware of the smaller knowledge base and that the supplier is nearly always very small (and you may be reliant on their survival), as well as cost.
3.2 Bespoke software, written for your organisation, may appear to offer advantages. However, it is likely to be costly initially, be dangerous if the author is not totally professional, and make you even more reliant on individuals. It is rare that documentation (if there is any!) is adequate for future users.
4 What packages meet the requirements?
4.1 If there aren’t any, reconsider the above!
4.2 Make sure you do a good search. Ask other similar organisations what they use, ask co-ordinating bodies, find a current computer magazine survey, re-visit the VolResource web site for updates..
5 Check them out
5.1 Arrange to see the packages in action, in a realistic setting (eg another voluntary organisation) if at all possible.
5.2 Think of difficult questions. Sales people will tend to reel off a list of features, and glibly say that they will meet your needs. Get them to tell, preferably show, you HOW they will actually do that, and have some examples to run through. Reporting and coding/analysis are the obvious tricky ones. If they can’t do it themselves, as they aren’t technical enough, get them to come back with the solution later.
6 Decide best fit
6.1 What fits your wish list best? Be prepared to compromise, but be clear what those compromises are, and why (and how you are going to cope with any rsulting complications).
7 Work out practicalities
7.1 Can you negotiate a charity discount? Be given extra time to pay? Will you in fact have the cash in the bank to pay the bill when needed?
7.2 Timing is vital (again). The obvious target is beginning of a new financial year, to start using the package in earnest (‘go live’). However, this may be a bad idea – will you be able to cope with all the year-end sorting out at the same time? It also means that there is no fall-back if something goes wrong with your timetable, unless you completely re-think. The only real rule is go live at the beginning of a month, or perhaps a quarter if that is an important time period.
7.3 Parallel runs are strongly recommended, where you run both the new computerised system, and the old one (manual or whatever) at the same time, and compare results after a month or two. In practice, this level of sophistication rarely happens, but you do need to do some sort of dummy run, and get proof that your systems will work.
7.4 Who will install the package on to the machine(s). If you have a network, who will be responsible for this aspect? The package supplier may not know enough about networks, and your network consultant may have no idea how an accounts package needs to be set up. Get them to talk to each other (easier said than done)!
7.5 Who will set up the accounts structure? Who will enter initial data? Do you need the auditor’s involvement to ensure the structure will meet their needs, and the opening data is correct? Design/adapt your paper systems to make data entry and referencing easy.Tags: accountancy, software