50张票据交给多模态AI：金额都读对了，为什么总账还是错的？

50张发票和付款截图交给多模态 AI 后，它几乎都读对了金额。

但把结果加总，我却发现总支出明显偏大——同一笔消费的订单页、付款截图和电子发票，被它算了三遍。

这类错误比“看错一个小数点”更危险。金额识别错了，通常一眼就能发现；重复记账却可能让每一行看起来都合理，直到月底对账时才发现：表格很整齐，账却对不上。

这也是多模态 AI 处理财务凭证的真正门槛：不是从图片里读出数字，而是判断哪些图片属于同一笔交易、应该归到什么类别，以及为什么这样判断。

AI能把图片变成字段，但“凭证”不等于“交易”。

先把实验标准定下来，否则“识别准确”没有意义

这次测试使用50张混合图片，覆盖日常记账和报销中常见的凭证类型：

• 15张电子发票或发票截图
• 10张纸质发票照片
• 10张微信、支付宝付款截图
• 5张银行卡扣款通知
• 5张电商订单详情页
• 5张退款、冲正或重复截图

图片先统一编号为 IMG_001 到 IMG_050，并遮盖姓名、手机号、地址、银行卡号、订单号、发票代码及号码等敏感信息。时间、商户和金额结构则保留下来，供模型判断凭证关系。

在把图片交给 AI 之前，还必须人工制作一份“标准答案”，至少标注：

• 图片总数
• 实际独立交易数
• 重复凭证组数
• 总实付金额
• 发票金额与实付金额不一致的交易数
• 需要人工判断的模糊分类数

这里有一个容易被忽略的细节：标准答案必须先由人工完成并封存，不能根据模型输出反向修改。

否则，AI 说有多少笔交易，我们就把多少笔当成答案，评测最终只会变成模型给自己打分。

首轮测试中，我要求模型直接提取日期、商户、金额和类别，再输出一张汇总表。结果并不意外：单张图片看，字段大多可以正常读取；放到交易级别看，重复记账、金额口径混乱和退款遗漏开始集中出现。

问题不在“眼睛”，而在“大脑”。

金额为什么好识别，去重为什么特别容易翻车

发票上的“价税合计”、付款页面上的“实付金额”，通常有清晰的版式和视觉层级。对支持图片理解的模型来说，读取这些字段已经不算特别困难。

但去重需要理解图片之间的关系。

一笔交易，可能有三份凭证

最典型的情况是，一次采购同时留下：

1. 电商订单详情页

2. 微信或支付宝付款截图

3. 商家开具的电子发票

如果按图片数量统计，系统会得到三笔支出；如果按真实交易统计，它们只能对应一笔账。

首轮输出中，订单页、付款截图和发票分别占了一行。每一行的商户和金额都像真的，但总账被重复放大。

正确做法不是删除其中两张图片，而是建立一个交易对象，并把三张图片作为它的关联证据：

{
"transaction_id": "T-001",
"merchant": "某电商平台",
"transaction_date": "2025-03-08",
"order_amount": 128.00,
"paid_amount": 108.00,
"invoice_amount": 128.00,
"category": "办公用品",
"evidence_ids": ["IMG_003", "IMG_017", "IMG_026"],
"dedup_reason": "订单号一致，商户一致，日期相近",
"confidence": 0.86,
"review_status": "pending"
}

这里最关键的设计是：交易和凭证不是同一个对象。

一笔交易可以关联多张凭证，一张退款凭证也可能需要关联到更早的一笔原交易。

金额相同，不代表是同一笔

另一组常见案例，是同一天出现两笔金额相同的打车或餐饮消费。

如果规则只是“商户相同＋日期相同＋金额相同”，系统很可能把两笔真实消费错误合并。反过来，同一笔交易因为优惠券、运费或部分开票，几张凭证上的金额又可能不相同。

因此，金额＋日期只能用于生成候选组，不能直接作为去重结论。

更可靠的判断顺序应该是：

1. 优先比较订单号、发票号等唯一标识

2. 比较商户、商品或服务内容

3. 检查交易时间是否处于合理窗口

4. 对照支付渠道和付款账户

5. 比较订单金额、实付金额、开票金额

6. 结合图片相似度识别截图、裁剪图和连拍照片

7. 证据不足时标记为“待复核”

去重系统最怕的不是“不敢合并”，而是“过度自信地合并”。

三种金额，不能只保留一个

存在平台优惠时，一张订单里可能同时出现：

• order_amount：商品或服务原始订单金额
• paid_amount：用户最终实际支付金额
• invoice_amount：商家实际开票金额

例如，订单金额为128元，使用优惠后实付108元，发票仍可能按128元开具。也可能因为部分商品不可开票，最终发票金额低于实付金额。

如果系统只保留一个 amount 字段，后续很难判断到底应该按哪个口径记账。

个人记账通常更关注实付金额，报销流程还需要核对开票金额，项目成本分析则可能需要保留订单原价与优惠信息。金额不一致不一定是识别错误，也可能是业务事实。

退款不是收入，而是原交易的后续状态

退款截图也很容易被模型单独识别为一笔“收入”，或者被直接忽略。

更合理的处理方式，是为退款记录提取原订单号、退款金额、退款时间和支付渠道，再尝试关联原交易。部分退款不能简单删除原支出，而应保留原始支付和后续退款两段记录，计算净支出。

模型至少应该主动标记三类异常：

• 找到退款，但没有找到原交易
• 原交易存在，但退款金额超过实付金额
• 退款与原交易的商户、订单号或支付渠道无法对应

归类不是看商户，而是先把规则写清楚

完成去重后，第二个麻烦是分类。

同一家便利店，买咖啡可能属于餐饮，买打印纸可能属于办公用品，买礼品可能属于业务招待或员工福利。仅凭商户名称，AI不可能稳定判断费用性质。

