|Back to Top|
Reconciliation of Accounts Payable, Receivable, and Bank accounts is a huge, expensive problem in small/medium sized businesses.
Tomorrow's accounting systems must become capable of facilitating reconciling of our mutual liabilities or assets with 3rd parties, in one of several ways:
I don't see why solutions are taking so long to emerge, when you consider the horrible amount of time spent reconciling A/R and A/P in this country. A reasonable estimate would be at least equivalent to 500,000 full time workers, as this is the bulk of the bookkeeping work in America.
For example, a customer might log into the web site of their vendor, using an account/password provided by the vendor, click on "SETTLEMENTS" and request a listing of open items. The vendor would respond by sending it in text, HTML, XML, or reply by email. This is not a transaction that requires extreme trust.
Perhaps a more complete, recurring communication could be established. The two companies software would regularly inform the other whenever any Receivable or Payable were posted to the GL of either company with respect to the other. Such Notices of Postings would pop up for approval of settlement by the user at the receiving site. At that point there are at least 10 different banking or cybercash solutions for immediate settlement. There is also a wide and deep competition among billing providers, to print a check and envelope for you as a service, usually below $1.00. Thus, you can reach anybody, today, electronically.
The key points are using the computer to
Most business owners will embrace this technology, when they are satisfied the benefits exceed the costs, and it is reasonably secure. As a point of reference, consider that the great majority of small businesses still print and mail checks because of the current fee levels for electronic banking. The green light is beginning to flash, for business use of electronic billing and payments in 2000, on its cost/benefit. If account reconciliation mechanisms are implemented along with the EBPP solution it will increase acceptance of EBPP.
The Chicken and egg problem is a real problem but not insurmountable, this time.
The exchange of account listings is a technology that a few participants could implement, without requiring everybody in the system to implement simultaneously. For example, if any software popular with small business implemented AR/AP reconciliation exports and imports, those users who really need it, know who they are. AR/AP clerks routinely fax printouts of their account listings to each other today--- Under this scenario, they would ask the trading partner, whether electronic account listings were available. The hit rate could be considerable. Both parties could log into the internet in the usual manner, and enable their AR/ AP to exchange mutual data, and identify unmatched items. Neither party would need to have much fear of hackers, etc. talking directly to another rank amateur like this.
Any accounting software vendor could support this today using standard XML schemas such as OFX. Here is a snippet from the OFX specification:
184.108.40.206.2 Bill Information <PRESBILLINFO>
The bill information aggregate <PRESBILLINFO> provides information about a single bill, including the amount due, date due, and pointers to more information.
If the client requested bill detail in the <PRESLISTRQ> , the bill publisher provides the detail in zero or more <BILLDETAILTABLE> aggregates. If the client did not request bill detail, the server should use the <DETAILAVAILABLE> flag to indicate whether the client can request bill detail at a later time using the <PRESDETAILRQ> aggregate...
Technically, you can see that there are vendor-neutral, standard data formats, network architectures, security solutions, and supporting software for automatic account reconciliation. One would inquire, then, why desktop accounting vendors do not implement them.
One problem is trust: accounting solutions involving any type of network connection will not be accepted by some companies (indeed some of those companies are still on DOS for whatever reasons)
Some indeterminate number of small businesses are involved in questionable activities or tax evasion. They will continue to have extreme privacy concerns, and make a disproportionate amount of noise about it. Ironically, nobody can really maintain a secure firewall today, at low cost, anyway. The only way to maintain the security of your General Ledger during the time your computer is connected to the internet would be to maintain it on an ASP or Web GL service that only accessible thru 128-bit SSL. That way there's no data on your PC.
In any case, automatic reconciliation raises interesting new problems: companies that disclose the contents of A/R and A/P might not get to keep as many overpayments from their customers. American business overpays or double-pays invoices with considerable frequency. Here is a little quiz:
Ask any professional bookkeeper, in small business! A survey published a few years ago indicated that more than half the large corporations polled retained such overpayments without notification. Ask any CPA whether their clients have a few old receivables with credit balances. So, everybody is playing the game of paying fewer overpayments than the overpayments that fall in their own favor.
Scenarios such as OFX introduce greater risk than ever before, that your supplier may detect your double-posting of a liability, and create a double-billing to equal it. Under the old paper system, your suppliers' statement would have revealed your error and you would have corrected it. This same problem can occur in A/R if you underbill your customer.
Note that single-table systems such as a STR do not have this particular risk. There is a moment of agreement upon a transaction, and it is posted in a shared table. You have agreed upon the terms within an arms length exchange, with both parties vigilent. You have removed the types of errors that result from maintenance of separate books, and from after-the-fact data entry. So, there is less possibility of bookkeeping error.
Eventually, the economies of integration of our business processes with customers and suppliers will be so large that unconnected accounting will be non-competitive within a few years. Accounting software is in an embrionic state with flippers and fins. But the end is near, for all these hard-coded, isolated, completely self-contained, non-communicating accounting packages.
For more discussion see http://www.gldialtone.com/exploration.htm and http://www.gldialtone.com/endredundancy.htm.
Todd Boyle CPA --Kirkland WA-- firstname.lastname@example.org