数电时代发票系统的搭建方案
随着数字化转型的不断深入,发票管理系统在企业运营中扮演着越来越重要的角色。本文提供了一个全面的视角,深入探讨了在数字化、电子化浪潮中,企业应如何构建一个高效、合规的发票系统。
目前(2024年)税控发票和数电发票并行。发票领域处在税控发票渐行渐少,但仍会持续一段时间;数电发票风头正盛,但并未完全稳定的阶段。
一些集团型企业、业财税服务软件公司、B端互联网公司纷纷入局,共创金税四期新的数电发票时代,期望最终做到全国36个省市区发票数字化、电子化、统一化管理。
那么,数电背景下,发票系统如何搭建才能更符合企业诉求呢?
本文将从发票系统介绍、业务流程与架构、发票产品设计、业务支撑基础体系等几个方面对此进行阐述,以期抛砖引玉,吸引更多志同道合的伙伴一起探讨该问题。
PART.01 发票系统介绍
发票,是指在购销商品、提供或者接受服务以及从事其他经营活动中,开具、收取的收付款凭证。
发票存在的意义:
- 是记录经济活动内容的载体。
- 是最基本的会计原始凭证之一。
- 是税务机关控制税源,征收税款的重要依据。
- 是国家监督经济活动,维护经济秩序,保护国家财产安全的重要手段。
目前会搭建发票系统的有几类单位:
- 国家税务总局。
- 需要财税信息化的企业。
- 提供业财税集成化服务的软件服务商。
- 提供发票服务的软件服务商。
在搭建发票系统过程中需要考虑下图所示相关因素。
不同类型的单位,关注点不一致,共同点是需要理解经济活动中的业务形态和任务形态,需要有将业务形态转化为任务形态,并通过软件系统的形式进行展现、与经济活动关联,并记录经济活动的流转。
在我们的日常生活中,衣食住行都离不开经济流转;只要有经济流转,就需要纳税;大多数需要纳税(增值税等)的情况,都需要开具发票,以发票的形式承载纳税信息。
如下图所示,对于发票系统来说,客户群体既有奥特莱斯、全聚德、亚朵酒店、滴滴出行这类B端企业,也有在这类场所消费的消费者。
当然,一些事业单位、学校等机构,也存在需要开具、使用发票的场景,比如到医院就医,可以开具医疗服务的常规发票,用于补充医疗报销,最终消费者所在公司的财务人员,可以完成财务入账处理,将发票作为一类财务凭证存储。
典型应用场景
PART.02 发票系统业务流程与架构
数电阶段,电子税局将发票系统分为开票和用票2个模块。金税三期时,一般的服务商会把发票系统分为销项发票和进项发票2个模块。相对来说,两种分类方式,都是根据发票开具和发票使用进行的区分,但细微层面是有一定的区别的,这里不做扩展,本文将按开票和用票的分类方式进行讲解。
发票系统的业务范围主要包括下表所示的几部分:
发票系统业务范围
搭建发票系统时,可以根据实际业务诉求,建设发票系统架构。
一般而言,企业的发票系统,业务流程如下图所示,当企业进行货物、劳务、服务等的销售或转让时,可从业务系统或者财务系统(存在财务人员在财务系统审核后开票的场景)发起开票申请,待开票信息完整、数据校验无误后,可开具发票并交付给收票方。
收票方可以是企业,也可以是个人。当收票方是企业时,采购了对应的产品,需要将票据信息采集、验证、入池,确认无误后,增值税专票等可抵扣的场景,需要做勾选抵扣处理,以抵扣本公司的销项税,从而降低企业经营成本。
无论是开具还是接收发票的企业,均需对发票做纳税申报、财务入账处理,最终完成财务、税务、票据数据的对应关系,保证账务的准确性。
从管理角度,企业也有很多报表类需求,通过对数据的查询、统计、汇总、分析,更清晰的知悉本公司的运营情况,以便在后续经营过程中,更好地决策。
发票系统业务流程
基于上述的业务场景和业务流程,可以考虑如下产品架构,将发票系统分为票据中台、发票业务、发票池3个模块。
票据中台负责连接外部系统,业财系统需要开票时,可将数据传入票据中台,通过票据中台的票据处理和规则处理,形成标准的开票和用票数据,进入开用票业务处理模块,进行发票开具或发票勾选抵扣等业务处理。最终所有开具发票和取得发票均在发票池中存储,以备各个系统及模块调用和分析。
在发票开具和勾选抵扣业务中,需要与多个系统打交道,比如通过税局的系统开票、查验、抵扣认证;通过银行、财政等系统,获取非税票据信息。全流程自动化闭环时,有的企业也会选择第三方通道系统一次性完成发票业务的对接,相当于发票系统外包。
发票系统产品架构
PART.03 发票系统产品设计
企业在搭建发票系统前,需完成一些前置准备工作,比如需要获得开具、使用发票的纳税人资质,一般纳税人或者小规模纳税人均可,根据企业实际情况向当地税务机关申请即可。
申请完成后,需要选择使用哪种方式处理发票业务,目前市面上存在的方式包括:金税盘、税控盘、税务ukey、税控服务器、电子税局(增值税综合服务平台、电子税务局)等。
发票开用前置准备
硬件设备在逐渐退出市场;在增值税综合服务平台进行业务处理的企业,在逐渐向电子税局过渡,选择时需要谨慎。
电子税局包括web端、乐企接口服务、APP等多种产品形态,一般大型企业对接时,可考虑申请乐企接口,直接对接税局。
3.1 开票业务
不同的企业,开票这个操作的执行人不一致,一般来说,酒店、餐饮等服务行业,是前台开票;制造、零售等行业,是业务人员发起开票申请;物业、新兴技术等行业,是财务人员开票。
在发票系统手工开票,多系统需要打通,通过接口或者导入开票等场景,具体处理方式也不一致。
总结来说,常见的开票流程如下图所示,无论是线下通过Excel、邮件还是系统间进行数据处理和数据流转,开票时,都需要经过数据准备、业务加工、票税加工、合规校验、发票开具、发票交付几个流程。大多数企业都是有数据统计诉求的,只是不同类型的企业,统计的点和深度不一致,下图举了几个简单的例子。
开票业务流程
3.1.1 业务数据处理
基于上述开票业务流程,搭建开票系统时业务数据处理的处理步骤如下图所示。
业务数据处理
进行数据准备时,需要:
- 确定业务单据需要开票;(按需)
- 发起开票申请;
- 进行业务单据和开票申请单关联;(按需)
- 进行单据的合并拆分。(按需)
手工开票且无需关联业务数据时,可只考虑2;需要关联业务数据时,1-4均需考虑到位。
不同的企业,准备数据时处理逻辑不一样,存在先款后票和先票后款等多种情况,根据实际情况决定业务单据和开票申请单据直接的逻辑关系。
支持单据合并,商品明细合并与否可选;支持按金额、数量、明细行等方式拆分单据。
业务数据,时常跟税局要求的开票数据有出入,在准备开票前,需要进行业务加工,将业务数据加工为发票需要的购方信息、销方信息、交易明细和特定要素信息。
常规发票只需要购销方信息和交易信息即可。
业务中的交易信息,在发票上会根据税务分类要求,分类为货物、劳务、服务、不动产、无形资产等大类。
数电时期,税局为方便精细化管理,增加了特定要素信息,业务系统一般会保存这类数据,只要按照税局的要求,将数据进行转译或者映射即可。
当业务系统与发票系统交互时,还需进行票税加工,这一步,哪个系统来做都可以,只要结果符合预期即可。
票税加工的具体事项包括:价税分离、尾差处理、开票状态管理、待开处理等。
交易明细开票时,需完成价税分离。即所销售商品/货物/劳务等的价税合计金额,需被分离为不含税金额和税额,税额用于向税局缴纳税款。
计算不尽时,税局允许单行0.06元,合计1.27元的尾差存在。
一般的发票系统,主要存在两部分数据:待开票数据、已开票数据。票税加工后的数据,就是待开票数据。
合规校验,是发票开具前的最后一个步骤,有的校验点,是在票税加工前进行,有的是在加工后,上述流程里的顺序,是大逻辑的顺序,细节处理时,步骤间有交叉。
检验点包括纳税人资质校验、票面校验、优惠政策校验、库存校验等等。
纳税人资质需符合相关要求方可开票,比如有成品油生产或经销企业资质,可开具成品油发票。
不同地区优惠政策不一致,需根据当地情况校验优惠政策类型。
这里不同的开票通道,细节存在区别,比如备注的长度,数电web页面和乐企接口区别就很大,如果需要接入多通道时,需要考虑通道的特殊性。
上述业务数据处理,最终形成如图所示的发票票面信息。
金税四期以来,税局细化了30余个特定业务,不同特定业务和特殊票种的票面信息有一定的差异。
3.1.2 发票开具红冲作废
数据准备完成后,可以发起正向或逆向的发票开具服务,包括开票、红冲、作废等,相关的主要业务操作包括:
发票开具红冲作废
这部分,是开票系统的核心。
根据不同的通道选择,在“税盘在线/服务器可连接/已注册电局账号/已申请乐企(多选一或多选二)”、“数据准备完成,校验通过”2个前提下,可对接对应的通道开具发票。
发票开具后,遇到开票有误、销售折让、退货、服务中止等场景时,可红冲发票;是发票开具的逆向流程之一。
税控发票红冲时:
- 普票直接红冲。
- 专票先申请红字信息表,税局审核通过后红冲。
数电发票红冲时,专普票均需申请红字确认单,确认通过后,根据场景自动红冲或手工红冲。
二者的区别点在于:税控红字信息表,是税局审核,只有专票需要申请;数电所有红冲场景,均需申请红字确认单,申请后是购销双方确认,而非税局审核(存在无需确认的情况)。
纸质发票支持作废。空白发票,损毁、遗失等情况,可进行空白发票作废。
当月已开纸质发票(蓝字、红字均可),开票有误可作废;蓝字发票,在销售折让、退货、服务中止等场景时,当月也可进行作废处理;是发票开具的逆向流程之二。
目前纸质发票正在逐渐退出市场,如果企业可以选择,建议选择并引导客户使用电子发票,在降本增效、快捷交付、便捷流转等方面,电票比纸票的优势都相对大一些。
以电子税局开具发票流程为例,阐述发票开具核心业务的数据流转过程:
不同的开票通道,区别比较大,有兴趣的伙伴可以后续通过进阶版本了解细节。
3.1.3 发票交付
发票开具完成后,需将其交付给企业或者消费者,常见的交付方式包括:邮箱交付、短信交付、接口交付、二维码交付等。
中国市场比较卷,交付方式丰富多彩,为了满足老年市场或部分必须有纸质化资料的公司的需求,还支持电票通过A4或A5纸打印后交付。
一般其他国家的发票交付,主要是邮件交付。
交付方式和业务事项如下图所示,细节不再通过文字赘述。
发票交付的页面示例如下图所示:
3.1.4 数据统计
一般情况下,需要数据统计功能,是向企业运营管理负责。企业期望通过数据化管理日常运营时,会更多地关注数据统计结果,并会安排相关的岗位对统计结果进行分析,作为运营决策的支撑。
同时,系统间进行对接时,还会通过发票明细信息、发票汇总信息等内容,完成数据的比对,以及纳税申报需要的销项信息的事前汇总。
常见的统计内容如下图所示:
其中发票汇总,一般是分税率对金额、税额进行汇总,如下图所示:
发票汇总表
3.2 用票业务
一般是采购人员、报销人员(企业员工)、财务、税务等角色,会时常跟用票业务打交道。
企业运行过程中,存在产品/服务等采购-加工/处理-销售等过程,销售时需要开具发票给到下游客户;采购时,需要进行供应商选型,完成采购申请,采购完成后,供应商需要给企业开具发票,这类发票是当前企业的进项发票。
另外,在企业员工出差、加班等场景时,可以发起报销,这类发票,部分需要作为进项发票做抵扣处理(比如增值税专用发票),以抵扣销项税;部分不可抵扣的发票也需要做财务入账处理。
基于上述场景考量,常见的用票流程可以抽象为如下图所示环节,在用票系统搭建时,主要考虑发票采集、合规校验、勾选确认等主要环节;如需与业财税系统对接,可以考虑协同管理、票据入账等模块的搭建;有企业管理诉求或者为纳税申报准备进项票据数据汇总需求时,可进行数据的统计分析处理。
用票系统业务流程
3.2.1 业务数据准备
基于上述用票业务流程,搭建用票系统时业务数据准备的处理步骤如下图所示。
业务数据准备
真正票据全量电子化后,可能不再有票据采集这个场景。但很长一段时间内,票据采集这个模块将一直存在,用票的票据类型和源系统过多,政府部门之间、政府和企业之间、企业和企业之间的真正打通,还需要longlong长时间。
可以通过手工录入、扫码枪录入、发票文件传入、表格导入、邮箱采集、税局下载等方式采集票据。
需要采集的票据类型包括但不限于:增值税发票,火车票、航空电子客票行程单等非增值税发票,海关缴款书等。
票据如在本系统存在,则可直接使用;如在本系统不存在,需要通过各种方式采集票据。
票据采集的来源各种各样,也不确定所采集票据的正确性,在票据采集完成后,需要进行合规校验。可以通过税局的发票查验功能或企业特定的业务规则,进行合规校验操作。
发票查验,一般会将所采集发票与税局抵账库发票进行对比,确定发票真实性。
部分企业在报销、入账等场景,要求较严格,比如要求发票不允许连号、销方为非黑名单客户等,这种情况可以通过企业特定的业务规则做合规校验处理,此时用票系统需要提供校验规则配置功能。
真正进入用票池的发票数据,是需要经过数据清洗、处理和分类的,即数据准备阶段。比如将合规校验通过的数据,按客户实际业务需要,存入对应待勾选列表备用。
票据采集示例如下:
海关缴款书采集
3.2.2 票据勾选确认
数据准备完成后,可以发起正向或逆向的票据勾选确认流程,包括票据勾选、统计确认等,相关的主要业务操作包括:
这部分,是用票系统的核心。
根据当前实际情况,选择发票、海关缴款书还是代扣代缴完税凭证进行勾选确认,一般先勾选,勾选完成后系统自动完成统计操作,在申报期可以进行确认抵扣逻辑。
选择可勾选的票据,确认无误后,提交相关数据到税局,进行勾选抵扣。
根据实际业务,存在抵扣勾选、不抵扣勾选、逾期抵扣、注销抵扣、出口退税抵扣等场景,需将票据按业务场景分类,在具体列表中展示。
农产品等特定业务发票,需事前处理,处理完成后方可勾选抵扣。
所有勾选抵扣数据,统一统计确认,用于纳税申报。
各类场景下的票据勾选确认结果,均统一进行统计确认,确认无误后,数据用于纳税申报。
退税勾选统计确认后不可撤销,需谨慎处理。
以电子税局票据勾选抵扣流程为例,阐述发票使用核心业务的数据流转过程:
勾选抵扣功能页面示例:
3.2.3 票据协同
上文有提到需要用到票据协同的场景,具体落地到系统层时,如下图所示:
以上三项仅为示例,不同场景,需要的协同点不一样,根据客户类型的区别,可以孵化很多协同场景。
以发票入账为例,页面示例如下:
其中,字段逻辑为:
3.2.4 统计分析
一般情况下,需要数据统计功能,是向企业运营管理负责。企业期望通过数据化管理日常运营时,会更多地关注数据统计结果,并会安排相关的岗位对统计结果进行分析,作为运营决策的支撑。
同时,系统间进行对接时,还会通过采购统计信息、报销统计信息等内容,完成数据的比对,以及纳税申报需要的进项信息的事前汇总等。
常见的统计内容如下图所示:
其中用票系统可以为申报表<附表二>提供数据,自动计算当期可抵扣的各税率的进项申报金额、税额等信息,如下图所示。
PART.04 实际案例-滴滴出行
在企业运用开票和用票系统的过程中,相对简单的案例展示层,如下图所示:
一个努力的小伙伴加班工作后,用滴滴APP打车回家,支付完成后形成出行订单。过一段时间报销时,打开APP选择对应单据,开具发票。
开具完成后,通过邮箱或者短信接收发票。
将已下载的发票,在公司使用的报销系统中导入,完成报销操作。
财务人员接收到对应发票并审核通过后,完成财务入账操作并将款项打给小伙伴。
写在最后
当新与旧碰撞时,总会引发人更多的思考:
- 什么是正确的、便捷的?
- 怎样才能快速高效的完成系统的搭建?
- 精细化的业务形态,如何自动化的完成多类业务场景的适配?
- 当业务需求与监管需求相遇时,怎样融合能更好地政企互通?
日常工作中,繁杂、紧急、多而散的需求铺面而来,每天每天接收、接收、接收,处理、处理、处理,有时候不免会觉得我在干什么呢,做的这些事,到底有什么意义?
当跳出这些流水线一样的需求流转时,用产品的视角重新审视发票系统,会发现:哦,原来我是在创造一个新的时代,真正的业务电子化,也不过就是每一次需求的沟通和落地,每一次的需求接收和处理,这么一点点丰满和完善起来的呀。
当对业务流程理解到位,产品架构搭建清晰,需求的逐次实现,实际是在将业务逻辑和用户场景更清晰地表达和完善,为自己公司的商业模式奠定基石,为高效应答客户的业务诉求提供环境。
作者:一米,公众号:B端起飞啦
本文由 @一米 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
写的真好
先讲业务再讲设计,非常好的发票系统讲解文章。
文章写的很详细,让我对发票有了更深的认识。
写的很详细呀