银行询证指南

银行审计函证数据标准指南

为进一步规范银行审计函证及回函工作，维护金融市场秩序，稳步推进银行函证数字化、标准化建设，财政部遵循《可扩展商业报告语言（XBRL）技术规范》（GB/T 25500-2010）系列国家标准，研究起草了《银行审计函证数据标准》（以下简称“函证数据标准”）。函证数据标准是一种计算机可执行的XBRL分类标准，在语法（技术规范）上遵循XBRL技术规范系列国家标准，在语义上遵循《银行函证及回函工作操作指引》（财办会〔2020〕21号），以银行询证函标准格式为基础，反映了银行询证函承载的全部信息，以便会计师事务所和银行在信息化条件下集中统一地处理函证业务，进一步提升函证程序的质量与效率，推动函证方式方法与实现路径的变化。为方便使用函证数据标准，我们起草了函证数据标准元素清单和本指南。

本指南作为函证数据标准使用和实例文档解析的说明文件，应与元素清单配套使用，旨在帮助具备一定XBRL知识的使用者了解函证数据标准的架构、内容以及实例文档的要素和解析方式。上述使用者包括银行、会计师事务所、第三方数字函证平台、被审计单位和相关软件开发者等。

一、      函证数据标准涵盖的内容

函证数据标准对《银行询证函》中的信息进行了XBRL标记，表1列示了函证数据标准标记的所有字段。

表 1：函证数据标准标记内容

二、      函证数据标准的架构

函证数据标准的架构分为逻辑设计和物理结构两个层面。逻辑设计是指以XBRL语言反映《银行询证函》的内容信息。物理结构是指函证数据标准的各文件和文件夹的层级设计与组织方式。

（一）逻辑设计

函证数据标准的逻辑设计具体如下：

1．元素

函证数据标准中的元素是依据GB/T25500-2010《可扩展商业报告语言（XBRL）技术规范》系列国家标准，根据《银行函证及回函工作操作指引》规定的标准格式中包含的信息提取的，用于定义和描述《银行询证函》披露的会计概念和业务概念。函证数据标准中使用的概念（元素）总数为172个。

函证数据标准使用了GB/T25500-2010《可扩展商业报告语言（XBRL）技术规范》系列国家标准所定义的3类元素（替换组）：数据项（Item），超立方体项（HypercubeItem），维度项（DimensionItem）。表2列示了函证数据标准中3类元素的使用情况。

表 2：函证数据标准使用的元素种类（替换组）

（1）元素属性

函证数据标准中的每项元素都包含一系列属性。图1以“账户名称”为例列举了部分元素属性：

图 1：函证数据标准中元素“账户名称”及其属性

函证数据标准元素的部分重要属性如下：

① 元素名称（element name）

元素名称以元素的英文标准标签为基础确定，遵循“驼峰规则”（Camel Case），以便计算机识别。例如，“账户名称”的英文标准标签是“Name of bank account”，元素名称应该是“NameOfBankAccount”。

② 元素ID （element ID）

元素ID是函证数据标准中所使用的每一个元素的唯一编号。元素ID的结构是：{函证数据标准的命名空间前缀_元素名称}。

③ 时期类型（period type）

如果元素用于表达存量概念，时期类型应设为“instant”（时点）；如用于表达流量概念，时期类型应设为“duration”（期间）。所有抽象（abstract）元素、表（table）元素、轴（axis）元素的时期类型都是“duration”，其他元素的时期类型为“instant”，以便于对实例数据的标记。

④ 数据类型（type）

函证数据标准的数据类型属于标准数据类型，即XBRL国际组织发布的、国际通用的数据类型。函证数据标准共使用了8种标准数据类型，具体如表3所示。

表 3：函证数据标准使用的标准数据类型统计及举例

（2）函证数据标准中使用的重要虚元素

在根据函证数据标准编制的实例文档中，大部分元素都可被赋予事实值，称之为“实元素”；另一部分元素没有事实值，其作用是用来组织实元素间的关系，称之为“虚元素”。下面列举了函证数据标准中部分重要虚元素的用法。

