Accpac 5.5A ERP review (particularly for MYOB upgrade)
This is a review of Accpac ERP from the point of view of a small business (previously using MYOB).
Context: two companies, very international trading business, turnover in the range of approx $100m AUD, with around 85 people.
Order entry and stock is handled by an internally developed system with minimal interfacing to the finance system. Until mid 2009, MYOB Premier was used by Finance, with around five to seven concurrent users. We have been using Accpac since July 2009, as our finance system. We are using version 5.5A, the current version at the time we deployed it.
We took a very minimal approach. We have no customisations to Accpac functionality, apart from a few in-house developed reports. We also did our own data-conversion from MYOB: all open items and account balances for the past two financial years were loaded with Excel macros. This was quite a lot of work. The MYOB ODBC driver was invaluable for this (it costs about $300).
Accpac ERP Pricing and Licensing model
(This may only be relevant to Australia.)
AccPac is made up of modules. Core modules are available as bundles known as Series 100, 200 and 500. Each higher series includes more bundled modules (more functionality), and more functionality and higher limits inside common modules. For example, Series 500 allows more budget versions then Series 100 (which is limited to two), more levels in the chart of accounts, and "rollup" accounts to make budgeting much easier. Accpac has a tradition of increasing the limits of Series 100 and 200 with each major software release. Modules not included in the bundle can be added.
|Interested in SME Finance? You may also like my articles on transforming the finance function at an SME|
The core modules inside the bundles are charged per concurrent user. The pricing is stepped up, so that Series 200 user licences cost a lot more than Series 100, but series 100 is capped at a maximum of ten concurrent users. Therefore Sage can offer cheaper prices to smaller sites to compete against MYOB, while trying to protect margins with large customers. Probably a strategy doomed to fail with the move to software-as-a-service, but we were a small site so the Series 100 pricing was necessary to make Accpac competitive. It worked; Accpac's pricing model allows it to be much more competitive for small sites than some of the competitors we compared against (as long as those competitors are using the traditional licensing model).
The software cost also includes the annual licence fee, which is compulsory for the first year. Competitors are more flexible on this. The maintenance fee is around 20% of the module licence cost. It's not compulsory after the first year. The fee entitles the site to upgrades to future versions. I haven't yet confronted the decision to pay. I will evaluate the timing and attractiveness of upgrades.
Apart from the core modules, there is a wide range of non-core modules that can be added to Accpac, some of them third-party developed. We took a few, and they integrate perfectly. Recommended modules for MYOB migrators are the Optional Fields module, and the Orchid EFT module, which is discussed below. Apart from Accpac, most sites would probably want a license for Crystal Reports. Accpac reports and forms are all Crystal, so a license of Crystal Reports makes it very easy to tweak cheques and statements. Crystal Reports XI and 2008 both seem to work perfectly.
Concurrent users and security.
The licence allows a certain number of concurrent users. It doesn't matter what company database they are using. MYOB's licensing is based on the database. So with a five-user MYOB database, five users can each have two company databases open. With Accpac, this requires ten concurrent user licenses. Accpac is much, much more multi-user than MYOB. Performance is not affected by the number of users, and the use of a real database-server means that multiple people can work in the same module very easily. It also provides very good control over security, allowing precise definitions of who can do what. Security can even be defined per GL account, as well as the more usual user-role level. Security can be time-based (ie user X can do things, but only during working hours). Unfortunately, Accpac doesn't ship with default security profiles. It doesn't have any separation-of-duty analysis.
Stability and Reliability
Our deployment of AccPac is v 5.5A. This 5.5 release is at least years old. It's now very mature, which some years of bug fixes included. However, we ran into two bugs shortly after starting, one to do with bank recs and one to do with data import of invoices. Our reseller quickly researched the problems and remotely installed fixes, and we suffered no data loss. Overall, Accpac has performed very well in more than a year of live use.
Deployment, Database setup and Data conversion
Series 100 is limited to five company databases. If you buy the intercompany module, you'll use one of your company codes for it (this module automates intercompany bookings, but it's not necessary).You'll need at least one database for training and testing. For us, with two companies, the five database limit is close to the minimum we'd need. In other words, this is a significant restriction. We have various holding companies that need annual updating, and unfortunately we don't have enough databases free in Accpac to use Accpac for them.
Each Accpac company actually needs two databases: a company database and a system database. A system database contains users and some other common data, such as exchanges rates. A system database is designed to be shared across multiple company databases. While users are centralised, each company code maintaines its own profile of what those users can do.
Logon can be handled via Windows authentication, or by maintaining passwords in Accpac. Basic tools are provided, but passwords are a bit limited (uppercase only, for example). We use Windows authentication, although we were advised against this.
The recommended installation method is to keep the client executables on a network drive, since then only one location needs updating for patches. For a LAN inside the office, there is hardly any performance hit. For remote use from home over a VPN, it's very slow. Our solution is to use a remote desktop connection to a virtual machine, although possibly a local client on the laptop provided acceptable performance. I would recommend carefully evaluating remote use if it's important.
When would you need to make a separate company database, and when could you get by with using a profit-centre chart of accounts inside the one database? This is an advanced question, beyond my expertise. However, if you want different functional currencies and different financial years, you'll need different company databases.
Programs that create data, such as customer invoice entry, also have import/export functions. These work with a range of common data formats, such as CSV and Excel. We used this function to load open items, customers and vendors, using a VBA macro to convert MYOB data into the format used by Accpac, and then loading into Accpac. Data entry this way gets all the validation that Accpac can throw at something. It's quite fast, and it could handle a decent level of transactions.
It can also be used for bulk data maintenance: export, modify in Excel, and reimport. Unlike MYOB, these import and export functions can be done while other users are active.
Converting data from MYOB took quite a few hours to set up (via macros). However, it was worth it as once automated, data load is very easy. Seeing two full years of account balances in the new chart of accounts, and all open items perfectly carried over, was a nice warm feeling! The skills required are quite technical (my skill level is decent VBA programming skills and moderate SQL skills). I've have an article giving some insight into accessing MYOB data with SQL.
Accpac "programs" are icons launched in the usual way. Some of them change data (journal or invoice entry), and some of them are reports. The reports are entirely Crystal reports. Crystal Reports is also used for invoice and cheque forms.
Crystal Reports can export data to Excel reasonably well. Other ways to get data in Excel format are to use the Financial Reporter tool, which is a great part of Accpac, but limited to financial data. Accpac comes with a single user licence of a product called Alchemex, a third party tool which is also an Excel report writer. I plan to learn this but so far the Financial Reporter tool has been more than sufficient. And another way is to use SQL queries, which I touch on below.
Crystal reports is a very strong traditional report writer. It is weak in delivering online reports (you can't turn off pagination, for example), and it has weak to non-existent interactivity. It's miles ahead of MYOB, but for a genuine enterprise system where you want to share information with a wide-range of people, it's probably not a good solution. I don't know what is a good solution because we haven't addressed this yet.
Of course, a huge advantage of Accpac over MYOB is the real database backend (we use Microsoft's SQLServer), meaning that we can pull data direct into Excel via SQL queries. Accpac's data dictionary is well described, and opening any existing report into Crystal Reports will reveal the tables used, another way of learning how to build the right query. My preferred reporting method has been to embed SQL queries in an Excel workbook, and then make pivot-tables on that raw data. I fairly easily worked how how to invoke Accpac processing of data when it is necessary, in AR and AP aging, for example. There are very easy-to-use tables with the aged payables and receivable data, but they need to be updated first. It was quite easy to invoke the accpac program to do that via an Excel macro. So far, I have one tutorial on this.
Grouping: many "objects" in Accpac have a group field: Customer Group, Vendor Group, Account Group.
You use this field for reporting convenience: example, to report on all DVD suppliers. The reports only allow selection by range; you can't pick non-continuous values. That is, you can't pick only DVD and Games customers and exclude all others that fall between DVD and Games alphabetically. This is a poor aspect of Accpac; v 5.5 shows its age here.
Functionality, Core Financials. GL
Accpac is a highly mature, bullet-proof accounting package. It's a batch-based system, so journals are entered in batches (which can be as simple as one double entry, or hundreds). Batches are then posted in a separate step. The control over posting batches is a central part of Accpac. Once a batch is posted, it can't be modified, although a "reverse" button will create a batch which is exactly opposite. If this "reversing" batch is posted, then then will be a set of symmetric bookings cancelling out the first batch.This is obviously much stricter than MYOB, which allows modifications of posted entries in the current fiscal year (and you can't touch closed years). Accpac does allows postings into previous years, by the way, and correctly updates all necessary closing entries (such as retained earnings), which is much, much more sophisticated than MYOB. Of course, periods which are closed can't be posted to. Batches can be provisionally posted, with is a temporary posting. Provisional batches can be modified and posted again and again; reporting has to switch to "provisional" to see the effect. Also note that there are no entry value-completion features in Accpac. MYOB will prompt the user with the value required to balance an entry. Not with Accpac. You can see what the unbalanced amount is for the current entry, but you have to type it yourself. I don't do a lot of journals, but this anti-feature has saved me from making mistakes a few times. A sign of Accpac's solid and deep heritage.
GL journals can create automatic reversing entries, defaulting to the start of the next period (but that can be changed).
All these steps mean a lot of control over who does what. You can allow a junior to book supplier invoices, have a more senior AP person review them before posting to AP, and then have a different person post the resulting GL entries.
Accapc also has a very strong sub-ledger approach. AP and AR are actually separate programs. It's possible to use Accpac's AR without using Accpac's GL. What this means for normal use is that a customer invoice is created in AR, creating a draft AR batch. This is posted to the AR subledger, updating open items. At this point, a GL batch is created but not posted.This strong use of sub-ledgers is very traditional in accounting systems, for good reason.
An ACCPAC weakness is that closing a period simultaneously affects sub-ledgers and the GL. It's not possible to stop a sub-ledger user from entering invoices in period 1 without simulateously stopping GL users from entering batches, which is a nuisance at closing when the GL team is doing adjustments but you don't want accidental posting of late-arrived invoices by the AP people, for example. This is a practical weakness to the scalability of Accpac, because careful co-ordination is required.
The different sub-ledgers always end up causing GL batches. GL accounts can have restricting limiting which sub-ledgers and post to them (that is, control accounts can be blocked for GL journal entries). For example, your AR accounts should not allow GL batches (that is, manually created journal entries). However, unfortunately if you have a GL account that needs GL-based revaluation (a foreign currency bank account for example), then that account must be open to GL-created journals. This is not a problem for AR and AP control accounts, because AP and AR have their own revaluation procedures which create revaluation bookings from the sub-ledger, so there is no need to open AR and AP control accounts to GL journals. Hopefully, Sage will change Accpac to distinguish between GL currency revaluations and GL journals.
Foreign currency is another area where Accpac shows its depth. Accounts can be setup as multicurrency accounts. You can control which currencies can be posted to any account, and revaluation possiblities can be set per account. A variety of different exchange rates set can be maintained, such as spot rates, or monthly rates. Foreign currency functions can use any of these rate sets.
Foreign-currency revaluation is strong. Open items are revaluated via sub-ledger revaluation processes, and foreign currency GL accounts can be revalued with a GL revaluation process. Meanwhile, realised gains and losses are calculated. There's a lot of flexibilty over which accounts can be used for all of these. A number of different exchange rates can be used (example, daily spot rates, or monthly average rates). Multi-currency accounts are well handled. When journalling to a multi-currency account, either the functional currency or the source current can be entered. The conversion is shown, and it can can be edited, allowing precise matching of foreign currency amounts on supplier invoices or bank statements. The exchange rate database is stored in the "system database", meaning it can be shared across multiple company databases. Exchange rates are easily updated with a macro (see Automation below). MYOB is very weak in foreign currency handling.
We currently have AUD as the functional currency in both company codes, including one based in HK. Accpac will let us use a different functional currency should we wish. Accpac has very strong forex support, and is in a different league to MYOB. It's well ahead of other packages we looked at, as well.
Technically, all unrealised-gain/loss foreign currency revaluations are created as reversing entries, so the net effect is always zero. This is very safe. AR and AP revaluations can be done provisionally, to see what the revaluation effect is.
You can start your year whenever you like. There are 14 periods: 12 months, and two special periods. The months default to calendar months, but you can change them if necessary. One of the special periods is for adjustments, and the other is for closing. The closing period is used by Accpac for its closing entries; manual postings are also possible.
Chart of accounts
The chart of accounts in Series 100 is more sophisticated than we needed, and a long way ahead of MYOB. Up to three segments can be used. When setting up the GL, you define these segments and how many characters are to be given to each. This can be used for profit centre and cost centre support in the chart of accounts. In effect, this is little more than a way to generate long account numbers with some consistency. Many reports support reporting by specific account segments. Properly set up, you could generated P&Ls for separate divisions using this, and departmental cost reporting. On the other hand, browsing to select accounts will show all created combinations, so the complexity of the chart will grow quickly if this feature is used significantly. I think it is best used selectively; for example, to add cost-centre accounting to some expense accounts.
Chart of account grouping is support by an Account Group. This means you have only a one-level account hierarchy. With a a little bit of mucking around, the additional module "Optional Fields" can be used to add more levels. I have defined a second level. The ability to tag accounts is useful in some reports, for example to identifiy all depreciation/amoritsation balance sheet accounts despite the fact they they are grouped with their parent asset account. Once gain, this can be achieved with Optional Fields.
I am not sure if Series 200 and above come with more standard functionality in this area. As with all systems, careful design of the chart pays off.
Because account grouping is controlled by a field, "account group", the numerical proximity of accounts doesn't matter as much as it does in MYOB, were numerical proximity is necessary for grouping accounts on reports.
Series 100 allows two budget sets. Accpac provides some support to create budget amounts, although I ignored this and uploaded data from a spreadsheet. Series 100 allows budgets to be loaded against real accounts but does not provide any "rollup" or "breakdown" budget functionality. More expensive versions allow more budget sets and rollup accounts. I'm not sure whether series 200 has rollups, or if only series 500 does. This functionality is something I do miss in Series 100. My budgeting is not done at great detail, so I have arbitralily chosen one account per account group to accept the budget values.
Drill down, drill though
Accpac works quite well with drill down. Example: from an "account history" display, showing the end-of-period balances, you can double click to view transactions, and then can drill down to journal entries and the source document.
Bank recs are handled as a semi-module. They journal directly into GL, but the functionality sits in its own area. A bank rec isn't going to change very much from one system to another ... payments, receipts and so on created in the sub-ledgers appear as open items. Inter-bank transfers are nicely handled. We encountered an accpac bug in bank recs soon after going live (the first of two bugs we've found). I have people who've never done bank recs before who are quite happy with Accpac; once someone has their head around bank reconciliations, the software implementation is not a big deal. However, improvements in usablity are a big focus of the next release. Bank reconciliations in accpac are an area where it pays to keep hard copies, because you can't retrospectively see what was done in previous bank recs. Bank reconciliatoins create GL batches which then need to be posted, so the transactions linked to a bank rec can be traced.
We don't yet import bank statements electronically: this is still on the list. Because we were forced to keep separate "AR" MYOB databases due to database size, we have huge efficiency gains having AR open items integrated with Accpac, so we still feel that we're miles ahead with Accpac, even while using a manual approach. Unlike the M-Powered service of MYOB, bank statements must be downloaded from your bank's online banking interface, and then uploaded to Accpac.
Out of the box, you get only a Trial Balance report in the standard set of reports. However, the GL module comes with "Financial Reporter", which turns out to be quite a useful report writer tool based in Excel. FR is powerful and highly optimised towards financial reports. It doesn't have a GUI front end, not really, but it is well documented, easy to use and capable of providing very good financial reports directly in Excel. Once you have the hang of it, you can generate sophisticated reports easily. For example, my standard P&L shows this month, last month, year to date, year to date last year, MAT this year and last year, budget year to date and in the month, with comparison columns, with subtotals per account group and some KPIs. This is very easy to do you are working in Excel. The FR functionality is based around a small number of formulas that pull data from Accpac (such as "Account Balance this month"). The reference to the period you want is made with consistent coding, so once you have the layout set up for current month reporting, it's very easy to duplicate for other periods and data ranges. Executing a report is done from inside Excel (with an addin). FR parses the report specification and generated a value-only report section. You can drill down on P&L data to open Accpac's history windows to trace transactions. FR can also go straight to making a finished report saved to disk, skipping the interactivity in Excel. This is an old and mature tool, and I'm a big fan. It works with Excel 2007 as well as with older versions. A lot of the processing happens in Excel, so there is a penalty to using a slow computer, which is not true with using Accpac in general.
I have also made a simple crystal P&L report which is good for quick, simple views of the result.
Generally speaking, the reports which come with Accpac are basic and traditional. There is little to help with forecasting or analysis, and there is not even a P&L or Balance Sheet (although there are good examples of how to do with with the Financial Reporter). You are on your own when it comes to making a cash flow report. Accpac provides no business intelligence support in the corepackage, although an free one-admin user licence of a third party tool is included. In 5.5A this tool is not integrated with Accpac. This is an area Accpac will need to address.
Core functionality: Tax, Australian Tax
Accpac does not specifically support Australian GST, except that it ships with a macro which gather BAS data, which I have not yet got working.
The system is designed to handle US taxes and value added taxes. US taxes are very complicated. For value added taxes, such as the Australian GST, it works quite well. A number of tax classes can be defined, and then used for reporting (such as export sales, capital purchases). GST is not integrated as well as it is in MYOB, where tax entries are possible even in journal entries. In Accpac, there is no tax intelligence in GL journals, only in open items.
Tax can be calculated automatically, manually entered; values can be tax inclusive or exclusive. That's all configurable.
Tax reporting in standard Accpac for BAS is minimal, but there is a macro to provide much better Australian support.
Overall, MYOB's GST tax handling is better for Australian use. It's simpler and completely oriented to a value-added system. For example, even while creating journal entries, MYOB lets you control GST effects. Accpac only does tax in the sub-ledgers. If you make journal entries with a tax effect, you need to manually get the tax right. Accpac does the job, and can support international operations much better.
Functionality:Accounts Receivable, Customers
Customer grouping: For accounting purposes, customers are assigned to an number of account sets. You'll definitely want an account set for each currency that you use. A customer record can belong to only one currency, which means the currency of the customer open items. (They can pay in any currency). So far, this is the same as MYOB. Howeve, Accpac is more flexible, because you can have multiple account sets of the same currency. We have some intercompany customers. To get them to use a separate AR control account in MYOB, I invented a new currency "Intercompany Dollars
so I could get these customers to be treated differently. No need to do that in Accpac.
Apart from the accounting treatment, customers can be grouped in Customer Groups, which most people would treat as a customer type.
Functionality:Accounts Payable, Suppliers and Vendors
Suppliers are called Vendors in Accpac.
Vendors can be grouped and assigned any one of a number of AP control accounts, which is a million miles ahead of MYOB. So you can separate intercompany vendors, for example. The international currency management is rock-solid.
AP use the batch approach, as does everything in Accpac. AP is a separate module. Posting an invoice in AP updates the vendor records, but it merely creates a batch in GL, which needs a GL posting. There is a lot of flexibility in how much detail from AP gets transferred to GL during the posting process.
The AP module has its own revaluation process (which updates GL).
MYOB has "M-Powered", meaning a live link from MYOB to Australian banks. It takes a while to setup, but it works ok. Accpac can not offer such a seamless experience. Standard Accpac in fact doesn't know much about EFT at all. There are no fields to store relevant information, such as Swift, IBAN or BSB account numbers. We bought a third-party module (from our Accpac reseller) to provide this functionality. The output is a file to be uploaded to your bank via the online banking facility. It works well with Autralian banks for Australian transfers. We have yet not been very persistent trying to get it working with our main overseas bank, HSBC based in Hong Kong. The EFT module provides a way to manage all the necessary banking details, and it also inlcludes email remittance advice functionality (which can be used with normal payment batches as well). It fits into the normal payment processing workflow.
Automation and productivity
Accpac has a macro recorder facility using Microsoft's Visual Basic for Applications (as used in Microsoft Office). Plus it has some example macros. I found it quite easy to write a macro which loads exchange rates from the internet and updates accpac, working off an supplied example. I've also made a macro which runs from inside Excel, connects to Accpac and executes the official Accpac customer aging program, and then pulls AR aging data into Excel for pivot table analysis. This is quite sophisticated (standard Accpac macros run from inside Accpac) but I managed through use of the macro recorder and supplied documentation. Basically, nearly everything can be controlled in this way, so the ability to automate and integrate Accpac is very powerful. This is a very strong feature of Accpac. Competing software could not match Accpac for this, from what we saw. It means it is very easy to extend Accpac in secure ways using common programming environments that even advanced users can tackle.
Accpac has a number of technically-based productivity advantages over MYOB. It doesn't crash or get very slow, it handles mutliple years of data, and you need single-user mode much less.
We are not using any workflow features, apart from the different levels of batch posting. Sage sells a CRM product which provides some workflow support, and the purchase order module has some basic workflow support. It requires extra cost either way to support this; we will develop our internal systems to support this, and then integrate into Accpac.
Documentation and Support
Several times during this review I have referred to the quality of Accpac's documentation. It's clear and comprehensive. There is online help, plus manuals in PDF. The manuals are the most comprehensive. You'll get guidance of checklists to activate a module, user and system management manuals, and a good quide on using Crystal Reporter with Accpac.
There is an international accpac website with good forum-based support. I get answers very quickly. I have also found our reseller very good, although I tend to prefer using the forums philosophically, because over time a knowledge base builds up to assist other users (and in turn, I'm more likely to find answers there to future questions).
Interested in SME Finance? You may also like my articles on transforming the finance function at an SME
|< Prev||Next >|