每刻报销
企业差旅及费用管理平台
每刻AI报销
企业差旅及费用管理平台
每刻AI档案
电子会计档案管理系统
每刻AI云票
数电乐企进销项发票管理平台
每刻AI应付
自动化应付协同管理平台
每刻AI应收
自动化应收协同管理平台
每刻BI + AI
财务专属的可视化数据分析平台
出差申请
以事前管控为核心的费用前置申请
差旅预订
提供一站式商旅出行消费体验
商旅月结
员工无需报销,一票完成所有结算
智能识票
自动提取发票信息一键生成费用
费用分摊
多维度灵活分摊、满足精准核算
智能审核
海量业务规则与财务经验高效融合
智能支付
自动导出支付,节省出纳50%工作量
银行流水回单
银行直连标准化,回单智能匹配
进销项发票
进销项发票分类管理,税务生态直连
业务场景类单据
自定义对接费用、销售等场景单据
合同管理
自定义对接采购、销售等合同
核算账务数据
对接记账凭证等,总账系统生态直连
纸质电子化
纸质资料电子化与数据结构化提取
线上化对账管理服务
自定义对账审批流,流程在线管控
智能化对账处理规则
支持多种对账场景,自动匹配数据
自动对账差异项校验
对比客户与企业账单,生成差异明细
对账单自动下推开票
对账单完成后自动生成开票申请单
应收数据自动生成
按照系统配置规则自动生成应收单
应收自动及时入账
与ERP集成,应收凭证自动推送入账
应收关联业务明细
应收单发票明细与业务明细关联校验
应收账款数据台账
在线查看、管理应收账款数据
全面数字化的电子发票推广后,财务人员常会收到同一张发票的 XML 数据、OFD 或 PDF 版式文件,以及来自业务系统的订单、报销单和付款记录。文件更多并不意味着归档更完整:如果只保存截图,后续可能无法利用结构化信息;如果只保存一份数据文件,又可能影响日常阅读和业务复核。数电发票归档的关键是理解不同文件承担的作用,并把它们与真实交易和会计凭证保留在可追溯的关系中。
税务部门公开说明,数电发票增加 XML 数据电文格式,同时保留 PDF、OFD 等格式。XML 更便于系统读取和自动处理;OFD、PDF 更便于人阅读、展示和流转。企业的归档策略不应简单地要求“只留某一种”,而应基于凭证来源、会计系统能力、审计调阅习惯和适用规则,明确哪些电子文件和元数据需要保留。
| 格式 | 常见用途 | 归档管理关注点 |
|---|---|---|
| XML | 结构化数据读取、自动匹配、校验 | 与版式文件及业务记录的对应关系;防止文件丢失或错配 |
| OFD | 版式呈现、电子签名与发票阅读 | 阅读工具适配、文件完整性、与凭证的索引关系 |
| 日常查看、对外流转、部分电子凭证承载 | 是否为原始电子文件或转换件;与其他资料的关联 |
企业可以把“结构化数据用于处理、版式文件用于阅读、业务资料用于说明交易、会计凭证用于记录核算”作为基本认识。但具体留存要求仍需结合电子凭证来源、企业会计制度与档案制度判断,不能用一条统一规则替代所有场景。
从一张数电发票进入企业开始,至少要经历接收、查验或验真、报销或业务匹配、入账和归档几个环节。若任何一环靠人工临时处理,后续就容易出现“找得到发票、找不到付款回单”“看得到 PDF、读不到数据”“凭证附件有文件但无法确认对应业务”等问题。
例如,在费用报销场景中,应关注数电票与报销单、审批记录、消费明细和会计凭证的关系;在采购付款场景中,应关注发票、订单、合同、验收资料、付款申请和银行回单是否能通过同一索引规则关联;在共享服务场景中,还应关注跨法人、跨期间、拆分或合并入账时的关系如何保留。
第一类是“打印件替代电子原件”。财政部、国家档案局明确,单位以电子会计凭证的纸质打印件作为报销入账归档依据时,应同时保存打印该纸质件的电子会计凭证。打印可以服务线下流程,但不能让原始电子文件从归档链路中消失。
第二类是“文件能打开就算完成”。文件可读并不等于资料完整。应检查发票、原始业务单据、付款资料和会计凭证之间是否形成可解释关系,尤其要留意同一发票分次报销、合并付款、退款红冲和跨期调整等情况。
第三类是“同一文件多处存”。邮箱、个人电脑、报销系统、共享盘和档案系统同时保存文件,可能提高查找成本,也可能形成版本和权限失控。企业应明确正式归档位置,并保留必要的来源与处理痕迹。
第四类是“异常没有人负责”。查验失败、文件损坏、数据解析异常、金额或税额不一致等问题,应有明确的处理入口、责任人和关闭条件。把异常集中到月末或审计前处理,通常会放大补资料成本。
企业可以为数电发票建立一张规则表,不求一开始覆盖所有例外,但应把高频业务说清楚:资料来自哪里、由谁接收、需要校验什么、匹配到哪类业务单据、由谁审核、何时入账、正式归档到哪里、异常怎样处理。对于各类电子文件,可同步记录文件类型、来源、接收时间、关键业务标识、会计凭证号和保管期限等信息。
规则落地后,可用真实样本反复测试。测试不只看是否成功归档,也要刻意放入重复发票、缺少订单、付款金额不一致、发票红冲和权限不足等样本,观察系统或流程能否识别、提示、分派并留痕。
数电票往往是企业最适合启动的入口,但不应把电子凭证建设局限在发票。银行电子回单、电子对账单、财政电子票据、电子客票和国库集中支付电子凭证等,均可能成为同一笔经济业务的证据组成部分。财政部发布的电子凭证会计数据标准推广应用版已对多类高频凭证提供相关标准材料,企业可以按自身业务优先级逐步扩展。
每刻档案可帮助企业在归档阶段将电子凭证、业务资料和会计资料建立关联,支持按权限检索、调阅与留痕。企业在选择或配置相关能力时,应以真实的资料来源和异常样本验证能否满足自身需求。
数电票规则设计最容易被标准样例带偏。项目组通常会先选择格式规范、字段齐全的文件,快速完成识别和展示。但企业真实环境中会同时出现 XML、OFD、PDF、业务附件、查验结果和入账记录,还会遇到重复接收、红冲、更正、跨期入账和历史文件。要判断系统能否承担归档任务,应由企业准备脱敏样本,而不是完全使用供应商自带数据。
建议至少准备五组。第一组是标准数电票,检查原始文件、版式阅读和结构化字段;第二组是一张票对应多笔费用或多个成本对象;第三组是多张票合并到一张会计凭证;第四组包含红冲或更正;第五组故意缺少业务附件或付款依据。每组都要从票据入口走到业务单据、审批、付款和会计凭证,再从凭证反向调阅全部资料。
测评过程中不应只记录“识别成功”。还要记录原始电子文件是否保持不变,解析结果与原文件是否对应,系统是否能识别重复资料,红冲前后的关系如何呈现,人工补件发生在哪个岗位,以及导出后能否保留必要说明。对归档系统而言,识别只是起点,可解释的业务关系才是后续审计和复核真正需要的结果。
同一张数电票可能同时存在结构化数据和版式文件,企业应明确每类文件在接收、处理、阅读和归档中的用途。XML 等结构化数据适合系统解析、校验和匹配;OFD、PDF 更适合阅读和展示;订单、合同、审批和回单用于说明交易背景;会计凭证用于记录核算结果。只有这些材料围绕同一业务建立关系,归档才不是文件堆放。
对应表至少要写清四项内容:文件由哪个平台产生,通过什么方式进入企业,哪一个版本属于原始电子文件,发生红冲或更正后如何保留关系。若来源系统会同时推送多个文件,还要明确去重标识;若系统为了预览生成转换件,要确认转换件不能覆盖原文件;若某种格式需要专用阅读器,要明确安装、升级和长期维护责任。
企业还应抽取一张票完成反向验证:从会计凭证找到结构化数据和版式文件,再从原始电子凭证找到报销单、采购单、付款和入账结果。如果任何一步只能依靠文件名、人工记忆或回到原平台查找,就说明当前索引和资料关系仍需完善。
数电票归档中,最容易造成混乱的不是正常文件,而是状态变化。红冲后不能简单删除原票,更正后也不应只保留最终展示结果。企业需要保存能够说明变化前后关系的资料,并确认它们分别影响了哪笔报销、付款和会计凭证。审计人员查看时,应能理解原业务如何处理,而不是看到多份互相矛盾的附件。
重复接收也要区分来源重复和业务重复。相同电子凭证可能从票税平台、费控系统或供应商门户多次进入,系统应通过唯一标识和关键字段识别;但同一合同下出现多张金额相同的合法发票,不能仅按金额和日期误判重复。规则需要兼顾自动识别与人工确认,并保留确认依据。
解析失败、文件损坏或接口延迟时,应形成待处理清单。清单至少包括来源、接收时间、失败原因、责任岗位、补救动作和关闭状态。月末结账前,财务可以按清单核对当期未完成事项,避免问题在审计抽凭时才暴露。
企业从数电票起步后,通常会继续接入银行电子回单、电子对账单、铁路电子客票、航空运输电子客票行程单、财政电子票据等资料。不同凭证的数据元素和获取方式不同,但管理问题相似:原始文件如何接收,结构化数据如何解析,与哪笔业务和会计凭证关联,异常由谁处理,归档后如何调阅。
扩展时不宜只复制接口。项目组应为每类凭证重新确认业务场景、必要组件和责任岗位。例如银行回单需要处理合并支付、分笔付款、手续费和退款;电子客票需要与差旅申请、行程和报销记录对应;财政电子票据可能涉及不同的业务和核算口径。共同的归档平台可以复用目录、权限和调阅能力,但业务规则仍需逐类确认。
每刻档案可用于关联电子凭证、业务资料、资金记录和会计凭证,并支持四性检测、异常处理和审计利用。企业在系统建设中应重点检查原始文件是否保留、关系是否准确、状态变化是否可追溯,而不是用“支持某种格式”替代完整验收。
在费用报销场景,归档规则应把数电票与报销单、消费明细、审批记录和会计凭证关联;如果一张票被拆分到多个费用科目,还要保留拆分依据。在采购付款场景,发票需要与订单、合同、验收、付款申请和银行回单形成关系;发生分批到货、分次开票或合并付款时,不能依赖一对一匹配。在差旅场景,铁路电子客票和航空运输电子客票行程单还要与行程、人员和报销记录对应。不同场景共用文件格式,但业务关系并不相同。
字段设计也应服务后续查询。除发票代码号码、金额、税额和开票日期外,企业通常还需要法人、供应商、业务类型、报销单号、订单或合同号、付款流水、凭证号和会计期间。哪些字段来自电子凭证,哪些来自业务系统,哪些由归档规则生成,应在项目中注明。把所有信息都塞进文件名既不稳定,也无法支持可靠的权限和统计。
上线验收可以分三次进行。第一次在资料接收后检查原文件和解析字段;第二次在入账后检查业务、付款与会计凭证关系;第三次在月末或审计模拟中检查批量查询、导出和异常关闭。三次验收关注不同问题,比在项目最后集中检查更容易定位责任和修正规则。
对于历史数电票,不必机械追求一次性全量补录。可以先按年度、组织和利用频率分批处理,明确哪些资料只做目录索引,哪些需要恢复业务关系,哪些仍应回到原系统调阅。存量与新增采用不同策略并不矛盾,但必须在查询结果中让使用者知道资料完整程度,避免把历史缺口误认为当前系统故障。
审计或内部复核需要批量取得资料时,企业还应事先定义导出规则。导出的资料包可以按法人、期间、凭证或业务编号组织,并附带能够说明文件关系的目录;涉及敏感信息时,应经过审批并限制有效期和使用范围。单纯把若干 PDF 打包下载,可能仍需要审计人员逐份猜测对应关系,也难以证明导出内容是否完整。
归档后的数电票还会被用于税务复核、供应商核对和业务争议处理。查询入口不应只有发票号码,还应支持从供应商、订单、合同、报销人、付款流水和会计凭证等常用线索进入。企业可以收集近一年最常见的查询问题,用这些问题检验目录和索引是否贴近实际工作,而不是只满足项目人员设计的标准查询。
查询结果还应明确资料来源和当前状态,避免使用者把预览件误认为原始电子文件,边界清晰。
数电票归档不是在 XML、OFD、PDF 中选择一个文件留下,而是让结构化处理、日常阅读、交易说明和会计核算各有可靠依据。企业先建立格式与用途对应表,再处理红冲、更正、重复和失败等异常,最后把方法扩展到更多电子凭证,能够减少月末补资料和审计找附件的成本。判断归档是否完成的标准,应是一笔业务能够被准确还原,而不是某个文件夹里已经出现了发票。
每刻报销
超过200+上市企业的费控选择
根据相关政策规定,安卓手机用户需至
各手机应用商店搜索安装“每刻报销”
开发者:杭州每刻科技有限公司
应用版本:7.18.2|应用权限|隐私政策|Privacy Policy