XBRL GL

There has been quite some file format debate. However differences in Chart of accounts between countries, represents a much bigger compatibility problem of information interchange between accounting and financial reports between accounting cultures. Tax regulations also make huge differences in the actual content of accounting and financial report information between countries.

The basic issue is if it is possible to transfer accounting data over governmental boundaries and the data would be understood by the receiver? Will it be possible for someone to read a balance sheet with a foreign chart of accounts and understand it? Will it make any difference to transfer it by computer files in standardized file formats?

The EU commission has spent large efforts into the field of tax administrative harmonisation and for instance is the main intention latest version of the EU VAT directive to achieve this and to support electronic trade documents like electronic invoices better in cross border trade especially within the European Union Value Added Tax Area. But there is still a huge way to real compatible charts of accounts and international accounting information interchange.

One question is if international trade agreements have much value without a global harmonisation in VAT tax administrative legislation between the agreeing parts. The EU-agreements with countries like Norway do not include VAT union membership. And so goods are stuck in customs (to large costs) for VAT declaration and administratively it requires a lot of work. Work and halting not happening within the EU VAT union. With global VAT legislation administrative harmonisation a lot is suddenly possible.

Another problem is the EU government procurement regulations in demands of standards organisations specifications, of recognition of the private market efforts from many initiatives being made so far. It actually stops governmental administration to take part, contribute and use the work being done so far. UN/CEFACT is an official UN standards organisation, but UN/CEFACT have big problems finalizing its project and few if any, understand the general idea on how to apply UN/CEFACT accounting, UN/CEFACT(EDIFICAS) being asked can't/don't tell. This is one of the main problems for tax authorities to make demands/providing service for the companies on electronic interchange of data. (A question is how long the world can afford modern procurement?) However XBRL looks for recognition as standards organisation.

XBRL has a general problem being designed for the receiving users of information like audits and analysers and it doesn’t look to be enough really convincing arguments for the information producers (companies doing the actual accounting) to pay for the XBRL GL file producing features in commercial software. And without support of the information producers there will be no data for the analysers and audits in XBRL GL format, and so no market for commercial software for them either.

Accounting is originally manual work and parts of it has been computerised using accounting commercial software. But a commercial aspect of accounting is its boundaries and what should be included in accounting commercial software feature packages.

The accounting work is making accounting vouchers with entries and then check the entries are right. The major checking tools are the bank account statements to and cash (register) lists, to prove that every monetary transaction is accounted for in the accounting. Still this checking is to a large extent manual very labour-intensive work computers do much better. Secondly proving that there are evidences for what the transactions consist of by the voucher documentation. Vouchers that are incoming and outgoing invoices (and receipts), in practice a physical voucher folder. (Still the EU VAT directive and many countries VAT legislation demands keeping physical paper folders of vouchers making scanned vouchers not that smooth to work with. This despite the EU commission has a vision of electronic vouchers. Same legislation makes problems with electronic invoices and integration with accounting. So there are still much to solve.)

Another way of looking it are the legal demands and 95% of all legal demands of accounting comes from VAT legislation where the EU VAT directive (European Union value added tax) is the most fully covering documentation. In that perspective it's obvious that invoices and receipts are first and foremost accounting documents (required by the VAT legislation), secondly civil law documents and thirdly they are general trade documents. The accounting documentation required by the VAT legislation is the main regulating law of the entire accounting requirements.

To make benefits for the producer of the data it is most likely in this field integration and atomisation features that are worth paying for by the paying customer of commercial software producing accounting information files (like XBRL GL SIE and UN/CEFACT). To do that invoices (with Accounts payables and Accounts receivables) and bank account statements could be considered as accounting documents, and included in a standard file format solution. None of the present file formats do that but would open up the market for third party automation software using AI.

The lack of accounting integration is also the most likely reason for electronic invoice formats still having very low market penetration and progress is slow. Mainly because the electronic invoice formats are not in first place designed for accounting and VAT legislation demands, but in unregulated trade document perspectives.

Interesting is that there are no standard file formats for bank account statements and it is not (according to the UN/CEFACT banking group TBG5) in the interest of the banks, but for accounting to have, making automatic matching possible with accounting. However an international standard file format for bank account statements would make huge benefits in developing internet banking pages with new features benefitting the bank customers. Especially if integration with a standard invoice (receipt) format would be included.

XBRL GL is also without an additional use instruction set, not tight/clear enough in of its file format, still making it very uncertain, in how to use XBRL GL. That a reading party would actually understand what data in an external XBRL GL file, really stands for.

The situation is like agreeing on using a common writing alphabet without agreeing on what language to use it for. If someone sends a letter in Portuguese in Latin letters to a Dutchman often the Dutchman do not understand Portuguese, even though he can read Latin letters. We have the same problem here. And with no general solution, agreements between every writing and reading user must be made, and that is not a smooth solution getting volumes and a market for commercial software.

An issue SIE as a vendor organisation is able to solve but a standards organisation ethics do not allow UN/CEFACT or XBRL to handle. SIE could be a key player here, supplying an applied instruction layer to XBRL GL (and UN/CEFACT accounting). But at the SIE year meeting 2013 after studying XBRL GL for a year, and a representative of XBRL GL international present at the meeting, the main members argued “who is the paying customer?” and the project of making a SIE XBRL GL implementation ran into the sand.

There are a number of articles in the branch would press about very expensive XBRL projects with very sparse results of volume use. The contradiction between standards organisation ethics and applied technology (a common implementation instruction set) issues, is a hard thing to solve to make such projects more successful.

In 1992, SIE solved the issue for the SIE (file format) as a non-standards organisation vendor society. All members but one large vendor, agreed to a common implementation, including an implementation instruction set, and made it available for all vendors in the market. All other (national, future and international) vendors in the domestic Swedish accounting related commercial software market had to, by customer demand, follow the standard to sell any volumes. Actually the existence of the common format showed the market very good arguments for the data producing users real strong benefits. especially the daily interaction between the company, accounting consultant and audit, being very rational and benefitted in possible daily information feedback. Benefits and features are almost impossible to convince paying customers before the features are actually available, and this is a huge commercial problem for XBRL GL and UN/CEFACT to solve, not being a vendor interest group society. It is interesting to note that the starting vision of SIE was about the same as XBRL, export accounting data to tax declaration commercial software. But it is possible to find special benefit points data for producers, and by it make them pay to get the features of the accounting standard file format, but it is a hard commercial design issue.

There is a general stand-off situation in this market field. And how XBRL will solve it, is the major future question.