① 抽象（abstract）元素

抽象元素用于组织列报链接库中元素的展示层级。所有抽象元素的“abstract”属性都应设为“true”，时期类型为“duration”。

② 轴（axis）元素和表（table）元素

轴元素和表元素的“substitutionGroup”（替换组）属性与其他元素不同，分别是“dimensionItem”（维度项）和“hypercubeItem”（超立方体项）。它们的元素数据类型都是“stringItemType”（字符串型），时期类型都是“duration”（期间型）。为满足《银行询证函》的披露需求，函证数据标准定义了表元素，并在其下设置了与之相配的轴元素。

（3）元素标签及后缀

在函证数据标准中，同一个元素可有多个标签，其中至少有中英文标准标签各一个。英文标签只有第一个单词的首字母以及缩写词要求大写。一些特定元素的标准标签还必须增加标准后缀，具体如下：

① [abstract]：所有抽象（abstract）元素的标准标签后缀；

② [table]：所有替换组属性是超立方体项的表（table）元素的标准标签后缀；

③ [axis]：所有替换组属性是维度项的轴（axis）元素的标准标签后缀。

2．扩展链接角色（ELR）

（1）扩展链接角色的定义

扩展链接角色（ELR）是一组可被视为一个整体进行处理的银行询证函信息关系的标识符。

（2）扩展链接角色的统一资源标识符（URI）的定义

在设计扩展链接角色时，函证数据标准依据GB/T25500-2010《可扩展商业报告语言（XBRL）技术规范》系列国家标准的规定，为扩展链接角色定义了统一资源标识符，统一资源标识符的定义遵循以下模式：http://xbrl.mof.gov.cn/role/yyyy-mm-dd/{“编码”}。

其中，yyyy-mm-dd为函证数据标准的版本日期；“编码”表示扩展链接角色的6位编码，便于计算机识别及检索。

函证数据标准在定义扩展链接角色的6位编码时，遵守了财政部《企业会计准则通用分类标准指南》中的特定的编码规则，具体如表4所示：

表 4：扩展链接角色编码及其对应的数字或字母含义

3．维度

维度是用来对存在维度结构的表格进行建模的一种XBRL技术。函证数据标准使用了类型化维度（Typed dimension），即域成员不能在函证数据标准中逐个枚举的维度，适用于在一张表中有结构相同的多行或者多列、但具体行列数无法事先确定的情况。类型化维度的xbrldt:typedDomainRef属性不能为空，该属性所指向的元素的数据类型为类型化维度域成员的数据类型。关于类型化维度域成员的定义要求，可参考“三、实例文档要素及解析方式说明”。

函证数据标准在两种具体场景下使用了类型化维度。一是函证编号，可以为询证函中的所有信息项增加维度信息，作为每一份数字询证函数据信息的唯一标识。二是自然序号，可以给同一类询证项目信息增加行次维度，满足同一类询证内容多条记录的同时披露。

（二）物理结构

从物理形态上来看，函证数据标准是一个电子文件包，文件结构如图2所示：

图 2：函证数据标准的物理文件结构

1．物理结构的组织方式

函证数据标准以《银行询证函》为基础组织文件结构，图3显示了函证数据标准文件夹及相关内容。

图 3：函证数据文件夹及其内容

2．文件夹和文件结构说明

函证数据标准文件夹和文件结构及其内容的具体说明如下：

（1）根目录是函证数据标准文件的根文件夹，以函证数据标准版本日期命名。试行版标准的版本日期为2020年12月31日。

（2）adds-on是存放函证数据标准引用的XBRL标准数据类型文件的文件夹。

（3）con-yyyymmdd.xsd是函证数据标准的模式文件，元素及扩展链接角色均存放在该文件中。

（4）con-yyyymmdd_pre.xml是函证数据标准的列报链接库。

（5）con-yyyymmdd_def.xml是函证数据标准的定义链接库。

（6）con-yyyymmdd_gla-{cn|en}.xml是定义扩展链接角色中英文标签的链接库文件。

