电子发票格式识别
校验一张电子发票之前,你得先知道它是什么。粘贴 XML,拿到它的语法、种类和规范 —— 以及该用哪个校验器。
🔒 你的数据不会离开浏览器。
为什么说它是正门
一张 EN 16931 发票可能以两种完全不同的 XML 形态到达 —— OASIS UBL(根元素 Invoice 或 CreditNote)和 UN/CEFACT CII(根元素 CrossIndustryInvoice)—— 用互不相干的元素树装着同样的信息。为其中一种写的校验器读不了另一种。所以第一个问题从来不是「它合不合法」,而是「它是哪一种,适用哪套规则」。
决定一切的字段是 CustomizationID
只有一个元素 CustomizationID 声明这张发票自称遵循哪套规范。它是关于一张电子发票最有用的一个事实,因为现实里最常见的拒收并不是哪条业务规则坏了 —— 而是文件被发给了一个运行着另一套规范的接收方,和它自己声明的不一样。文件本身没问题;只是它声称遵循的规则,不是接收方在检查的那一套。
| 规范 | 是什么 |
|---|---|
| Peppol BIS Billing 3.0 | EN 16931 在 Peppol 网络上的规范 —— 补上了经由 Peppol 网络投递发票所需的规则。 |
| XRechnung(扩展版) | EN 16931 的德国 CIUS,扩展变体 —— 在核心标准之上叠加 XRechnung 规则,另含德国的附加项。 |
| XRechnung | EN 16931 的德国 CIUS —— 向德国公共机构开票时必须使用,在德国 B2B 中也被广泛采用。 |
| EN 16931(核心标准,无国别规则) | 欧洲核心发票标准,不叠加任何国别规则。它是合法的,但期待某个国别规范的接收方仍可能拒收。 |
规范的 URN 是核实来的,不是凭记忆写的
本工具认得的每一个 CustomizationID 都取自一手来源,而不是凭记忆敲出来的:Peppol 的值来自 Peppol 规范,XRechnung 的值抽取自 KoSIT 公开发布的 Schematron。XRechnung 按族匹配,所以当前的 xeinkauf.de 命名空间和旧的 xoev-de 命名空间都认得,版本号也直接从标识符本身读出来。
三层规则,以及为什么一张合法的发票照样被拒收
EN 16931 是核心。国别或网络规范 —— Peppol、XRechnung —— 是在核心之上叠加规则的定制化:Peppol 补上网络需要的规则,XRechnung 补上德国接收方需要的规则。一张发票可以满足核心标准,却仍然过不了接收方运行的那一层。适用的是哪一层,正是这个识别器在你花时间去对规则之前先回答的问题。
它不做的事
它不检查业务规则 —— 它只识别和指路。本站有对应校验器的,会点出名字;CII 文件能被识别出来,但这里的发票校验器读的是 UBL。它是地图,不是旅程。
本工具执行的全部检查(共 11 条规则)
IDD-P01 XML 格式不正确
要说一份文件遵循哪套标准,它先得能被解析。一个没闭合的标签、一个多出来的尖括号或者一个坏掉的实体,都会让读取停在一个确定的位置 —— 下游的每一个校验器也都会停在那里。
修复: 先修好指出位置处的标记,再重新识别这份文件。
IDD-S01 已识别出语法
一张 EN 16931 发票使用两种 XML 语法之一:OASIS UBL,根元素是 Invoice 或 CreditNote;UN/CEFACT CII,根元素是 CrossIndustryInvoice。两者用完全不同的元素树装着同样的信息,为其中一种写的校验器读不了另一种。
IDD-S02 这不是我们认得的电子发票语法
根元素既不是 UBL 的 Invoice 或 CreditNote,也不是 CII 的 CrossIndustryInvoice。它可能是另一种业务单据、另一套标准,或者根本就不是发票的 XML —— 但无论是哪种,本识别器以及它指向的校验器都读不了它。
修复: 确认这确实是一张 EN 16931 的 UBL 或 CII 发票。
IDD-K01 单据种类
一份单据是发票还是贷记单,由它的根元素决定,而不是由里面的任何金额决定。把贷记单当发票校验,会在本不适用的规则上失败;反过来,则会漏掉本该适用的规则。
IDD-K02 语法认得,但不是发票或贷记单
这份文件是合法的 UBL 或 CII,但它的根是别的单据类型 —— 订单、发货通知之类。发票校验器不适用于它。
修复: 改用与这种单据类型对应的工具;本识别器和发票校验器只针对发票与贷记单。
IDD-C01 没有声明规范
CustomizationID 这个字段告诉接收方,这份文件自称遵循哪一套规则。没有它,文件就是一张格式正确、却没有指明任何规范的发票,接收方只能去猜该用哪套规则 —— 或者干脆以没有声明为由拒收。
修复: 把 CustomizationID 设成这份文件所依据的规范。
IDD-C02 声明的规范已识别
CustomizationID 对上了一个已知规范,所以适用哪些规则是确定的。这是关于一张电子发票最有用的一个事实:它决定了文件必须通过哪个校验器;而现实中最常见的拒收,就是文件被发给了一个运行着另一套规范的接收方,和它自己声明的不一样。
IDD-C03 声明了规范,但不是我们认得的
文件写了一个本工具不认识的 CustomizationID。它可能是尚未覆盖的国家的国别规范、一个更新的版本,或者一个敲错的值。接收方只要没有运行这个确切的规范,就会拒收这份文件 —— 哪怕里面的每一条业务规则都是对的。
修复: 确认 CustomizationID 与接收方期望的值逐字一致。
IDD-R01 适用哪个校验器
识别出规范,只有在它告诉你下一步做什么时才有用。本站有对应校验器的,会点出它的名字,让文件按正确的规则检查,而不是按一个笼统的猜测。
IDD-M01 这里能识别 CII,但发票校验器读的是 UBL
本识别器认得 CII,也读取它的上下文,但本站的发票校验器目前检查的是 UBL 文件。CII 文件会被识别并说出规范名,所以你知道它是什么;要校验它的业务规则,需要一个能读 CII 的检查器。
IDD-V01 语法版本
UBL 和 CII 各有自己的版本号,和发票规范是两回事。文件里写明了就会报出来,因为为某一个版本写的校验器或接收方,即使规范对得上,也可能在另一个版本上出岔子。
本工具只做识别与指路,不校验业务规则。它认得的规范列在上面,每一个都出自核实过的来源。
关于这些规则。 每一条都有编号、严重级别和通俗解释。每个来源链接都已登记在案,并对线上页面实际复验过,而不是凭印象写上去的;本工具的来源最近一次复验于 2026年8月23日. 规则如何编写、测试与保持更新 →