1. Identity

Provide person(s) with a capability to strongly identify themselves by public/private keypairs.  

2. ledger of economic commitments and transfers

Provide a storage service to person(s) involved in any economic commitment or fulfillment (transfer of ownership), to store their version of such events in unambiguous semantics (based on UBL), including their digital signature. 

3. message transport and notification service

Provide a transaction forwarding service that sends copies to the reciprocal party(ies) named in these events, informing them of the date/time, amount, and other details, to keep their representations of business events in a consistent state.

4.  service for recording replies such as acceptances

Provide a listening service through which these reciprocal party(ies) may submit and store their response(s) such as acceptance  including their digital signature. 

5. archive and report generation service

Provide persistent and responsive storage of these transactions, sufficient to achieve a robust and intrinsic reconciliation of every balance between those parties such as banks, and payables, and receivables.

Overview

This facility is not for everybody.  It is only for people who keep track of stuff, and want their counterparty in exchanges to have an unambiguous notification of the facts in the exchange.   This facility is furthermore, of no use when counterparties do not want to see the facts in commercial transactions they have entered, but prefer instead to create their own accounts of events unilaterally.  (That is the default in the world today.) 

The STR is a simple thing without much logic, which sits on a network visible to any two or more parties to any transaction, receives a copy of any validly formed record (which may be a transaction), and always attempts to forward it to the named addressee(s) (reciprocal party) for an optional response (which may be an acknowledgment, acceptance, etc.)   

When any response is received, if validly signed by the named reciprocal party, is permanently stored,  encrypted, visible to those two parties alone. 

The STR may be regarded as a combination of a ledger with some encryption and communication scripts.  Or you might regard it as a ledger with an http or email daemon bolted onto it.  Some people have commented "This is an NNTP server with a few extra fields" (because it accepts  transaction documents, propagates them to the STR of the reciprocal party, accepts responses as if to a thread/topic, and propagates responses to the home URLs named by the initiator and recipient.)

The STR might be implemented in these scenarios, either publicly or privately,:

1. privately to serve as the storage for a person's primary accounting system,
2. behind a Web interface for humans,
3. as a web service, 
4. as a component, below any of a variety of software that creates transactions,
5. as firmware within a cash register or other POS device
6. in cellphones, or handheld computing devices with a network interface, and so forth

Implementations must be intermittently, connected to a network in order to offload its executed transactions according to the rules, below, and maintain the required listening service for responses.

The intent of this STR is recording any type of atomic business transaction.  There is a payload element in the STR record (the XMLpayload) which is not parsed or processed in any way, by the STR server.  Obvious payloads include a PO or invoice.

This design is intended to support the simplest kinds of choreographies and ebXML ccollaborations, such as Order-Fulfillment-Settlement or Drop-Shipment.  An information element, GroupID is provided to associate different entries which take place at different points in time, or in separate systems during completion of the  scenario.  The STR is a cheap effort to grab the main benefits of middleware servers like BizTalk without the high cost or platform stickiness.

Note, this is NOT a completely anonymous system.  It requires at least an alias, associated with a public key. The STR server accepts rows from any party but the rows are orphaned and irretrievable until a user record is created in the Users table. 

STR Server behaviors

The STR table below attempts to define an essential minimum of data for transaction events.  The table stores "draft" transactions submitted by an originating party, which may be ratified by the addressee (hereinafter called the recipient or reciprocal party.)

If the STR server receives a response to these "drafts" or "offers" from the reciprocal party, the STR updates the shared section of the STR record with the ResponseCode and Signature provided by the reciprocal party, and stores the reciprocal party's private section data such as codes and document associated with the exchange.  The server does little else other than mechanics such as dates and row IDs.

The STR is an infrastructure component which may be implemented as

• an independent server on the network, or
  
• attached to any web-hosted business system such as a web storefront, exchange, marketplace, trading hub, etc., or
  
• integrated with any entity's business system which talks to the internet at least intermittently.

