1.  Define a minimal, standard data format and set of behaviors by which any two or more parties can conduct business over the internet, by posting files on any shared file system or service.

2.  Run without server-side logic other than persistent file storage. Run on simple file servers such as SANs (Storage Area Networks), FTP servers, NFS, or any of an emerging class of unregulated peer-to-peer networks, for example,

• Magi http://magi.endeavors.org/html/index2.html
• Freenet http://freenet.sourceforge.net/
• Publius  http://www.cs.nyu.edu/~waldman/publius/
• Mojo Nation http://www.mojonation.net/

3.  Achieve an intrinsic reconciliation of balances between all parties (i.e. mutual  payables and receivables), including between banks and accountholders, by sharing access to common elements of the transactions (e.g. amount, date, description) between parties. See http://www.gldialtone.com/STR.htm for further discussion of this.)

4.  Maintain security by control of encryption keys rather than account-level and user-level security on servers, which most financial accounts and marketplaces are based upon.

5.  Maintain permanent, incorruptible trail of adds and edits including a primitive transaction control, based on server-side policy of never deleting anything.  Storage server is configured to allow its user population to create and read files, but prohibits renaming or deletion of files.  Storage requirements may grow forever, or optionally, the SAN may delete files after a minimum of 3 years, or longer according to local policy.  Commercial transactions as a class, are not subject to high volume of edits.  

6.  Avoid transaction filename collisions by delegating naming responsibility to File-Based Webledger clients.  Transactions are stored in files named with random filenames such as 16-byte GUIDs. Information retrieval is based on filenames.  In the rare event the file service reports a filename collision, the FBW client retries with different names until successful.

7.  Provide a root ledger solution (general ledger) under the user's exclusive control, providing a realistic software application for the small business.  User will maintain fiscal control over transactions on the SAN, and all other assets and liabilities, management reporting, tax and financial reporting, etc. based on a consolidation metaphor.  The FBW is a classic double-entry accounting (CDEA) sub-ledger which can manage a great variety of transactions in the Freenet, while presumably not serving as primary general ledger of most ordinary businesses.  It provides transaction rowsets in flat files, for consolidation into any commercial accounting software except Intuit Quickbooks, which has no import.

8.  Provide rich reporting capabilities  (i.e. fact table) enabling the small business with extensive data warehouse potentials unconstrained by behaviors of trading partners.

9.  Support ebXML patterns i.e. related commercial transactions

-----------------------------------------------

There are two components to the File-based Webledger architecture: a client, and a  filesystem.  

1.  General Ledger

COMPILED APPLICATION - The FBW architecture calls for a fairly complex, ambitious software application hereinafter referred to as a General Ledger, which runs locally (or hosted someplace outside the freenet or SAN filesystem).  (The term webledger usually refers to hosted accounting systems that run natively on the internet using a browser or other thin client interface.  There are at least 15 true webledgers online today, and hundred of others based on Citrix or Win terminals.)

FLAT SCHEMA - The General Ledger stores its transactions on any file system, in sets of Debit and Credit rows in rootledgerXML format.  The rootledgerXML schema is a flat structure equivalent to ASCII flatfiles.   Example datafile, uses 13 of the available 85 fields in the schema:

<Transaction>
 <JELine>
  <Entity>ToddsConsultingLLC</Entity>
  <TransactionID>0000111</TransactionID>
  <TransactionRowID>0000001</TransactionRowID>
  <TransactionDate>2000-08-22</TransactionDate>
  <Reference>DepositAug17</Reference>
  <XBRLtype>accountsReceivableTradeGross</XBRLtype>
  <Party>MyClient, Inc.</Party>
  <PartyRole>Customer</PartyRole>
  <Amount>-97.50</Amount>
  <Description>3 hours site visit 13 Aug.</Description>
  <AccountCode>12000</AccountCode>
  <Project>MCI-4</Project>
 </JELine>
 <JELine>
  <Entity>ToddsConsultingLLC</Entity>
  <TransactionID>0000111</TransactionID>
  <TransactionRowID>0000002</TransactionRowID>
  <TransactionDate>2000-08-22</TransactionDate>
  <Reference>DepositAug17</Reference>
  <XBRLtype>cash</XBRLtype>
  <Party>Bank of America</Party>
  <PartyRole>SettlementProvider</PartyRole>
  <Amount>97.50</Amount>
  <Description>3 hours site visit 13 Aug.</Description>
  <AccountCode>10100</AccountCode>
  <Project>MCI-4</Project>
 </JELine>
