财务和行政岗每月最头疼的事之一：把邮箱里、报销系统里、拍照上传的几十上百张发票和收据，一张张手工敲进财务系统。金额抄错一位、税号漏一个数字、日期看混了月份，对账时就得翻着原件一张张核对，月底集中报销时更是堆积如山。更麻烦的是发票来源杂——供应商邮件附 PDF、员工拍照上传 JPG、报销平台导出的电子发票——格式不统一，连"复制粘贴"都省不了多少事。
这个 n8n 工作流模板把票据处理从"手工录入"变成"邮件触发 -> 自动提取 -> 校验入账"的全自动链路：邮件一到就抓附件、用 LLM 抽取发票号/金额/日期/税号/类目、Code 节点校验格式化、通过的自动写入财务系统，不通过的走人工复核通知，最后统一归档。
工作流链路
Email Read 触发（IMAP 收发票邮件，下载附件）-> Extract from File 提取附件内容（PDF 解析/图片 OCR）-> HTTP Request 调 LLM 抽取字段（发票号/金额/日期/税号/类目）-> Code 节点校验+格式化（金额转数字、日期统一格式、必填项检查）-> IF 校验通过 -> 通过分支：HTTP Request 写入财务系统（财务 API / Google Sheets / 飞书多维表格）-> 归档记录（Set 节点标记状态）；不通过分支：HTTP Request 通知人工复核（Slack webhook / 邮件）-> 归档记录。
下载模板
使用步骤
- 导入：n8n -> Workflows -> Import from File，选 workflow-invoice-processing-automation.json
- Email Read 节点：配 IMAP 连接（邮箱地址、密码/授权码、IMAP 服务器如 imap.gmail.com:993），开启 downloadAttachments。建议在邮箱里设一个"收发票"专用文件夹，配合 label/filter 只处理发票邮件，别让全量邮件灌进来
- Extract from File 节点：PDF 发票选 pdf 操作；图片发票（拍照扫描件）需接 OCR——n8n 原生 extractFromFile 对图片支持有限，建议用 HTTP Request 调 OCR API（如腾讯云 OCR / 阿里云 OCR / Google Vision），或直接跳过此节点改用支持视觉的 LLM 读图
- LLM 抽取字段节点：填 API key（DeepSeek/Kimi/Qwen/通义千问都行），Prompt 里明确要抽取的字段：invoice_no（发票号）、amount（金额，含税/不含税）、date（开票日期）、tax_id（税号）、category（费用类目）。要求 LLM 只输出 JSON，别给解释
- Code 校验节点：核心逻辑三步——一是解析 LLM 返回的 JSON；二是校验必填项（发票号、金额、日期不能为空，金额必须是正数）；三是格式化（日期统一成 YYYY-MM-DD，金额转 Number 类型，税号去空格）。校验结果塞进 valid 字段供 IF 判断
- IF 节点：按 valid 字段分流，true 走入账分支，false 走复核分支
- 写入财务系统节点：按你的系统选——财务系统有 API 就用 HTTP Request POST；用 Google Sheets 配 n8n 官方 Google Sheets 节点 append row；飞书多维表格用 HTTP Request 调 OpenAPI
- 通知人工复核节点：配 Slack incoming webhook URL，message 里带上失败原因（哪个字段缺失）和发票号，方便人工定位。没 Slack 的换成发邮件通知
- 归档节点：Set 节点统一打标——已入账标"已入账"，待复核标"待复核"。后续可接 Move File 节点把原附件移到归档目录
- 试运行：往收票邮箱发一封带发票附件的测试邮件，手动触发工作流，查财务系统/表格是否出现新记录，金额和日期是否正确
配套 Prompt（LLM 抽取发票字段）
Prompt
你是发票字段抽取器。从下面这段发票文本中抽取以下字段：
1. invoice_no：发票号（字母+数字组合）
2. amount：价税合计金额（数字，不含货币符号）
3. date：开票日期（YYYY-MM-DD 格式）
4. tax_id：销售方税号
5. category：费用类目（如：餐饮/交通/办公/软件服务/咨询费）
仅输出 JSON，字段为 invoice_no / amount / date / tax_id / category。
如果某字段在文本中找不到，填 null。不要输出任何解释文本。
发票文本：
{{ $json.data }}踩坑
- LLM 抽取金额搞混含税/不含税：中国增值税发票有"金额"（不含税）和"价税合计"（含税）两个数。Prompt 里必须写明要哪个（入账通常要价税合计），否则 LLM 随机挑一个，金额对不上账
- PDF 发票格式千差万别：电子发票（PDF）的排版各家不一样，有的发票号在左上角有的在右上角。LLM 抽取比正则稳，但偶尔会把"发票代码"当成"发票号"。Code 节点加一层长度/格式校验（中国发票号通常 20 位数字）
- 拍照件 OCR 质量差导致 LLM 读错：手机拍照的发票歪斜、反光、部分模糊。先做图像预处理（裁切、矫正、增强对比度）再送 OCR，准确率提升明显。或者直接用支持视觉的多模态 LLM（如 GPT-4o / Qwen-VL）读图，省掉中间 OCR 步骤
- 邮箱全量触发灌爆工作流：Email Read 默认拉所有新邮件。务必在邮箱侧设 filter 只把发票邮件分到专用文件夹，再让 n8n 只监听那个文件夹，否则每封邮件都触发一遍 LLM 调用，费钱又费时间
- 重复发票重复入账：同一张发票被转发两次就入两次。Code 节点里加一层发票号去重——查一下财务系统/表格里是否已存在该 invoice_no，存在就跳过
合规提示
- 票据含敏感财务/税务信息：发票上的税号、金额、交易对手方信息属于企业敏感数据。用云端 LLM 处理等于把财务数据发给第三方，需评估数据出境合规风险
- 建议本地处理：对数据敏感的场景，优先用本地 OCR（如 PaddleOCR / Tesseract）+ 本地部署的 LLM（如 Qwen2.5 通过 Ollama 本地推理），数据不出内网
- 中国电子发票/增值税专票有法规要求：电子发票的存档、报销流程受《会计档案管理办法》等法规约束，自动化入账不等于合规入账——仍需保留原件、走审批流、按税法要求申报。自动化只替代"录入"环节，不替代"审批"和"合规留存"
- 以当地财税法规为准：不同国家/地区的发票合规要求不同（如欧盟 VAT invoice、中国增值税专票、美国 1099 等），本工作流仅提供技术链路，具体合规要求请咨询财务/法务
参考来源
- n8n Email Read 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.emailread/
- n8n Extract from File 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.extractfromfile/
- n8n Code 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.code/
- n8n IF 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.if/
- 飞书多维表格 OpenAPI：https://open.feishu.cn/document/server-docs/docs/bitable-v1/bitable-overview
- Google Sheets API append values：https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values/append