You are here: Home » General » OAccounts – is it feasible?

OAccounts – is it feasible?

by Dennis Howlett on March 16, 2009

Purely by chance I came across this thoughtful piece by Martin Kleppmann, proposing the idea of an open standard for the interchange of data between accoutning applications. He’s gone as far as to start outlining what he terms OAccounts might look like. Martin’s thesis is based on:

OAccounts uses the OASIS UBL open standard for representing invoice and payment data. This powerful standard is gradually getting adopted worldwide — for example, it is already mandatory in Denmark for any suppliers to the public sector to use it. It is well designed by people who understand the nuts and bolts of international commerce, and it really ought to be a format which all applications can understand.

I sense Martin is amplifying a single use case to make a point but heh – who wants to dampen enthusiasm?

It was interesting to see the way leaders of the saa/on-demand movement weighed in on Martin’s post, welcoming the idea but pointing out, as Rod Drury, CEO of Xero did that:

The SaaS industry loves standards. It’s not just for moving between systems but would allow others to do innovative extensions and would grow the SaaS ecosystem.

I think the lead will come from the SaaS vendors working together, but I think we all have a bit to do first. Probably a few years away when volumes will be significantly higher than they are today and a few of us have resources to put into this.

I disagree with Rod. Time and again, the software industry has shown itself incapable of finding standards on issues that make interoperability a reality. We’ve been talking about XBRL for years and only now is it showing signs of life. More important, as Mike O’Grady of AquilaTechnology points out:

Obviously, Sage will not be in too much of a hurry to provide an OAccounts facility

And neither will the other vendors who play in the accounting space. The work required to refactor databases alone constitutes a pain that many will choose to avoid as far as possible. Years ago, Exchequer and CODA used BASDA’s eBIZ-XML to create invoice connections between their applications. It was a great idea at the time but nobody bit. Nobody cared.

Twinfield expended considerable effort figuring out XBRL, something that is about to become mandated in at least some territories. Given the industry’s laxity in developing for XBRL which is non-competitive and relates to reporting, what chance OAccounts? Later today I will be talking about SOA in Infor/SAP environments – a very new development that is designed to solve the same problem Martin outlines. Given the big boys aren’t playing at all, what chance the as yet nascent saas industry? Seriously.

API’s certainly help in the development of other applications. Check what Freshbooks has been doing with partners like Basecamp, Outright and IAC-EZ. Check what Kashflow has done with MyCake.org and others. I said the other day that Kashflow could become a platform. But then equally it might plough its own path and add on the very features that others are developing. It wouldn’t be the first time that’s happened.

I can see some use cases for standards based integration. I can for instance see how it would be useful to integrate contractor systems to larger AP systems run by agencies or organizations that use large ERP systems. But that adds yet another layer of complexity to the landscape.

In the meantime, the vendor community races to develop services that are ever more complete in a direct bid to compete with the Sage’s of this world. They all know that in the UK, Sage is the elephant in the room while in the US it is Intuit. They have to convince a would be or existing Sage/Intuit user that their offering offers better value first before worrying about integrations to potential competitors.

Martin’s premise is that he wants his data to be portable. Why? He wanted to move from Sage to a saas product. History suggests customers switch applications once every 5-7 years. The incentive to develop against a standard therefore is low unless everyone agrees it is appropriate. Even where a switch is made today, it’s relatively easy to move the data from one app to another – up to a point. Most accounting software can at least spit out and import a CSV file.

But if you want a way to integrate any and all applications then you’re into a different ballgame altogether. Accounting in the full sense is a local style of product/service, not global. That alone creates problems if you are thinking of working across international boundaries. That’s one of the reasons that Sage has acquired so many companies around the world.

Even if you’re thinking of working in a single country then you inevitably stumble across the need to work with government mandated gateways that operate according to their own interpreatatino and requirements.

I see the point of having standards for the movement of data between services like Mint, PayPal and the accounting apps. But if the complete lack of standards there is an indication of how well/badly the industry as a whole is doing then I’m afraid we could have a very long wait. That’s not to say it won’t happen, just that politically, let alone practically, the industry is in for one heck of an uphill struggle.

The more likely scenario is that a TIBCO/IBM-esque standard could be developed where a thrid party acts as the glue provider. That’s exactly what Martin’s second diagram (see above) looks like.

Related articles by Zemanta
Reblog this post [with Zemanta]
  • Share/Bookmark