</Transaction>

DAYFILES - The  GL initially maintains all transactions in a single transaction file; it later splits the transactions into groups such as monthfiles, dayfiles, or dayfiles-by-user, as necessary to maintain performance or reduce multiuser contention.  The GL files can be stored in any location (local drive, or the SAN or freenet) or potentially, combinations of multiple locations.  The General Ledger may support all of the 89+ fields in rootledgerXML or any subset as long as it includes the mandatory fields (date, amount, etc.)

The General Ledger also stores precomputed totals by month, by account, or by any other dimensions it is configured to maintain them.  Precomputed totals are maintained in the  same rootledgerXML format as the transaction decks.  The minimum deployment of FBW requires one summary file, in order to provide minimal proof of transaction integrity.

The General Ledger maintains a special file (an index) containing a list of the filenames it has used to store its transaction decks and summary reports.  Changes to files are made by creating a whole new file, updating the index, and leaving the previous versions of files on the server.  Optionally, owners of the data may contract to delete the orphans at dates such as after audits, or, move them to offline storage.

2.  Filesystem

The filesystem necessary to support the FBW publicly might be as follows:

a.  globally visible 24x7 on the internet.
b.  open to the whole wide world. 
c.  any user may create files or directories.
d.  the service is writable but then read-only.
e.  all files globally visible. 
f.   in principle, applications may assume files never get deleted.
g.  In practice, the ASP may limit sizes, and deletes files after 90 days
h.  ASP enables users to specify a different file expiration date for each file.
i.   filesystem supports HTTP requests- a basic webserver.
j.   micropayment accompanies each file submission. 
k.  application is responsible to request confirmations whether an upload succeeded.
l.   all messages from ASPs are encrypted with their public key.

Users would setup directories and call them inboxes. 

2.  Shared Transaction Files

