OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Feedback on the Standard Audit File (SAF)

Title: Feedback on the Standard Audit File (SAF)

1.  There are many similarities of structure and detail between the SAF and the "standard interpretation" of XBRL-GL as being a series of journal entries with a header, with each entry having a pointer off to an XBRL taxonomy element; geneaology or happy accident does not really matter; it's a good thing since they are known to work.  I think this expands the usability and flexibility of auditfile and SAF will be successful.

2.  The individual elements in SAF, unlike XBRL-GL, do not have their own individual context references; I believe this is perfectly sensible -- all of the 'context' needed to understand a given element in an instance comes from elements along its ancestor path.  In fact implementations of XBRL-GL so far, whether live or just demonstrations, often have successfully taken the same short cut, so it's hard to argue against.

3.  The SAF at this point does not seem to ground out in a Schema, although it is obviously quite close.  I think that one feature of XBRL that might be quite useful here is the overall structure of having a set of linkbases that provide additional information about each individual element that may be used in different applications -- the example most people having seen an XBRL presentation would be most familiar with being the "label" linkbases that provide a name for each element in several languages.

4.  Because there is no Schema yet (or I missed it... or missed this detail) it is not clear to me whether the intent is to allow child elements and attributes from other namespaces to appear in complexType elements.  I think that is important and I strongly recommend it.  The three additional modules of XBRL-GL 1.1 (saxon, multicurrency, and business) for example, add extensions that have been found necessary in real-life and multi-national settings that I don't see any close analogues of in SAF.

5.  The scope of the schema is on journal entries, which would appear to make it suitable for tax purposes.  If there is any ambition to use it more generally, I'd suggest that there should be a careful review to see where the Schema should define elements as types (even if they have initially just a single concrete member element) so that subsequent efforts can define new schemas for commonly needed data exchanges such as charts of accounts, customer and vendor masters, and so on, using different element names for clarity.

6.  One area of ambiguity concerns the need for customer-supplier identifiers at the line vs. the transaction level.  Are we positive that such a choice must be made?  It seems plausible to me that one could define a base type of line without the ID, and use that in a transaction that has IDs that apply to all lines it contains.  Then a different type of transaction is also included, based on extensions of those line types, and those have individual IDs.   Applications would know where to look for the ID simply based on the type of either element.  You could also put IDs in both places if you really want to get into inheritance and override semantics, but I think having the two options would work fine.

Walter Hamscher | www.hamscher.com | Chair, XBRL International Steering Committee | Consultant to PricewaterhouseCoopers

Disclaimer: while I don't have anyone specifically in mind when I say this, I just want to be clear that I am not offering here an official 'XBRL International' position nor an official PwC position.   That said, I do believe that most people in both of those organisations would tend to agree with the above observations.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]