Having decided to finally migrate from an offline accounting system to an online one, we landed up opting for Xero. You can see in Part 1 of this series how this was prompted because neither Sage One nor Quickbooks allowed CSV imports for customers or invoices.
We were expecting great things when we handed our Sage Pastel final Trial Balance over to the Xero consultant for conversion from Pastel to Xero. The slick online interface of Xero wowed us, and diving into the Xero forums and discussions it was evident that Xero is a dynamic organization with loads of developer support and integrations.
The conversion process went reasonably smoothly and we made the switch, keeping our Pastel Partner set of accounts going in tandem as a backup should the Xero move fail. But within a week on Xero our expectations were dashed. We discovered something about the Xero database that is a really bad fit for our business.
As so often happens, the issue only reared its head once we started using the system. I don’t blame any of the Xero accountants, who advised us for not pointing the issue out. In fairness, our glitch with Xero is probably not something that is likely to affect 95% of Xero’s small business users, but in my opinion it is a major design flaw, nonetheless, and will certainly hamper Xero’s growth into larger businesses.
To understand the flaw you need to know a little about how databases work. Every account on a database has one item of data that is the “unique identifier” (sometimes referred to as a Primary Key). Most online services these days use the client’s email address as the unique identifier (which is why, when you sign up for some online services, you often get the error message – “sorry, that email address is already in use”, which means you opened an account with them previously that you forgot about). The vast majority of accounting packages (online and offline) use “Account Number” as the primary key. It is a no-brainer – no customer will ever need to change their account number. Besides which, a lot more can go wrong with words which, unlike numbers, often have spaces, full stops and even special characters in them.
Pastel Partner worked on account numbers (as does our own custom database), and in retrospect, the workflows we had running on Pastel went super smoothly (albeit that they were all offline). Xero, for some unknown reason, decided to use “Customer Name” as its unique identifier. Clearly this was a mistake. My guess is that Xero started very small, and grew from there, and once they started growing, the problem was already “baked in” and impractical to reverse.
As I said, if you are a small business with around forty customers, you are unlikely to even be aware of the potential pitfalls. But when you have 4000+ customers in your database, like we do, things can go wrong horribly fast.
We have a lot of accounts that have exactly the same name, but Xero will only accept one of these accounts. Our programmers, therefore, had to develop a fancy work-around so that if the customer’s name already existed in the database, the next account that has the same name would have a number added on to the end of their name ( thereby differentiating it from the first name).
If you are wondering how we have customers with the same name, here are all the (not uncommon) ways it can come about.
A customer ends their subscription with us, and then a few months later registers again. Happens often! Just because they ended their subscription doesn’t mean we could close the original account. It has to be kept open for audit trail purposes.
National accounting firms listed with us often elect to have their billing separated for their regional offices – same customer name, different account.
Members of the same firm have separate accounts with us (we give each accountant a separate account as that is the way our database works) which they often like to pay individually. Again – same customer name, different account.
Another issue is that we have a lot of individual accountants listed, and when you have over 4000 listed you would be amazed at how many “J.Smit’s” there are.
There are other problems too. Customers change their names. We’ve been going for fourteen years now and in that time many corporate entities have name changes. Single woman get married. It happens. On our own database, and on Pastel too, a change of name would happen in the background without the blink of an eye, the account number remaining unchanged. Now, with Xero – if there is a name change we have to manually go into Xero and change the account, which also makes reconciling old transactions - where the former name was used as a reference - a nightmare.
This problem is still not solved, and still gives us headaches every week. The work-around of appending numbers to customer names is far from perfect. Technically speaking, if you really wanted to get pedantic about it, this “unique customer name” method does not even produce legally valid invoices, as an invoice to XYZ (Pty) Ltd should be an invoice to XYZ (Pty) Ltd – not XYZ (Pty) Ltd 152
Update: we have come up with a suggested workaround for Xero's unique identifier problem. The suggestion has been linked to an exisitng Xero feature request and we are hoping it will soon be incorporated.
Besides the primary key issue, we have had a few other disappointments along the way. All the marketing literature boasts that Payfast (a popular online South African payment gateway which we use for our credit card payments) and Xero are “fully integrated”. Well it depends how you define “fully integrated”… Yes, there are some nifty “pay now” invoicing integrations, but the fact of the matter is that you still have to download CSVs from Payfast and import them into Xero. That is quite a way off “full integration” in my book.
Another integration that didn’t meet our needs was the promise that our bank account with FNB would be real-time integrated with Xero. It turns out that this only works with the standard FNB business account, not the Enterprise FNB business account which we have. My main gripe with this issue is directly with FNB. Apparently there is a work around to put the integration in place, but FNB have been anything but helpful, and we are still waiting for a solution.
One of the features we were really looking forward to was the functionality of sending our customers a url/link to their online invoice. Although this works on a customer-by-customer basis we were hoping to be able to get a list of invoice URLs to import in bulk into Mailchimp (our mailing service). But you can only get at these URLs one-by-one, which is a real shame because the list option would be a great feature. Xero allows you to access this type of data using their API - but that means expensive development costs. I live in hope for this one, as Xero is actively developing its product and they are definitely responsive to customer feature requests.
Notwithstanding all of the above, we have elected to stay with Xero, rather than switching back to Pastel or to Sage One (or even Quickbooks). I am hoping this is not a mistake, but In part three of this mini-series I will explain why we have chosen this route, despite all of the non-trivial drawbacks.
We realise full-well that we are not experts in every accounting software system out there, and that there might be simple solutions or work-arounds (possibly even within Xero itself) that we have overlooked. We would welcome any suggestions from any of our listed accountants (many of whom are no doubt way more knowledgable than us). Simply shoot us an email with your ideas. With permission we may even add some of the suggestions to this article (with a link to the author's Personal Profile page)
The opinons expressed above are those of Chris Preen in his personal capacity and do not neccessarily reflect the opinions of Find a Professional.