如何将银行对账单导入记账工具

即使银行或信用卡的结算周期已经结束，对账单看起来可以直接导入，里面仍可能藏着几个坑。有些交易可能早已记进账本，因为你之前已经根据收据录入过。一笔信用卡还款也可能被误当成新的支出，而对应的消费其实几周前就已经记录。

要安全地将银行对账单导入记账工具，先保留银行提供的原始资料，让 AI 智能体整理出一份可审阅的草稿，只批准你能确认来龙去脉的记录，最后核对所有受影响账户的余额。

Expense Budget Tracker 没有原生的 CSV 或 PDF 一键上传向导，也不会与你的银行保持长期连接。这套流程由外部 AI 智能体或脚本读取对账单，并与记账工具交互。文件交给智能体处理；具体写入账本的内容，仍由你审阅和控制。

先保留一份随时可以回查的原始文件

保留原始对账单，不要改动。使用它的副本，并向智能体提供确切的文件路径或附件、账户、币种和已经结束的账期。

只要条件允许，一份文件就应该只对应一个账户和一个账单周期。如果银行导出文件合并了两张卡，混杂了待处理交易和已入账交易，或者覆盖了多个重叠周期，请先把审阅内容拆成明确的区段，再统一交易格式。否则，之后一旦余额对不上，排查范围就会大得多。

导入已经结束的账期时，只使用已经入账的交易。待处理项目的金额、描述或日期都可能变化。把它们单独放进待观察清单，不要当成已经结算的历史记录。

不同文件格式的提取风险也不同。导入 CSV 银行对账单时，可以从结构化字段入手；导入 PDF 银行对账单时，可能从提取出的文本开始，也可能只能从图像像素着手。

• 结构化 CSV 通常是最干净的起点，但智能体仍要确认分隔符、日期格式、小数分隔符、币种，以及金额是分别放在借方列和贷方列中，还是放在一个带正负号的字段里。
• 文本型 PDF 可能保留可读的交易文本，却丢失列对齐。为草稿中的每一行附上页码，再加上交易序号或行号引用，这样才能追溯到原文。
• 扫描版或纯图片 PDF 需要 OCR 或图像理解。页面被裁切、字迹模糊、列合并，都可能导致无法准确提取。如果日期、金额、币种或余额有任何一项不清楚，就停下来，要求提供更清晰的文件或人工确认。

AI 银行对账单解析器的可靠程度，取决于文件本身以及所选工具能否访问它。表格看起来整洁，并不能证明每一行、每个数字都提取无误。

严格按这张表审阅

智能体应该先在账本之外生成草稿。对账单中每一笔已入账的原始交易都必须在审阅表中恰好占一行，包括重复项和排除项。各列按以下顺序排列：

列	应填写的内容
source_ref	CSV 行号；对于 PDF，则填写页码加交易序号或行号
posted_at	原始资料提供入账日期和时间时，如实填入；只有原始资料给出时区或用户确认过时区，才填写时区
raw_description	与原始资料显示完全一致的文本，不要清理商户名称
statement_amount	与原始资料显示完全一致的原始借方金额、贷方金额或带正负号金额
currency	原始资料中的币种；绝不能只凭货币符号自行推断而不作说明
ledger_amount	按记账工具的正负号约定标准化后的金额
target_account	从工作区现有账户中准确选定的账户
proposed_kind	当前生效的 schema 允许这类资金变动使用的确切值
proposed_category	确切的现有分类；如果是转账，则使用当前生效的 schema 要求的无分类值
transfer_match	对应账户和来源引用，或 unresolved
duplicate_candidate	匹配的账本记录及证据，或 none found
uncertainty	任何尚未解决的文本、日期、金额、账户、币种或分类问题
decision	insert、match existing、exclude 或 needs review

例如，已经根据收据录入的交易仍应保留在表中，并标记为 match existing。它不应该从证据中消失，也不应该再次写入账本。

即使智能体已经整理出更清晰的字段，原始描述和对账单金额仍然很重要。一旦建议的分类或正负号看起来不对，它们就是回查原始资料最快的线索。

连接智能体，再以实际数据为准

对于终端智能体或直接调用 HTTP 的脚本，从这里开始：

GET https://api.expense-budget-tracker.com/v1/

按照服务发现响应中的指引完成邮箱验证码流程，并把返回的长期有效 ApiKey 保存在聊天上下文之外。已认证请求使用 Authorization: ApiKey <key>。智能体设置指南介绍了完整的接入流程。

在构造任何 SQL 之前，智能体应该：

1. 确认当前登录账号和确切的工作区。
2. 选择目标工作区，或随请求发送它的 ID。
3. 查看 GET /v1/schema，了解当前允许使用的数据关系和列。
4. 通过 POST /v1/sql/query 查询确切的目标账户、账户币种、现有分类，以及最近一次可信的对账点。
5. 在提出写入方案前，查询对账单周期及其查重边界内的现有账本记录。

不要把本文中的列清单复制到导入脚本里。当前生效的 schema 才是准绳。API 参考文档说明了端点和 SQL 规则，而 /v1/schema 会告诉智能体当前可以写入什么。

