Consistent accounting recognition by parties in ecommerce

[Todd Boyle <tboyle@rosehill.net>]

Problem:

E-commerce systems send requests for resources such as inventory or 
money (decrements in resources) without unambiguously identifying the 
offsetting resource increment(s) at the same point in time, or 
unambiguously communicating the timing of recognition of accounting 
events.  

Example: a request for inventory may not indicate whether this is a
prepaid, or accounts payable, or other terms required for accounting.

Causes of the problem:

* Senders don't have contracts in electronic form.
* No standard format for terms of contracts; adoption cannot happen.
* Even if contracts existed in electronic form, the additional cost,
   computing and bandwidth to generate *balanced* resource messages 
   from sender and transmit, would influence adoption decisions.
* asyymmetry of benefit: the author bears computing cost while the
   recipient gets the admin savings.
* Receivers of such messages would anyways need to verify them against
   contracts rather than releasing money and goods without controls.
* Timing of legal recognition anyways involves logistical facts outside
   the electronic environment such as physical dispatch or receipt of
   goods.  Capturing this data comprehensively/globally would be costly.
* There is no clear consensus among community of developers or vendors
   of collaboration patterns and business process, that enforcing the 
   same timing and character of recognition (including balanced entries) 
   by both trading partners is either possible, or within their scope.

Result:

The two parties' assessment of both character and timing of recognition
into payables, receivables, inventory, or other accounts will sometimes 
be inconsistent.  In other words, the accounting processes will not be
completely automated and they will be costly.  The consequences of any 
separately maintained lists such as AR and AP include:

* The redundant data stores attract updates from different classes 
    of users, at different times, and different levels of aggregation
    such as by the statement, by invoice or by line item, for
    differing time segments etc.

* Neither data store is usually correct, complete, or timely.

* Costs arise due to business errors based on wrong information 
   (overdrafts, credit/collection errors, etc.)

* Time is wasted confirming and reconciling one against the other,
    even when the systems are in agreement.

* Systems are developed to address the problems, by automating the 
   checking and comparison of the two lists, or to post all changes 
   to both lists, etc. 

* Those secondary systems introduce rigidity and problems throughout 
   the software environment. 

..

I think I know the answer and it doesn't involve refinements in
metadata and message content such as ebXML, even if ebXML were
somehow to become a complete unambiguous replication system.  

The answer is to have the transaction database in a shared public
place, where the core facts about contract and exchange are 
enshrined.  Amount, date, product/quantity are the real core
components.   Whenever any economic event occurs, whoever needs
to have it booked must go to the public transaction database and
input their version of the event.  The other party should go and
approve the event or reject it.  All parties would have views of
the transactions which they initiated, or are named as a recipient.

All of the facts of the exchange that are actually part of the 
shared contract with the other party would be in the public repository 
(not the private parts of their accounting entries).  This scheme does 
not require any disclosure or loss of privacy because it focuses on 
things the trading partners already share in their "communications."

This is the only "Repository" that's worth building, in my opinion. 
The shared transaction repository would solve the problems and achieve 
the results needed by SMEs, even if it was plain english text fields 
instead of EDI elements because there is exactly one master copy of the 
deal.

If I were the guv, the UCC would be amended that no contract be 
enforceable unless it's posted in a licensed public repository. 
That would solve a *lot* of problems, with a rather trivial 
cost of database/network.  For example the thing could be hardwired
to the banking system.  

"Money" is nothing but your "row" in a database, at some central bank.
Here is your "money".  Just consider, how ridiculously complicated we
have allowed this "money" system to become:

                                  My Account         My General
Central Bank     My Bank          in my bank          ledger

=========
=========
=========
=========  -->  =========
=========  -->  =========
=========  -->  =========
=========  -->  =========   -->  =========  equals   ========= cash in bank
=========  -->  =========                            ========= receivables
=========  -->  =========                            ========= receivables
=========  -->  =========                            ========= receivables
=========                                            ========= payables
=========                                            ========= payables
=========                                            ========= payables
=========                                            (...)
=========
=========

