• Have a hot IT team, capable of establishing reliable, secure, performing systems within budget? Check.
• Have a keen finance team, dedicated, involved, trusted? Check.

So where’s the gap?

It’s certainly there. I know it is because I often can’t deliver the information that managers want; I can’t answer the root cause questions to the numbers that I present. This gap is a cause of systems falling short of expectation, of organisations not being able to get out of their systems what they are looking for.

The bases are not covered

I believe the gap arises where

1. accountants take responsibility for the content and meaning of data but not how to store and retrieve it, and
2. IT people take responsibility for storage and retrieval of data but no accountability for what the numbers mean or how they are presented^*, but
3. nobody understands both.

* - I’m grateful to Stephan-Robert Langer for giving me this characterisation of how accountants and IT people relate to data.

The same gap is identified by David Carter in his call to accountants to break up the BI party.

Filling the Gap

I think I’ve long recognised this gap, because I invariably took on the role of filling it in all of the companies I worked for. So who is in the best place to fill it, an IT person willing to learn financial concepts and take on responsibility for the meaning of data, or an accountant not afraid to grapple with SQL, data normalisation and storage technologies?

It sounds a tough call on both counts, doesn’t it? However, the pragmatic answer is clear. At the end of the day, the accountant is accountable for the numbers, and if that means straddling the gap into IT skills to ensure they can be delivered and explained then that needs to be done. No one else is going to do it.

As explained in an earlier post, Isolist is an AddIn for Excel, providing a dedicated reconciliation function that matches the records from two data lists and identifies any mismatches. The requirement to perform such list-matching tasks is wide-spread:- certainly for management accountants but also, I believe, more generally too.

To get the ball rolling, I’m giving a special offer to users of the Beta version who can find and let me know of any bugs or other problems with the product. If you find a genuine software problem, I’ll send you a free license for version 1.

Me - Creating spreadsheets is a little bit like programming. In fact, you could say that it is a sort of programming.
Friend - Programming? Spreadsheets? They don’t look like programming to me.
Me - I admit the ‘programming language’ is unusual and very high level, maybe like a 4GL, but look at what’s happening: You start with a blank sheet, you give the computer a set of rules and some input data and it generates outputs. Conceptually that’s a program, isn’t it?
Friend - [with a sceptical look] Hmmm.

I’d forgotten that converstion until today when I read Writing formulas is computer programming.

Of course it makes no difference whether or not you call using a spreadsheet programming. The fact that you could call it programming, though, is interesting because it indicates that programming needn’t be scary or nerdy. If you can accept that then you’re more likely to make more effective use of your PC.

Anecdotal aside

I say ‘ought’ because I’ve had one of those experiences where I’ve taken a job in a business and found that bank reconciliations had not been done for eighteen months. Having the most fundamental of accounts not in good order is a clear indicator that lots of other problems are hidden in the accounts. It makes for an uncomfortable period as Controller when, over several reporting periods, more and more things come out of the woodwork as the balance sheet is trued up. In my case, bringing the bank account up to date took several solid days of work, but bigger problems were found elsewhere. Maybe others of you have had similar experiences.

Other sources of reconciliation

Back to the subject of the post, in addition to reconciling bank statements, accountants may face several other reconciliation tasks, on either a regular or an occasional basis. Do you recognise any of these?:

• Business systems to general ledger. Some organisations operate a mix of applications, either through historical accident or by design in order to cover needs that are not met by a single application. For example, if the sales order and customer invoicing system is separate to the accounting system then reconciliations are generally required to ensure that revenues are correctly accounted for.
• Intercompany and branch office accounts. Organisations with more than one location or subsidiary frequently share resources and fund or borrow from one another. Where a separate ledger is run for each subsidiary, it is necessary for the intercompany accounts in each one to be matched in order that they remain consistent with one another.
• Stock-take to inventory system. Common in organisations that hold physical stock, different inventory systems give varying levels of assistance to the stock-take process. An accountant or colleague may be required to reconcile a physical count with the system inventory balances.
• Sub-ledger to general ledger. Even where systems are well integrated, it’s often prudent to check that transactions originating in a sub-ledger have not gone awry when posted to the general ledger. Reconciling control reports from each side is not uncommon.
• Closing balances to opening balances. You might think that it should never be necessary to reconcile a previous closing balance to a current opening balance but, unfortunately, the world simply isn’t perfect. When posting a year end journal, both human and system errors are possible. A different scenario might be where a group accountant receives trial balances from subsidiaries month by month, but the latest figures somehow don’t match properly with last month’s…

