n8n实操：Razorpay收款每日自动对账、异常记录与失败付款催收

原文要点

该n8n模板每天7:30运行，从Google Sheets读取Invoices、Bank Credits、Payments Ledger、Exceptions，再经Razorpay API分页拉取支付、结算对账报告与结算记录做匹配、算手续费并回写表格；匹配方式含手工覆盖、发票引用和Razorpay order ID。对不上的款项交OpenAI给疑似发票匹配建议，仅记为异常不自动核销。已付发票经Gmail发收据并取消旧收款链接；失败付款自动新建Razorpay收款链接、由OpenAI起草催收邮件经Gmail发出，大额或最后尝试的案件升级Slack，最后给财务发HTML报告并在Slack发摘要。

这次做成什么

在自有n8n上把这条Razorpay日对账流跑通：建好五个标签页的测试表格，用Razorpay测试模式凭据造几笔支付，验证精确匹配、异常建议只记录不核销、收据/催收邮件和Slack摘要。全程用测试密钥与合成数据。

准备什么

• n8n实例及导入该模板（n8n.io/workflows/20132）
• Razorpay账户的测试模式Key ID与Key Secret（HTTP Basic Auth：Key ID作用户名）
• Google账号：Sheets与Gmail凭据；OpenAI API key；Slack OAuth凭据
• 上游下单流程能把发票ID写入Razorpay订单receipt或payment notes（如notes.invoice_id），否则无法精确匹配
• 一个测试收件邮箱充当客户与财务收件人

具体怎么做

1. 建五个标签页并填测试数据

   新建工作簿，建Invoices、Payments Ledger、Settlements、Exceptions、Bank Credits五个标签页，把所有Sheets节点的YOUR_GOOGLE_SHEET_ID替换为你的表格ID；按下方合成CSV填入发票与银行入账样本。

2. 配置Razorpay与规则参数

   新建Razorpay HTTP Basic Auth凭据（用户名=测试Key ID，密码=Key Secret），选进所有Razorpay HTTP Request节点。在Set Recon Rules节点填财务邮箱、支持联系方式、回溯窗口、容差、SLA天数、手续费比例与催收次数上限，Slack节点设频道如#finance-recon。

3. 在Razorpay测试模式造数

   用测试模式创建两笔支付：一笔订单receipt或notes.invoice_id写入INV-2001且金额一致，另一笔不写发票引用、金额与INV-2002相近但不等，用于制造“疑似匹配”异常。

4. 手动执行并验证各分支

   手动触发一次：INV-2001应被精确匹配、算手续费、回写台账并经Gmail发收据；无引用那笔应进入Exceptions且仅记录OpenAI的疑似匹配建议、不改动发票状态。再模拟一笔失败付款，确认自动新建收款链接、发出催收邮件并把chase字段回写。

5. 核对报告与摘要后开定时

   确认财务邮箱收到HTML对账报告、Slack收到摘要后，激活工作流按每日7:30自动运行；切真实密钥前先小额试跑。

可直接复制的材料

--- Invoices ---
Invoice ID,Client Email,Amount,Currency,Status,Due Date
INV-2001,test-client-a@example.com,15000,INR,open,2026-09-30
INV-2002,test-client-b@example.com,14800,INR,open,2026-09-28
INV-2003,test-client-c@example.com,32000,INR,open,2026-09-25

--- Bank Credits ---
Credit ID,Amount,Currency,Value Date,Narration
BC-9001,15000,INR,2026-09-28,RAZORPAY SETTLEMENT
BC-9002,14750,INR,2026-09-28,RAZORPAY SETTLEMENT

{
  "finance_email": "finance-test@example.com",
  "support_contact": "support-test@example.com",
  "lookback_days_payments": 7,
  "lookback_days_settlements": 14,
  "amount_tolerance": 100,
  "settlement_sla_days": 3,
  "fee_percentage": 2.0,
  "max_chase_attempts": 3,
  "high_value_threshold": 30000,
  "slack_channel": "#finance-recon"
}

输入与输出示例

本站虚构演示，未实际调用Razorpay/OpenAI；手续费与阈值均为上表练习参考值。

输入

INV-2001（15000 INR，支付带notes.invoice_id=INV-2001）、一笔14750 INR无引用支付、INV-2003对应一笔失败付款；amount_tolerance=100，high_value_threshold=30000

对应输出

INV-2001精确匹配：台账写入支付记录、手续费按2%计300 INR、发票状态置paid、Gmail发出收据并取消旧收款链接；14750那笔进Exceptions，OpenAI建议“疑似INV-2002（差50，容差内）”，仅记录不改状态；INV-2003失败付款：新建Razorpay收款链接、催收邮件发出、chase次数+1，因32000≥30000同步升级Slack；财务邮箱收到HTML报告，#finance-recon收到摘要：已核1笔、异常1笔、催收1笔。

做完检查这些

• 带notes.invoice_id的支付被精确匹配：台账、结算、发票状态三处回写一致且手续费入账
• 无引用支付只生成Exceptions记录与建议文案，发票状态不被自动改动
• 失败付款触发新收款链接+催收邮件，chase字段递增；达到大额阈值或最后尝试时Slack出现升级消息
• 财务邮箱收到HTML报告且Slack摘要数字与表格回写一致

容易卡住的地方

• 精确匹配依赖上游把发票ID写进receipt或notes.invoice_id，没打通前大部分支付都会落成异常
• 必须用HTTP Basic Auth且Key ID当用户名，用Bearer方式会401
• 测试模式与生产模式密钥不要混用，切换环境时凭据和数据都要换
• 容差设太宽会把不同发票误建议为候选，设太窄则结算扣费后永远对不上
• OpenAI建议只是记录，任何核销动作都应由人复核后在表内手工覆盖
• 分页拉取依赖Razorpay API限流，数据量大时关注节点报错