|
公司反对审计师验证的原因之一是由此产生的额外费用，即它们将不得不在XBRL兼容软件、相关咨询及培训方面有所投入。
带点调侃地说，如果某人在他人的工作中发现了错误，这通常被称为“批评”，而在软件世界里，这种情况叫做“软件测试”。软件测试工程师是非常重要的资源，他们的任务就是从无数个由软件工程师编制的字节组成的代码中检测软件缺陷。
可扩展商业报告语言（XBRL）是最新一代的软件语言，可被计算机理解。拥有超过5千万卢比实收资本或超过10亿卢比营业额的印度上市公司、其驻外和当地分公司及所有公司只剩下不到90天的时间来使用XBRL格式报送2010-2011年度法定申报表。
印度公司事务部（MCA）携手印度特许会计师协会（ICAI）已经为XBRL做好了所有准备工作。报送方面，也发布了一套分类标准和商业规则。在pdf/excel/word/格式文件与XBRL文件之间充当翻译角色的XBRL验证工具也将很快推出。
验证XBRL
活动期间，MCA已表示将规定由法定审计师来验证XBRL报表。给出的表面理由是MCA工作人员对技术还不够精通，无法理解计算机可读的报表。然而，审计师可能会用同样的语气回答,他们其实也不是很懂。众所周知，财务报表是由管理层负责的，而审计师的责任就是对这些报表发表意见。
一旦审计师发布了报告，并且在财务报表的虚线上签名，他的责任就终止了。在向监管机构报送的文件中出现的不一致能否被追溯到审计师是一个颇具争议的话题。随法定审计报告一起发布的还有一份避风港声明：本报告基于我们所获得的信息和说明制作完成。在公司未审计财务报表中也可以发现类似声明。这些财务报表报送给监管机构，并在公共领域发布，随附一份说明显示这些报表已被法定审计师审核（如果确实被审核）。但审核比全面审计验证的范围要小很多。
说到底，审计师可以表态他们已经审核了XBRL报告。不少公司反对审计师验证的原因之一就是这项工作将牵涉到额外成本，它们将不得不在XBRL兼容软件、咨询及培训上有一定的投入。虽然最好还是留给管理层去核实XBRL财务报告，但是管理层很可能会从软件供应商那里获得延续认证。
尽管在向XBRL标准过渡期间产生的初期费用将不可避免，但一旦大批实体转向XBRL阵营，这些费用会就会稳定下来。XBRL向软件供应商提供了一个绝佳机会，即在云计算平台上建立商业运用程序，提供“软件即服务”（SaaS）。说起法定审计师为XBRL报表真实性作担保的例子，在全球范围内似乎都不太多见。
XBRL中的错误
XBRL报送中出现错误的可能性很小，但也是存在的。业务规则中提供了一些验证性检查，确保不会出现显著差异。比如，在一条业务规则中，流动资产净值是一个强制性字段，因此不能留空。XBRL分类标准可能不会为某个特殊实体设置一个特别列项。为这个特殊实体添加标签可能会出现问题。在这种情况下，该实体不得不使用最适合的选项，将其标记到分类标准中与其属性相似的一项。MCA已明确表示当前的分类标准将会得到扩展。
大多数XBRL软件产品有逆向工程工具，通过该工具，XBRL报送文件可被翻译成为普遍使用的、熟悉的文件。公司可以考虑初步使用XBRL编制内部报告，这样就可以在监管报送前把所有可能出现的困难解决掉。基于这一点，在到期日前，MCA可能会考虑安排一次XBRL试运行报送，解决一些可能会出现的问题。如果发现问题太多，MCA可能会允许在今年同时采用新老方式进行报送，明年再过渡到XBRL报送。这也是从会计软件包过渡到企业会计系统时普遍运用的一项策略。 |