支持 MCP 的客户端也可以改为连接：

https://mcp.expense-budget-tracker.com/mcp

这条路径使用浏览器 OAuth，而不是 ApiKey。申请 expenses:read 权限范围，即可使用 list_workspaces、get_schema 和 sql_query。只有客户端准备调用 sql_execute 时，才添加可选的 expenses:write 权限范围。MCP 连接器指南解释了连接和批准机制。

两种路径返回的查询结果都不超过 100 行。直接 API 还将每个变更请求影响的行数限制为最多 100 行。如果一个周期包含更多记录，请按互不重叠的日期区间或来源记录范围分段读取，并确认每一笔已入账的对账单记录都恰好在审阅表中出现一次。

设定实用的查重范围

查询目标账户完整的对账单周期，并向前、向后各延伸三个自然日。这一小段重叠区间可以找出根据收据录入的记录，以及因购买日期与入账日期不同而错开的导入记录。它只是审阅范围，并不能证明两行记录就是同一笔交易。

如果原始资料和账本都包含稳定的银行交易标识，就把它视为强有力的重复证据。如果没有，那么只有在以下各项全部匹配时，才标记为重复候选项：

• 目标账户
• 币种
• 带正负号的确切金额
• 日期相差不超过三个自然日

然后比较原始描述、规范后的交易对手方、交易参考文本，以及任何收据证据。两笔真实消费可能恰好发生在同一家商户，金额也相同，因此智能体应该列出候选项，而不是默默删除、更新或跳过记录。

对账单流程与收据流程会在这里交汇。收据扫描流程可以核实单笔消费的细节：商户、商品、税费、小费和总额。对账单可以核实账户上的资金变动，也可能提供期初和期末余额。当两者描述的是同一笔消费时，应将它们匹配起来，不要重复记账。

根据账本现有分类起草

读取所选工作区已经使用的分类，再把对账单记录映射到这些名称。商户描述可以提供分类线索，却不能作为定论。单凭支付处理商、电商平台或陌生的转账标签，尤其不足以判断分类。

把不明确的记录设为 needs review。不要为了让表格看起来完整就创造新分类。真正有用的输出，是一份关联到具体来源引用的简短不确定项清单，而不是夹在已批准记录中的自信猜测。

退款也需要同样谨慎。清楚保留它在原始资料中的正负号和账户资金流向，再根据工作区现有的处理方式进行映射。不要默默把每个正数金额都标成收入。

别让转账变成并不存在的支出

内部转账只会改变账户余额，不会产生消费支出。如果两个账户都在你的追踪范围内，就按照当前生效的 schema 所要求的关联方式，记录两个账户上的资金变动。资金从一个账户转出、进入另一个账户，这一对记录不应虚增支出。

常见情况包括：

• 如果活期账户和储蓄账户都在追踪范围内，两者之间的资金移动属于内部转账
• 信用卡消费是信用卡账户上的支出
• 之后从活期账户给这张已追踪的信用卡还款属于转账，不是再次记录消费
• 单独列出的银行手续费属于支出，即使它紧挨着一笔转账
• 跨币种转账的两边分别保留各自账户对账单上的实际金额和币种；不要为缺失的一边编造换算金额

如果缺少对应账户或对账单，就把 transfer_match 保留为 unresolved。不要虚构另一笔对应记录，也不要为了完成这一批次就把该记录批准为普通支出。详细的判断边界见银行转账算支出吗？。

对于预算追踪范围之外的账户，需要制定明确规则。一笔跨越该边界的付款可能是购买、偿还债务、投资入金、报销，也可能是其他事项。银行描述中出现“转账”一词，并不能直接确定它的性质。

批准的是具体批次，不是模糊意向

等对账单中的每一笔已入账原始记录都有了决定之后——即使决定是 needs review——智能体应该展示：

• 工作区、对账单对应账户、币种和周期
• 已入账原始记录的行数，以及对账单中的借方总额、贷方总额或带正负号总额
• 与现有账本记录匹配的行
• 从导入中排除的行及原因
• 尚未解决的重复候选项或转账候选项
• 根据当前生效的 schema 构造的一小批精确 SQL
• 预计影响的行数

请使用像下面这样具体的批准文本：

我只批准对账单导入批次 [number]。
工作区：[name and ID]
对账单对应账户：[account name and ID]
周期：[start through end]
已批准的来源引用：[exact list]
预计影响的行数：[count]
只执行最新预览中显示的确切 SQL。
不要更改任何其他行。回读验证后停止。

如果工作区、账户、SQL、来源清单或预期影响发生变化，这次批准就不再适用。请重新生成预览并再次请求批准。

分小批写入，每批都要回读

对于直接 API，每次向 POST /v1/sql/execute 发送一条已批准的 INSERT、UPDATE 或 DELETE 语句。对于 MCP，使用带 expenses:write 的 sql_execute。多行插入仍然可以写在一条语句中，但每批都要足够小，让人能够将其中每一行与审阅表对照。先从最小且完整的一组开始——例如一组成对的转账记录，或几行普通记录。只有在回读结果无误，并且下一批也有自己的预览和批准后，才能继续。