The STR server manages an Offer/Acceptance process.  Offers received from users are filed in the STR table, and forwarded to recipients. That's about all there is to it.  The originating party must complete the "required" fields of the table below, and the other columns are left blank for the system or recipient to complete.

If the recipient agrees, he or she simply fills in and sign their remaining fields of the row, and re-submits the transaction.  This might be done thru an HTML interface on the STR server, or XML document exchange. The server validates  these "acceptance" messages by finding the original offer, and records the acceptance in that row of the STR table.

After validation, rows are posted to the STR table with encrypted, unforgeable timestamps.   Once the offers fields have been recorded in STR table, those fields are  read-only.  Timestamps provide a true, unforgeable record of a variety of reciprocal relationships such as Payor/Recipient, Accounts Receivable/Accounts Payable, and so forth, described in its XML field and limited only by the users' imagination. 

You might be asking, "If the whole content of the offer can be encapsulated in the XML file, why are there so many columns?"  --The reason is to provide a minimal set of indexes to enable the STR to respond to queries without parsing XML files. An arbitrary design decision was made to carry an Account Code, Amount, and Currency in separate fields so that you could at least request a report and totals by party, by account, by date.  These are the foundation of reports such as aged receivables/payables by customer or vendor, or cash balances, etc. which are automatically reconciled with  the records of their trading partners.  OK? The purpose of the STR is intercompany accounting. 

The STR is capable of recording any type of atomic business transaction by providing XML data fields to contain business documents, within each row of the database (e.g. invoices or POs for use by the local systems of STR users or trading partners.)   There are 10 fields shared by the two parties, plus 7 private fields for each of the two parties.  (This is a single-entry record-- one row represents one transaction between two parties. The STR table does not balance.)  

STR Client behaviors

The requirements for any client application are as follows:

1.  Originates transactions by creating a compound document, containing the transaction date, two parties' identities and URIs, amount of the transaction, and optionally, a few other data such as a document describing the consideration exchanged for the money. The originator is optionally, capable of digitally signing its submission.   The message may be a multipart MIME email or HTTP post; these are outside the scope of this spec.  This spec assumes transport is available to submit the transaction the STR server.

2.  Accepts transactions received from other parties.  The recipient inserts one additional value into the transaction document; the UserID.  Optionally the recipient will digitally sign the completed doc. before resubmitting it to the STR. 

In order to illustrate the STR operation, this paper describes as its participant, a simple webledger: a double entry general ledger which runs over the internet in a browser, having additionally, a capability to send and receive STR transactions.  (Webledgers are a server application, which are clients from the viewpoint of BSPs)

A webledger generally manages a Chart of Accounts table and other mechanics we don't need to discuss here. It is not essential that this particular webledger be supported by the STR, or that it be a dedicated client of the STR. It is just an example of an asynchronous consumer of the STR's services.  The STR could have other types of clients. 

