Summary of XBRL boundary debate

[Andy Greener <andy@gid.co.uk>]

All,

During the conf call last week I undertook to revisit the discussion
thread about XBRL applicability and summarise the points and issues,
with a view to helping define a boundary around XBRL applicability to
direct tax reporting scenarios.

The text below is entirely draft in nature. Please feel free to comment,
correct or suggest alternatives, extensions, restrictions, etc. I have
tried to pick up on the salient points of the discussion - my apologies
if I've left anything out that you consider to be important. Now is the
time to speak up (or rather, write up!).


It was suggested during the conf call that there are three pertinent
sub-domains of tax reporting (ignoring indirect taxation and G2G):

1. Corporate reports and accounts
	- firmly covered by XBRL "VR"*

2. Corporate accounting transactions
	- covered by 'SAF' (one implementation of which might be XBRL GL)

3. "everything else"
	- personal direct tax and duties, non-accounting employment data, etc

[* "ordinary" XBRL has been described as XBRL "View Reporting" by the GL
folks to distinguish it from XBRL "General Ledger" auditing]


Auditing is a bit of special case which needs to be addressed separately,
so I'll leave that aside for now. The dividing line between 1 and 3 seems
to be at the heart of the matter.

There were several statements in the discussion thread about what XBRL
was, and wasn't, deemed to be good for, so I'll summarise those:


What XBRL is deemed to be good for:
-----------------------------------

Corporate financial reporting (as a subset of corporate business reporting)
and therefore by extension, corporate tax reporting.

Data sourced from accounting systems (implies corporate data? Also implies
both aggregated (report) and raw (audit) data).

Reporting data that can be re-used/re-purposed easily (implies multiple
business/regulatory/tax reporting requirements).

Data that is 'tabular' (at best) or unstructured in nature.

Data that is ultimately targeted at accountants (for assessment or
certification purposes).

Data that flows in a reporting chain, of which tax reporting is but one
step.

Data that may be audited (as raw) and/or reported (aggregated) separately
in time (i.e. re-used).


What XBRL is not deemed to to be good for:
------------------------------------------

Structured transactions ("transaction" is defined in the loosest sense
here, and isn't necessarily restricted to corporate financial transactions
that might be fodder for an 'audit' - it simply means some sort of update
or transfer of hierarchic - not necessarily financial - data).

Data where the 'vocabulary' & 'grammar' is an integral part of the structure.

"Serialised" objects represented as XML data structures (by "serialised"
I mean a byte-stream representation of an in-memory data structure or
object).

Data that is targeted at computer systems (i.e. application to application
transfer of "objects" or data structures).


Inferences
----------

At this stage I want to draw inferences from the above, not conclusions :-)
It's a little early for that!

The words "corporate", "accounting/accountant" and "re-use" seem to
figure prominently in first section, whereas "structure", "serialisation"
and "transaction" (in its loosest sense) figure in the second.

Here's a first attempt at putting that all together:

"XBRL is most suitable for re-usable corporate data extracted from accounting
systems and destined (at least in part) for assessment or certification by 
an accountant"

"XBRL is least/not suitable for application-to-application transactions
comprising structured, serialised data"

Perhaps these statements need to be tightened so that they are more
directly applicable to the tax domain? (our audience is tax administrations
after all).

Comments please!

	Andy

-- 

Andy Greener                         Mob: +44 7836 331933
GID Ltd, Reading, UK                 Tel: +44 118 956 1248
andy@gid.co.uk                       Fax: +44 118 958 9005