It’s at the boundaries between systems where the need for reconciliations arises. Maybe you recognise some of these tasks in your own work. I’ve certainly spent much time working on a wide variety of reconciliations over the years and the famous bank reconciliation is typically the easiest and quickest. It’s because reconciliations are so common that I decided, as my first product, to create a tool to make the task as easy as possible. Progress is steady and I’m planning to have Isolist ready for public testing about one month from now.

MVC

Many people will be unfamiliar with the “Model-View-Controller” pattern used in programming, so I’ll expand briefly on the idea and reasoning.

The basic idea is that a complex program is usually more robust and easier to work with when composed of separate, well-defined modules that work co-operatively. In the MVC pattern, the “model” broadly stands for the program module that holds data and the “view” is the program module that presents the data to the user. The pattern involves making these separate and, in particular, ensuring that the data is independent of how it is viewed.

Achieving this separation provides several huge benefits, including:

• data can be tested for accuracy and completeness independently of any other factors, such as whether a report has ‘read’ the data correctly,
• the work involved in maintaining and updating views/reports is limited to only one part of the program; the data itself remains intact and safe,
• it becomes very easy to provide multiple and different views of the same data, without having to duplicate or modify the data in any way.

Implication for Excel

Excel provides blank worksheets, inviting you to structure your data however you like. Learning from the MVC pattern, we should provide good structure, even though Excel doesn’t require it. Generally this will involve capturing data in clean lists and using separate sheets, pivot tables, etc. to provide the output that we want.

For small, one-off workbooks, don’t bother. But if you have lots of data, or will be using the same workbook over a period of time, then consider keeping your data and your reports separate.

SQL-Ledger Introduction

SQL-Ledger is a system for accounting, order processing and stock control and follows a traditional design - with the interesting exception of being a web application. It uses PostgreSQL, a respected and mature open source database system, for data storage, although if you already use Oracle or DB2, these databases can also be used with SQL-Ledger if preferred.

The software is freely available from DWS Systems Inc., the primary developers, who also provide documentation, support and customization services for a fee. It is now apparent in only my second accounting system review that this business model (aiming for wider market share by making software available for free and then aiming to profit from related products and services) is common for open-source accounting systems.

The prices for support of open-source systems are inevitably similar to the prices for support of commercial systems and so businesses of any appreciable size will not gain a significant cost advantage in using open-source systems over the cheaper commercial products available. (This is part of the reason why the cost advantage of using Linux over Windows is so debatable.) The decision on which route to go will always need to be made specifically for each individual business.

Although the documentation for SQL-Ledger can only be obtained by spending US$ 190, I found a useful introduction to SQL-Ledger provided by Metatron Technology Consulting, which discusses system capabilities, usage guidance and customization options. If you are considering SQL-Ledger for yourself, that document would be a very good place to start.

Installation

Being a web application, all installation is to a server. Client PCs need no software installed since they use only a web browser to access the system. On the server, SQL-Ledger is platform-agnostic as long as the dependencies (Perl with database modules, Apache, PostgreSQL and LaTeX) can be met. These are all readily available for both Windows and Unix-based servers. Alternatively, you can do what I did and obtain a “virtual appliance” as a single package and run it in a VMware host.