酒店订单也可能同时包含住宿、早餐、会议室和服务费；云服务账单可以是软件订阅，也可以归入某个项目的直接成本。

如果只给模型一句“请自动分类”，它往往会生成听起来合理、但前后不一致的答案。

更可执行的方法是两阶段分类。

第一阶段：先进入稳定的一级类别

例如：

• 差旅交通
• 住宿
• 餐饮
• 办公用品
• 软件与云服务
• 业务招待
• 员工福利
• 退款与冲正
• 待确认

第二阶段：结合上下文细分

再根据用途、项目、报销主体、商品明细等信息，补充：

• 所属项目
• 成本中心
• 是否可报销
• 是否属于个人消费
• 是否需要拆分记账

分类字典还应明确优先级和正反例。例如，“商户是便利店”不能直接归为餐饮；只有商品明细为食品，且用途符合公司规则时，才进入相应类别。

无法确认时，输出“待人工确认”比强行给答案更专业。

一段可复制的提示词，但它不是万能药

下面这段提示词可以作为第一轮测试模板：

你将收到一组发票、订单页和付款截图。

任务不是按图片数量统计，而是识别其中的独立交易。

请执行以下步骤：
1. 为每张图片提取：图片编号、凭证类型、商户、交易日期、
开票日期、订单号、发票号、订单金额、实付金额、开票金额、
退款金额、支付渠道。
2. 判断哪些图片可能对应同一笔交易，并列出关联依据。
3. 不要仅凭金额相同就合并；优先参考订单号、发票号、商户、
日期时间、支付渠道和商品信息。
4. 对无法确定是否重复的图片标记为“待复核”，不要强行合并。
5. 按给定分类字典归类，并说明分类依据。
6. 每笔独立交易必须保留对应的原始图片编号。
7. 分别输出：
- 图片级字段表
- 交易级汇总表
- 待复核清单
- 异常清单

它比“帮我识别这些发票并汇总”更可靠，因为任务被拆成了字段提取、交易聚合、分类和异常检测。

但提示词无法独自解决所有问题。图片数量增加后，还需要程序负责文件管理、结果校验、批次处理和失败重试。

可交账的系统，必须保留证据链

只让 AI 输出一张最终表格，最大的问题不是表格可能出错，而是出错后无法追溯。

一条可审计的交易记录，至少应该包含：

• 交易编号
• 商户与日期
• 订单金额、实付金额、开票金额
• 原始图片编号
• 图片识别原文
• 关联凭证列表
• 去重理由
• 分类依据
• 模型置信度
• 异常说明
• 人工复核状态
• 人工修改记录

推荐工作流如下：

上传前，可以先用文件哈希发现完全相同的重复文件：

import hashlib
from pathlib import Path

def file_hash(path):
data = Path(path).read_bytes()
return hashlib.sha256(data).hexdigest()

seen = {}

for path in Path("receipts").glob("*"):
digest = file_hash(path)

if digest in seen:
print(f"完全重复：{path.name} -> {seen[digest]}")
else:
seen[digest] = path.name

不过，文件哈希只能发现字节完全一致的文件。图片经过裁剪、压缩、重新截图，或者换一个角度拍摄后，哈希就会变化。后续仍需结合图像相似度和交易字段判断。

数据保存也应至少分成三层：

1. 原始层：未经修改的图片与文件哈希

2. 模型层：模型第一次提取的字段和判断依据

3. 复核层：人工确认、修改内容与操作记录

不要让修改后的Excel覆盖原始输出。否则一旦出现争议，很难确认错误来自原图、模型还是人工调整。

从“能识别”到“能交账”，评估指标必须换一套

多模态 AI 的票据能力不能只看金额字段准确率。完整评测至少应包含以下指标：

本文不填入未经完整复核的伪精确百分比。实际测试时，应把每项指标按人工标准答案计算并公开分母，而不是只给一个笼统的“综合准确率”。

改造工作流后，最明显的变化也不只是“识别更准”，而是系统开始区分确定结果、候选关联和待复核项目。最终账目因此更接近人工标准，同时每一笔结论都能返回原图检查。

这才是多模态 AI 真正能够创造的价值：压缩整理和核对成本，而不是绕过财务判断。

如何复现这套票据整理流程

如果你也想测试自己的发票、订单截图或付款记录，可以通过 api.884819.xyz 使用平台内置的AI对话功能，或接入支持图片理解的模型，先跑一轮图片级字段提取，再按照本文的交易聚合模板进行去重与分类。

建议先从经过脱敏的少量样本开始，对比不同模型在结构化输出、重复判断和证据引用方面的表现，再决定是否批量处理。

8848AI使用用户名和密码即可注册，不需要邮箱验证；没有月租和订阅，按量付费，Deepseek、千问等国产模型完全免费，注册后可以直接使用平台内置AI对话功能。

上传真实票据前，请先确认相应的数据处理与保存规则，并对身份证号、地址、手机号、银行卡号、完整订单号和发票号码等敏感信息进行脱敏。

多模态 AI 可以把50张图片变成一份可检查的候选账目，但不能把“读到了什么”自动等同于“这笔账应该怎么记”。

真正可用的系统，不是永不犯错，而是每个结论都能回到原始凭证复核。

这次解决的是“50张图片如何变成可复核的账目”。但当图片增加到500张甚至5000张时，新的问题会立刻出现：不可能一次性把所有图片塞给模型，不同批次还可能重复生成同一笔交易。

下一篇，我们将实测一套批量处理方案：如何切分任务、控制上下文、处理失败重试，并完成跨批次去重。

#多模态AI #AI财务 #发票识别 #自动化记账 #Prompt技巧 #AI教程 #8848AI