（7）con-yyyymmdd_lab-{cn|en}.xml是定义元素中英文标签的链接库文件。

3．绝对路径和相对路径

为便于使用者定位函证数据标准中的模式文件和链接库等文件，函证数据标准采用了绝对路径和相对路径两种定位方式。函证数据标准对XBRL标准数据类型的引用，采用绝对路径引用的方式，直接指向国际XBRL技术规范；函证数据标准内部各部分之间的引用，采用较为便捷的相对路径的方式，无须过多考虑文件的存储位置。

绝对路径的形式即为定义XBRL标准数据类型的地址。例如，要定位数字型数据分类标准模式文件时，其路径为：

http://www.xbrl.org/dtr/type/numeric-2009-12-16.xsd

相对路径以函证数据标准模式文件所在目录为当前目录，表5列举了部分函证数据标准文件的相对路径：

表 5：函证数据标准文件的相对路径举例

4．命名空间

为便于使用者辨认特定版本数据标准所定义的元素、类型和关系，函证数据标准中包含了命名空间。函证数据标准命名空间即“http://xbrl.mof.gov.cn/taxonomy/2020-12-31/con”，命名空间前缀为银行询证函（confirmation）的缩写，即“con”。

5．模式文件

函证数据标准使用模式文件定义元素、扩展链接角色等对象，文件后缀为“.xsd”，根据银行询证函内容确定的元素及扩展链接角色均存放在该文件中。

6．链接库

链接库是用来定义元素间关系的文件。函证数据标准使用了3种链接库：列报链接库（Presentation linkbase）、定义链接库（Definition linkbase）、标签链接库（Label linkbase）。

（1）列报链接库

列报链接库用来定义元素与元素在列报上的层级关系和顺序关系。为了确保列报层级的一致性和元素间关系的连续性，函证数据标准在列报链接库的每一个扩展链接角色（ELR）中，都设置了一个抽象概念作为父元素。

（2）定义链接库

定义链接库用来表示元素间的定义层关系，如一般与特殊、原名与别名的关系等。函证数据标准中的维度关系也在定义链接库中表达。

（3）标签链接库

标签链接库用来表示元素及其显示名称间的对应关系，以将元素与人们更容易阅读和理解的名称联系起来。函证数据标准同时使用中文、英文定义元素标签。在确定标签时，遵循可读、简明、一致的命名规则。

同一个元素可能有多个不同标签，在同一种语言下每个标签有唯一的标签角色。标签角色规定了相应元素在特定情形下应当显示的恰当标签。函证数据标准使用的标签角色及说明如表6所示。

表 6：标签角色及说明

三、      实例文档要素及解析方式说明

实例文档作为《银行询证函》结构化数据的载体，不仅包含了数据本身及其与函证数据标准元素之间的对应关系，同时也包含了数据相关的属性信息（如数据所属时间、单位等），这些信息使得标记数据能够与业务场景紧密关联起来

实例文档共包含五类内容，分别是根元素（xbrli:xbrl）、数据标准引用（link:schemaRef）、事实值（fact）、上下文（context）和单位（unit），使用者可结合三个要素的具体信息来进一步理解实例文档。

（一）根元素

实例文档根元素的标签名是<xbrli:xbrl>，根元素标签的属性是实例文档所引用的所有命名空间信息，其中也包括函证数据标准前缀con，具体如下表7所示：

表 7：函证数据标准标记内容

（二）数据标准引用

每一份实例文档都是基于一套数据标准编制的，数据标准是解析实例文档的基础。在根标签中，使用<link:schemaRef>标签定义实例文档对数据标准文件的引用，通过“xlink:href”指向引用数据标准的相对地址：

<link:schemaRef xlink:type="simple" xlink:href="con-20201231.xsd"/>

（三）事实值

事实值就是《银行询证函》版面信息填写的内容，例如对于“银行账号”这个项目，其事实值就是银行账户的账号信息。通过为元素赋值，并指定上下文、单位和精度属性，来完成对于事实值的完整定义。赋予实例文档的事实值可为数值（金额、十进制数字等）或非数值数据（字符串或者转义文本，例如XHTML格式内容）。事实值也可为日期类型和时间类型。表8列示了部分事实值。