Note that my receivables and payables, are really NOTHING but future-
dated rows in the real money database, with repudiability and risk
built into them (which is absolutely NOT wanted by most people or
businesses 99% of the time).   This is YOUR money!  Control it.

Within a shared transaction repository, if you don't post your agreement
to both sides of the contract, you don't get your goods.  If you hit 
"POST" that sucker is posted, baby. 

Below is just an example, to think about, among many scenarios.

  WELCOME TO STATE OF NEVADA PUBLIC TRANSACTION REPOSITORY 15MAR2001

  ENTER YOUR ACCOUNT CODE:           [ JILLS:213467236 ]
  ENTER YOUR PASSPHRASE:             [ ***********       ]
  ENTER THE OTHER PARTY:             [                   ]
  ENTER THE AMOUNT:                  [                   ]
  ENTER THE DATE TO EXECUTE:         [                   ]
  ENTER THE DESCRIPTION              [                   ]
  OR UPLOAD YOUR DOCUMENT OR MESSAGE:   [../data/POtortilla41.xml ]

  ...pause

  SESSION COMPLETE   # NEVADA:27468356354545

I'm going to push this link out here, because I think its significant. 
http://www.mobiletransaction.org/pdf/MeT-Account-Based-Payment-20010221.pdf
It is a hardware lockbox with your signing keys, keypad and display
hardwired in silicon.  Hard to crack silicon devices.  

After you input your little session on the shared repository above, 
Your cellphone rings, via bluetooth from the PC.  
You get a little WAP screen:

   WELCOME TO STATE OF NEVADA PTR 15MAR2001

   SESSION#        NEVADA:27468356354545
   ORIGINATOR:     TRES HERMANOS MEX RESTAURANT
   RECIPIENT:      PUGET SOUND TORTILLAS SEATTLE
   VALUE:          237.50

   DO YOU AGREE TO SIGN?

      [  SIGN ]

  ...pause

  SESSION COMPLETE   # NEVADA:27468356354545


Nothing happens.   When the other party posts an acceptance of
the transaction, it becomes real.  If he doesn't sign his 
acceptance by SMTP, HTTP, SOAP, IRC chat, carrier pigeon etc. 
he doesn't get his money.  I'm skipping a lot.  

When you review your inbox, you see the vendor accepted your 
order and it is real.  You're done.  Everything is done--
payment, tax, bookkeeping, billing.  At the end of the month
if you're curious you could fetch your trial balance with a
group-by query but why bother.   This automatically settles
your payroll and sales tax because you would name the tax 
agency in the journal entry you uploaded.

Incidentally it will be hard for the payee to not get paid, not know
they have been paid, not know exactly what you ordered, etc.  If you
don't get your tortillas, you drag and drop the transaction over onto
the LAWYER icon, and pay $10 for a small claims filing.  The guy doesn't
show up with proof of delivery, you get your refund.

Anyway, empirical reputation metrics on that shared host could be 
maintained, for any party who wished to maintain them or disclose them,
which would be basically, everybody. 

Let's quit messin' around, can we, at least, reconcile the AR/AP?
Money is the root element.  Everything else is debatable but 
Once we agree on the money let's book it:

------PARTY A's BOOKS----     common   -----PARTY B's BOOKS -------
<bla>                                                         <bla>
<yada><yada>                                            <yada><bla>
<bla><bla><bla>                                     <bla><bla><bla>
<bla><bla><hare><hare>                        <bla><heebie><jeebie>
<bla><bla><bla><bla><bla>                 <bla><bla><bla><bla><bla>
<bla><bla><bla><bla><bla><bla><money><bla><bla><bla><bla><bla><bla>
<bla><hare><hare><bla><bla>             <bla><yada><yada><bla><bla>
<yada><yada><bla><bla>                     <hubba><hubba><bla><bla>
<whoopie><bla><bla>                                 <bla><bla><bla>
<bla><bla>                                               <bla><bla>
<bla>                                                         <bla>

You're solving the wrong problem by trying to disambiguate all the
bla bla's.

tODD
http://WWW.GLdialtone.com/endredundancy.htm
http://WWW.GLdialtone.com/str.htm