先明确技术适用范围
区块链发票报销流程需要注意哪些问题，首先要看系统实际采用了什么技术。链上记录、数字签名和可验证凭证各有作用，不能仅凭“区块链”名称判断核验方式。以下解释适用于理解相关技术边界，不代表某个平台的操作规范或税务认定标准。
以太坊交易文档说明的是网络状态更新机制，W3C可验证凭证数据模型讨论的是凭证表达与验证。两者可帮助理解技术原理，但都不能直接作为发票报销规则。
核验通过不等于费用真实
W3C可验证凭证模型明确区分可验证性与声明真实性：验证凭证后，接收方仍需按照业务规则判断是否采信。这意味着，即使签名和数据完整性检查通过，也不能仅据此认定凭证描述的业务确实发生。
用于报销场景时，应把技术核验和业务审核分开理解。前者关注凭证来源与内容是否被改动，后者关注费用用途、业务依据及单位报销条件。具体需要哪些附件，应由适用制度确定。
提交记录与报销完成要分清
以太坊交易文档描述了提交、等待纳入区块以及后续确认的过程。生成交易标识并不等于相关操作已经完成，更不能推导出报销审批或付款完成。
如果报销系统确实使用链上操作，应明确界面状态对应哪个环节。记录已提交、链上处理完成、业务审核通过和付款完成，属于不同层次；遇到状态不一致，应结合系统业务记录核对，避免仅凭链上标识认定报销成功。
重复提交与凭证保存
内容完整性核验本身不能判断一项费用是否已经报销。防止重复报销还需要业务系统关联凭证与报销记录，不能把防篡改能力理解为自动防重复能力。
链上标识也不等于完整发票或业务附件。保存资料时，需要明确系统留存的是原始凭证、摘要还是查询入口，并按适用的档案要求保留可供审核的材料。
隐私与常见误解
W3C模型指出，数字凭证的长期留存和跨来源关联可能带来隐私问题。报销系统宜按业务需要限制资料展示和访问权限，避免将个人信息或业务明细无必要地公开。
是否必须使用以太坊、支付链上费用？不能一概而论，以太坊的费用机制不能套用于所有发票系统。是否采用可验证凭证就必须上链？也不是，W3C模型中的相关注册机制可以使用可信数据库或分布式账本等不同设施，实际流程取决于系统实现。