[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tax] RE: [tax-tasc] Summary of XBRL GL discussion
Eric, and Marc, and anyone who feels that I have been a little
negative in my comments, let's put to rest any assumption that I am
either for or against XBRL or any variant thereof. My comments come
from a more practical place, and that is what are the key protocols
that should make up a compliance framework, and how does this framework
then get executed to fulfill a particular need (like the registration,
declaration or reporting, e-filing, settlement/payment, or the
regulatory bulletin payloads), and how will I then deliver it?|
So, does XBRL fit within this framework? Yes indeed and I do believe that to exclude such a protocol would certainly do our clients (taxpayer and tax authorities alike) a collective disfavor.
As to the payload question, my comments were based on several examples, and since, Marc had asked for some specifics, including, I do apologize for making them all transaction based tax examples, but that was the basis for my original argument:-
a) Fiscal declaration periods for sales taxes that are not the same as the corporate or management reporting financial systems fiscal close (4-4-5 in the grocery business and monthly or quarterly tax reporting in the US for instance)
- One could also argue a scenario where a company paying corporate tax by monthly installments based on actual results on a monthly tax calendar, there could potentially be a disconnect bt the two reporting calendars
b) movement of goods that are not accounted for but may represent a legal movement for tax reporting (but not liability) purposes
c) an annual turnover report on withholdings based on certificates issued, canceled, etc - again some of which will not have been accounted, such as a voided and re-issued or replacement certificate.
If XBRL-GL (a specific example in section 2.2 of the well articulated arguments from Philip Allen) is able, as ,Eric, you have mentioned, to accommodate these types of reporting requirements, be selectively removing or not using the accounting references, or extending the core model for additional data elements that a particular Tax Authority deems relevant, or replace a part of the XBRL-GL specification to include part or all of the CIQ standard as a reference model for parties, addresses, etc. If this is the case, then there is a very powerful argument for using XBRL as a key protocol for payload part of the compliance reporting supply chain.
Thanks for the feedback,
Alex: I must respectfully disagree with your assertion that "[t]he XBRL-GL assumption is that ALL roads lead to the general ledger and taxes or tax computations are based on an accounting view of the world". Perhaps you were exaggerating/oversimplifying for an effect? While a sophisticated general ledger system can potentially hold a tremendous amount of detail, 1) there is no promise that all of that detail will find its way there but lives in the sub-systems, 2) many of the documents and their related data in a business cycle do not find their way there at all although they are captured in other parts of the system ... 3) and I am not even sure on what basis you can say that the tax motivator is necessarily "the accounting view". XBRL GL is a generic representation of the documents, parties, resources, links to accounts, links to XML/XBRL elements for reporting, and other classifications that are put together in different combinations to represent transactions or other triggers of taxation as a generic audit trail. It represents through the existing modules some large portion of the fields collected in a typical transaction, and the "X" of XML/XBRL is extensibility. so it can be expanded upon for the specifics of transactions in other industries. Anything with monetary amounts or quantities that can be put to accounts or classification codes can be represented. Documents and transactions can be represented before "accounting"/assignment of accounts or classifications, if that's what "where accounting may not occur" means. <eccn /> Alex Fiteni <firstname.lastname@example.org> 04/13/2004 06:43 PM To Harm-Jan van Burg <email@example.com> cc firstname.lastname@example.org, email@example.com Subject Re: [tax] RE: [tax-tasc] Summary of XBRL GL discussion Some additional considerations...... While the corporate income tax domain may favor an accounting based audit approach, there are many jurisdictions that levy taxes on transactions at several points where accounting may not occur, or the accounting for such is handled much later than the settlement date. Such tax methods require reporting and settlement based on a tax reporting period, that may or may not coincide with an accounting period. The XBRL-GL assumption is that ALL roads lead to the general ledger and taxes or tax computations are based on an accounting view of the world, not a legislative view of the world - and this from an accountant no less!! While this may work for countries that tie the tax reporting and computations to a common accounting and tax reporting period definition, how can we respond to those taxation systems that do not? As well, there are times when a full disclosure of the facts of a transaction may be warranted, and the information in SAF and even XBRL-GL may not, indeed will not, be sufficient. Alex_________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.