In searching for a bookkeeping xml format, I stumbled upon XBRL eXtensible Business Reporting Language, and I'm surprised I've never heard of it before. It actually looks pretty good! If I wasn't able to find something like it, I was thinking of coming up with my own "basic bookkeeping markup language", or BBML. I just want a really simple and basic data model (which is published and documented) so there is more cohesion in the open source financial software arena, specifically for bookkeeping. It is unfortunate that in my research I keep finding widely different interpretations of the same well founded of bookkeeping - a well founded theory that has around for several hundred years! An XML data format for bookkeeping and accounting will obviously be useful for many reasons, mainly providing people with different goals to collaborate more effectively. XBRL
This is good stuff! This page explains the concepts very well:
But more to the XML core, it appears that there are three useful schemas to me:
- gl-gen-2006-10-25.xsd
- gl-cor-2006-10-25.xsd
- gl-bus-2006-10-25.xsd
There are a bunch more included in the taxonomy, and here's a good explanation from xbrl.org:
"This taxonomy (a modular set) is intended to provide a standardized format for representing the data fields found in accounting and operation systems and transactional reports that will allow organizations to tag journal entries, accounting master files, and historical status reports in XBRL. The modular set consists of the COR (Core), the BUS (Advanced Business Concepts), MUC (MultiCurrency), USK (concepts for the US, UK, etc) and TAF (tax audit file) modules."
While other programs will need more than those three schemas, I'm cool with dealing with just those three for PBooks at the moment. Browsing through these xml schemas, I will highlight the following snippets:
Account Types from gl-gen:
These remind me of my complaints regarding bank accounts being separate from other accounts. And I see here they listed an account type of account. Make sense? Maybe not.
This I can agree on. Well said. I'll be happy to use this model in PBooks.
Even gl-cor starts to get too specific for me, so I might just stick with gl-gen and gl-bus for now. Actually it is definitely useful for PBooks. I just review the example journal entry XBRL document at GaLaPaGoS and found it incredibly helpful. While some stuff still doesn't make perfect sense, a lot of it makes really good sense, jives with the financial model I've setup for PBooks, and validates some of my concepts, building my confidence. Woo-hoo! :-)
Basically, for a journal entry to be represented in XBRL, you start with "accountingEntries", then "documentInfo" and "entityInfo". After that, you get into the journal entry content. "entryHeader" encapsulates a journal entry. It can contain two or more "entryDetails", which contain account, amount, credit / debit, documentType, posting date, and status. Love it! I'm surprised that each entryDetails have their own postingDate.
Next I'll be dissecting the example fixed asset xbrl file at GaLaPaGoS.
I've just emailed the xbrl gl group to ask this:
Hello, I've reviewed some of the examples in the GaLaPaGoS archives - very helpful, but the chart of accounts is not yet active. I was wondering if anyone can supply a link to an example chart of accounts. I'd like to see how mainAccountTypeItemType and default balance (debit / credit) are structured. Thank youABRA In doing more research, I found this company ABZ Informatik. They have published some java and xslt tools for working with XBRL, which I'm thrilled about because I'm very interested in XSLT (though not as much into java). They even reference one of my favorite sayings by Isaac Newton, something along the lines of "I can see far because I stand on the shoulder's of giants." Good stuff! I just downloaded "ABRA" and am checking out the stylesheets and read this:
"The stylesheet processor must support Java extensions in order to run this stylesheet. Further the libraries of the ABRA distribution have to be in the current classpath."
That is kind of disappointing, and for that same reason I've purposefully avoided injecting php functions into my xslt documents even though it is possible. What's the point of using an open standard like xslt if you are going to lock it into a specific language? Might as well use the language's native data structures in my humble opinion. :-/
Also found these resources:
XBRL Example at Emporia University - this site has some excellent links, like this one:
GaLaPaGoS - Global Ledger Practices Guide for Study - very good!
XBRL Stuff:
John Udell emails with KPMG staffer on XBRL
XSL-FO for XBRL (bottom of page)
XSLT for Financial Computations
KPMG Tutorial on XBRL (Required IE :-( )
Dated but useful page of XML for accountants
Standard Advantage - includes listing of XBRL patents
NYU project page including one for Morgan Stanley involving XBRL