In these days of increased regulation, companies pay at least moderate attention to the quality of the data appearing in their quarterly or annual accounts. To a lesser extent, they pay attention to the quality of the data in their major corporate systems - in research my company carried out in 2008, a scary 61 per cent of respondents did not measure the cost of poor data quality in their organisations.

Yet the flaky state of data quality in our corporate systems is a shining pearl of perfection compared to the state of the data, much of it business-critical, in that most humble of tools, Excel. At least the data in the corporate finance system gets some attention, but much corporate data is on desktops, which lie beneath the surface of corporate awareness.

Just how bad is the picture? Studies by both academics and audit firms suggest that as many as 90 per cent of corporate spreadsheets have material errors in them. Now of course, if Joe Bloggs takes a copy of some data for an internal presentation and screws it up, then little real harm is done. But companies use spreadsheet models to take very serious investment decisions. When I was at Shell I used to sit opposite a group of bright young things whose job it was to develop and audit serious financial spreadsheet models, which determined such multi-million-dollar matters as which oil fields to invest in. These models could be fiendishly complex but this team did at least have development standards for the models, and routinely did quality checking of them through a variety of audit techniques. Are the spreadsheet models in your company as carefully developed and audited?

Problems arise, paradoxically, because Excel is so easy to use. People writing applications that affect major corporate systems will, hopefully, have had a modicum of training in how to structure and test code, but anyone can knock up a spreadsheet model in Excel. It is so easy to drag and drop those cells, and have Excel auto-fill those formulae for you, and so tempting to just assume that the spreadsheet numbers actually reflect what you intend, rather than painstakingly check whether the numbers are really correct. The problem gets worse when the models become more elaborate; it is difficult to ‘read' a spreadsheet as few people document their logic via comments, or define proper names for cells that are used in formulae. When a large spreadsheet model gets handed over to someone else, the potential for error or misunderstanding is enormous.

There are numerous documented examples of the consequences that ensue, and one organisation (the catchily titled European Spreadsheet Risks Interest Group) maintains a web page full of newspaper reports related to spreadsheet blunders. These range from governments screwing up budgets to firms seriously misreporting their results, in some cases with serious consequences for employees.

It is also easy to forget that spreadsheets are often sent to third parties, at which point all kinds of fun and games can occur. One lawyer working on the Barclays buyout of Lehman Brothers' defunct assets, for instance, had drawn up an Excel spreadsheet detailing the trading contracts that Barclays was prepared to accept as part of the deal.

The lawyer took out 179 particularly undesirable contracts, but rather than deleting the cells, marked them as ‘hidden' cells in Excel. This was all fine until a first-year legal associate who was helping to put together the final paperwork converted the spreadsheet to a PDF file and, you guessed it, managed to include all the hidden cells as well as the items Barclays was supposed to be agreeing to buy. The deal went through, and although I don't know what happened next, one can only imagine the wrangling between Barclays and the administrators that ensued.

I don't have any easy solutions to the spreadsheet minefield but there are some basic things that can be done, such as training staff in proper model development techniques and adopting standards for Excel development and version control; there are even a few tools out there that can help. For more on this I can recommend the writings of Phil Howard at Bloor Research, who has done some pioneering research in this area.

However, my point is not to focus entirely on the evils of spreadsheets but to emphasise that the lack of attention paid to this area is symptomatic of a more general carelessness when it comes to data quality. I continue to be surprised by how little attention is paid to the quality of the information on which we all rely, and how blindly we assume that ‘facts' presented are actually accurate. In reality, companies pay perilously limited attention to the quality of data in their corporate systems, and generally seem disturbingly unaware of the scale of the potential data horrors lurking beneath the surface.