Skip to content
Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Distributed Financial Data Exchange


Financial data is everywhere and increasing everyday, yet outside the enterprise domain sharing that data has almost never been more difficult than it is today. There is a real need for a common standard reporting transaction data between all the different applications small businesses and individuals use today.

OAuth has recently been developed as a standard which solves the trust and authentication aspects of sharing private confidential data. HTTP solves moving and subscribing to data so near realtime information can become widely available. XMPP could be harnessed to create real time data streams. The only thing missing is a simple easy data format. This is what WideLedger aims to define.

Use Cases

Small Business Use Case

ZYX LLC is a small design firm. ZYX use AccountsRus to manage their accounts. ZYX subscribe to the BasePack project management web site and pay $49 monthly. BasePack provides a wideledger feed of XYZ’s monthly invoices. Bill a co-owner of ZYX tells AccountsRus to subscribe to BasePack’s wideledger feed. AccountsRus connects to BasePack and Bill gives them permission to access their data. After this AccountsRus automatically receives and records monthly expenses.

Web Startup

48 Vibrations LLC a web startup in Detroit operate BasePack, which is a web service offering paid monthly subscriptions. They developed their application so it offers WideLedger data to both their clients and to themselves. They use VibrAccount a web based accounting system to manage their books and taxes. Jane one of the partners in 48 Vibrations goes to VibrAccounts web site and tell it to subscribe to data from their web site with the URL provided to her by one of their developers. VibrAccounts connects to the 48 Vibrations admin site and Jane gives them permission to subscribe to the sales data. From now on VibrAccounts contains near real time data of their sales.


Almost all transaction data can be modelled in a ledger format. This should be as generic and straight forwards as possible. It should also be open for additional data to be embedded for industry specific data. It is of vital importance that the specification be as simple and generic as possible.


There are 3 main types of roles in the general WideLedger data flow.

  • Data owner – The end user or business who owns the data (eg. ZYX LLC in the Small Business Use Case above)
  • Reporter – The web service who provides the transaction data (eg. BasePack)
  • Collector – Accounting or other software that gathers and aggregates the data from the reporter on the behalf of the data owner (eg. AccountsRus)

Underlying Data Formats

All underlying formats should support the same basic data elements, which will be defined later.

A reporting web site MUST support microformatted html. This technique allows you to transparently mark data elements on an existing web page using CSS class names. This allows any site with existing financial data to implement WideLedger in half an hour.

Further dataformats supported are xml,csv and json.

Data Elements


The Ledger element contains entries and shared information about the ledger.

Entry Data

The entry data forms the core data in the ledger.

idurlYThe unique url for the transaction
accounturl The account for the entry
account vcardcontact data Contact data for entry.
timestamptimestamp YThe transaction date
currencyiso currencycode The Currency of the transaction
amountnumberYThe amount of the transaction
typeurl A URL describing the kind of transaction
memotext Description of transaction


Each transaction has a unique url. This MUST be a valid http/https url. Following it up should contain further information regarding the transaction.


Accounts are specified using a url. If the account is the Reporter’s own account it SHOULD be specified as the url of that site. User URL’s can be their own url’s, email addresses or account page url’s within the reporters site.


Timestamp’s are specified using ISO-8601 format.


Currency codes are specified as ISO currency codes


Amounts are specified as positive or negative values and can be any precision. Negative values are specified with a – (minus) sign. Currency signs and other text SHOULD be ignored.


Type is a url describing the class of product or service this was. A web service could use a unique url for each service plan they sell. If it is a product, it’s product page.


The memo field describes briefly the transaction. This SHOULD be limited to 256 characters.


Open Distributed Financial Reporting Specification



No releases published


No packages published