Financial reporting and the web

The relationship between Financial Reporting and the Web is in its early days. The former has an established presence in the City, with a strict regimen focusing on the exactitude of data and representing the needs of their employer. The latter is a younger, more bohemian and naïve soul preoccupied with the needs of others and as a result can been seen as confused and constantly changing.

A May to September marriage perhaps, but one whose courtship is underway and it has simply got to happen, so mutual understanding is key.

For perspective, OTG came into Financial Reporting from the web side; systems development mostly but with a good grounding in the internet and e-Commerce. Three seasons in Financial Reporting systems development have been an eye-opener and given us a small mound on which to stand and see where this coupling might be heading.

The elephant in the room here is XBRL, but before we come to that we need to start somewhere - and cover Content Management Systems on the way, because as we'll see they play a crucial role in all this.

Having first decided that a web version of the report is needed, there is a wealth of alternatives with different costs and benefits. For example you could;

• upload a simple PDF version, linked to the corporate site;

• create a nicely designed HTML front end, then append the financial data as a Word document;

• create a full HTML version of the site including all the data as tables;

• provide the data to the company's Content Management System team to generate a micro-site;

• out-source the lot and link to it from the corporate site.

So - you've decided what you want - now how to get there?

If you've been producing printed reports then you'll doubtless have a graphics team and a Desktop Publishing (DTP) team, (perhaps using Adobe InDesign or Quark) that are familiar with the demands of the job, so it makes sense to start from there and work towards your goal - i.e. export the data from your DTP system in a format from which your website can be built. By something complicated.

That format is generally XML - the ubiquitous data transfer language that can be bent and shaped to suit pretty much any job.

DTP vendors are starting to provide XML export facilities, but very often your preferred desktop publishing system is itself housed within a workflow system that tracks changes, allows audits and remote access and  has its own XML export facility; so you have all that covered, great.

Now - to the web, you need templates to be designed and for that you need bods skilled in web languages like CSS and HTML - a couple more acronyms we just have to live with.

So - you train your DTP guys up to tag up the data ('this lot is for the Chairman's Statement page') and you press the XML Export button. The missing part of the puzzle is the system than takes the XML and combines it with the templates to create the website, injecting that tagged content into the right template pages and linking them together with navigation bars, breadcrumbs and all the other webby stuff.

Currently these systems tend to be in-house as we are reaching the raw edge of where things are at right now (for small sites this can be done manually with cut and paste, although this can be prone to error, and reflowing content is not exactly a snap).

But as ever with the web, changes are afoot. Enter XBRL (the HMRC's requirement that in 2011 all Financial Reports are delivered in this version of XML). It's a hot topic right now and one in which we are heavily involved; see it as a type of XML that is designed by the Government to handle the delivery of Financial Reporting data in a consistent manner. Couple of danger words there but we'll gloss over that.

And, to add some spice to the soup; the content of the website can't be the same as the printed version. You don't have page number references for example, the idea of chapters may not exist - navigation has totally changed, entire sections may not be relevant, extra content may need to be added. So there needs to be a point at which the Web version is allowed to go its own way from the Print - a cut-off point where changes can be made directly to the website content, and those changes tracked and audited as usual.

So we have; XML export, generation of the website including internal navigation, manual (tracked) changes by multiple staff that are overseen by Account Managers and checked by proof readers (often in different languages) and subsequent delivery to the HMRC in XBRL format. That, technically speaking, is a bunch of stuff. What to do?

Enter the Content Management System (CMS), to a small fanfare.

CM systems have been around for a while now, but not long enough for there to be a clear leader (there are thousands on the web - many are free and some are worth paying for). Essentially they allow multiple staff to add and edit content via a web interface, those changed being tracked internally and then approved by an editor who then publishes them to the web. The CMS builds the site, and allows the staff to change it easily.

The good ones are modular in format, and as such are able to be easily modified and extended to handle extra requirements (like XML import/export and subsequent XBRL export), with independently developed modules snapping on like a socket on a wrench. The key point here is to look for system that allow Remote Publishing - ie that can generate a website that can stand alone from without support from the CMS - Percussion have such a system and that's the bit where we plug ourselves.

Thats said, there's another good reason for adopting a decent CMS into your workflow and that's future strategy. Should you decide to go straight to web on a given report, you have the solution right there - no extra software or skills needed. And the odds are good that your clients may already be using a CMS in-house, so content delivery from yours directly to theirs in XML is a real possibility.

So that's roughly where things are at, and roughly where they are going. I say roughly as the only constant is change, but in short - maintaining an independent and flexible approach will help you be ready for the changes the future may bring, and a good modular CMS will provide you with the ideal platform on which you can tackle those changes.

Phil Hanchet, OTG