财务报表附注规范表述现状与建议.docx

财务报表附注规范表述现状与建议2010-3-31 11:51欧阳电平周舟【大 中 小】【打印】【我要纠错】XBRL（可扩展商业报告语言）作为互联网上财务报告的信息标准及会计信 息处理技术已经历了10余年的发展历程，目前在发达国家正得到广泛和深入的应用。XBRL分类标准是对财务报告（或商业报告）文档进行描述和分类的系统， 同时也是一个解释术语的字典。建立XBRL分类标准的前提是定义用于交换的财务信息元数据，包括财务报告中有关财务和非财务的概念。创建XBRL分类标准 有两种方法：规范性方法，即应用XBRL规范对现有会计准则与制度进行解释而生成分类文档；实证性方法，即从大量的具体财务报告中发现规律的方法。我国会 计准则严格规范了财务会计报表的 披露，对财务会计报表分类设计所需要做的就是将这些规范以XBRL的形式实现，适宜规范性方法，并且这种“翻译”工作的难度和工作量都是有限的。而会计准 则对报表附注的披露给出的是范围和原则，要从中提取公认的概念，并保证有效、正交和完整则非常困难，创建报表附注分类标准的工作量巨大，并且不同行业附注 的内容和信息结构有所不同，适宜采用实证方法。由于XBRL财务报告仅仅是现有财务报告的另一种载体表达规范，因此，建立XBRL分类标准的依据仍然是会 计准则与会计制度。笔者根据XBRL国际公布的建立分类标准的六个步骤：财务事实来源、结构、收集数据、输入、更正、输出，选择了我国上市公司房地产行业 2007年年报中的销售与收款业务相关的报表附注进行了分析及其分类标准创建的实验。根据上交所和深交所公布的年报信息，已上市的房地产企业72家，剔除 了2家2007年转型的，选择了70家样本。由于报表附注承载着财务报表以外所需披露的大量的变动的财务与非财务信息，而会计准则和制度对披露的内容和格 式仅仅作了原则性的要求，无论是从披露的内容还是表述上给出的弹性都很大，因而要制定报表附注的XBRL分类标准非常困难。但通过对会计准则中报表附注规 范表述的讨论，以及对上市公司报表附注的部分内容制定XBRL分类标准的实验，仍可为制定XBRL报表附注的分类标准及其推广应用提供启示与建议。 一、国内财务报表附注规范表述现状 （一）报表附注披露内容存在公司偏好性制定报表附注的XBRL分类标准，首先要确定哪些概念（术语）可以作为分类标准的元素，或者说报表附注要提供哪些标准化的“信息材料”以满足信息使用者的需求。我国企业会计准则 和上市公司信息披露电子化规范规定的披露内容是制定分类标准基本元素的依据，而对于没有强制要求或公司可扩充的披露内容，则要从大量的具体财务报告中 发现规律。通过对70家房地产企业的报表附注进行统计分析，发现公司对附注披露内容的各自偏好性很大，要在附注中提取公认的概念作为分类标准的元素，并保 证其有效、完整和一致，有很大困难。如企业会计准则对“营业收入”的注释仅要求披露“主营业务收入”和“其他业务收入”的本年（期）发生额及上年 （期）发生额。而统计显示：ll家企业按照业务、地区等披露营业收入而不区分主营业务收入和其他业务收入；7家企业披露主营业务收入和其他业务收入金额的 同时，按照行业、地区等披露营业收入金额；3家企业按照行业分别披露主营业务收入和其他业务收入的金额：17家企业按照行业和地区分别披露主营业务收入和 其他业务收入的金额。另外，对行业、地区、业务的分类定义也各有不同。表1是报表附注中对收入部分增加披露的信息元素的部分统计。“公司偏好性”是一种对 报表数据侧重于利己的注释，是普遍存在的现象。 （二）报表附注中术语（概念）使用的不规范性定义元素名称及其具有的属性，以及元素的内外部关联关系是制定XBRL分类标准的重要环节，元素名要能唯一 表达一个财务信息概念，必须规范和统一，以便计算机程序处理不产生二义性。如应收账款、应收账款账面余额、应收账款净值是三个不同的概念，纸质的财务报告 中经常混用“应收账款”术语，读者通过上下文的语境可以区别和理解，而XBRL分类中则必须定义为三个元素，并正确标记。通过对这70家上市公司报表附注 的统计分析发现：附注中运用的财务术语（概念）很不规范，有些术语是准则中没有明确区分（如资产负债表中的“应收账款”表达的是应收账款净值），有些是与 行业相关的报表附注中术语的定义问题，有些财务报告中没有注释，更多的是企业使用的习惯性表述，这些给元素命名带来很大障碍。表2是统计分析的销售与收款 业务有关附注中部分财务术语名称的使用情况。 （三）报表附注中表格注释的不规范和不一致性XBRL分类标准中有两类元素：数据项和元组，表格一般属于元组元素。元组元素要进一步拆分成信息元素，并 且要准确定义这些信息元素的名称、语义、层次结构、元素的内外关联关系等。附注中的表格格式的规范和统一涉及到XBRL格式的信息单元的语义的一致性、信 息的可比性，以及信息的可汇总性。报表附注中运用了大量的表格对财务报表项目注释，或对需要报告的表外项目进行说明。而企业会计准则应用指南 仅仅给出了最基本的注释表格的格式，导致各上市公司报表附注表格披露信息的不规范和不一致。如对应收账款注释仅仅给出了“账龄分类表”（账龄结构、期末账 面余额、年初账面余额）和“客户类别分类表”（客户类别、期末账面余额、年初账面余额）的简单结构，而对账龄结构和客户类别如何划分则没有给出说明。在对 70家上市公司报表附注的统计分析中，存在着大量的表格注释内容和深度不一致的现象。如账龄结构按1年以内（含1年）、1至2年（含2年）、2至3年（含 3年）、3年以上披露的企业占53；按1年以内（含1年）、1至2年（含2年）、2至3年（含3年）、3至4年（含4年）、4至5年（含5年）、5年以 上披露的企业占20；还有其他不同深度的分类披露。另外，对分类的基点没有规范。如有63家企业按地区披露主营业务收入，其中40家以“市”为单 位，10家以“省”为单位，5家以“华中”“华南”等地区为单位，还有以“省内省外”为单位等。附注中表格格式的不规范和不一致与企业的规模、管理模式， 以及“公司偏好性”等有关。 二、研究结论与建议 （一）规范的会计术语表述习 惯与制定XBRL分类标准可以相互促进由于创建XBRL财务报告分类标准仅仅是根据企业会计准则将现有财务报告按XBRL格式规范表述，因此，企业 会计准则与纸质财务报告自身的规范表述是制定XBRL分类标准的基础。我国的企业会计准则作为会计信息生产与提供的规范，主要体现在会计确认、计量 和报告的原则与规范上，解决了会计信息的采集和加工的规则与方法，以及企业财务报告的内容、结构和质量标准等。在制定分类标准的实验中发现，企业会计准 则中最规范的表述主要体现在会计报表披露的内容和结构上，对会计术语的表达本身并不规范。如企业会计准则基本准则第十章财务会计报告第四十四条中表述：财务会计报告包括会计报表及其附注；而企业会计准则第30号一财务报表列报 则表述成财务报表。虽然，人们能读懂此处的“会计报表”和“财务报表”这二个术语表达的是同一个事物（或概念），但XBRL分类标准中术语（概念）名必须 唯一。由于人们长期以来习惯表述达成的理解默契（本文也没有区别财务报告和财务会计报告），企业财务报告中会计术语表达的随意性较大，通过制定XBRL分 类标准，可以再一次界定和准确使用会计术语，使会汁真正成为会计信息生产、提供和表述的规范语言。 （二）按行业成分XBRL组织，规 范财务报表附注的表述，建立分类标准XBRL作为一种可扩展的商业报告语言，实行三层分类体系：国家标准分类体系、行业标准分类体系、企业标准分类体系。 前两者由国家或行业的权威性组织根据XBRL技术规范制定。这种自上而下的机制可避免“各自为政”的情况，避免产生新的信息壁垒，便于电子化报告数据的流 通、交换和共享。我国新的企业会计准则是国家标准，适应于所有行业，从这个层面看，XBRL财务报表附注分类标准属于国家标准分类体系制定的范畴。然 而，报表附注注释的内容、术语、明细分类、汇总指标等都因行业不同有很大的区别。如房地产行业的销售收入可以按房地产销售、物业管理、房地产租赁等分类， 而机械制造业则不同。XBRL作为一种语言规范，其分类标准体系所表述的概念（信息元素）要便于行业内进行比较分析等。因此，笔者建议，在国家XBRL财 务报告分类标准制定原则的指导下，按行业成立XBRL组织，对行业的财务报表附注涉及的所有内容、格式，以及术语（概念）的名称和实质等进行规范表述，按 行业建立XBRL报表附注分类标准。2003年，我国证监会出台了上市公司信息披露电子化规范，规定电子文档中重要信息的数据化过程，以及建立分类标 准时需要使用的命名空间规范、信息文件命名规范、元素命名规范、数据元属性规范、实例文档命名规范等。这些也是创建行业XBRL报表附注分类标准需要遵循 的。 （三）规范报表附注披露的内容与表格结构规范报表附注披露的内容和表格结构其实质是信息使用者将能从报表附注中获得哪些“信息材 料”。这也是目前XBRL分类标准制定中经常讨论的“信息粒度”问题，粒度太粗则信息损失，太细则信息可比性损失。从对70家上市公司财务报告中报表附注 披露的内容与表格结构来看。都在企业会计准则要求披露的基础上进行了大量的扩展。虽然扩展的程度有所不同，但由于行业业务的相近性，以及通用财务报告 中信息供应的有限性，对附注披露的内容和表格的结构按行业进行规范和确定是可行的。当前的问题关键不在于“信息粒度”，而是需要有权威的部门来组织和指 导，制定原则；会计理论和实务工作者要立即行动，从会计信息使用者需求的角度进行确定。 尽管XBRL发展历程不长，但作为互联网上一种新的企业财务报告的信息标准和会计信息处理技术，由于其广阔的应用前景，将加速推进XBRL的存储、安 全、传输等技术的发展与完善。然而，我国会计理论和实务界对此还没有做好准备。首先是大家对此还很陌生，无论是大学的课堂，还是会计实务界都没有推广普及 XBRL应用知识。其二，XBRL既是一种新的财务报告表述语言又是一种新的会计信息处理技术，需要了解其技术知识同时要掌握其应用知识，否则容易对其产 生距离感和恐惧感。其三，XBRL格式的财务报告作为标准化的“信息材料”必须规范其生产、存储、传输、使用的整个供应链环节，对管理提出了更高的要求。 其四，XBRL的应用需要企业的投入，包括软硬件成本、人员培训成本、信息管理成本等，在企业还不了解XBRL的应用能给其带来多少收益时，态度也就不会 是积极的。一项新技术的应用有一个认识和推广的过程。只要不排斥它，积极应对，有宏观政策的引导，就能够跟上国际上XBRL发展和应用的步伐。而从信息技 术迅猛发展的速度来看，XBRL格式的网络财务报告即将来临。 本文系湖北省科委自科基金项目“XBRL在企业信息披露中的应用研究（2t）07ABAl78）”阶段性研究成果 参考文献： 1陈彦：XBRL格式财务报告的分类标准研究，武汉大学硕士论文2009年。 2查尔斯。霍夫曼著，财政部会计准则委员会组织翻译：XBRL在财务报告中的应用，中国财政经济出版社2008年版。别人总觉得是在显吧，干脆把这个项目认为是小项目了，不知道把这个项目是小了，别人会不会又觉得又显吧了？说大也不行、说小也不行，也的确没招了。我想主要把项目里遇到的问题分享给大家一起探讨，也并不是为了什么显吧什么的，希望大家用一个正确的心态阅读此文章，希望有更多的朋友把更大软件项目的经验分享给大家，让大家知道一下，大型软件项目里都会遇到什么问题，如何解决才好，我们平时做些什么准备工作比较好？ 有的时候20个功能模块，也并不能代表工作量有多少，其中有一个模块是进销存，有一个模块是工程管理，就这么2个模块就可以足够搞死人了，一个完整的进销 存要多少功能？多少开发量？一个相对完整的工程管理模块，有多少工作量？所以模块的数量也并不能代表整个项目的工作量，只是一个参考而已。【一】行业知识积累、开发积累方面 01. 无行业知识积累 - 哪个行业，都有哪个行业的一整套的业务流程、业务逻辑，这些业务能充分的理解、深入的分析，都需要一个过程，不是一天两天就可以搞定，就成为行业专家了。 02. 没有稳定的开发平台积累 - 开发一个大型的软件项目，往往需要一个稳定的开发框架，若没有稳定的框架、又要组织一大堆人来开发软件项目，阵脚很容易乱套，整个项目也容易凌乱，而且一 个稳定的开发平台的积累，也是需要一个过程，除非是有顶尖高手能把以前的积累贡献出来，例如B/S的网页框架、添加、修改、列表、分页、查询、打印等等的 一个规范的处理模式。【二】建建设、分工协调方面 03. 团建建设匆忙 - 就像一个足球队，不是1天2天就能建设好，一个分工明确、工作效率比较高的团队不是那么短时间就可以组件好的，都需要一个磨练的过程。 04. 开发人员不稳定 -哪个IT公司，人员稳定的，都比较难做到，往往项目里的一些员工眼看着就要辞职什么的，心都没在工作上，怎么可能做出像样的程序模块呢？ 05. 人员配备不足 - 哪个公司也不会在没有固定项目的前提下，白养着一大帮人，老板也承受不了这样的风险，IT软件人员的开支相对比其他行业高一些，例如洗脚店。 06. 没有测试人员 - 软件项目，没有测试人员，就是丰田车子一样，虽然看上去很美好，但是很多问题，没有充分测试好，开发人员天天看着自己的程序，也麻木了，一般找不出自己的问题。 07. 没有美工配备 - 现在用户的要求也都比较高，光靠程序员总难做出漂亮的页面，功能再强大，美工设计不过关，还是比较难让客户满意。 08. 资深开发人员太少力量不足 - 虽然开发人员有好几个，但是大多数是菜鸟，一般对项目的推动力够，进展缓慢，虽然资金上是省了一些，但是周期会拉很长，资深的开发人员要价高一些，虽然眼前有项目，但是项目开发好了，这些人干什么？辞退？若不辞退，没几个月公司就耗不起了，人员开支太大了。【三】开发过程方面 09. 客户的要求也不简单 - 现在能搞百万级的软件项目的公司，一般也不是菜鸟公司，也很有想法，管理也是蛮有套路的，你开发的软件，必须要能经得起客户的折腾，很多很多细节也不是对 付就可以了，一对付，客户也不让啊，满足客户的N多需求，就不像是20个功能模块那么简单，甚至是开发200个模块一样难。 10.配套设计、配套文档跟不上 - 虽然客户要的是软件功能，但是还有很多环节，例如项目的验收、付款等等，都需要有配套的文档，配套的设计文档，人员之间的交流，也需要很多文档，开发人员 往往不善于写文档，这当然也跟我们的水平有关系的，再加上项目费用控制，又无法招聘N多的人员来写配套文档，连最底的正常工作使用上的测试环节也不过关， 更难写配套的文档了，文档一整理，一个人花费了几个月了，打印出来就是上千页，每次更新、调整，都需要很多精力花费在这个上。【四】项目管理方面11. 项目资金到位不及时 - 一般大的软件项目，资金及时到位都不容易，项目又经过了好几手，往往需要一个比较长的周期，这时项目的前期就无法有充足的资金去分配，无法招聘到合适的开发人员，项目的进展也会缓慢一些。 12.管理与开发脱节 - 一般这样的项目是异地开发，公司的领导又不会亲自到现场去管理，往往是在异地进行指导管理，领导有领导的想法，领导有领导的做法，但是实际项目有实际项目 的困难，一般领导的指挥与决策与实际项目的情况有些脱节，甚至为了满足领导的项目，大家还需要折腾一些额外的事情，很累。 13. 指手画脚的人也多 - 这么大一个项目，各级领导都有独特的意见建议，项目承包放的意见建议、项目承建方领导的意见建议，其实绝大部分人只是嘴巴上说说，对项目几乎没有实质的价值，因为干活都需要我们自己来干，他们又不会指点细节、解决难题的，基本上都是官场上的应付。 14. 项目经理的沟通协调不过关 - 若项目经理负责的事情过多了，他精力也会被分散，很可能会抓不主重点，例如，项目的架构是这个人负责，项目的难题解决这个人负责，项目的美化也这个人负 责，项目的人员招聘也这个人负责，反正项目里的，能负责的，都这个人负责了，往往跟领导的沟通会被淡化，与客户的沟通也会被淡化，因为精力是有限的，用在 别的地方过多了，沟通协调上就容易出问题了。【五】项目工作量、难度评估方面 15.项目的难度、工作量评估不准- 往往项目的前期，就看那么20个模块，每周做一个模块，5个人来做的话，不是1个月就可以搞定了吗? 那我给你4倍的时间，4个月总可以了吧？听听也是有道理，给了4倍的时间，其实，问题出在“每周做一个模块”上，其实每个月做一个模块都难，项目的难度复 杂度被低估了，评估项目的复杂度，往往也有一些方法，但是更可靠的是项目经验，例如我们老板亲自评估往往能估得更准一些。 16. 小项目能做得又快又好未必大项目能做得好 - 小项目的要求都很低，甚至是文档都不需要，但是大项目，不只是工作量大，复杂度、需要协调沟通解决的事情会是很多很多，各种细节的处理要求等等都会超出小 项目很多很多，例如10个项目的难度、工作量，很可能没一个大型项目的工作量高，是需要在能力上的质的突破，不只是量的突破。 17. 项目除了软件开发，还需要其他很多环节 - 例如我们开发好，给客户确认时，往往客户又有其他事情在忙，等客户不忙了，我们又在忙修改错误，所以一个不成熟的东西，想真正做好，前期的准备工作上往往 需要投入巨大的人力物力，否则，跟客户的沟通确认的周期就你无法想象的漫长，因为你忙时客户空，客户空时你忙，甚至是你忙时客户也忙，所以项目的周期往往 被没有经验的开发人员评估得很短，实际上需要一个漫长的过程，小公司很容易被耗死。【六】薪酬待遇方面 18. 项目很容易进入恶性循环 - 项目没能按时完工，客户的款不会按时支付，公司的费用控制会严格，各种项目中的开支都不会按时发放，甚至会进行制裁，例如6个月的