Shared transaction files (STFs) are composite files based on rootledgerXML (http://www.gldialtone.com/rootledgerXML.htm) or any other flatfile General Ledger schema, which are intended to be accessible to the two or more parties to a transaction. STF files serve two purposes: they are the message format for communicating transactions between parties, and they are the persistent storage memorializing the transaction once completed.

The STF is conceptually, a triple-entry general ledger row, consisting of a shared entry and two private stubs for the parties:

(Obviously, the private stubs are optional, since they are private. For more discussion of triple-entry see the STR spec.)

The STF actually contains only pointers.  The originator's FBW client puts this file up in the sky, and if the reciprocal party agrees to it, they replace it with a completed version.

Posting Cycle for Shared Transactions

1.   The originator enters a transaction into their FBW Client (General Ledger). We now want the simplest possible way to put the shared component of this entry up in the sky, where the other party can find it.

2.   The originator's FBW Client needs a public key for the recipient.  It looks in its Party table, or URI or other locator in "RecipientSTRhome", or public directories for public keys.

3.  The originator's FBW Client begins to assemble an STR file.  By now, all of the data for the Shared Transaction are already in the Originators GL.  But the originator's FBW Client needs to store filenames inside the STR file for both the original entry, and for future use by the recipient as the filename of the acceptance.  This address for the acceptance file must be pre-assigned, otherwise you'll never find it from reading the original posting, because FBW architecture does not allow editing or deleting files.

The strategy taken by the FBW Client is not guaranteed but is highly unlikely to fail.  It creates random filenames and asks the STF for them, continuing until it finds two filenames that do not exist on the server. The originator then plugs these filenames into the STR file.

4.  The originator's FBW Client places the STF file on the server. 

5.  The FBW Client sends a notification to the recipient (reciprocal party) containing the filename to the transaction, or optionally, may send the whole STF file. 

6.  The reciprocal party loves this. They examine the entry and if agreeable, clicks "POST" to post the shared entry into their private system, and save a bunch of data entry. 

7.  The reciprocal party's FBW Client posts a new copy of the STF file containing all of the original data plus their stub of the transaction and digital signature, onto the server of their choice.

In most cases that is the end of the posting cycle.  All of the multiparty use cases in the STR architecture are valid in the FBW architecture.

Design proposal

The FBW application would have a GUI and an API, with limited functions, in V. 1.0. It would be a high performance software application which maintains a flatfile General Ledger in an array in memory.

The "RootLedger" application will have columns (fields) defined in http://www.gldialtone.com/rootledgerXML.htm  i.e. a collection of every field found in small and midrange accounting platforms. 

Most companies know what fields they need. The RootLedger application will implement subsets of rootledgerXML fields when it initializes (rather than the whole 86 columns) by reference to RootLedger.cfg configuration file. It may load persistent ledger data from data files upon initiating. 

Functions would include:

Import or Export a rootledger ASCII file or stream
 - in space-delimited ASCII format
 - in comma-delimited format
 - as DBF files, or
 - in ODBC, SQL, or other formats

Import/Export XML files or streams
 - in rootledgerXML format
 - in OAGIS 6.2 PostJournal XML format
 - in SMBXML format
 - in FastXML format
 - in XBRL format with rootledgerXML taxonomy

Import/Export to Peachtree 8.0 format
 - in comma-delimited format
 - or using PAWCOM DLL

Import Quickbooks data
 - using Datablox DLL

All of these functions will have options to 

- sort by various collections of columns, 
- filter for expressions in various columns, and
- group by various columns. i.e. generate sums by account, etc. 

All import functions will impose constraints

- transaction deck must balance; transactions must balance.

- future versions may maintain Charts of Accounts and other 
structures and constraints.

This application may be used as a complete General Ledger backend for any arbitrary collection of business modules, or, as the GLR component within a GL architecture having transaction and reporting components.  See http://www.gldialtone.com/GLT-GLR.htm

It would scream, having all data in RAM. It will persist its CDEA transaction rows to disk in rootledgerXML format or any other supported format, whenever instructed by its API or GUI. The "Disk" can be local, on a LAN, on an internet host, or on FreeNet or MojoNation.  

In case of system failure, it would bootstrap itself by reading its indexes and collecting the most recent consistent set of datafiles. Or, if persisting its XML data to a SQL RDBMS, it might bootstrap by first reading from its indexes in the RDBMS.

All XML parsing will be done by string parsers against the hardcoded strings in rootLedgerXML.  The merit is that a GL can be maintained without the cost or overhead of an RDBMS, or a new server OS. You don't require any XML software, or the long series of disruptive upgrades to XML, Schemas, XSLT, etc. You don't buy BizTalk server or other middleware, and wait patiently while vendors set the rules for ecommerce.

An immediate use case for this software application is: 

Step 1: crack your data out of those lock-in accounting platforms.
Step 2: upload it to a decent webledger host someplace.
Step 3: start conducting business on the internet
Step 4: keep conducting business with the local GL, too.
Step 5: download your transaction decks from your webledger 
   and BSPs and local applications, to maintain your consolidated
   view on your own root ledger. Update your views as often
   as necessary to maintain fiscal control over the service 
   providers or local operations.
Step 6: implement downstream reporting in XBRL.

The goal is a multi-party webledger architecture that enables submission of intercompany journals or transactions, conducting business in more flexible, immediate ways without the fees and interruptions caused by banks or other intermediaries. 

Todd Boyle CPA Kirkland WA  425-827-3107  www.gldialtone.com

Links

Peer to peer workgroup http://www.peer-to-peerwg.org/
Sharing is a Virtue http://intelligententerprise.com/000929/supplychain.shtml