Accountants helping ebXML get GAAP recognition right

[Todd Boyle <tboyle@rosehill.net>]

John A. Edwards said on the XBRL list,
RE: [xbrl-public] Re: Software for unambiguous rephrasing of
FASB pronouncements, 1/4/01

> Some of the rules in the accounting Handbook are already in software,
> (while others happen not to be, since they contain more qualitative
> relations), so I think there is a precedent for translating the GAAP
> rules into a non-human-readable format such as software

Yes.  That is the heart of the matter.  Surely, implementing FASB's
GAAP formulas in software would not be a copyright violation.

> It could operate by integrating a client's actual data instances
> with a GAAP rule.

That's right.  But only if sufficient data accompanied the transaction
in the accounting software.  The data required for successful determination
is objective enough to capture into a General Ledger in almost every
case.  However, the questions would be completely different, depending
on the type of asset, liability or expense.  Accordingly, nobody is
capturing it richly enough, today, because GLs typically capture the
same fields or dimensions for all transactions and cannot support
thousands of discrete columns, on every row.

A programmers first impulse is to store GAAP classfications accurately
in a GL at *transaction execution time*.   It seems to me there are
two broad approaches?  One is to "improve" the users' initial choice
of XBRL classification, and the other is to make transactions classify
and record themselves correctly automatically based on empirical facts
at execution time.  The latter is the right approach of course.

Under the first approach you could guide the user, at the point they
first select a classification or account code associated with their
favorite short list of XBRL Types.  If the transaction was not
one of the types that they have used before they would have to find
the correct XBRL type from the full taxonomy for the country/industry
they are required to report with.  Here is the main XBRL taxonomy for
the U.S. (codes 93 thru 427 are the basic transaction Types)
http://x52.deja.com/getdoc.xp?AN=694999619&CONTEXT=978657105.179372112&hitnu
m=0

You may recall that I once thought the job is FINISHED at that point.
I said WHOOPIE!  lets just put one more field of data entry in our GLs
and store the XBRL type http://www.egroups.com/message/xbrl-public/11

After many arguments public and private I realized XBRL is just a list
of descriptions:  http://www.egroups.com/message/xbrl-public/316
and continue pestering ebXML for unambiguous transaction data.
http://lists.ebxml.org/archives/ebxml-core/200010/msg00030.html

Anyways, let's assume the accounting software developer decides
to improve their *support* for the users' initial, manual choice
of XBRL classification.

Upon making an XBRL Type selection, a follow-on screen might ask
the sorts of questions specifically necessary to ensure that the
classification was correct (beyond simply throwing up the GAAP
definitions which are quite dense)

Bear in mind however, that by choosing an XBRL type, the user has
logically chosen one of the OUTCOMES of a decision process.  He
has decided that he is at one of the final conclusions of a
graphical flowchart like this:
http://www.inlandrevenue.gov.uk/manuals/remanual/objects/101a.gif

Accordingly, all sorts of cool GUI ideas come to mind.  Maybe
display that flowchart for them, in which the user could zoom
out a little, to the big picture and perhaps verify some
of the forks in the road that he has already taken!!!

Alternatively, you would gather sufficiently granular data at the
actual point of the accounts payable/purchasing screen to lock
down the decision.  This would be extremely useful in eliminating
civil claims and disagreements between the two parties anyway.

While you snooze, some big software company (which helped design
XBRL to begin with) is building some real cool software that will
pay them huge dividends, and give them an entrenched leadership
in the market impossible for small developers to compete with.

No doubt some smartalec will soon enough, create a website where
SME's can go to conduct business, period.  This is like Francis
Fukuyama's "The end of history".   The website would have all
the infrastructure bolted in place, and screens that are sufficiently
user friendly yet granular enough, to create excruciatingly exact
purchase and sales contracts.  You would agree on precise Product
or Services definitions from commercial XML vocabularies for your
industry (size, location, quantity, units of measure, etc. etc.)
You would agree on precise settlement terms (due date, settlement
agent or bank, interest, penalty terms etc etc.) and if financial
instrument were involved you would deal with the whole vocabulary
of FPML or other precise financial terms.

One party would craft the initial offer or other "gesture" by
using one of the standard CPAs (Collaboration Protocol Agreement)
from the ebXML business process templates.  Offer-Acceptance is
one of the obvious ones.  These CPAs can guide the order,
fulfillment, and settlement process saving TONS of time and
effort for everybody--even small business.  They associate the
different entries in your GL so that the software can better
manage all the reconcilation and settlement stuff automatically.

What would drop out the end of this website would be simple
little GL transactions that are PROPERLY classified for GAAP
natively instead of requiring expensive human classification.

The ebXML workgroups has already got at least two initiatives
underway which would provide free, open software specifications
for these futuristic "business process" engines.  Very cool stuff!

One is the Xtreme Ease-of-Implementation model in the BP workgroup,
http://lists.ebxml.org/archives/ebxml-bp/200011/msg00053.html
and the other is the Business Service Interface (BSI) in the
TRP workgroup.
http://lists.ebxml.org/archives/ebxml-tp/200010/msg00070.html

These are a sort of template or roadmap that guides not only
the money but management and movements of all the other resources
such as materials and shipping and tasks.

Accountants and GAAP experts should pitch in and HELP the ebXML
achieve accurate financial reporting outcomes from these
promising new software platforms.  In particular ebXML needs help
in clarifying the point of transaction recognition within the
CPA for legal and GAAP purposes, and, delivering those transaction
events in a suitable format for downstream work by accountants.

> Further, there is a well-established model for fair use,
> where copyrighted material is allowed to be routinely quoted in
> snippets and properly attributed or footnoted.  So the software could
> also avoid plagiarizing GAAP, by producing a partial fair "copy" or
> translation (snippet), footnoted, integrated with the client's data
> to which it is applied, not the whole manual.

Yes, that would certainly be helpful.  I call upon FASB to
unclench their copyright grip from **our** GAAP definitions,
so that they can be used within accounting systems to help
owners and employees report their transactions correctly.

More importantly, releasing the GAAP definitions is important
to help guide software developers in creating new, more modern
business software which would save *enormous* time not only at
the grunt, clerical level but also in middle management and
professional levels as well.  That's where a lot of the potential
economic savings could be made.  This will free those people (us!)
to work at higher economic value-added levels where we can
contribute more value and make more money.   (such as setting
up the CPAs and relationships at the beginning of the year
instead of sorting out the mess at end of the year.)

Not everybody will agree with me but I think the real key is to
get the small and midsized business creating better formed
transactions from the outset.  Transactions which are less
ambiguous, which create less liability for us and for the client
themselves.   I continue to believe this can only really be
achieved within a framework where both parties are looking at
the *very same transaction* when they hit <ENTER> and post the
transaction.

... etc. etc.

Say, what were we talking about anywayyy?

* Todd F. Boyle CPA    http://www.GLDialtone.com/
* tboyle@rosehill.net    Kirkland WA    (425) 827-3107
* XML accounting, webledgers, BSPs, ASPs, whatever it takes
* 12/11/2000- Functional Architect, Netaccount.com