随着电子发票截止日期的临近，企业发现自己面临着一个核心问题：选择哪个平台？
市场是围绕这个问题构建的，包括产品演示、功能比较、快速集成的承诺，一切都有助于将解决方案的选择作为项目的起点。然而，在很多情况下，这是逻辑的倒置。
由于改革主要不是提出工具问题，它凸显了发票情况的复杂性，通常记录不完善，有时控制不力。
技术改革、异构实践
监管框架现已稳定，从 2026 年 9 月起，所有公司都必须能够接收电子发票，而最大的公司也必须开具电子发票。排放义务将于 2027 年普及。
目标模型是已知的：结构化格式、互连平台、寻址目录以及几乎即时将数据传输到税务管理部门。
理论上，机制是统一的，但实际上，它适用于不统一的组织。
这是您需要注意的地方，因为公司不会在单一框架内开具发票。它可以在一系列情况下开具发票：预付款、最终发票、多个订单、分包、保理、费用报告、国际流动。如此多的案例，每一个都遵循特定的规则。
构建项目的用例
为了构建这种多样性，在改革的准备工作中正式确定了几十个用例。这种粒度反映了公司的运营现实。
每个案例涉及：
- 要产生的数据，
- 要进行的检查，
- 验证电路，
- 整合限制。
因此，承担相同监管义务的两家公司可能具有截然不同的功能需求。
一个将能够依赖简单的、很大程度上自动化的流程，而另一个则必须管理特定案例的积累，并强烈依赖于其信息系统。
盲点：先选择后理解
在许多组织中，这种复杂性并未正式化，团队都知道，但很少记录在案。
风险在于根据通用标准（合规性、价格、连接器）选择平台，而没有精确描述要覆盖的流程。
因此，一个解决方案可以完美地满足监管要求，但并不适合公司的业务实际。
这种差异不是立即可见的，但它会在实现过程中出现，然后在运行中：
- 以其未遮盖的流动，
- 缺失数据，
- 持续的手工处理，
- 更频繁的拒绝或争议。
地图到飞行员
在这种情况下，映射用例构成了一个结构化步骤。
它包括具体化公司真正所做的事情：
- 开具和接收什么类型的发票，
- 存在哪些特定场景，
- 哪些工具产生数据，
- 有哪些可用信息，
- 手动处理所在的位置，
- 如何组织验证。
这项工作经常揭示当前实践与目标模型要求之间的差距。它还强调了薄弱环节，无论是不完整的数据、隐式流程还是技术依赖性。
除了合规之外，还有一个组织问题
所有所谓的“批准”平台都将确保最低限度：发射、接收、数据传输、状态管理。
然而，区别在于吸收用例复杂性的能力。
具体而言，这决定了自动化能力：
-
- 订单、收据和发票之间的核对，
- 工作流程管理，
- 处理纠纷，
- 甚至是恢复管理。
如果没有事先绘制地图，这些维度仍然难以评估。
一项具有启示意义的改革
电子发票不仅改变了流程。它暴露了现有的脆弱性，并使以前被容忍的做法变得可见：
-
- 缺失或近似数据，
- 非正式验证，
- 并联电路，
- 依赖手工治疗。
通过采用结构化格式和加强可追溯性，它迫使公司将可能仍然隐含的内容正式化。
改变问题
在此背景下，最初的问题是，选择哪个平台？似乎是次要的，结构化问题变成：我们实际上如何计费？
正是从这种理解出发，解决方案的选择才有意义。不是作为对监管义务的标准回应，而是作为符合流动现实的工具。
此次改革规范了发票的运输，但没有规范组织。