Tagged as: FreshBooks, Intuit, KashFlow, PayPal, Software as a service, xero

  • Dennis, thank you for your thoughts. You are of course right about my highlighting of Denmark as UBL adopter being a bit of a desparate attempt to demonstrate some sort of relevance to reality.

    For me, what motivates OAccounts is only secondarily the ability to switch accounting software; as you say, it happens fairly rarely (although it might happen more frequently if there wasn't so much effort associated with it). The primary reason is that I as a third-party developer would like to be able to easily write extensions which do the things I want, such as integrating with a website, providing custom reporting, or running batch jobs.

    In that sense you could see OAccounts more as an attempt to unify APIs to accounting systems (which are currently incredibly diverse and inconsistent with each other, even when trying to achieve exactly the same thing).

    I think that a lot of open standards have been driven by developers and their principles, not so much by commercial consideration. In fields other than accounting, open standards have been very successful, and my best guess at why this has not yet happened in accounting is that in general, developers are not particularly interested in accounting.

    That's not to say an open standard isn't commercially valuable. If you take into account the amount of time and money saved in integration tasks, particularly those with third-party tools, and the productivity gained in having those tools available (rather than having to stick with whatever inferior mechanisms vendors provide out-of-the-box), I think it becomes a very worthwhile investment.

    However, it will have to evolve. I am starting not by writing a grand standard which attempts to solve everybody's problems, but by writing a small standard and a reference implementation which solves my own problems as a small business owner. Then, bit by bit we can extend it based on feedback from real-life application use and turn it into something more general. Whether it can ever grow from its small business roots to something enterprise-grade I don't know, but maybe that's not important either.
  • @martin: I am sure you're right in much of what you say. But I would say you are better endeavouring to write the middleware adapters as a proof of concept because I can't see the industry flocking to this anytime soon. How about a Sage > Anything two-way adapter? That would be a great start and one I'm sure the industry would welcome.
  • Eric E. Cohen
    You mention "XBRL which is non-competitive and relates to reporting"; while you may be fully aware that some might disagree, I do want to point out a lesser-known part of XBRL that may be fully relevant to the discussion, something called XBRL's Global Ledger Framework (XBRL GL). It certainly does relate to "reporting", in that it was designed to be the "drill down" tool from, and ideal summarization tool to, end reporting and uniquely reconciles to multiple reports (e.g., local GAAP/IFRS, book/tax) simultaneously.

    However XBRL GL can represent much more, down to the level of detail you describe, serving to fill the gaps and seamlessly link to original source documents and transactions (helping to reestablish the Seamless Audit Trail). It was designed for the purpose I believe has been laid out - a single, generic, holistic, interoperable, standards-based way to represent the data that flows in and through an operational, business and accounting system, which can seamlessly interface to incoming transactions (such as UBL) and outgoing external reports (XBRL and other XML schema based). Examples of its use to represent everything from payroll timesheets (pre-accounting), customer and vendor invoices, project costing reports and - of course - journal entries and trial balances - can be found at http://gl.iphix.net, along with Webcasts showing how standard, off-the-shelf software such as Altova MapForce can be used to turn anything into XBRL GL, and XBRL GL into anything, leveraging it as a standard metadata hub.

    Respectfully, I must disagree with Twinfield's assertion that "XBRL GL is still in its infancy and is not yet established"; the basic model that became XBRL GL preceded the establishment of XBRL; XBRL GL has a decade plus of development behind it; it is a RECOMMENDATION of XBRL International (v1 in 2002 and v2 in 2007) and is being used by major corporations to integrate disparate systems and streamline their consolidation process; a number of governmental entities are using it or considering it as an important part of a wide variety of internal and public-facing purposes; and the formalization process continues in collaboration with a number of different standards orgs.

    I am not aware that Twinfield has had any contact with the XBRL GL working group, asked for help from the group, or made any recommendations on how XBRL GL can meet its needs better; the working group would be pleased to work with Twinfield or any other serious potential implementer. It is the Working Group's desire to work with anyone with a serious interest and knowledge in this area; even if we both walk away just having learned something useful, we will have all won.

    There are less sophisticated (sometimes read "less complex" or simpler) solutions on the market. There are more expansive solutions as well. XBRL GL was designed to meet some specific needs:

    - XBRL GL uniquely is designed to unambiguously link to XBRL end reporting (and, in fact, any XML-based reporting). I am not aware of any other standard that lets you say "This account or transaction is summarized to account 1200 for books and 6000 for tax". However, it is not reliant on, nor requires anyone to use, XBRL for end reporting.

    - XBRL GL uniquely can track fully detailed transactional information or more summarized information "pre"-accounting classification (you can use XBRL GL and never enter an account number or classification code) and maintaining concurrent sets of books, tracking cross-GAAP (say UK/IFRS or book/tax) entries and tracking permanent and timing differences across reporting sets of books.

    - XBRL GL uniquely offers a wide variety of free educational materials, such as the annotated instances, working group notes and webcasts, and welcomes feedback from interested parties, with public mailing lists (http://groups.yahoo.com/group/xbrl-gl-public amongst them), regular opportunities to speak with the working group and public vetting periods for all releases.

    - XBRL GL was designed to allow the collection and sharing of information independent of country of origin, of industry, of accounting or reporting.

    - While XBRL GL is XBRL and can leverage the standardization of labels so one standard can be better understood by anyone in any country where an XBRL set of "labels" has been provided, it is also not dependent on XBRL tooling to use; any good XML mapper, such as Altova's MapForce (even before the recently added XBRL functionality) can suffice.

    Representatives from the XBRL GL Working Group are active in reaching out to overlapping and related efforts to try to bring harmonization amongst the efforts. Mutual improvement may lead to greater interoperability and perhaps eventual harmonization.

    I believe we want very much the same thing. We would strongly appreciate the community's feedback on how to improve XBRL GL. We would be glad to help serious parties understand what XBRL GL does so others can take anything useful they find in its design and incorporate it into what they are doing. But let's gather around something and see if we can make the dream you are laying out possible ... and actual.

    - - -

    Regarding the Linked Data concept:

    Sir Tim Berners-Lee spoke about it recently at http://www.ted.com/index.php/talks/tim_berners_... - an interesting 15 minutes.

    We are generically exploring XBRL and the Semantic Web as part of a new W3C Activity - http://www.w3.org/2009/02/xbrl-ig/charter.html

    - - -

    For those with a greater bent toward UML

    http://www.omg.org/cgi-bin/doc?finance/2008-12-2
  • Maybe I should have a deeper look at XBRL GL then. To be honest, I haven't explored it in depth because I couldn't find any documentation which explained it on a level and in a manner which was useful to me. (UBL suffers from that syndrome too, but maybe to a slightly lesser extent.) I found the documents were either about high-level requirements and goals, which don't go very far towards explaining how one would actually implement XBRL, or the actual schema files, which are necessarily extremely detailed and abstract. I couldn't find any developer-focused introduction in between the two extremes.

    I am a developer, and I believe that the key to wide adoption of a software platform or data standard is that developers see why it is useful, get excited about it, and start writing software for it. Like FreeAgent's Ed Molyneux demonstrated: http://twitter.com/edmolyneux/status/1283011848

    Moreover, I am a small business owner, and thus obviously biased towards the needs of small business. It's a very different world from the reporting obligations of publicly listed companies. In my world, an integration project needs to happen with one developer in half a day. Compare that to an enterprise integration project in which you need a small army of consultants for six months. Both have their reasons, they are just very different. But in my case, simplicity is key.

    While I fully respect the large amount of effort which has gone into XBRL and any other standard, I believe that you need to market a standard just as you need to market anything else; and that involves choosing your target audience and explaining it on a level appropriate to them. I don't know who the target audience of XBRL is, but I'm pretty sure that it's not developers in small businesses.
  • Eric E. Cohen
    > Maybe I should have a deeper look at XBRL GL then.

    Or, if we have an opportunity to collaborate as part of OAccounts, I can try to point out relevant aspects as you move forward.

    > To be honest, I haven’t explored it in depth because I couldn’t find any documentation which explained it on a level and in a manner which was useful to me. (UBL suffers from that syndrome too, but maybe to a slightly lesser extent.) I found the documents were either about high-level requirements and goals, which don’t go very far towards explaining how one would actually implement XBRL, or the actual schema files, which are necessarily extremely detailed and abstract. I couldn’t find any developer-focused introduction in between the two extremes.

    I will point you to our GaLaPaGoS (Global Ledger Practices Guide for Study) site - http://gl.iphix.net - it has a wide variety of resources we hope are relevant to developers, including especially:

    1. Archives of webcasts, both technical and "marketing"
    2. Annotated instance documents; these, I think, are your best tool. They are examples of XBRL GL for specific uses, along with annotations (commentary on the structures of XBRL GL, their specific use in the presentation illustrated, options and issues)

    > I am a developer, and I believe that the key to wide adoption of a software platform or data standard is that developers see why it is useful, get excited about it, and start writing software for it. Like FreeAgent’s Ed Molyneux demonstrated: http://twitter.com/edmolyneux/status/1283011848

    That would be very good.

    > Moreover, I am a small business owner, and thus obviously biased towards the needs of small business. It’s a very different world from the reporting obligations of publicly listed companies. In my world, an integration project needs to happen with one developer in half a day. Compare that to an enterprise integration project in which you need a small army of consultants for six months. Both have their reasons, they are just very different.

    I am a CPA who had a one man consulting firm, trying to help small businesses (and small CPAs) cope with computerization - getting data from an outsource payroll provider into their accounting system, or sharing their data with their tax preparer. XBRL GL began for small businesses, and having a standard import/export format for small business continues to be my desire.

    > While I fully respect the large amount of effort which has gone into XBRL and any other standard, I believe that you need to market a standard just as you need to market anything else; and that involves choosing your target audience and explaining it on a level appropriate to them.

    One challenge of a standards org is running everything - including official marketing materials - through official processes.

    > I don’t know who the target audience of XBRL is, but I’m pretty sure that it’s not developers in small businesses.

    XBRL broadly, no. XBRL GL - rather the opposite. When there is an establish standard, a developer who formerly had to choose one accounting product and develop for it could now broaden their audience - if major accounting products could import a standard export file, your product would instantly integrate with all compliant products.

    > But in my case, simplicity is key.

    I hear you. The great trade off. I helped companies select accounting software for many years. They wanted "simple", "the minimum". And then they needed "one more feature.

    Thanks for the response!
  • > I will point you to our GaLaPaGoS (Global Ledger Practices Guide for Study) site - http://gl.iphix.net

    Ah, excellent -- those annotated instance documents are a great help. Thank you for pointing out this resource. Even just looking at it briefly suggests that XBRL GL may be suitable after all. I will look into it further.

    > One challenge of a standards org is running everything - including official marketing materials - through official processes.

    I understand. I think though that there is more scope for 'unofficial' marketing, through blogs, wikis, informal tutorials etc. -- of course none of that is normative, but it doesn't need to be. (To give an extreme example, think of how many developers use HTTP, and know the structure of the headers -- but hardly any of them have actually read the RFC. Most pick up the general idea from an informal blog post or book somewhere, and only refer back to the RFC in cases of doubt, e.g. to decide whether a particular encoded character is valid in a particular place in the headers.)

    I will try to contribute my bit with regard to informal, accessible documentation.
  • We've been doing this commercially in the Sage Accounting space for a couple of years now using our own open format Connect XML - we have connectors and transports for shifting data between Sage 50, Sage 200, Sage Act!, Salesforce, Ebay, PayPal, Secure Trading, osCommerce, ZenCart, ClickCartPro, AutotaskCRM + loads more.

    Denis has already mentioned here http://is.gd/nPNv about our integrations between our integration between SaaS provider Salesforce CRM and Sage Accounts.

    We already have in development connectors for other accounting apps and yes you can move data between the apps by exporting to Connect XML as the intermediate format.

    Its good to see an open standard being discussed as when we looked at this originally there were no decent and simple standards for what we wanted to do so we be following the OAccounts project with some interest

    Adam
  • Eric E. Cohen
    Adam -

    Are the specifications for Connect XML publicly available? Is it the definition(s) that are illustated at http://www.getconnect.co.uk/downloads/connect_s... and described in http://docs.internetware.co.uk/connect/? (I cannot find the actual .xsd(s) - only documentation to the schema).

    By "open format", do you mean you are making it freely available for reuse, as XBRL GL does under XBRL's IP policy (royalty free, freely available to implement and use) or Martin is doing under Creative Commons?

    I would be very interested in studying your work, considering demonstrating a mapping between Connect XML and XBRL GL, and seeing if there are some lessons that can be learned / opportunities for harmonization. It's always good to do a completeness test!

    Nothing else comes up quickly in a search engine; nothing comes up by typing "Connect XML" into the search box at Sage.com ...

    Much of the original inspiration for XBRL GL came from Sage NA products - I was a dealer and engaged more than once to help a client move from a lower end Sage NA product (Peachtree, Daceasy, SBT) to MAS 90, or even from one version of MAS 90 to a very different version of MAS 90 (because they had paid for customizations in version n and the standard upgrade utilities would not upgrade their custom data, or they chose to skip a release rather than pay again, so needed extra help moving to version n+2) and sought to make sure XBRL GL could serve to properly feed and export data from these products, across products lines and versions, both commercial and not-for-profit (I was a big MIP Fund Accounting fan, another Sage NA product line). A central hub format would make it easier to identify enumerations and other codes that would need to happen to prepare the data before doing the import into the latest product as well.

    Working with CPAs/CAs to bring detailed data from their clients' systems into their own, I had a particular interest in being able to get data from Sage NA's fixed asset management solutions (Best/FAS). As a practitioner, I had spent too much time manually reentering fixed asset information and doing the depreciation - I wanted to be able to let accountants have simple access to their clients' systems (as appropriate).

    (Intuit QuickBooks, Realworld, Macola and Great Plains/GP Dynamics were also highly influential, but that's another story.)

    By the way - if anyone wants to get in touch with the XBRL GL Working Group, you can email xbrlgl@xbrl.org (which goes to the Chair of the WG, not me) or take part in public discussion of XBRL GL and related standards in this space at http://groups.yahoo.com/group/xbrl-gl-public.
  • One point I'd like to raise: has thought been given to the scalability of hub and spoke systems of the kind that Martin is proposing? I"m not convinced they can massively scale in highly distributed environments. Doesn't P2P work better in that regard? I may be talking a bit beyond the limits of my technical knowledge but if you are going to architect something along these lines then it would be a pity to run into the kinds of problem that services like Twitter faced and which have had to be re-engineered.

    Can I direct you to SCALA/Lift as a possible open source messaging platform? David Pollak is the lead developer - it is open source and it is massively scalable. The reason I know is because it was used in our ESME project which is now part of the Apache incubator. We had to demonstrate scale as we were piloting on SAP/NetWeaver. David is a super cool guy and really knows about scale.
  • Eric E. Cohen
    Your question is interesting, and draws our attention to what is being proposed in the hub and spokes. Are we talking about a metadata hub (where data going in to and out from any system is transformed by a common intermediary format) - or an architectural issue?

    The hope, of course, is that metadata standards free you up to choose an architecture - or multiple architectural approaches - that makes the most sense and the agility to easily change between architectures. Send the data, leave the data in place and link to it, use a data warehouse or not.

    So I read _virtual_ hub and spokes (overcoming the n-squared problem through a common mapping, requiring 2n maps instead of n*(n-1)/2 for one way proprietary mappings), not architectural; glad for Martin to clarify!
  • > has thought been given to the scalability of hub and spoke systems of the kind that Martin is proposing?

    It is something I am definitely keeping in mind. My intension of the hub and spoke diagram is really to indicate how OAccounts could be a 'lingua franca' between all these different systems. OAccounts in that sense is just a protocol via which you communicate with another node, whereby that other node could be a hub, or a spoke, or a node in some decentralised system; it is not the protocol's job to specify a particular implementation architecture. To use Eric's wording, yes, it is a "metadata standard".

    That said, I am hoping to also produce an open source reference implementation, which will of course make many more architectural decisions (while leaving the possibility for other developers to write their own if they have different requirements). Curiously, it happens that I have started doing this in Scala! (Scala is the best language I could find for XML processing. Not using Lift yet, but I'll have a look to see whether it would add value here.)

    One aspect which is quite important to me is to keep a version history of all changes to the accounts; very useful for audit trails, reconstructing past events in case of investigation etc. The reference implementation will probably use the distributed version control system Git for this purpose. It offers a lot of advantages, although of course for some purposes it might me more suitable to use standard database storage.
  • The XSD isnt public domain or CC, I can send it over to you if you let me know where to send it - definitely would be worthwhile us discussing things in more depth. If you just drop me an email
    Adam
  • @adam - I'm not sure - but if you're referring to Eric's responses then I am happy to broker the exchange of email addresses but my privacy policy does not permit me to do that without Eric's position. If you can clarify that than I can do the permission thing.
  • Eric E. Cohen
    Really appreciate the privacy policy! I have been in touch with Adam off-line.
  • @Dennis - Thanks for the offer - we've managed to find each other.
  • Companies benefit from fixed asset software because their fixed asset management process becomes more automated and complete. Follow up inventories and associated reconciliations are more efficient when using state-of-the-art barcode technology in conjunction with fixed asset software.
  • Eric E. Cohen
    Well, "Fixed Asset Software", I'm with you - I think that many companies have yet to take advantage of good Fixed Assets software. However, the ability to interchange data between those products - whatever the developer - and the tax preparer, auditor, SaaS provider and other parties who may not use the same software is important, and what this conversation has really been focusing on.

    Many, many moons ago, I was a reseller of Operator 10 software (now found at http://www.allmaxsoftware.com/), which was for tracking maintenance of assets (e.g., that boiler at the Slough facility might not have exploded if we remembered to maintain it now and then!)

    Wouldn't it be great if Fixed Assets packages talked to maintenance systems? Or if any Fixed Asset system could interchange data at any desired level of detail with other systems, such as:
    - Purchasing and payable systems automatically updating Fixed Assets
    - Fixed Assets usage tied in with planning (capacity requirements planning), costing (job costing), etc.
    - Maintenance also tying in with FA, PO and Payables
    - and of course, general ledger
blog comments powered by Disqus

Previous post:

Next post: