本帖最后由 热传网 于 2024-9-21 16:23 编辑
目前（2024年）税控发票和数电发票并行。发票领域处在税控发票渐行渐少，但仍会持续一段时间；数电发票风头正盛，但并未完全稳定的阶段。
那么，数电背景下，发票系统如何搭建才能更符合企业诉求呢？
本文将从发票系统介绍、业务流程与架构、发票产品设计、业务支撑基础体系等几个方面对此进行阐述，以期抛砖引玉，吸引更多志同道合的伙伴一起探讨该问题。
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端起飞啦
本文来源 @一米 。未经作者许可，禁止转载
| 
发表于 2024-9-18 21:09:18