The interface to the webledger will be immediately understood (and hated!) by anybody familiar with low-end DOS/Windows accounting systems.  The table consists simply of a flat file of debits and credits which total zero, which emulate an old paper-based general journal.  Every row is marked with the transaction date, transactionID, and other columns such as those described in rootledgerXML (http://www.ledgerism.net/rootledgerXML.htm#fields) 

In addition to the native database fields described in this STR spec and in the rootledgerXML, business documents of arbitrary complexity such as invoices, orders, inventory movements, payroll details, etc. are stored in an XML document, as a hunk of text, within a single field.  Users could go hog wild and transport xCBL messages, or EDI or ebXML core components in the payload field of the STR if desired.  But the webledger client itself would have no functionality except General Journal.

Let's revisit why a webledger, rather than a compiled client, was chosen to illustrate the STR architecture: SMBs will use multiple business service providers (BSPs) for payroll, bill payment,  purchasing, webstores for selling, banks for receiving payments, and so forth. Most small businesses will not conduct business over the internet from a windows application on drive C: for two reasons: lack of security, and inferior functionality and integration compared with hosted applications.  

Here is a visual model of a root ledger or master general ledger, in an environment where the small business uses several different BSPs.  Clearly, every company will continue to require a summary view of all of their dealings, for fiscal control, taxation, cash management, etc.  Root Ledgers apparently will continue to require the CDEA model. There is no other semantic or processing model for the 7 requirements of a root ledger.

The webledger component of this project is an example of a root ledger because it can maintain records of transactions executed on multiple hosts.  Regardless of the location of the root ledger or who "controls" it, there will be a root ledger someplace, accumulating records of transactions from subsystems, sub-ledgers, DotComs and BSPs, etc. 

Users will generally leave their transaction detail on the ASP or BSP hosts.  In such cases, they will require drilldown from their root ledger to the detail on originating ASP or BSP.  Drilldown is addressed by the STR design, below.

This particular webledger therefore, is nothing special.  It is a theoretical client, running alongside this whole new experimental piece of software called an STR.  The webledger  enables a user (or application) to posts transactions directly into the webledger table for their own company (i.e. balanced multi-line journal entries).  It also provides some minor logic to receive transactions in XML form, from the STR, for review before posting, and to transparently submit copies of transactions to the STR whenever a transaction is recorded for any other party on earth. 

STR User accounts 

Anybody on earth can submit a proposed document, i.e. a monetary transaction, naming one or more other parties to a sale, contract, etc.  The STR server accepts rows from any party but the rows are orphaned and irretrievable until a user record is created in the Users table of the STR.  

If the originating party is not authenticated as having an account on the STR server, it first goes into a process creating an account, before processing the transaction.  ("Processing" means little more than passing the record to the reciprocal party.)  An alias is created, and a dialogue initiated with the originating party to gather a password and optionally, other data according to the policy of the STR operator.

Reciprocal parties named in Offers, may be users having an account on this STR or other STRs conforming with this specification, or, they may be non-users having at least an email address.  Similarly to the Offers processing, if a reciprocal party initially has no account, an alias is created, and a dialogue initiated with the originating party to gather a password and optionally, other data according to the policy of the STR operator.

If a row is received by the STR with empty reciprocal party fields, it is stored in the table anyway, under an assumption the originator is using the STR as a host for webledger GL entries.  In that case, obviously, no forwarding etc. is performed.

Here is the STR table: (Blue is shared, Yellow is Originator's private data, and Green is Reciprocal Party's private data.)

Additional fields may optionally be supported by an STR within Originator's private data or Reciprocal Party's private data areas.  For example, any subset of the fields of  rootledgerXML may be implemented, making the STR into a basic webledger host.

You will notice that none of the Originator nor Reciprocal private data fields is mandatory.  It is logically crazy that anything private be required in this spec, since those fields cannot have any function for the other party.

How entries are formed: 

Accountants will get this immediately: you just post the part of a double-entry transaction which hits your AR or AP.   Visualize the STR as your balance sheet (payables, receivables etc.) and create debits or credits into the STR whenever there is another party associated with a transaction.

As promised in the first page of this spec, the STR serves as a full webledger host if both sides of a general ledger transaction are submitted to the STR by an Originator.  The STR will accept stewardship for any row, even if it lacks a recipient.  Thus, nothing stops a user from submitting large number of rows, even their their entire GL, up on the STR and querying it by account, by date, and so forth.

Multi-party use cases

One of the primary objectives of the STR is to enable lightweight commercial dealings by partnerships and collaborations of greater than two parties.

For multi-company splits, the Offer/Acceptance service accepts sets of rows involving more than one company ID. An example of a transaction follows, in which an independent insurance agent works out of her home and sells a policy. She logs into the insurance agency's system as a user and uses an application to book the business. Lets imagine this General Journal entry results:

Example multiparty transaction:

JournalNo. Date LineNo. Account                         Debit   Credit 8884   09/07/2000 601  40100 Gross Premium income      $       $ 3000 8884   09/07/2000 602  21000 Fed. excise tax payable               50 * 8884   09/07/2000 603  22000 State sale tax payable               100 * 8884   09/07/2000 604  27500 Commission payable                   270 * 8884   09/07/2000 605  28100 10% Withholding, contractors          30 * 8884   09/07/2000 606  12000 Accts Receivable            3100         * 8884   09/07/2000 607  55700 Excise taxes expense          50 8884   09/07/2000 608  56400 Commissions expense          300 8884   09/07/2000 609  26200 Property premium payable            2500 * 8884   09/07/2000 610  60400 Property premium costs      2500 ------ ------  Total                                                    5950    5950

Now, suppose the Agency's computer is all tricked out with an STR interface.  It would submit five liabilities up there and one receivable, a total of six rows*.  The STR associates the six rows using the Originator's transactionID and the external GroupID, 
to tie my rows together.  As the ResponseCode values are received from multiple parties, the STR dutifully updates ResponseCode on each row, and the TransactionResponseCode and GroupResponseCode for the highest level of agreement reached by all the rows of the associated groups. 

Implementing an application program interface (API) to an STR
(tag snatching.  value snatching.)

The STR enables a lightweight B2B by sharing four clusters of information:

1. date/time,
2. amount,
3. identities of the parties, and
4. description of the service or goods.

Shared transactions (STs) can be implemented easily and transparently by any true webledger such as NetLedger, QBWeb, IntAcct, NetAccount, etc. Webledgers are in a unique position of avoiding all the logic of encryption and key management because you already control permissions on the STR table. Here is how you do it:

1. In the subscriber's preferences, ask whether they want to implement transaction sharing. (let's assume, yes)