表 8：事实值举例

1．数值型事实值

数值型事实值的定义，除了通过contextRef指向一个预定义的上下文（context），还会通过unitRef指向一个预定的单位（unit），并通过事实值的decimal（小数点后位数）属性表达数据的精确度，图4是“银行账户余额”对应的事实值定义信息：

图4：数值型事实值定义方式示例

2．非数值型事实值

非数值型事实值的定义，是将事实值赋予给对应的元素名，并通过contextRef指向一个预定义的上下文（context），图5为“账户名称”对应的事实值定义信息：

图5：非数值型事实值定义方式示例

（四）上下文

每个事实值都会通过contextRef属性赋予的上下文ID指向预定义的上下文（context）。通过指定上下文，才能够确定事实值的具体含义。

上下文要素包括：实体信息（entity）、时期信息（period）和场景信息（scenario）。在根标签下，使用使用<xbrli:context>标签定义元素数据的上下文信息，下设子标签<xbrli:entity>、<xbrli:period>、<xbrli:scenario>，用于标记上文所述的实体信息、时期信息和场景信息。

1．实体信息

实体信息即指实例文档数据的发布者信息，使用标签<xbrli:entity>标记。在银行询证函中，使用被审计单位的统一社会信用代码作为实体的唯一标识码，在<xbrli:identifier>标签的文本中标记。

2．时期信息

时期信息是指事实值所对应的日期或期间，使用标签<xbrli:period>标记。在银行询证函中，期间类型为时点型的，使用<xbrli:instant>标签表示，统一采用yyyy-mm-dd的日期格式。期间类型为时段型的，使用<xbrli: startDate>标签和<xbrli: endDate>分别表示期间的起始日期和截至日期，同样采用yyyy-mm-dd日期格式。

3．场景信息

场景信息是基于维度的上下文需要定义的信息，一般包含涉及的轴（axis）和域成员（member）信息，使用标签<xbrli:scenario>标记。

维度信息可以进一步分为明确维度和类型化维度，场景信息中涉及的所有域成员都已在函证数据标准中明确定义了上下文的为明确维度；场景信息中涉及的所有域成员只能在实例文档中定义的上下文为类型化维度。函证数据标准中定义了类型化维度，即“函证编号”和“自然序号”维度，和明确化维度，即“询证项目”和“被审验单位类型”维度。“函证编号”域成员的取值就是询证函的唯一编号，“自然序号”域成员的取值就是同一询证项目下每条记录的行次，“询证项目”域成员的取值就是《银行函证及回函工作操作指引》列举出的1-14项询证及附表信息，“被审验单位类型”域成员的取值是进行验资业务的被审验单位的三种类型，分别是一般企业、拟设立企业和外商投资（外放出资）企业。

场景信息中类型化维度“函证编号”的定义方式如下图所示：

图6：数字函证类型化维度示例

（五）单位和精确度

单位是用来说明数值型数据（非字符串及转义文本）的度量单位，最常见的度量单位就是货币型的单位，例如人民币、美元等。数值型数据的事实值应通过单位指向（unitRef）属性将定义的单位ID（unit ID）指向一个预定的单位；对事实值单位的定义同时也指明了事实值的含义，如为货币型元素赋值时，通过单位的定义能够明确金额所代表的币种。函证数据标准中涉及了各类账户余额的单位定义，表9展示了金额型元素常用的单位定义。

表 9：实例文档常用单位定义举例

在根标签中，使用<xbrli:unit>标签预定义计量单位，单位的定义方式如下图所示：

图7：单位信息标记示例

XBRL通过事实值的precision（精确度）或decimal（小数点后位数）属性提供了表达数值型数据精确度的方式，一般使用decimal属性比采用precision属性能够更直观地展示数据的精度。表10列示了数值型数据使用decimal属性的例子。

表 10：数值型事实值的精确度举例