Having booted the virtual server, I ran the update script supplied with SQL-Ledger which updated my installation to the then current version 2.6.22. I understand from the SQL-Ledger website that a version 2.7 is available with some new features, although oddly they don’t list this as their latest version and the automatic upgrade didn’t download it. I interpret this to mean that it’s not ready for production use.

Configuration

Much of the setup and configuration for SQL-Ledger can be done from the web browser. An administration page is provided for setting up databases and users, following which you can log in to the actual system and set up your required accounts, codes, parts and services, etc. There are, however, some configuration options that need to be made in a traditional Unix-style text file, the most important of which is setting up printers. This is inevitably a bit messy, particularly if printing from a Unix server to a Windows printer. It would be much better if this sort of thing were fully handled by an extra admin screen.

SQL-Ledger can handle multiple companies, each of which is held in a separate database. Multiple user ids can be created for each company, but each user id can only access one company. Therefore, if you want one user to use two companies they will require two separate user ids.

Loading data. For small businesses it may be practical, if tedious, to enter all accounts, customers, suppliers and products one by one into the appropriate screens. If lots of data needs to be imported, some scripts are available on the main website to read data from tab-delimited files directly into SQL-Ledger’s database. These, however, are heavily-caveated and so probably require some serious tinkering to do the job correctly. Again, this task would be much better handled by a user-friendly screen in the application.

For setting up opening balances the only option available is to enter normal transactions. SQL-Ledger recommend posting a supplier invoice to set the stock levels for each item, posting a GL journal to set up the opening trial balance and presumably posting all open sales and purchase invoices, unmatched receipts and payments, etc. as originals.

In Use

The menu of commands in SQL-Ledger is displayed in a column on the left of the screen, with sub-menus that can be expanded or collapsed by clicking on the header. This is simple but effective and easy to use.

The main body of the screen is where most of the action takes place. Data is presented cleanly, if not particularly stylishly, and all screens follow a common pattern which quickly becomes familiar.

The various enquiry and report screens are all prefaced by a configuration screen where search-text, report filters and columns to be included are specified, resulting in good flexibility in the data that is presented on screen. However, it would be much less cumbersome if the system remembered the report settings made between one use of the report and the next - as it is, you need to re-specify them each time.

One error occured whilst I was using SQL-Ledger, related to updating the average cost for a stock item when posting a purchase invoice. This didn’t seem to have any wider ramifications and other than that the system appeared stable and reliable.

Order Processing

Transactions can be started at any stage, so in the sales process, for example, you can start with a quote, an order or an invoice. Entering data is straightforward and it’s possible to view a lookup screen of parts or services to find the ones required for the order.

When displaying an order or invoice on screen, several related actions can be performed by clicking on buttons across the bottom of the screen. The actions presented are independent of order status, so the opportunity to progress transactions just as you like is very fluid.

Superficially useful, this fluidity strikes me as being very dangerous. Not only is any action allowed at any time, but no warnings or second chances are ever given prior to an action being performed - regardless of how unwise that action might be.

Here’s an example of what I mean:-

• having entered a sales order you may then process a shipment, but no invoice is generated until you specifically ask for one - there is no warning that an order hasn’t been invoiced
• after shipment but before invoicing, you could choose to close an order - no warning is given on this action
• from this situation (assuming you realize that you are missing revenue) all is not lost. Simply search for and display the closed order and then press the sales invoice button to generate an invoice - no warning is given
• But you could do this any number of times, generating multiple invoices for the same order - and again no warning is given on this action.

Such fluidity is a double-edged sword but the downside edge is much sharper than the upside one. Careful patrol of open orders and diligent following of procedures are necessary to ensure transactions are processed correctly.

A problem worse than this becomes apparent when examining the effects of shipping and receiving stock items. On processing a shipment or receipt, the on-hand stock balances are adjusted accordingly but no accounting entry for stock movements is recorded until the order is invoiced. Therefore the reported stock list quantities and values will not reconcile with the balance sheet stock values if any invoices are outstanding - a highly undesirable circumstance.

