电子发票系统架构：企业系统、税务平台与传输网络各做什么
一张结构化发票从企业系统生成后，怎样通过不同的监管平台或交换网络到达买方？关键是厘清数据、路由、监管校验和业务状态分别由谁负责。
电子发票不是由某一个平台“包办”的单一软件功能。企业系统产生交易数据，映射和校验服务把数据转换成当地接受的格式；集成服务处理身份认证、消息传输、重试和状态回传；在特定制度下，税务机关平台会先验证或接收发票；传输网络负责把文件送到对方；买方系统再做业务匹配、审批和入账。各模块可以由同一家供应商提供，也可以分属不同系统和机构，责任边界仍然需要分清。
1. 发票数据从哪里来，如何变成可交换的信息
数据通常来自销售、采购、订单、物流和财务系统。发票号码、日期、买卖双方税号、商品或服务、数量、单价、税率、税额和付款条件等字段，要能与合同及实际交易对应。企业如果在多个ERP或地区系统中使用不同字段和代码，出站前就需要有一层映射和规则处理。
映射工作包含两个问题：一是字段“叫什么、怎么编码”，二是字段“代表什么”。把内部税码简单复制到发票格式中，并不能保证对方理解它。欧盟 EN 16931 以共同的语义数据模型定义核心发票字段，并通过语法绑定映射到具体消息格式。该标准适用于欧盟电子发票规则覆盖的场景，不是全球所有国家统一采用的发票格式。
截至本文资料核对日，欧盟委员会技术资料说明，EN 16931-1:2026 已于2026年5月发布，2017版已正式撤回；2017版仍在迁移期间保持合规。委员会同时指出，迁移计划仍由相关组织和成员国制定。企业不能只看一个标准名字就锁定接口版本，应核实交易地的实施时间、语法和验证规则。
格式映射之外，还需要校验税率、计税基础、币种、舍入、豁免原因、客户识别码和发票类型等地区规则。校验可以在发送前发现常见错误，减少税务平台或买方拒收；但校验程序只能说明所执行的规则是否通过，不能证明交易本身真实，也不能替企业判断合同解释或税务争议。
2. 集成服务把不同系统接在一起
企业服务层、集成平台或发票服务通常负责把ERP与外部接口连起来。它可以接收ERP发出的业务事件，调用映射和验证规则，附加数字签名或认证信息，选择外部通道，记录发送时间与唯一消息编号，再把返回状态写回业务系统。
这一层还需要处理日常失败：对方暂时不可用时，消息是否进入待重试队列；重复提交时如何识别同一张发票；不同系统用什么编号关联订单、发票和回执；规则升级后如何追踪由哪个版本验证；某一国家接口停止工作时，财务团队从哪里看到未完成记录。它的价值主要体现在控制和可追溯性，而不是单纯多加一层软件。
中大型企业常保留统一的内部发票模型，再通过本地适配器连接国家平台、网络或服务商。这样能减少ERP与每一个外部系统点对点开发，但统一模型也要容纳当地法定字段、差异流程和文件格式。把国家差异强行压平，会让错误藏在映射表和人工补救里。
3. 交换路径并不相同
集中式验证或清关
在这种模式下，发票先提交给税务机关或其指定平台；平台按该地规定执行格式、身份或业务规则检查，并返回接受、拒绝或其他状态。巴西 NF-e 是一个具体例子：国家电子发票门户说明，发票由企业生成并签名，再传给州财政部门（SEFAZ）进行使用授权；授权后相关信息按其操作模型传送到联邦税务局的国家环境。细节要结合巴西税务规则理解，不能简单套用到其他国家。
交换网络传输，税务报告另行处理
Peppol 展示了另一种职责分配。OpenPeppol 将其描述为四角模型：发送企业通过自己的服务提供商和接入点，经过网络到达接收方的服务提供商及接入点，再交付给买方。网络提供寻址、安全传输和互操作规则；它本身不因此等同于税务机关的清关平台。是否需要向税务机关报送发票或交易数据，取决于当地法律及其接入安排。
直连或服务商通道
企业也可能通过API、EDI、SFTP、门户或指定中介直接向买方发送结构化发票。税务报送可以通过另一条接口进行，也可能按周期发生，或者该交易类别没有实时交易级报送要求。欧盟委员会介绍电子发票时，将“生成结构正确的发票”和“从卖方系统传到买方系统”作为两项基本功能；实际成员国规则还会在欧盟共同要求之外增加本国要求。
意大利的 SdI 又说明，集中交换与交付可以由税务机关管理的服务共同承担。意大利税务局说明，适用范围内的电子发票须通过 SdI；该系统执行检查并将文件转给接收方，同时返回送达信息。它还提供多种通信方式，企业可直接连接或委托中介。这个例子能说明角色可以重叠，却不能推出所有国家都需要一个中央交换环节。
4. 回执要按发出者和含义分别处理
同一张发票可能经历几种不同状态。传输服务的确认表示消息被接收或送达；税务平台的回应表示它完成了指定的监管处理；买方的业务响应表示已收到、正在处理、接受、拒绝或提出异议；付款系统的记录则说明付款指令或资金清算进度。
这些状态由不同主体生成，不能压成一个“成功”字段。OpenPeppol 的发票业务流程和响应规范分别覆盖发票交换及买方响应，但具体流程要由使用双方采用的业务规范和当地规则决定。企业集成时应保存状态代码、发送者、接收时间、关联发票号、规则版本和原始回执，并定义长时间没有状态时由谁检查。
传输超时并不总是意味着发票没到；贸然再次开具会造成重复。应先依据消息标识查询原始发送结果，再决定重试还是重新生成。若税务平台拒绝，问题可能在字段、身份或规则版本；若买方拒绝，原因可能是订单或交付不匹配。处理队列和责任团队应能区分这些情况。
5. 归档和监控要覆盖整条链路
归档不能只留一个PDF预览。企业应根据适用法规和审计要求，考虑保存原始结构化数据、发票标识、发送和接收时间、校验结果、税务回执（如适用）、买方审批和异议、会计凭证、修改关系及访问日志。留存期限、签名要求、存储地点和可读性要求都可能因司法辖区而不同。
监控页面最好按业务未完成事项组织：等待发送、外部接口失败、监管节点拒绝、买方尚未处理、金额或订单不匹配、重复风险、等待付款和无法归档。财务人员需要看到待处理发票、负责人和下一步，而不只是基础设施是否在线。数据安全、授权访问、加密、备份和灾难恢复也应纳入系统运行设计。
OECD 2026年关于增值税数字连续交易报告的报告指出，各地制度发展并不同步，系统差异给跨境企业带来合规复杂度。报告讨论的是税务机关如何设计持续报送制度，并不主张所有司法辖区都采用同一种模式。企业系统需按当地规则配置接口、字段和报送时点，同时维持内部数据的一致性。
结论：按责任和数据流搭架构
电子发票架构首先要回答三个问题：交易事实由哪个业务系统提供，发票经过哪些本地规则和外部接口，谁对每一个回执或状态负责。ERP、映射校验、集成服务、税务平台、传输网络、买方系统和档案系统可以组合，但路由送达、监管处理、业务审批和付款是不同结果。
保持内部数据模型的一致性，同时让当地格式、监管报送和网络接入通过清晰的适配层实现。这样能看清国家差异，也能在规则变化时找到需要调整的接口和责任人。本文描述常见架构组件，不替企业决定供应商或部署方式。
适用范围：本文讨论B2B结构化电子发票和增值税/销售税相关数字报告。政府采购、消费端电子收据、工资单、海关单证和电子账簿可能使用不同制度。实施时请核验当地主管机关的最新文件和生效日期。
资料与来源
- 欧盟委员会：What is eInvoicing。用于说明结构化发票与卖方到买方传输是两项基本功能；页面侧重欧盟公共采购及 EN 16931 语境。
- 欧盟委员会：符合电子发票标准。用于解释语义模型、业务规则及其到具体语法的映射。
- 欧盟委员会：欧洲标准与技术规范。页面记载 EN 16931-1:2026 于2026年5月发布及旧版迁移状态；具体安排需查看各国主管机构更新。
- OpenPeppol：互操作框架，说明Peppol网络及四角模型。
- OpenPeppol：BIS Billing 3.0，说明卖方发送、买方接收及处理发票的业务流程。
- 巴西国家电子发票门户：NF-e 常见问题。用于说明SEFAZ授权和巴西操作模式。
- 意大利税务局：电子发票流程说明。用于说明SdI检查、传递和通信渠道。
- 欧盟委员会：VAT in the Digital Age (ViDA)。用于说明跨境数字报告安排，不代表所有交易都通过单一交换平台。
- OECD (2026)：Digital Continuous Transactional Reporting for VAT。用于理解各地持续交易报告设计及跨境差异。
这些官方文件和标准用于解释系统角色及具体制度例子，不构成全球统一架构规范。本文不提供法律、税务或安全实施意见。
How E-Invoicing Systems Fit Together: Business Software, Tax Platforms and Exchange Networks
A structured invoice moves through business software, validation and integration services, regulatory systems or exchange networks, and the buyer’s own processes. The architecture becomes clear when each component’s role is defined.
E-invoicing is not one platform that handles every task. Business systems produce transaction data. Mapping and validation services convert it into locally accepted structures. Integration services manage authentication, transport, retries and status updates. In some regimes, a tax authority platform validates, clears or receives the invoice. A network routes the document to the counterparty. The buyer then matches it to orders and deliveries, approves it and posts it to accounts payable. One vendor may provide several components, but their responsibilities remain distinct.
The diagram above is a reference model, not a universal country design. Tax platforms perform legally defined reporting, validation, authorisation or receipt functions. Exchange networks provide addressing, secure transport and interoperability. Some systems combine these roles; others keep them separate.
1. Transaction data and invoice semantics
Invoice data usually originates in sales, procurement, order, logistics and finance systems. Parties need to connect invoice numbers, dates, tax identifiers, goods or services, quantities, prices, tax rates, amounts and payment terms to the underlying transaction. Where companies use several ERP systems and local codes, data mapping is required before an invoice leaves the enterprise.
Mapping has both a technical and a semantic dimension. Fields must be encoded in a syntax, and both parties must understand what each field means. The EU’s EN 16931 standard defines a semantic model for core invoice data and bindings to supported syntaxes. It applies within the European e-invoicing framework; it is not a single global invoice format.
As of 27 October 2026, European Commission technical material says EN 16931-1:2026 was published in May 2026 and the 2017 edition was formally withdrawn, while remaining compliant during a migration period. The Commission says migration plans are being developed. Businesses should confirm versions, syntax and validation rules with authorities in the countries where they operate.
Local validation can check formats, required fields, tax calculations, currencies, rounding, exemption codes and party identifiers. Passing a validator means only that the checks it performs have passed. It does not prove that a transaction occurred or settle a contractual or tax dispute.
2. Integration services connect internal and external systems
An enterprise service layer, integration platform or e-invoicing service links the ERP to external interfaces. It can accept a business event, apply mapping and validation rules, add authentication or signature data where required, select an outbound channel, assign a message identifier, record timestamps and return external statuses to the source system.
This layer also handles ordinary failures: messages waiting for an unavailable endpoint, duplicate submissions, identifiers used to reconcile invoices with orders and acknowledgements, rule-version tracking, and open items during an outage. Its value lies in control and traceability, not simply adding another software tier.
Many companies use a common internal invoice model with local adapters for tax systems, networks and service providers. The model must still preserve legally required local fields and process differences. Flattening those differences can hide errors in mapping tables and manual workarounds.
3. Exchange paths differ by jurisdiction
Central clearance or validation
In a central model, an invoice first goes to a tax authority or designated platform. That system performs checks required by the jurisdiction and returns an acceptance, rejection or other status. Brazil’s NF-e is one example: the national portal describes an issuer generating and signing the invoice, then sending it to the state finance department (SEFAZ) for authorisation. Under the operating model, SEFAZ forwards the information to the Federal Revenue Service’s National Environment. Authorisation confirms specified identity, format and formal checks; it does not mean that SEFAZ verifies the commercial substance of the transaction. The legal effects belong to Brazil’s NF-e rules.
Exchange networks with tax reporting handled separately
Peppol illustrates a different division of responsibility. OpenPeppol describes a four-corner model: the supplier sends through its service provider and access point, the network routes the document, and the recipient’s provider and access point deliver it to the buyer. The network provides addressing, secure transport and interoperability; it is not thereby a tax-authority clearance platform. Whether invoice or transaction data must also be reported to a tax authority depends on local law and implementation.
Direct or service-provider channels
Companies may exchange structured invoices through APIs, EDI, SFTP, portals or intermediaries. Tax reporting may use a separate interface, occur periodically, or not be required at transaction level for a particular class of trade. The European Commission describes two basic functions: creating a correctly structured invoice and transferring it from the seller’s system to the buyer’s. Member States can add national rules.
Italy’s Sistema di Interscambio (SdI) shows how roles can overlap. Italy’s Revenue Agency says invoices within the relevant scope must pass through SdI, which performs checks, forwards invoices to recipients and provides delivery information. Businesses can use different communication channels and connect directly or through an intermediary. This is an Italian operating model, not a template every country must follow.
4. Status messages need owners and definitions
An invoice can generate several status messages. A transport acknowledgement records that a message was received or delivered. A tax-platform response records a specified regulatory action. A buyer response records receipt, processing, approval, rejection or a dispute. A payment system records a payment instruction or settlement event.
Different actors create these statuses, so a single “success” field is misleading. OpenPeppol’s billing and response specifications cover exchange and buyer responses, but the process depends on the parties’ profile and local rules. Useful records include the code, issuer, timestamp, invoice and message identifiers, rule version and original response. Teams also need an owner for items with no response.
A transport timeout does not always mean an invoice failed to arrive. Before resending, teams should check the original message identifier to avoid duplicate issuance. A tax rejection may concern a field, identifier or rule version; a buyer rejection may concern an order or delivery. Separate queues help distinguish these issues.
5. Monitoring and records cover the whole chain
Archiving only a PDF preview is insufficient for many operational and audit needs. Subject to applicable rules, records may include the original structured invoice, identifiers, timestamps, validation results, tax responses where applicable, buyer approval or dispute, accounting entries, modification links and access logs. Retention periods, signature requirements, storage locations and readability requirements vary by jurisdiction.
Operational dashboards should surface unresolved business items: invoices waiting to send, failed endpoints, regulatory rejections, missing buyer responses, purchase-order mismatches, duplicate risks, payments pending and records not yet archived. Finance teams need to see the invoice, owner and next action—not merely whether infrastructure is online. Access controls, encryption, backups and recovery also belong in the operating design.
The OECD’s 2026 report on digital continuous transactional reporting notes that jurisdictions are developing different regimes, creating compliance complexity for cross-border businesses. It discusses tax-reporting policy and design; it does not recommend one universal architecture. Companies need locally configured interfaces and reporting schedules alongside consistent internal data.
Conclusion: organise the architecture around responsibilities and data flows
Start with three questions: which business system owns transaction data, which local rules and external interfaces the invoice must pass through, and who owns each returned status. ERP, mapping, integration, tax platforms, exchange networks, buyer systems and archives can be combined in different ways, but routing, regulatory processing, buyer approval and payment are different outcomes.
Keep internal data consistent and connect it to local formats, reporting rules and exchange channels through clearly defined adapters. This makes country differences visible and shows which interfaces and owners change when rules change. This article describes common components; it does not select vendors or dictate an enterprise deployment.
Scope: This article discusses structured B2B e-invoices and VAT/GST-related digital reporting. Public procurement, consumer receipts, payroll, customs documents and e-ledgers may follow different regimes. Verify the current requirements and effective dates with the competent authority in each jurisdiction.