If you’ve got this far, you’re unlikely to be just a user of Sage products.  Far more likely that you’re involved in the provision of advice or products to accounts software users.

That distinction distills the essential point that Dennis Howlett and others miss when discussing Sage and their disinterest in Saas.

Sage customers don’t use Sage products because they are great technically.  Rather they use them because:

• Sage are going to be around for a long while
• the products are known by professional advisers and are quite likely to be familiar to new staff
• the products are good enough feature-wise
• there are lots of choices for suppliers of advice, training and support

So from a customer point of view, the issues are about confidence not technology. 

Given this it’s perhaps unsurprising Sage haven’t really been a software / technology company for many years.  Instead they are a company that generates recurring revenues through services.  An extreme view would be that they only bother with software licence sales because such sales top up their recurring revenues.  And their financial performance says they are getting something right.

Dennis Howlett contends that Sage are more interested in keeping their financial analyst community happy than their customers.  To my mind this is to fundamentally misunderstand Sage. 

It is absolutely the case that they are a public company, so their financial performance is their primary concern.  But customers are without question next on their list.  Indeed one of my frustrations is that it is the weight of customer requests that seems to drive their decisions about what features to add, rather than original or imaginative thinking on Sage’s part.  So when customers want Saas, or even what it represents, Sage will give it to them.  Meantime Saas evangelists will continue to be disappointed!

One of the arguments for and consequences of Saas is “disintermediation”.  Or in simplistic terms reducing costs by cutting out middlemen.  But what happens if the middlemen perform an important service?  At this point I should declare an interest as one of Sage’s middlemen in the UK.

Given that I’m not exactly disinterested, lets instead look at Sage’s view.  Their primary accounts products for the small and medium sized products in the UK are Sage 50 and Sage 200.  The interesting point is that they sell and support Sage 50, which is aimed at smaller businesses, directly (as well as through resellers), whereas they don’t sell and support Sage 200.  Given their primary focus on profitability, this must reflect customer needs.

The problem is that the allocation date, which is set within the top right section of Sage 200’s allocation screens, defaults to the current date.   This is really easy to overlook, and calls to our Sage 200 support team suggest most users are, quite reasonably, unaware of the implications of that date. However, this can cause a few hiccoughs if left unchanged, affecting retrospective debtors/creditors reports, retrospective statements, and any view of average times to pay by customers (visible in the account details report).

With this in mind, it is generally a good idea to change the allocation date from the default of the current system date to that of the latest transaction in the batch being allocated, to keep analyses based on transaction and allocation dates consistent.   Sage 50 does this automatically, so perhaps this is something the software developers need to talk to each other about!

There is a fix, however, if you forget to do this when allocating.  You can always go into the Amend Allocation option under the Adjust Transactions menu on the sales or purchase ledgers and either undo or amend the date on the problem allocations.