2. Most user interfaces capable of generating transactions in the webledger can potentially name external party as reciprocals to the transaction.

Obviously any purchase, sale, payment or receipt always involves a reciprocal party. General journal also may involve a reciprocal party and is very important to include in your transaction sharing.

Each customer, supplier and bank maintenance screen will require additional fields. 

a. enable ST's (boolean) b. party's URI or username on the webledger, to send transactions to, c. URI of the external STR if not this webledger.

Each transaction screen will also require the same fields, to apply them on a transaction by transaction level.

3. Obviously, when entering any invoice or other external transaction, the user will ensure the fields are completed properly, and upon posting the transaction it will be transmitted to the STR as an "Offer" or unratified transaction.  Webledger hosts already have all necessary data.  An STR interface is trivial for a Webledger to implement. The XMLpayload will be the invoice or other transaction doc. formatted in your proprietary interface XML (which webledger hosts must publish or perish.)

4. If the reciprocal party is a user on this host, the "Invoice" from the other user will need to be flipped to become a "Bill".  If the party is not one of your users, then, the XMLpayload may be difficult to transform.  In any case, the amount, date and party are seldom ambiguous, and at this point, the AR, AP, and bank balances potentially begin to reconcile. 

The challenge of metadata mapping

The mapping of XML elements and attributes that exist in foreign XML documents (not in your native XML format) is apparently done by XSLT transformations, by most internet business systems.  In future it will apparently be done by reference to registries and repositories whose address is stored in the XML document.  

Webledger developers should meanwhile, consider tag snatching code that runs thru likely words and tags that might contain party, address, product, etc. information and maps them into your webledger.  Any true geek could get a 80% hit rate with some of this code in a few days, because there just aren't that many different strings used to label the key data in a Purchase Order or invoice.  Alternatively, any incoming XML document may be presented in a user interface, in which the user can point and associates any particular element or  structure with accounting functions in the webledger-- teaching the webledger the meanings of the tags.  Webledger host could "cheat" by remembering each XML schema it runs across, and the associated handful of tags mappings it learned in previous encounters.  

Obviously, everybody's party code and products codes will massively collide if nothing is done to map the metadata.  So, you must create mapping solutions (below). What you want is something that is like a neural network that enables all the users on this host, inexorably, to use the same party IDs and product IDs if they want to, and, to give them incentives to want that.

