电子发票的本质,不是一份电子文件。
它是同一笔交易在某个时点形成的、可以追溯和验证的法律与业务表达。一笔交易中的履约、商业结算和法定税务事实,可能发生在不同时间。发票负责把这些事实关联起来,但不会让它们变成同一个事实。
一张“发票”背后的三类事实
| 业务事实 | 它回答的问题 | 常见凭证 |
|---|---|---|
| 履约事实 | 什么货已经交付,什么服务已经完成? | 出库、交货、验收、服务确认 |
| 商业结算事实 | 客户应付多少、何时到期、是否已经付款? | Billing、商业发票、应收、收款与清账 |
| 法定税务事实 | 什么内容已经依法开具、申报、校验或批准? | 法定号码、UUID/IRN、税局状态与时间戳 |
三类事实可能共用金额、客户和订单引用,但它们的号码、日期、状态和更正规则相互独立。
因此,电子发票设计首先要问的不是“这个字段从哪里取一个值”,而是:
- 当前表达的究竟是哪一个业务事实?
- 这个事实的唯一权威来源在哪里?
- 事实缺失或冲突时,系统应该在哪里阻断?
场景一:收款发生在交货之前
企业收到预付款时,资金已经发生变化,商业上也形成了继续履约或退款的义务,但货物可能还没有交付、服务也没有完成。
有些国家还要求企业针对预收款或分期付款形成法定税务单据。这样,同一笔交易会先后出现预收款、预收款税票、实际交货、尾款和最终结算。
国家补充:印尼税务总局说明了预收款或分期付款对应的Faktur Pajak处理。因此,商业发票引用、Faktur Pajak法定号码、付款日期和交货日期可能各不相同。
场景二:开票和货物移动不在同一天
未来交货场景中,买卖双方已经确认交易,企业也可能已经形成商业开票或法定单据,但货物仍在仓库。等货物真正出库时,又会形成新的物流事实以及相应的税务事实。
这时,商业交易成立、法定开票、实际出库和客户付款可能分布在四个不同时间点。
国家补充:巴西戈亚斯州的官方指引中,未来交货可以先开用于简单开票的NF-e;货物实际移动时再开另一张NF-e并引用前一张。付款还可能早于实际交货。
场景三:一笔交易被分成多次履约和结算
一张订单不一定对应一次交货、一张商业发票和一张法定电子发票。
一张订单可能分成多次交货;一个服务合同可能按里程碑逐步验收;多次交货也可能合并结算。相反,一次履约也可能按预付款、进度款、尾款分成多次收款。
因此,订单、交货、验收、Billing、法定电子发票和付款之间,往往是多对多关系,而不是简单的一对一关系。每一次履约和结算都必须保留自己的数量、金额、日期和引用。
场景四:业务单据已经存在,法定电子发票还没有成立
企业业务系统可以先生成Billing或商业发票,但法定电子发票平台可能仍处于草稿、处理中、拒绝或待修正状态。
商业发票存在,并不代表法定电子发票已经成立;平台验证通过,也不代表货物已经发出或客户已经付款。
国家补充:马来西亚MyInvois在验证成功后才接受电子发票;印度源发票提交到Invoice Registration Portal并取得IRN后,才形成相应的注册结果。两者都说明业务源单和法定结果必须分别记录。
场景五:发票注册和货物运输是两套控制
对于实物交易,法定电子发票和运输凭证可以互相关联,但它们解决的问题不同。
电子发票证明交易在税务上的申报或成立状态;运输凭证则证明货物是否具备运输依据,以及实际从哪里运到哪里。
国家补充:印度的IRN与e-Way Bill体现了这种分离。发票注册成功和货物具备运输凭证,是两套相连但不同的状态。
场景六:法定数据、传输通道和可读页面不是一回事
电子发票可能通过电子邮件、Peppol、税务平台、企业门户或者接口传输,也可以被展示成PDF或网页供人阅读。
但是,法定结构化数据、传输通道和可读视图属于不同层次。更换邮件为Peppol,不会自动改变发票的法律内容;重新生成PDF,也不应该改变已经成立的法定事实。
国家补充:德国电子发票强调结构化数据的可电子处理能力,而邮件、Peppol等属于传输方式,PDF或页面属于可读展示。
场景七:退货、冲销和更正不能改写历史
一张法定电子发票一旦被接受,后续发生退货、价格调整、取消或错误更正时,不能简单覆盖原来的法定号码、税局时间、金额和状态。
正确的处理方式,是根据适用规则形成明确关联的红字、贷项、借项、替换或更正单据,并保留原票与新单据之间的关系。
原交易、原法定发票、更正发票、退货实物流和退款,也仍然是相互关联但彼此独立的事实。
国家差异,只是同一本质的不同实现
不同国家的差异主要体现在触发时点、平台、法定号码、报文格式、传输方式和更正单据上。
但底层问题始终一致:先确认发生了什么业务事实,在唯一权威位置记录它,再把它与其他事实建立明确关系;法定数据缺失或冲突时,应当阻断,而不是从其他字段中猜一个值继续发送。
全球系统应该怎样记录
一个稳健的全球电子发票系统,应当分别保存:
- 履约数量、交货日期、服务完成和验收证据;
- Billing号码、商业发票号、金额、币种和到期日;
- 收款、退款、清账日期及资金引用;
- 法定电子发票号码、UUID/IRN、税局状态与时间戳;
- 适用场景下的运输凭证;
- 原票与红字、贷项、借项、替换或更正单据的关系。
每一条事实链维护自己的状态和异常处理,再通过明确引用完成对账。Readiness检查必须与最终法定报文实际读取的权威来源一致;缺失时明确提示和阻断,不能用商业、物流或测试默认值静默补齐。
电子发票真正复杂在哪里
电子发票真正困难的地方,不是把PDF变成XML,也不是为每个国家复制一套接口。
真正的难点,是在预收、交货、分批履约、平台验证、运输、付款和更正等不同场景中,保持履约、商业结算和法定税务事实各自准确,同时又能长期关联和对账。
系统只有先承认“发票不是一个对象,而是一组业务事实之间的关系”,才能真正支持全球电子发票。
国家官方参考
- 印尼:预收款与结清Faktur Pajak
- 巴西戈亚斯州:未来交货的开票与货物移动
- 印度:Invoice Registration Portal FAQ
- 马来西亚:MyInvois FAQ
- 德国联邦财政部:电子发票FAQ
各国规则会持续变化,实际适用范围和税务解释应以当地官方指引及专业顾问意见为准。