采购发票对账：采购单号、费用类别和税项不要混成一列

行政采购外包交接时，一份表格可能同时装着订单号、采购单号、商品金额和运费。看起来信息齐全，接手人却未必能解释一行数字属于哪张单据。问题常出在整理时丢掉了字段之间的关系：编号只剩一个，费用也只剩一个总额。

Amazon Business 的 Invoices API 参考文档可以作为字段识读的具体例子。本文所读版本号为2026-02-01，文档标明的区域是日本；这个日期是接口版本，并不表示本文讨论的结构适用于所有地区或其他采购平台。

在该接口的发票行项目中，订单元数据与采购单信息分属不同对象，发货信息又是另一项。采购单信息本身可以不出现，出现时其中的采购单号是必填字段，而行项目参考号是可选字段。因此，整理人员不能因为表格设了“采购单号”一栏，就断言每一条导出记录原本都应当带有该值。空缺应区分为原数据未提供、提取遗漏或尚待核对。

费用也有两个阅读维度。文档的类别区分商品小计、运输处理、促销、折扣和其他费用等；类型则区分本金性质金额与税项。把类别和类型都压缩成“费用名称”，会让接手人难以判断一笔税项对应什么收费。金额列还应保留原币种和原始符号，不能在不了解数据口径时擅自把折扣都改成负数或把含税总额再次加税。

用于交接的整理稿，可以先保留原发票行标识，再依次放入订单关联、采购单关联、收费类别、收费类型以及原始金额。它不必一次完成所有自动计算，但应能让每个汇总数返回具体原始记录。无法建立关联的行单列待核，不要为了让表格整齐而随便补一个附近的订单号。

最后，接口里存在某种费用类别，只能说明系统有相应表达位置，不能证明某个服务商有权收取这笔钱。本文没有查看真实发票或采购合同，也不判断税额抵扣、付款责任及外包服务收费是否合理。把数据结构说明白，能为后续核验留下入口；决定具体金额和责任，还需要对应业务凭据与适用规则。