智能发票报销Agent系统【附带源码】
在企业日常运营中，发票报销是高频且繁琐的财务流程。传统方式依赖人工逐一核对发票信息、手动录入报销系统，不仅效率低下，还容易出现信息录入错误、分类混淆等问题，尤其面对网约车、餐饮、通讯费等不同类型发票时，字段差异大、处理规则复杂，进一步增加了财务人员的工作负担。
本系统通过多Agent协同架构，实现了发票报销的全流程自动化。系统利用MinerU API精准解析PDF发票，通过分类Agent智能识别发票类型，自动路由至对应的网约车、餐饮或通讯费Agent进行结构化信息抽取，最终完成报销提交。整个过程无需人工干预，支持千帆和Ollama双LLM后端，大幅提升了报销效率，降低了人工成本和错误率，为企业财务数字化转型提供了高效可靠的解决方案。
作者：百度 谭文涛
基于大模型的多Agent协同发票报销系统，支持网约车、餐饮、通讯费三类电子发票的自动解析、分类、信息抽取与报销提交
系统架构
┌─────────────────────────────────────────────────────────────┐
│ 主流程编排器 (Orchestrator) │
│ │
│ Step 1: MinerU API 解析PDF → Markdown │
│ ↓ │
│ Step 2: 发票分类Agent → 判断发票类型（网约车/餐饮/通讯费） │
│ ↓ │
│ Step 3: 路由到对应子Agent → 抽取结构化JSON │
│ ├── 🚗 网约车发票报销Agent │
│ ├── 🍽️ 餐饮发票报销Agent │
│ └── 📱 通讯费发票报销Agent │
│ ↓ │
│ Step 4: 模拟报销API → 提交报销记录 │
│ ↓ │
│ 保存JSON到output目录 │
└─────────────────────────────────────────────────────────────┘协作模式
串行流水线模式：每个发票文件依次经过 解析→分类→抽取→报销 四个步骤，步骤间严格串行执行。
文件结构
invoice-reimbursement-mas/
├── main.py # 主入口
├── config.py # 全局配置
├── core/
│ ├── __init__.py
│ ├── llm_client.py # LLM调用封装（千帆+Ollama双后端）
│ ├── mineru_parser.py # MinerU API PDF解析封装
│ ├── reimburse_api.py # 报销API模拟模块
│ └── orchestrator.py # 主流程编排器
├── agents/
│ ├── __init__.py
│ ├── classifier_agent.py # 发票分类Agent
│ ├── ride_agent.py # 网约车发票报销Agent
│ ├── meal_agent.py # 餐饮发票报销Agent
│ └── telecom_agent.py # 通讯费发票报销Agent
└── output/ # 输出目录（发票JSON + 汇总报告）运行方式
# 默认千帆LLM，处理指定目录下所有PDF
python3 main.py /path/to/invoices
# 处理单个PDF文件
python3 main.py /path/to/invoice.pdf
# 使用Ollama本地模型
python3 main.py --ollama /path/to/invoices
# 显示帮助
python3 main.py helpLLM后端支持
|
后端 |
配置 |
模型 |
|---|---|---|
|
百度千帆（默认） |
LLM_PROVIDER=qianfan |
ernie-x1-turbo-32k |
|
本机Ollama |
LLM_PROVIDER=ollama
或 |
qwen2.5:7b |
抽取字段说明
🚗网约车发票
|
字段 |
说明 |
|---|---|
invoice_code |
发票代码 |
invoice_number |
发票号码 |
invoice_date |
开票日期 |
seller_name |
销售方名称（出行平台） |
seller_tax_id |
销售方纳税人识别号 |
buyer_name |
购买方名称 |
buyer_tax_id |
购买方纳税人识别号 |
total_amount |
合计金额（不含税） |
total_tax |
合计税额 |
amount_in_words |
价税合计（大写） |
amount_in_figures |
价税合计（小写） |
ride_service |
出行服务类型 |
ride_platform |
出行平台名称 |
ride_time |
出行时间 |
ride_origin |
起点 |
ride_destination |
终点 |
🍽️餐饮发票
|
字段 |
说明 |
|---|---|
invoice_code |
发票代码 |
invoice_number |
发票号码 |
invoice_date |
开票日期 |
seller_name |
销售方名称（餐厅） |
seller_tax_id |
销售方纳税人识别号 |
buyer_name |
购买方名称 |
buyer_tax_id |
购买方纳税人识别号 |
total_amount |
合计金额（不含税） |
total_tax |
合计税额 |
amount_in_words |
价税合计（大写） |
amount_in_figures |
价税合计（小写） |
restaurant_name |
餐厅名称 |
restaurant_address |
餐厅地址 |
meal_type |
餐饮类型 |
dining_date |
就餐日期 |
dining_persons |
就餐人数 |
item_details |
明细列表（菜品/数量/单价/金额） |
📱通讯费发票
|
字段 |
说明 |
|---|---|
invoice_code |
发票代码 |
invoice_number |
发票号码 |
invoice_date |
开票日期 |
seller_name |
销售方名称（运营商） |
seller_tax_id |
销售方纳税人识别号 |
buyer_name |
购买方名称 |
buyer_tax_id |
购买方纳税人识别号 |
total_amount |
合计金额（不含税） |
total_tax |
合计税额 |
amount_in_words |
价税合计（大写） |
amount_in_figures |
价税合计（小写） |
carrier_name |
运营商名称 |
phone_number |
手机号码（脱敏） |
billing_period |
账期 |
service_type |
服务类型 |
package_name |
套餐名称 |
item_details |
明细列表 |
Agent提示词设计
发票分类Agent
- 角色
：专业发票分类助手
- 任务
：判断文本是否为发票 + 判断发票类型
- 输出
：JSON（is_invoice / invoice_type / confidence / reason）
- 兜底
：LLM调用失败时，使用关键词规则兜底分类
子Agent（网约车/餐饮/通讯费）
- 角色
：对应类型的专业发票信息抽取助手
- 任务
：从Markdown文本中精确抽取结构化字段
- 输出
：对应类型的完整JSON结构
- 特性
：每种类型有专属字段（如网约车有起点/终点，通讯费有手机号脱敏等）
报销API模拟
模拟企业报销系统的校验规则：
-
发票号码校验（缺失时使用文件名兜底）
-
金额有效性校验
-
单笔金额>5000元需额外审批
-
开票日期超过90天需附说明材料
-
类型特定规则（如网约车缺出行时间、餐饮缺就餐日期等给出建议）
运行结果示例
╔══════════════════════════════════════════════════════════════════╗
║ 智能发票报销 — 多Agent协同系统 ║
╚══════════════════════════════════════════════════════════════════╝
📈 总体统计:
总文件数: 3
✅ 报销成功: 3
🚫 类型不支持: 0
❌ 处理失败: 0
📋 明细:
✅ 海底捞餐饮电子发票.pdf
类型: 餐饮 | 金额: ¥219.00 | 报销单号: RB20260503182639-0AC4F8FE
✅ 滴滴网约车电子发票.pdf
类型: 网约车 | 金额: ¥14.00 | 报销单号: RB20260503182745-2498293B
✅ 联通通讯费电子发票.pdf
类型: 通讯费 | 金额: ¥164.00 | 报销单号: RB20260503183145-C5BBFFF7
项目源码
项目源码详见顶部资源包
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
31
0- 0
已为社区贡献5条内容
所有评论(0)