While many practitioners are buried under tax returns this January, Sage's Accountants Division is pushing forward its strategy to build open data exchange standards into its product portfolio. John Stokdyk reports.

The division's head of R&D Ben Bishop recently told AccountingWEB that the development of Sage's personal tax products was progressing on two fronts - functional improvements continue while the underlying architecture is upgraded.

But the Sage R&D team is also hard at work to enhancements to the Corporation Tax and accounts production that will also help pave the way for a fully integrated Sage Practice Solution. Much of the work taking place aligns with the company's enthusiasm for open standards, Bishop explained.

"We see open standards as a natural progression of what we are doing architecturally. We regularly talk about the emerging standards like XAPL [eXtensible Accountancy Practice Language] and XBRL [eXtensible Business Reporting Language], which are described XML documents. They are inherently open.

"We're also looking at how wrap them into web services and APIs to provide a more coherent interface into and out of our systems. That will have benefits in terms of integration internally with Sage 50, but will make the Sage Practice Solution a much more open application."

The XAPL schema will sit on top of Sage's core practice solution architecture to determine which data goes where in the system. Because it is a document-based data exchange model, the developer has better control over data changes from year to year. "Any changes you need to make can be handled in the XML document," Bishop said.

This XML-based approach has already paid dividends for Sage within its tax software modules. As part of the migration to a new software framework (Microsoft's .NET), the company introduced a form-rendering mechanism that also involves passing a defined XML document. Computations are fed into this document and validated within the application, and are then reformatted according to another XML-based schema and passed on to the tax program's efiling module.

"We're looking at making XAPL, and where it doesn't go far enough XBRL, part of the genetics of the product. We absolutely do not want to be reinventing the wheel," Bishop said.

XBRL has been the source of sustained debate within techy circles for several years. Originally designed to automate comparisions between financial reports by tagging them with standardised definition, XBRL was also chosen by HMRC as the means by which it was going to capture accounts data for Corporation Tax purposes.

Bishop sits with several other software developers on an HMRC technical subcommittee charged with finding a way to make XBRL work for the department's purposes.

The crux of the problem, Bishop explained, boils down to a conflict between HMRC's desire to receive accounts data in a standard format, and the preparers' need to ensure that human-readable presentations of a company's accounts would appear exactly as the accountants created them. The options considered included: using PDF files, - which would have limited HMRC's ability to extract data; a style-sheet based approach; and a third technique termed "in-line XBRL".

Style sheets could restrict the accountant's ability to format the information, so Sage decided to support in line XBRL, which did not define how the accounts were presented, but would ensure that if XBRL data was present, it would be rendered in a way that was both visually consistent for humans, and machine readable for HMRC.

"That satisfies HMRC and users, so it ticks all the boxes," Bishop said.

Sage's Accounts Production Advanced (SAPA) program has handled XBRL for 2-3 years and can file these accounts electronically with Companies House. Now the company's programmers are working with the Deloittes that devised SAPA to incorporate that data in line within an XBRL-compliant CT600 tax return. Version 4 of Sage's CT program, scheduled for release in September, is due to support the new standard.

"The CT600 part is probably the simpler element. They are very well defined forms that can be tagged with the relvant XBRL taxonomy. More complex for us as a developer is how we do it so that we can plug other solutions in our stable into that mechanism," Bishop said.

Meanwhile, International Financial Reporting Standards are also looming on the horizon and will mean yet another XBRL taxonomy that needs to be supported. But because it is based on similar XML-based definitions, it can be easily substituted for UK GAAP within compliant applications.

"These are complex procedures and issues," said Bishop. "We want the user community to understand that it's open, but my ultimate mission is to create software that takes away the pain of those processes."