《电子凭证会计数据标准——全面数字化的电子发票(试行版)》指南
为加快全面数字化的电子发票应用和推广实施工作,助力国家数字经济发展和会计信息化建设,提升财政监管和税收征管效能,财政部根据《电子发票业务数据规范》、《电子发票数据电文规范》和《可扩展商业报告语言(xbrl)技术规范》(gb/t 25500-2010)系列国家及行业标准,研究起草了《电子凭证会计数据标准——全面数字化的电子发票(试行版)》(不含铁路电子客票、航空运输电子客票行程单,下同,以下简称《数电票标准》)。《数电票标准》以税务部门现行试点实施的全面数字化的电子发票为基础,反映了数电票承载的全部会计信息,以便企业在信息化条件下对相关业务进行会计处理并完成归档工作。同时,《数电票标准》对发票开具、报销、入账、归档过程中产生的相关会计信息和发票状态信息进行了标准规范,能够有效防止数电票重复入账。为方便阅读理解,我们起草了《电子凭证会计数据标准——全面数字化的电子发票(试行版)》元素清单和本指南。
本指南作为《数电票标准》使用和实例文档解析的说明文件,应与元素清单一并阅读,旨在帮助软件开发商和数电票的接收单位了解《数电票标准》的架构、内容以及实例文档的要素和解析方式。
一、 概述
(一)全面数字化的电子发票介绍
全面数字化的电子发票(简称“数电票”)是与纸质发票具有同等法律效力的全新发票,不以纸质形式存在、不用介质支撑、无须申请领用、发票验旧及申请增版增量。纸质发票的票面信息全面数字化,将多个票种集成归并为电子发票单一票种,数电票实行全国统一赋码、自动流转交付。
数电票破除特定版式要求,增加了xml的数据电文格式便利交付,同时保留pdf、ofd等格式,降低发票使用成本,提升纳税人用票的便利度和获得感。数电票样式根据不同业务进行差异化展示,为纳税人提供更优质的个性化服务。
接收方取得数电票报销入账归档的,应按照《财政部 国家档案局关于规范电子会计凭证报销入账归档的通知》(财会〔2020〕6号,以下称《通知》)和《会计档案管理办法》(财政部、国家档案局令第79号)的相关规定执行。
第一,接收方可以根据《通知》第三条、第五条的规定,仅使用数电票含有数字签名的xml文件进行报销入账归档,可不再另以纸质形式保存。
第二,接收方如果需要以数电票的pdf、ofd格式文件的纸质打印件作为报销入账归档依据的,应当根据《通知》第四条的规定,同时保存数电票含有数字签名的xml格式电子文件。
(二)开具端和接收端工作简介
企业、单位在实际发生交易后,数电票开具方按照税务主管部门的有关要求,开具数电票。接收方获取数电票文件后,通过财政部门提供的免费工具包或自研信息系统解析数电票的结构化数据用于报销、入账。企业、单位在使用数电票报销完成,进行会计入账时,需依据财政部《数电票标准》的要求形成入账端电子凭证-会计信息结构化数据文件,并与开具端数电票带有数字签名的xml文件一并进行会计档案归档备查。
二、 数电票开具方
数电票开具方应按照税务主管部门的有关要求(参见《电子发票业务数据规范》和《电子发票数据电文规范》),开具出符合要求的数电票。
(一)xml数电票样例
|
(二)xml数电票样例要素参考说明
上述xml数电票样例中各数据要素的描述性说明如下表所示,供各试点单位参考。
表 1:xml数电票样例要素参考说明
元素名(英文) | 元素名(中文) | 元素类型 | 数据类型及格式 | 备注 |
einvoice | 发票信息 | 节点 | -- | |
├ header | 头部信息 | 节点 | -- | |
│├ eiid | 电子发票识别码 | 发票数据元 | ||
│├ einvoicetag | 电子发票标识 | 基本数据类型 | 字符型,长度:8 | 格式为“swei监管机构行政区划代码”,区划代码为4位数字。例如广东省监制的发票标识为“swei4400”。 |
│├ version | 版本 | 基本数据类型 | 字符型,长度:8 | 固定值,电子发票的规范版本,目前版本为0.2 |
│├ inherentlabel | 固定标签 | 节点 | -- | |
││├ inissutype | 开票类型 | 节点 | -- | 本节点标记发票属于红字票或蓝字票 |
│││├ labelcode | 标签代码 | 发票数据元 | ||
│││├ labelname | 标签名称 | 发票数据元 | ||
││├ einvoicetype | 发票票种 | 节点 | -- | |
│││├ labelcode | 标签代码 | 发票数据元 | ||
│││├ labelname | 标签名称 | 发票数据元 | ||
││├ generalorspecialvat | 票种类 | 节点 | -- | |
│││├ labelcode | 标签代码 | 发票数据元 | ||
│││├ labelname | 标签名称 | 发票数据元 | ||
││├ taxpayertype | 纳税人类型 | 节点 | -- | |
│││├ labelcode | 标签代码 | 发票数据元 | ||
│││├ labelname | 标签名称 | 发票数据元 | ||
│├ undefinedlabel | 其他标签 | 节点 | -- | |
││├ label | 标签 | 节点 | -- | |
│││├ labeltype | 标签类别 | 发票数据元 | ||
│││├ labelcode | 标签代码 | 发票数据元 | ||
│││├ labelname | 标签名称 | 发票数据元 | ||
├ einvoicedata | 票面信息 | 节点 | -- | |
│├ sellerinformation | 销售方信息 | 节点 | -- | |
││├ selleridnum | 销售方纳税人识别号 | 发票数据元 | 字符型,长度:[1,20] | |
││├ sellername | 销售方名称 | 发票数据元 | 字符型,长度:[1,200] | |
││├ selleraddr | 销售方地址 | 发票数据元 | 字符型,长度:[1,200] | |
││├ sellertelnum | 销售方电话 | 发票数据元 | 字符型,长度:[1,60] | |
││├ sellerbankname | 销售方开户行 | 发票数据元 | 字符型,长度:[1,80] | |
││├ sellerbankaccnum | 销售方账号 | 发票数据元 | 字符型,长度:[1,50] | |
│├ buyerinformation | 购买方信息 | 节点 | -- | |
││├ buyeridnum | 购买方纳税人识别号 | 发票数据元 | 字符型,长度:[1,20] | |
││├ buyername | 购买方名称 | 发票数据元 | 字符型,长度:[1,200] | |
││├ buyeraddr | 购买方地址 | 发票数据元 | 字符型,长度:[1,200] | |
││├ buyertelnum | 购买方电话 | 发票数据元 | 字符型,长度:[1,60] | |
││├ buyerbankname | 购买方开户行 | 发票数据元 | 字符型,长度:[1,80] | |
││├ buyerbankaccnum | 购买方账号 | 发票数据元 | 字符型,长度:[1,50] | |
││├ buyerhandlingname | 购买方经办人姓名 | 发票数据元 | 字符型,长度:[1,50] | |
│├ basicinformation | 票面基本信息 | 节点 | -- | |
││├ totalamwithouttax | 合计金额 | 发票数据元 | 数值型,总长18位,小数点后2位 | |
││├ totaltaxam | 合计税额 | 发票数据元 | 数值型,总长18位,小数点后6位 | |
││├ totaltax-includedamount | 价税合计(小写) | 发票数据元 | 数值型,总长18位,小数点后2位 | |
││├ totaltax-includedamountinchinese | 价税合计(大写) | 发票数据元 | 字符型,长度:[1,100] | |
││├ drawer | 开票人 | 发票数据元 | 字符型,长度:[1,50] | |
││├ requesttime | 开票请求时间 | 基本数据类型 | 记录开票人提交开票信息的时间 | |
│├ issuiteminformation | 票面明细信息 | 节点 | -- | |
││├ itemname | 项目名称 | 发票数据元 | 字符型,长度:[1,100] | |
││├ specmod | 规格型号 | 发票数据元 | 字符型,长度:[1,100] | |
││├ meaunits | 单位 | 发票数据元 | 字符型,长度:[1,50] | |
││├ quantity | 数量 | 发票数据元 | 数值型,总长18位,小数点后6位 | |
││├ unprice | 单价 | 发票数据元 | 数值型,总长18位,小数点后9位 | |
││├ amount | 金额 | 发票数据元 | 数值型,总长18位,小数点后2位 | |
││├ taxrate | 税率(征收率) | 发票数据元 | 数值型,总长10位,小数点后6位 | |
││├ comtaxam | 税额 | 发票数据元 | 数值型,总长18位,小数点后6位 | |
││├ totaltaxincludedamount | 含税金额 | 发票数据元 | 数值型,总长18位,小数点后6位 | |
││├ taxclassificationcode | 商品和服务税收分类编码 | 发票数据元 | 字符型,长度:20 | |
│├ specificinformation | 特定要素信息 | 节点 | -- | |
│├ additionalinformation | 附加信息 | 节点 | -- | |
││├ remark | 备注 | 基本数据类型 | 字符型,长度:[1,4000] | 若特定要素为红字发票,则备注中将包含红票对应蓝票号码及红字确认单编号 |
├ sellerauthentication | 开票方认证信息 | 节点 | -- | |
│├ authenticationmethods | 认证方式 | 基本数据类型 | 字符型,长度:2 | |
├ taxsupervisioninfo | 税务监制信息 | 节点 | -- | |
│├ invoicenumber | 发票号码 | 发票数据元 | 字符型,长度:[1,30] | |
│├ issuetime | 发票生成时间 | 发票数据元 | ||
│├ taxbureaucode | 监制税务机关代码 | 基本数据类型 | 字符型,长度:[1,30] | |
│├ taxbureauname | 监制税务机关名称 | 基本数据类型 | 字符型,长度:[1,100] | |
├ taxbureausignature | 税务局数字签名 | 节点 | -- | -- |
│├ reference | 签名原文引用 | 基本数据类型 | 字符型,长度:[1,200] | uri="/einvoice/header|/einvoice/einvoicedata|/einvoice/sellerauthentication|/einvoice/taxsupervisioninfo|/einvoice/taxbureausignature/signaturetime" |
│├ signaturealgorithm | 签名算法 | 基本数据类型 | 字符型,长度:[1,200] | 按照gb/t 17969.3-2008填写签名算法的对象标识符(object identifier,oid)。采用sm3withsm2签名算法时,签名算法的oid为“1.2.156.10197.1.501”。 |
│├ signatureformat | 签名格式类型 | 基本数据类型 | 字符型,长度:6 | 固定值,detach |
│├ signaturetime | 签名时间 | 基本数据类型 | 签名服务器时间 | |
│├ signaturevalue | 签名值 | 基本数据类型 | base64binary | 对签名原文进行数字签名的结果 |
│├ keyinfo | 证书信息 | 节点 | -- |
三、 数电票接收方
企业、单位以数电票报销、入账、归档的,应当按照《财政部国家档案局关于规范电子会计凭证报销入账归档的通知》(财会〔2020〕6号)的相关规定执行。数电票的传输、存储安全可靠,对任何篡改能够及时发现,作为电子凭证,符合《会计档案管理办法》(财政部 国家档案局令第79号)的相关要求。
(一)获取并解析数电票,以结构化数据报销
企业、单位的业务人员可通过电子发票服务平台、电子邮箱、二维码等渠道获取含有数字签名的xml格式的数电票,通过电子发票服务平台或者全国增值税发票查验平台查验所接收到数电票的合法性、真实性。查验通过后,从xml文件中解析和提取结构化数据信息,转换为计算机可识别的内容,作为报销申请的依据。在报销流程中需建立数电票xml文件与报销单的业务关联关系。接收端试点单位可在报销系统中自行定义报销审批流程、重复报账校验、敏感词校验等合规管理过程。
主流财务软件厂商应均已具备解析数电票和生成电子凭证实例文档的能力。财务软件厂商可根据《数电票标准》的要求,使用工具包解析数电票结构化数据并同步标记状态位(包括发票状态信息、会计主体信息、基础会计信息和企业所得税管理信息),自动生成标准化的电子发票业务(对象)数据,直接写入底层数据库或选择生成xbrl格式的实例文档。
接收方企业、单位需要完成进项抵扣等税务业务流程的,应按税务主管部门的要求进行业务处理。
(二)自动入账并回写信息
接收方企业、单位在使用数电票进行报销入账后,需要按照《数电票标准》的相关要求,将数电票信息、数电票状态、会计主体信息、基础会计信息和企业所得税信息即时回写到底层数据库或相应的实例文档中。
1、《数电票标准》内容架构
本标准将电子发票的部分票面信息以及通过电子发票进行开具、报销、入账、归档过程中需要的信息进行了xbrl标记,表1列示了标准标记相关字段。
表 1:《数电票标准》标记内容
(*项目为可抵扣发票专用信息)
序号 | 分组名称 | 字段名称 | 数据类型 | 说明 |
1 | 电子发票信息 | 发票号码 | 字符型 | 电子发票的唯一标识码,用于标识电子发票的开票年份、纳税人省级行政区域、开票渠道、顺序编码等信息的唯一标识码。 |
2 | 销售方名称 | 字符型 | ||
3 | 销售方纳税人识别号 | 字符型 | ||
4 | 不含税金额合计 | 货币型 | 对应《电子发票数据电文规范》中“合计金额” | |
5 | 合计税额 | 货币型 | ||
6 | 价税合计(小写) | 货币型 | ||
7 | 开票日期 | 日期型 | 对应《电子发票数据电文规范》中“开票请求时间” | |
8 | 电子发票状态信息 | 合同编号 | 字符型 | 选填项,记录发票关联的合同编号,企业可根据具体业务场景选择回写 |
9 | 业务单据与电子发票的匹配状态 | 字符型 | 选填项,记录业务单据与发票是否匹配,企业可根据具体业务场景选择回写,以采购场景为例,即订单、入库单和发票的三单匹配情况 | |
10 | 固定资产、无形资产折旧摊销方法 | 字符型 | 选填项,记录购置的固定资产折旧方法或无形资产摊销方法,企业可根据具体业务场景选择回写 | |
11 | 是否已做保理、出售或资产证券化 | 布尔型 | 选填项,记录发票是否已用于保理、出售和资产证券化业务,企业可根据具体业务场景选择回写 | |
12 | 是否红字发票 | 布尔型 | 必填项 | |
13 | 是否已验真 | 布尔型 | 必填项 | |
14 | 是否已入账 | 布尔型 | 必填项 | |
15 | 是否已用途确认* | 布尔型 | 必填项 | |
16 | 确认用途* | 字符型 | 必填项,增值税电子专用发票确认用途包含抵扣税款、出口退税、代办退税、不抵扣、出口转内销等 | |
17 | 用途确认所属期 | 年月型 | 必填项,格式为年-月,如2023-06 | |
18 | 是否已付款 | 布尔型 | 选填项,企业可根据发票付款情况选择回写付款状态信息,若存在拿到发票后多次付款的情况,需在完成所有付款后标记为“true” | |
19 | 银行回单编号 | 字符型 | 选填项,企业可根据发票付款情况选择回写付款后返回的银行回单编号 | |
20 | 是否进项税额转出* | 布尔型 | 必填项 | |
21 | 进项税额转出金额* | 货币型 | 必填项 | |
22 | 会计主体信息 | 会计主体统一社会信用代码 | 字符型 | 必填项 |
23 | 会计主体名称 | 字符型 | 必填项 | |
24 | 记账凭证信息 | 记账凭证编号 | 字符型 | 必填项,记账凭证的唯一标识,用于验证发票事项入账的唯一性 |
25 | 记账日期 | 日期型 | 必填项,格式为年-月-日,如2023-06-30 | |
26 | 会计期间 | 年月型 | 必填项,格式为年-月,如2023-06 | |
27 | 记账凭证摘要 | 字符型 | 选填项,企业可根据记账凭证实际情况选择回写,若摘要以分录行记录输出,仅记录第一行凭证分录的摘要信息 | |
28 | 借贷方会计信息 | 借贷方向 | 字符型 | 选填项,企业可根据每条会计分录的借贷方向选择回写,填写“借方”或“贷方” |
29 | 总账科目名称 | 字符型 | 选填项,企业可根据每条会计分录回写会计准则约定的统一规范科目名称 | |
30 | 明细科目名称 | 字符型 | 选填项,企业可根据每条会计分录回写准确反映经济业务内容的末级科目或者辅助信息 | |
31 | 入账金额 | 货币型 | 选填项,企业记录根据科目的本位币入账金额选择回写 | |
32 | 企业所得税管理信息 | 是否已所得税税前扣除 | 布尔型 | 选填项 |
33 | 所得税税前扣除年度起 | 年份型 | 选填项,格式为年,如2023 | |
34 | 所得税税前扣除年度止 | 年份型 | 选填项,格式为年,如2023 | |
35 | 权责发生制下支出所属期起 | 年月型 | 选填项,企业可根据发票关联业务的成本费用支出情况,按照权责发生制选择回写支出所属期起始时间,格式为年-月,如2023-06 | |
36 | 权责发生制下支出所属期止 | 年月型 | 选填项,企业可根据发票关联业务的成本费用支出情况,按照权责发生制选择回写支出所属期结束时间,格式为年-月,如2023-06 |
2、xbrl实例文档要素说明
实例文档作为电子发票结构化数据的载体,不仅包含了数据本身及其与《数电票标准》元素之间的对应关系,同时也包含了数据相关的属性信息(如数据所属时间、单位等),这些信息使得标记数据能够与业务场景紧密关联起来。
实例文档共包含五类内容,分别是根元素(xbrli:xbrl)、标准引用(link:schemaref)、事实值(fact)、上下文(context)和单位(unit),使用者可结合三个要素的具体信息来进一步理解实例文档。
1) 根元素
实例文档根元素的标签名是
表 2:《数电票标准》标记内容
前缀 | 命名空间url | 描述 |
einv | http://xbrl.mof.gov.cn/taxonomy/2023-05-15/einv | 数电票标准 |
num | http://www.xbrl.org/dtr/type/numeric | percentitemtype数据类型命名空间 |
label | http://xbrl.org/2008/label | 标签定义 |
xl | http://www.xbrl.org/2003/xlink | xbrl技术规范 |
link | http://www.xbrl.org/2003/linkbase | xbrl技术规范 |
xlink | http://www.w3.org/1999/xlink | xbrl技术规范 |
xbrli | http://www.xbrl.org/2003/instance | xbrl技术规范 |
gen | http://xbrl.org/2008/generic | |
iso4217 | http://www.xbrl.org/2003/iso4217 | 计量单位定义 |
2) 标准引用
每一份实例文档都是基于一套标准编制的,标准是解析实例文档的基础。在根标签中,使用
3) 事实值
事实值就是电子发票版面信息填写的内容,例如对于“销售方名称”这个项目,其事实值就是电子发票的销售方名称信息。通过为元素赋值,并指定上下文、单位和精度属性,来完成对于事实值的完整定义。赋予实例文档的事实值可为数值(金额、十进制数字等)或非数值数据(字符串或者转义文本,例如xhtml格式内容)。事实值也可为日期类型和时间类型。表3列示了部分事实值。
表3:事实值举例
电子发票信息项 | 数据类型 | 事实值例举 |
不含税金额合计 | 货币型 | 9000.00 |
开票日期 | 日期型 | 2023-06-30 |
销售方名称 | 字符型 | xxx有限公司 |
是否红字发票 | 布尔型 | false |
(1)数值型事实值
数值型事实值的定义,除了通过contextref指向一个预定义的上下文(context),还会通过unitref指向一个预定的单位(unit),并通过事实值的decimals(小数点后位数)属性表达数据的精确度,图1是“不含税金额合计”对应的事实值定义信息:
图1:数值型事实值定义方式示例
(2)非数值型事实值
非数值型事实值的定义,是将事实值赋予给对应的元素名,并通过contextref指向一个预定义的上下文(context),图2为“是否红字发票”对应的事实值定义信息:
图2:非数值型事实值定义方式示例
4) 上下文
每个事实值都会通过contextref属性赋予的上下文id指向预定义的上下文(context)。通过指定上下文,才能够确定事实值的具体含义。
上下文要素包括:实体信息(entity)、时期信息(period)和场景信息(scenario)。在根标签下,使用
(1)实体信息
实体信息即指实例文档数据的发布者信息,使用标签
(2)时期信息
时期信息是指事实值所对应的日期或期间,使用标签
5) 单位和精确度
单位是用来说明数值型数据(非字符串及转义文本)的度量单位,最常见的度量单位就是货币型的单位,例如人民币、美元等。数值型数据的事实值应通过单位指向(unitref)属性将定义的单位id(unit id)指向一个预定的单位;对事实值单位的定义同时也指明了事实值的含义,如为货币型元素赋值时,通过单位的定义能够明确金额所代表的币种。表4展示了货币型元素常用的单位定义。
表 4:实例文档常用单位定义举例
id | 单位的含义 | 分子 | 分母 |
u1 | 人民币 | iso4217:cny | 不适用 |
在根标签中,使用
图3:单位信息标记示例
xbrl通过事实值的precision(精确度)或decimals(小数点后位数)属性提供了表达数值型数据精确度的方式,一般使用decimals属性比采用precision属性能够更直观地展示数据的精度。表5列示了数值型数据使用decimals属性的例子。
表 5:数值型事实值的精确度举例
数值 | decimals取值 | 示例 |
精确到千位 | -3 | 12 000 |
精确到百万位 | -6 | 45 000 000 |
精确到2位小数 | 2 | 139 034.17 |
精确数字 | inf | 1.2645 |
6) 实例文档命名规则
实例文档的命名格式为{票据类型简称}_{票据类型}_{日期}_{票据唯一标识}.{文件后缀}。文件名称各组成部分之间以英文字符下划线连接。其中,{票据类型简称}是einv,即标识票据类型是数电票;{票据类型}用于区分实例文档的是普通发票还是专用发票;{日期}格式为yyyymmdd,对于接收方是记账日期;{票据唯一标识}是电子发票的唯一标识码,即发票号码;{文件后缀}是实例文档的后缀,即xml。
以电子发票(专用发票)为例,实例文档命名格式举例如下:
einv_spcl_yyyymmdd_发票号码.xml
3、数电票回写示例
企业、单位的业务人员在使用电子发票进行报销入账时,财务共享系统能够通过电子发票业务(对象)数据与企业会计凭证的映射关系自动生成凭证。在发票的流转过程中,系统也会将发票状态信息、相关的会计信息和企业所得税信息即时回写到底层数据库或相应实例文档中。以电子专用发票为例,将对下列信息进行回写。
1) 发票状态信息
以电子专用发票为例,发票状态信息如下:
(1)合同编号:r9988888
(2)业务单据与发票的匹配状态:已匹配
(3)是否红字发票:否
(4)是否已验真:是
(5)是否已入账:是
(6)是否已付款:是
(7)银行回单编号:6fe0-4f2c-88aa
(8)是否已用途确认:是
(9)确认用途:抵扣税款
(10)用途确认所属期:20xx-xx
(11)是否进项税额转出:否
2) 会计主体信息
(1)会计主体统一社会信用代码:911100007000xxxxxx
(2)会计主体名称:xxx有限公司
3) 基础会计信息
以电子专用发票为例,对应的基础会计信息如下:
(1)记账凭证编号:12345678
(2)记账日期:20xx-xx-xx
(3)会计期间:20xx-xx
(4)记账凭证摘要:xxxxx
(5)借贷方向:借方
(6)总账科目名称:合同履约成本
(7)明细科目名称:分包成本
(8)入账金额:97029.70
(9)借贷方向:借方
(10)总账科目名称:应交税费
(11)明细科目名称:进项税额
(12)入账金额:970.30
(13)借贷方向:贷方
(14)总账科目名称:应付账款
(15)明细科目名称:工程款
(16)入账金额:98000.00
考虑到账务处理中经常出现多借多贷的会计分录,在《数电票标准》中加入了“借贷方会计信息”这一元组元素,用来增加浮动行针对不确定的分录行进行标记。
以下列会计分录为例:
借:合同履约成本-工程施工-分包成本 应交税费-应交增值税-进项税额 贷:应付账款-工程款 |
该会计分录的实例文档内容应为:
|
4) 企业所得税管理信息
(1)权责发生制下支出所属期起:20xx-xx
(2)权责发生制下支出所属期止:20xx-xx
(3)是否已所得税税前扣除:否
(4)所得税税前扣除年度起:20xx
(5)所得税税前扣除年度止:20xx
(三)生成数电票入账信息实例文档数据进行归档备查
数电票入账后的电子凭证文件由两部分构成,分别是开具端单位开具(交付)的数电票含有数字签名的xml格式电子文件,以及接收端试点单位生成的会计入账信息结构化数据文件。
接收端试点单位应当在报销业务对应的会计入账完成后、会计凭证归档之前,根据实际入账情况使用工具包生成入账信息结构化数据文件,并将记账凭证、报销单、数电票含有数字签名的xml格式电子文件、入账信息结构化数据文件等会计资料组件形成电子会计凭证文件。
会计期间结束后,企业、单位需按照财政部的监管要求,按照财政部、国家档案局《会计档案管理办法》(财政部 档案局令第79号)和《关于规范电子会计凭证报销入账归档的通知》(财会〔2020〕6号)的相关要求,参考《电子会计档案管理规范》(da/t 94—2022)和《行政事业单位一般公共预算支出财务报销电子会计凭证档案管理技术规范》(da/t 95—2022),将上述电子会计凭证文件进行归档,以备财政部相关监管部门查验。
附录:
应用数电票实例文档操作指引
在实际应用中,主要有两种报账流程模式分别为:一般企业普遍适用流程模式和集团型企业财务报账模式,两种模式可分别按照如下步骤开展相关工作:
(一)一般企业普遍适用流程模式
1. 电子发票、电子凭证的获取和存储:企业通过邮箱下载、税务局网站下载等渠道获取数电票数字签名的xml数据文件。
2. 票据存储:将获取的数电票存储至发票池。对于无报账系统(如报销系统或发票池)支撑文件获取和存储的企事业单位,建议由员工手工下载至本地存储。
3. 文件验签、发票验真:在进行报销入账之前,企业需对接收的带数字签名的xml格式的数电票遵从现有的税收征管要求进行发票查验,以保证发票的真实性。只有查验成功的发票才可报销入账,企业记录发票的验真、验签信息。
4. 解析xml文档:自行或调用财政部提供的免费电子凭证工具包解析接收的xml文件,并存入发票池。
5. 根据数电票是否是增值税专票,如果是专票则进行5.1和5.2处理。
5.1. 发票抵扣:数电票关联的业务入账后,依据税务总局的要求进行抵扣处理,抵扣确认后保存到发票池,记录发票的抵扣信息。
5.2. 进项转出:发票进行抵扣后,企业根据发票用途的转变,进行进项转出处理,并将发票转出信息记录到发票池。
6. 资金支付:对于需要付款类业务,可以由资金系统进行业务处理审批后完成资金支付。信息化较好的企业单位按《数电票标准》的要求根据银行回单回写电子凭证支付状态位信息。
7.会计记账:核算系统根据报销业务信息、数电票的电子凭证信息,同时按照《数电票标准》要求回写电子凭证状态位信息。
8. 归档准备:企业可设定归档前的文件生成准备时机,自行或借助财政部的免费工具包生成电子凭证-入账信息结构化数据文件。并将记账凭证、报销单、数电票含有数字签名的xml格式电子文件、电子凭证入账信息结构化数据文件等文件打包形成电子会计凭证文件。
9. 会计资料归档:单位需按照财政部的监管要求,按照财政部、国家档案局《会计档案管理办法》(财政部 档案局令第79号)和《关于规范电子会计凭证报销入账归档的通知》(财会〔2020〕6号)的相关要求,参考《电子会计档案管理规范》(da/t 94—2022)和《行政事业单位一般公共预算支出财务报销电子会计凭证档案管理技术规范》(da/t 95—2022),将上述电子会计凭证文件进行归档,以备财政部相关监管部门查验。
(二)集团型企业财务报账模式
1. 电子发票、电子凭证的获取和存储:企业通过邮箱下载、税务局网站下载等渠道获取数电票数字签名的xml数据文件。
2. 票据存储:将获取的数电票存储至发票池。对于无报账系统(如报销系统或发票池)支撑文件获取和存储的企事业单位,建议由员工手工下载至本地存储。
3. 文件验签、发票验真:在进行报销入账之前,企业需对接收的带数字签名的xml格式的数电票遵从现有的税收征管要求进行发票查验,以保证发票的真实性。只有查验成功的发票才可报销入账,企业记录发票的验真、验签信息。
4. 解析实例文档结构化信息:自行或调用财政部提供的免费电子凭证工具包解析接收的xml文件,并存入发票池。数电票的结构化数据可根据企业财务内控需要内置到报销单中,同时建立数电票与报销单业务关联关系。
5. 发起报账申请:业务人员在企业报账系统或共享系统中发起费用报销申请,填写报销单时引用采集的数电票结构化数据。
6. 合规校验:按照财务报销制度对报销单进行合规校验,如重复报账校验、敏感词校验等。
7.审核复核:企业根据内控流程审核复核通过后,根据实际业务场景将电子凭证关联报账单业务信息、电子凭证信息等推送核算系统,按照核算入账规则生成记账凭证。
8. 根据数电票是否是增值税专票,如果是专票则进行8.1和8.2处理。
8.1. 发票抵扣:数电票关联的业务入账后,依据税务总局的要求进行抵扣处理,抵扣确认后保存到发票池,记录发票的抵扣信息。
8.2. 进项转出:发票进行抵扣后,企业根据发票用途的转变,进行进项转出处理,并将发票转出信息记录到发票池。
9. 资金支付:对于需要付款类业务,资金系统接收报账系统发送的支付申请信息,由资金系统进行业务审批后完成支付业务,完成支付后返回支付结果。信息化较好的企业单位按《数电票标准》的要求根据银行回单回写电子凭证支付状态位信息。
10.会计记账:核算系统接收业务系统传递的报销业务信息及凭证生成指令,自动生成记账凭证并存储关联的报销业务信息,同时按照《数电票标准》要求回写电子凭证状态位信息。
11. 归档准备:企业可设定归档前的文件生成准备时机,自行或借助财政部的免费工具包生成电子凭证-入账信息结构化数据文件。并将记账凭证、报销单、数电票含有数字签名的xml格式电子文件、电子凭证入账信息结构化数据文件等文件打包形成电子会计凭证文件。
12. 会计资料归档:单位需按照财政部的监管要求,按照财政部、国家档案局《会计档案管理办法》(财政部 档案局令第79号)和《关于规范电子会计凭证报销入账归档的通知》(财会〔2020〕6号)的相关要求,参考《电子会计档案管理规范》(da/t 94—2022)和《行政事业单位一般公共预算支出财务报销电子会计凭证档案管理技术规范》(da/t 95—2022),将上述电子会计凭证文件进行归档,以备财政部相关监管部门查验。