SQL-Ledger doesn’t track individual shipments and receipts on an order, so if a part-shipment is made, followed by a second shipment to complete the order there is no subsequent way of knowing the detail of what happened.

Accounting

Regarding accounting functionality, some features that I consider desirable are missing:

• there is no batch holding and processing facility - each transaction is entered and posted directly (although version 2.7 claims to include a “voucher system”, which may be what I am looking for)
• there is no period management independent from the date for each transaction and there is no way to close a period in a sub-ledger whilst leaving other ledgers open for further postings
• there is no facility for holding budget data

Sales and purchase ledgers integrate automatically and fully with the general ledger so there is no separate task to transfer data from sub-ledgers at the end of each period.

Stock receipts and shipments are posted directly to the general ledger using account codes that are defined individually for each stock item. This provides useful flexibility for posting different product ranges to different accounts for analysis, but less flexibility for non-routine stock transactions which may need to be recorded to different accounts.

Department codes can be created for segmentation of the accounting data. Departments can be specified either as cost centres or profit centres, depending on whether just expenses or both revenues and expenses require analysis. These department codes can then be used to classify sales transactions, purchase transactions and accounting journals.

There is no general ledger transaction report other than the report on transactions in a single account. A broader GL transaction report would commonly be used to trace bookings across several accounts and as a general accounting audit report.

When selecting invoices for payment, each one must be selected individually: there’s no routine for selection based on due dates or anything else. In fact, the due date doesn’t even appear on the payment selection screen.

Viewing of transactions on a customer or supplier account is either awkward or not possible - I couldn’t find a report showing both invoices and payments within a customer account.

Closed period control is possible, implemented by entering a cut-off date prior to which no transactions can be made or amended. This affects all system areas uniformly.

Year-end processing is a very simple affair. A date and description must be provided, following which the system generates a year-end journal. Processing is very abrupt so some care is required, although it’s always possible to open up the audit control and amend or delete the journal.

Standard financial reports are extremely basic. It is possible to define reports in a style that you require, but the tools used for this are HTML and LaTeX together with some system codes for picking up the required values (which presumably are only documented in the $ 109 manual). This is all too hard to warrant further investigation and I’m sure other accountants will feel the same.

Conclusion

Functionality falls short in a number of the areas that I would look for, which I listed in my introductory post.

So that’s a score of 5 out of 13 - pretty poor.

SQL-Ledger is likeable for its ease of use, clear screens and freedom of action. But this freedom of action is also a major concern for both financial and inventory control. The features provided are disappointingly simple - more so than one would expect given the marketing copy on the SQL-Ledger website. I guess for small service businesses that don’t need to track many stock items it’s perhaps worth a try, otherwise you should probably look elsewhere. I’m going to.

I’ve downloaded, installed and generally messed around with three or four other accounting systems and am working up to the next review - which will probably be of SQL-Ledger.

The others I’ve installed and scouted are:

1. Compiere - which makes some intriguing promises through having a non-standard design. This is a fairly substantial ERP and CRM application targeted at small or medium businesses and so will take me a while to assimilate. Nonetheless, I’m looking forward to trying this one.
2. VT Transaction+ - not open-source but a low price and a real alternative to the likes of Quickbooks. I installed the “plus” version which is in beta testing/ongoing development and loved the directness, simplicity and usability features. VT Transaction has an unusual spin on the meaning of “ledger” which might take a little getting used to and I’m not sure that my data import/export desires will be met. Anyhow, as it’s not open source I’ll leave a possible review ’til later.
3. TASBooks 1. I installed a trial version of this in a moment of weakness (I had been losing the battle that often accompanies installation of open-source software). Again, this is a low cost commercial product but, unlike VT, follows the common pattern of equating low cost with noddy users. It has those trite graphical workflow things, which I suppose are fine in Toyland but the real world is much more complicated. Nonetheless, if you find you can work happily within the straight-jacket workflows then the actual functionality seemed fine on initial viewing. Again, I won’t review just yet because it’s not open-source. In fact, I probably won’t ever review since the trial version lasts for only 15 days.
4. SQL-Ledger. Back to the real open-source stuff. SQL-Ledger has a sturdy composition in the company of most of the others mentioned, using a proper database at the back and being a full multi-user web application. On the face of it, SQL-Ledger looks reasonably competent so I’ll do some more work here and report back.