Users on a webledger host will resist automatic, programmatic posting of business transactions arriving from outside into their company on a webledger host. Developers must create "Inbox" or "Unposted Batch" screens for users to review and "Accept" incoming transactions. This is inevitable, regardless of the STR interface and must be built by any webledger or BSP who enables their users to conduct business over the internet.

PartyIDs:  The first time the webledger user receives a document from another party who is not in his customer or supplier list, the inbox screen will prompt the user to associate (map) this new party with a customer or supplier (or import the party record directly off the arriving XMLpayload) From that point onwards, you have either got equality, or mapping, with respect to this particular party. A new field will be required in each party record (and maintenance screen): "His code for Me." Most accounting software already has this in both AP and AR screens.

Note SMBs do not need universal, converged party codes such as DUNS numbers. They only need to map ONCE with each party because they only have one relationship with that party. Directory schemes and portals on the internet are aimed at many-to-many markets and that's fine-- those IDs will tend to propagate into the webledger population in due course.

ProductIDs: similarly, the first time your webledger user receives any XMLpayload having an unfamiliar productID, the import screen might prompt the user to map the product with his existing inventory item, or, import it straight away if it's new.

Here is the value-snatching button:

[Adopt my Suppliers' product ID as my product ID, and retroactively renumber my data.]

Over time, the B2B codes adopted among online STR populations will tend to converge. And everybody who has an email address may  be receiving unsolicited accounting transactions from customers and suppliers, at some point (most likely, UBL or other standard). ISVs will eventually implement one standard or another.  The internet changes our AP/AR cycle, that the AR/AP can be converged to a shared table. The cluster of four items must be shared, the economics are too compelling and it is too viral.

Settlement (payment) mechanisms through an STR

Much of the economics of this STR project depend on achieving adequate security to enable the parties to rely on it for conducting business.  In other words, it does not reach as much economic net gain as a mirror or archive which requires dealings to be conducted elsewhere.  The STR should be sufficiently secure to be used for bids and  offers etc. which stand on their own, and for settlements.

For example, if an Offer is posted containing a purchase order, its Acceptance by the seller may complete the first stage of an exchange.   The STR facilitates settlement of outstanding balances in two ways:

1.  Any digitally signed obligation or evidence that buyer owes seller effectively transfers some of the buyer's credit to the seller because the Account Receivable obligation can be sold to intermediaries.  For example if you give me a promissory note signed by General Motors, that is worth more to me than your note.  This is not new or different from traditional notes or accounts receivable which may be sold to third parties.   STR only provides electronic efficiency to the process of recording, examining, and transferring identities, signatures, and amounts.

2.  Intermediaries such as collection agents, factors etc. subscribing to this host might purchase such  receivables thru an Offer/Acceptance exchange with the seller, and deliver cash (or digital cash, or bank transfers, or book entry credits on other hosts) to the seller.  

3.  Buyers may pay intermediaries prior to intermediary paying seller, establishing a kind of escrow service, eliminating credit risk to the seller. The point is that delivery of cash is uncoupled from the passing of credit, to some extent. 

The creation of these liquid markets within the STR create conditions for efficient, low-cost services for remittances, settlement and cash management outside the fee structures, credit constraints, and lengthy settlement of banks.  Actual money settlement  might be netted for a subscriber by a service provider, or for groups of subscribers, or all members periodically, and the net balances aggregated into periodic totals for which checks would be printed and mailed to banks.  STR enables intercompany payments and settlements, among 2 or more parties.  STR also realizes a vision in which individuals may promiscuously form and join partnerships and JVs with ease, http://www.ledgerism.net/hypercub.htm This establishes a low-cost model eliminating data redundancy and inconsistency between trading parties.  When settlement transactions flow through the STR as well as orders and invoices, the STR becomes a complete record of the dealings between two trading parties, and differences become impossible. These are scenarios which achieve economic returns for any small business participating in STRs and running their STR commerce as a sub-ledger.

Todd Boyle Kirkland WA  425-827-3107