每批写入后，通过 /v1/sql/query 或 sql_query 再次查询这些确切记录。将保存的账户、时间戳、带正负号金额、币种、类型、分类和转账关系与已批准的预览逐项比较，然后把每一行回读记录映射到已批准的来源引用。HTTP 成功响应并不能证明账本里存入的就是你想要的内容。

不要把数据清理夹带进导入流程。如果回读发现某个值错误，或现有记录需要修正，请另行准备一条确切的 UPDATE 或 DELETE，说明它的影响，并重新请求批准。

核对导入影响的每一个账户

如果对账单提供期初和期末余额，先按照对账单自身的借方、贷方和余额约定计算：

expected source closing balance = source opening balance + sum(posted source movements)

对于记账工具，应从最近一个确认无误的账户余额核对点向前计算，而不是假定对账单的第一天已经核对过：

expected tracker balance at cutoff = last known-good tracker balance
                                   + sum(signed ledger movements after that checkpoint through the cutoff)

把银行特有的借方、贷方或信用卡欠款展示方式转换为记账工具的正负号约定，并展示转换过程。记账工具的预期余额必须等于该账户经过标准化的对账单期末余额。同时将导入的来源引用与审阅表对照：对账单中每一笔已入账记录，都应该已经插入、与现有记录匹配，或被明确排除。

如果此次导入创建或匹配了内部转账的两边，就应根据各自的对账单或确认无误的余额核对点，核对两个受影响的账户。来源账户的余额吻合，仍然可能掩盖目标账户一边虚构或重复的记录。

CSV 交易导出文件可能不包含期初和期末余额。在这种情况下，应使用银行另行提供的、对应确切截止时点的余额，或之前确认无误的对账点。如果两者都没有，你可以验证记录覆盖范围和总额，却不能声称已经完成完整的银行对账单核对。

停止条件很简单：如果任何账户存在无法解释的余额差异、尚未解决的原始记录、不确定的金额或币种，或者有歧义的重复项或转账，就停下来。不要为了平账而添加交易。保留草稿，并按照预算与银行余额核对流程排查具体差异。

先弄清对账单数据会流向哪里

这是一个无需连接银行的记账工具，但这并不代表对账单只会留在你的机器上。

你选择的 AI 客户端或模型提供商可能会处理 CSV 或 PDF，以及其中包含的财务文本。请查看该提供商的数据处理条款，并且只授予完成任务所需的文件访问权限。在本文所述流程中，智能体会把 SQL 请求和经过批准的结构化写入提交给记账工具，再接收选定的结构化记录。原始对账单文件不会上传到记账工具。

自托管 Expense Budget Tracker，并不会自动把 AI 智能体、OCR 工具或模型提供商也改为自托管。它们是不同的系统，各有自己的数据边界。如果你的首要目标是避免持续开放银行访问权限，请阅读预算应用如何在不连接银行的情况下运行，并据此选择流程中的每个组成部分。

可重复使用的提示词

把位于 [file path or attachment] 的已经结算完毕的银行或信用卡对账单导入 Expense
Budget Tracker。目标工作区是 [name]，账户是 [name]，覆盖日期为 [dates]。

暂时不要写入账本。保留原始文件。判断文件属于结构化 CSV、文本型 PDF，还是
扫描版/图片 PDF，并说明所有提取限制。排除待处理交易。严格按照本文创建审阅表，
为每一笔已入账记录保留来源引用、原始描述、原始金额、标准化后的账本金额和不确定项。

如果直接使用 HTTP，从 https://api.expense-budget-tracker.com/v1/ 开始，按照其
服务发现响应中的指引操作，使用返回或已保存的长期有效 ApiKey，确认 /me 和确切的工作区，
查看 /v1/schema，并通过 /v1/sql/query 读取。对于 MCP，使用带 expenses:read 的
list_workspaces、get_schema 和 sql_query；只有写入已获批准并准备通过 sql_execute
执行时，才申请 expenses:write。

提出 SQL 前，查询目标账户在该周期内的现有记录，并向前、向后各延伸三个自然日。必要时使用
互不重叠的边界，以遵守 100 行结果上限。标记重复候选项；绝不能默默跳过。复用现有分类。
把信用卡还款和已追踪账户之间的资金变动视为转账，按照当前生效的 schema 关联两个账户上
实际发生的资金变动；如果缺少对应记录，将其保留为未解决状态，不要凭空补造。

展示完整的审阅表、行数、对账单原始总额、重复证据、转账配对、排除项和所有未解决事项。
然后展示根据当前生效的 schema 构造的一小批精确 SQL，以及预计影响的行数。等待我针对该批次的批准。

获得批准后，只通过 /v1/sql/execute 或 sql_execute 执行那一条 INSERT、UPDATE 或
DELETE 语句。重新查询这些确切记录，并与已批准的预览进行比较。根据各账户的对账单期末
余额或某个确切且确认无误的余额核对点，核对每个受影响的账户。如果仍有任何问题无法解释，
立即停止，不要添加用于平账的记录。

结果很具体：原始证据、每一笔原始记录对应的决定、一项已批准的账本变更，以及说得清来龙去脉的余额。