Jason Holden has suggested I look at Interprise, which I’m willing to do but haven’t found a download link. It looks like I actually need to ask for it.

In case anyone else wants to look at Compiere or SQL-Ledger, the installation of database systems and other dependencies along with the actual programs can be alot of work. To save a day or two of frustration I downloaded virtual appliance images, which can be played in the free VMWare Player or VMWare Server applications:- a godsend.

Viewing Ling’s website is quite an experience :- you won’t have seen many websites like this before.

• It fails many of the rules from Web Pages That Suck,
• it ignores all rules of style and taste,
• it takes no account of usability,
• it is written in bad english
• and yet, somehow, it works*.

*- actually, not everyone likes it, but plenty do and the business seems to be growing.

How is this possible?

My theory is that LingsCars.com works because Ling is unusually transparent. (The humour helps too). Just look at some of the things she says:

- on when you may contact her:

I am human being, not robot! Office hours: Mon-Fri 9am to 6pm

- on speed camera information:

This page just for your info, but quite interesting, I think! Hey, I am only Chinese Contract Hire Expert human, so don’t blame me if some details wrong here, and you get ticket, but I do my best for you.

- on encouraging customers to buy now:

Physical stock is always limited, as cars cannot be made to appear by magic, there are only so many sat in corner of field. So be brave, grab a bargain and avoid me having to make phone calls to disappointed people who have left decision too late.

This is transparency to a fault. You can’t fail to recognise that behind this website is an identifiable person running a real business and working hard for her customers. Would you prefer a bland corporate image, espousing platitudes on belief in quality, how employees are the most valuable assets, etc.? I wouldn’t.

“These numbers are wrong. Why can’t you accountants add up?”

Perhaps the worst time to hear these words is during the monthly review, when the management team are assembled and looking at the culmination of your month’s work. Noise levels reduce momentarily as everyone in the room recognizes the “obvious error” in the Actual total. Your heart sinks.

How can this happen? The trial balance proves there’s no problem in the ledger. Maybe the reporting system is doing something strange?

The answer, of course, lies in the “£ k” shown in the table header. “£ k” doesn’t only mean that the report is expressed in thousands of pounds. It also means that any individual number on the report could be misrepresented by up to £500 - and you don’t care about this level of error.

Therefore, to read the column of Actuals as literally correct and conclude that the total must be wrong by £2,000 is an error of logic. What you’re really seeing is the values 190.4, 210.4, 80.4 and 30.4, totaling 512 (to the nearest thousand). But all those 0.4s are too small individually to be of interest.

So there. Don’t be dismayed if you run into this situation. I leave to you the job of gently educating your critic* the next time they make this mistake.

* - A cynic would guess the critic to be the sales manager responsible for Europe, aiming to divert attention from her negative variance.

Recommendations

I have three recommendations for dealing with roundings.

1. In the distant past I “corrected” for this problem, adjusting a few numbers up or down whilst taking care to ensure that they remained in line with the same value appearing on different schedules. I now repent. Not only is this practice a waste of time but it actually introduces errors into a schedule that is otherwise self consistent with the “£ k” header.
2. Never round your numbers prematurely. Reports should be fed with fully accurate numbers but display them using a custom number format to show the desired precision. Know how to format numbers in Excel and your reporting system to achieve your goal. The danger, otherwise, is that report totals will be calculated using rounded numbers, which can introduce significant, real errors that will be very obvious if the total is supposed to match the same value shown on a different schedule.
3. Never forget to specify the units displayed in the report, otherwise you can’t be sure to carry the point of logic with the European sales manager.