Nearly 100% of small businesses today are using standalone or LAN-based accounting software which is

• manually operated for every accounting process from purchasing to selling.
• requires redundant data entry at both ends of every transaction (buyer and seller).
• requires attention, mental concentration and accounting skills, even for day-to-day business.

Small business needs the following, rather obvious, capabilities:

• receive a purchase order electronically
  - authentication sufficient to be binding on the customer, so that we can fulfill it.
  - containing machine-readable items list, so we pick it from inventory.
  
• send an invoice electronically
  - with signing, or whatever features necessary to get a payment from customers.
  - in standard formats usable by bill consolidators and competitive service providers.
  - going into the recipients' accounting software as an unposted, draft Sales Order.
  
• make a payment electronically
  - including vendor invoices.
  - including payroll and other payments to individuals.
  - using standard remittance formats ensuring access to alternative 
         service providers, as well as banks.
  
• get a catalog electronically
  - determine what's available, at what price,
  - updating the ITEMS list in my software, and
  - eliminate the unnecessary work of adding items, prices, and descriptions to inventory.
  
• send a purchase order electronically
  - authentication sufficient to be binding on us, the senders, to ensure prompt service by our suppliers
  - containing machine-readable items list, so we can track our inventory status
  
• receive invoices
  - machine-readable so that our system can match the items with our inventory
  - formatted so that our GL can associate the bill with our Accounts Payable.
  - review and approve onscreen
  - a detailed, standard remittance advice with the payment so that our supplier
      applies it correctly to specific items we are paying for.

The above needs of small business have been technically possible since the invention of the modem, but there has been no standard vocabulary, no agreements on  standard behavior by software, and and no service providers.

If all of the shrinkwrap accounting software vendors awoke tomorrow morning and released electronic billing modules, which tapped into windows email functions to transmit and receive invoices in XML, millions of businesses would begin using those functions within a year or two. All of the above capabilities could be retrofitted to existing accounting systems --even DOS and linux accounting systems.   

In addition to internet transactions, the small business market also needs functionality which is not easy to retrofit into LAN-based packages:

• remote access to the accounting system, to enable services by remote employees, offsite bookkeepers, and CPAs
  
• good citizen in the internal computing environment: an accounting system that shares its data. The top priority is a capability to share customers and vendors.  These should be an open repository or directory system, to efficiently share the customer list with other communication, accounting and marketing systems. Today's businesses have multiple customer lists in their Accounting, Email, and contact systems, which are the root of much inefficiency.  Software vendors like Microsoft capture your customer list, churn the API every 6 months and require $1000/year or more, in rents to continue connecting with your own customer list. 
   
• good citizen: an accounting system that shares its functions with other software, enabling programmers to integrate other business processes with the accounting system. Posting transactions to a GL reliably, at low cost, requires that the GL expose a programmable interface for import and export of transactions and list data. The minimum acceptable performance is a command line capability for scripting. (Although many accounting systems store their transactions in database accessible through ODBC, that's useless because posting transactions directly to the database is risky and requires highly complex programming.  Transaction information should be encoded in standard event schemas such as GLIES, passable within command line parameters.)
  
• capability to sell goods and services online. It is not anticipated that any of the vendors of Windows accounting software will provide a competitive web storefront capability in the immediate future. This will require a degree of security, attractive selling environment and integration with the local items list that is more likely to be achieved by website tool developers or hosting providers on the internet. Web commerce platforms have become powerful and capable.  No small or midrange accounting software vendor has any cost-effective software package or solution for web commerce.

TB 8/11/99  http://www.gldialtone.com updated 3/9/2002