简介：面向SAP FI财务顾问、总账会计及ERP学习者的一份专题课件，聚焦清账（Clearing）这一财务关账与报表编制中的关键环节，帮助读者理清开放项目的处理逻辑与操作方法。资源包仅含1个PPT文件，大小约1.12MB，以讲义式页面组织概念、流程与知识要点，便于课堂讲解或自学翻阅。内容围绕账户间清账与同一账户内清账展开，并延伸到分配字段、检索码、手工与自动清账的适用条件，以及进项/出项支付、支付差异容差组、已清项重置等实务细节，配有客户行项目与清账凭证的对比说明。已有4629人学习，适合需要系统梳理SAP清账流程、补齐FI模块知识框架的读者用作要点速查与复习材料。
1. 清账不是“点一下按钮”：SAP 财务模块清账到底在解决什么问题
月底对账，科目余额是平的，打开行项目却看到三年前挂着的两笔，借贷各一半，加起来刚好抵消——这种场面做财务模块的人多少都遇到过。SAP 财务模块里的清账（Clearing），本质是把同一科目下互相对应的借方和贷方行项目配对销账，让未清项归零，让账龄分析和余额分析变成能用的数据。它不是过账的附属动作，而是一次独立的状态变更：系统会生成清账凭证，并把清账日期、清账凭证号写回被清的行项目。
标题里的清账，覆盖手动清账（F-03 / F-32 / F-44）、自动清账（F.13）、部分清账与剩余清账的取舍、清账差异处理，以及在 S/4HANA 的 ACDOCA 单表结构下这些动作留下的痕迹。这篇按这个顺序往下走，每一段都落到可复现的操作和参数上，顺带把踩过的坑摊开讲。
2. 未清项、清账状态与 ACDOCA：先弄懂清账的数据模型
2.1 从行项目到清账凭证：一次清账到底写了几张表
很多人以为清账是“把两笔删掉一笔”，这是最容易翻车的认知。清账不修改原凭证的金额，也不删除原行项目，它做的是一次带标记的追加：被清的行项目在 BSEG 上被打上三个字段——AUGDT（清账日期）、AUGBL（清账凭证号）、AUGCP（清账过账期间，由清账日期推导）。同时系统生成一张新的会计凭证，也就是清账凭证，这张凭证的凭证类型通常单独配置，用来和日常业务凭证区分开。
清账凭证本身的行项目有个特点：它在被清科目上生成借贷成对的分录，一借一贷金额相等方向相反，所以科目余额不变。换句话说，你在 FBL3N 里看科目余额，清账前后一模一样；变化的只有行项目状态——原来那两笔从“未清”变成“已清”，或者变成“部分清”。如果有差额，差额会进到配置好的差异科目，这时候科目余额才会动。
表层面更直观。经典总账里，未清项和已清项是分开存放的：总账是 BSIS（未清/部分清）和 BSAS（已清），客户是 BSID/BSAD，供应商是 BSIK/BSAK。系统靠 AUGDT 是否为空来决定一笔行项目落在哪一侧：AUGDT 为空就是未清，有值且金额全部清完就是已清，有值但还有剩余金额就是部分清。所以排查“为什么这笔记账还在未清清单里”，第一件事就是去看这几张表里的 AUGDT，而不是去问凭证有没有过账成功。
这个模型带来的直接后果是：清账是一个可逆但不可忽略的动作。反清账（重置）不是把凭证删掉，而是把清账凭证冲销、把原行项目的 AUGDT/AUGBL 清空，再让行项目回到未清状态。所以每清一次账，凭证流里就多一层，链路越长越难追溯，这也是为什么清账前一定要先模拟看凭证流。
2.2 部分清账、剩余清账、带清账过账：三种模式的差别与选型
这三个词在新人嘴里经常混着用，实际行为完全不同，混用一次可能就是一笔对不上的账。下面这张表是我在培训和交接时固定要过一遍的对照：
| 模式 | 典型入口 | 被清项最终状态 | 差额去哪 | 适用场景 |
|---|---|---|---|---|
| 部分清账 | F-03 / F-32 / F-44 手工改金额 | 保留未清，未清余额减少 | 不产生差额，剩余部分继续挂账 | 一笔大额分多次收回或分批核销 |
| 剩余清账 | F-03 内选“剩余清账” | 全额标记已清 | 差额生成新的未清项 | 折扣、短款、汇率导致的尾差 |
| 带清账的过账 | F-04 | 旧项已清，同时新增一笔分录 | 差额由新分录承载 | 收款同时做费用或手续费拆分 |
| 反清账 / 重置 | FBRA 一类入口 | 回到未清 | 清账凭证被冲销 | 清错对象、清错金额 |
部分清账的关键动作是在未清项列表里把某一行的“分配”金额改成小于原始金额。系统生成的清账凭证金额等于你实际清掉的数，原行项目的累计已清金额增加，剩余金额继续以未清形式存在。注意这里有个细节：部分清账之后，原行项目的 AUGDT 是有值的，报表会把它显示成部分清账状态，但它仍然出现在未清项清单里。很多报表逻辑用“AUGDT 为空”来判断未清，一做部分清账就漏数据，这是自建报表最常见的 bug 之一。
剩余清账反过来：你勾选的那一笔被全额清掉，差额作为一笔新的未清项生成出来。它的好处是原来的凭证链路干净了，坏处是未清项数量变多，账龄分析时会多出一批“新出生”的旧账。选型上我一般按一条经验判断：差额是业务上“还要继续追”的，用部分清账；差额是业务上“已经定损、以后不会再变”的，用剩余清账。前者保留原始凭证的连续性，后者让后续账龄更干净。
带清账的过账适合“一边收钱一边分摊”的场景。它在一张凭证里同时完成两件事：过一笔新的分录，清掉一笔旧的行项目。窗口一侧的手续费、汇兑尾差、平台扣费，通常就走这条路，优点是凭证号唯一、追溯简单，缺点是格式要求高，字段填错会直接报错。
2.3 S/4HANA 下清账数据落到 ACDOCA 后的四个变化
S/4HANA 把总账、客户、供应商、资产、成本核算的行项目合并到了 ACDOCA 一张表里，这个变化对清账的影响比想象中大，至少体现在四个地方。
第一，物理表没了，兼容视图还在。BSIS/BSAS 这类表在 S/4HANA 里以兼容视图的形式保留，老的报表和自建程序还能跑，但底层读的是 ACDOCA，性能和响应都和老系统不是一个量级。数据量大的科目，用老逻辑全表扫描会明显变慢，得改成按公司代码、会计年度、科目走索引。
第二，清账状态字段集中在同一张表。AUGDT、AUGBL、AUGCP 这几个字段在 ACDOCA 里对总账、客户、供应商是统一的一套，取数逻辑可以收敛成一段代码，不用再按科目类型分三套表写。好处是维护量小，坏处是老代码里按 BSID/BSIK 写的判断，在新环境里要么失效要么读不到全量。
第三，凭证流追溯更直接也更绕。清账凭证和业务凭证同表存储，查一笔钱的来龙去脉只需要按 AUGBL 关联一次；但 AUGBL 和原凭证是一对多关系，一个清账凭证可能同时清掉十几笔，写报表时如果直接 JOIN 不去重，金额会翻倍。
第四，清账年度和凭证年度可能不一致。跨年清账时，被清行的清账年度和它自己的会计年度不是同一个值，做年度对比报表时必须明确用哪个字段过滤，否则上年挂账、本年清掉的数据会同时出现在两个年度里。
提示：从经典总账迁移过来的自建报表，优先改取数口径，不要指望兼容视图兜底。先用 FAGLL03H 对一遍数，再决定是否重写 SQL。
3. 手动清账跑通：F-03、F-44、F-32 的最小操作路径
3.1 用 F-03 把两个总账行项目清掉
总账手工清账的主入口是 F-03。走之前先做一个检查，否则进去会是空的：用 FS00 打开目标科目，确认“行项目管理”和“未清项管理”两个标志都勾上。没勾“未清项管理”的科目，系统根本不记录清账状态，F-03 里也不会出现任何待清项，这是新手最常卡住的第一步。
确认之后按下面的顺序走：
- F-03 进入初始屏幕，输入科目、公司代码，选择“处理未清项”。
- 系统列出该科目当前所有未清和部分清的行项目，按过账日期排序。
- 勾选需要配对的两笔，一借一贷。勾选后金额栏会自动带出各自余额。
- 如果两边金额相等，直接点“模拟”，检查凭证抬头：凭证日期、过账日期、清账日期、凭证类型。
- 模拟无误后保存，系统给出清账凭证号，回到行项目清单会被清的两笔已经消失。
金额不相等时有两个分支：走部分清账，就把其中一行的分配金额改成实际要清的数额；走剩余清账，就保持全额勾选，然后在差额字段里填差额并指定差异科目。这两种选择在下一节展开。
参数上真正需要盯住的是三个字段。清账日期（AUGDT）决定这笔清账落在哪个期间，默认取当前日期，但经常需要手动改成业务发生的那个期间，尤其是补做上月清账的时候。过账日期决定凭证的会计期间，和清账日期可以不同。凭证类型决定清账凭证的编号范围和字段状态，很多项目会单独建一个清账专用类型，方便后续按类型筛清账动作。
注意：清账日期落在已关闭的期间会直接报错。做跨期清账前先确认期间是否开放，别在保存那一刻才发现要重来一遍。
3.2 部分清账与剩余清账的操作差异：输入框里改哪几个字段
两种模式在界面上只差一步操作，结果差很远。
部分清账：在未清项列表里，找到要部分核销的那一行，把“分配”列的金额从原始金额改成实际金额，然后勾选对方那笔做对冲。系统会校验：修改后的金额不能大于原始未清金额，也不能为零。保存后生成清账凭证，金额等于你输入的分配数。原行项目仍然留在未清清单里，未清余额等于原金额减去已清金额。如果一笔 10 万的应收分三次收回，就会产生三张清账凭证，原始凭证号始终不变，这是它的价值所在。
剩余清账：勾选行项目后点“剩余清账”，系统弹出输入界面。这时你要填的是“剩余项”的金额和它的基准日期，剩余金额会作为一笔新的未清项生成。原来的那笔被全额标记为已清，从清单上消失。举个例子：供应商发票 10 万，实际付款 9.8 万，差额 2000 是折扣。用剩余清账，10 万的发票被清掉，2000 作为新的未清项挂着，后续再做折扣核销或者费用化处理。
两个模式的选择还会影响差异科目的使用。部分清账不产生差额，所以不会碰差异科目；剩余清账的差额是一笔真实的新行项目，它可能进差异科目，也可能进正常的费用或收入科目，取决于你在界面上填的记账码。这也是为什么我建议把“差额进哪个科目”写进操作规范，不靠执行人临场判断。
还有一点容易被忽略：部分清账之后，如果想改主意做全额清账，操作上要先把之前那笔已清金额重置掉，不能直接在原凭证上叠加。链路一长，账龄和凭证流都会变复杂，所以清账前先想清楚这次到底清多少，比事后补救省事得多。
3.3 清账差异怎么处理：容差组、差异科目与汇率差异过账
清账时如果借贷两边差了一点，系统不一定让你过。这个“一点”由容差组控制。总账科目走的是总账容差组（OBA0），客户和供应商走各自的容差组，配置里可以按金额、按百分比，或者两者组合来限定允许的差额。超过容差，系统直接报“差额太大”，凭证存不下去。
容差组里还有一个关键字段是差异科目。差额在容差范围内时，系统把它过账到你在这里配置的科目，而不是留在被清科目上。这意味着同一笔业务，容差配得宽和配得窄，最终进损益的金额可能不一样。项目上线前一定要把容差和差异科目一起确认，只配容差不配科目，保存时会报科目缺失。
外币清账是另一个分支。被清项是外币时，清账日汇率和原始过账日汇率不同，会产生已实现汇兑损益。这部分差额走的是汇率差异的科目确定逻辑，和上面说的容差差额不是一回事。实操上的判断顺序是：先看两边本位币金额是否相等，再看外币金额是否相等，最后才决定差额填在哪一栏。顺序搞反，很容易把汇兑损益手工塞进容差差额里，月底对汇兑损益科目时就会对不上。
4. 自动清账落地：F.13 的规则配置与批量跑批
4.1 OB74 定义排序规则：让程序知道“哪两笔是一对”
手动清账靠人眼判断哪两笔能配，自动清账要靠规则告诉程序。总账和客户供应商的自动清账规则在 OB74 里维护，维护的维度是“科目类型 + 科目或账户组”，内容是排序字段的组合。
常用的排序字段包括分配号、参考、凭证日期、金额、税码、业务范围。程序的行为是：把排序字段值完全相同的借贷行项目配成一对，方向相反、金额相等才允许清。所以规则字段选得越细，能配上的越少；选得越粗，配上的越多但误配风险越高。
我的经验是分两档处理。业务上分配号填得规范的科目，用“分配号 + 金额”这一档，匹配准确率高；分配号经常空着或者随手填的科目，不要用它做规则，改用“参考 + 金额 + 凭证日期”这类组合，宁可匹配不上，也不要乱配。规则上线前，先拿历史三个月的数据在测试环境跑一遍，把匹配结果和人工清账结果比对，差异超过 5% 就说明规则需要调。
还有一个容易忽略的点：规则的优先级和唯一性。同一个科目如果同时命中两条规则，程序按什么顺序取，得提前确认清楚，不然后面排查“为什么这两笔被配到一起”会非常痛苦。规则命名也要有约定，比如按“科目类型-用途-版本”命名，别留一堆“Z001”“Z002”让后来的人猜。
4.2 F.13 跑批参数：公司代码、科目、日期、测试运行与日志
规则配好之后，执行入口是 F.13。这个事务的关键参数并不多，但每一个都影响结果范围：
| 参数 | 作用 | 常见设置 |
|---|---|---|
| 公司代码 | 限定处理范围 | 单公司跑，多公司分批 |
| 会计年度 | 限定行项目所属年度 | 通常当前年度，跨年清账要分段 |
| 科目 / 科目区间 | 限定参与清账的科目 | 按科目分批，避免一次锁太多 |
| 科目类型 | 总账、客户、供应商 | 分开跑，便于看日志 |
| 过账日期 | 生成清账凭证的日期 | 一般取当期期末 |
| 测试运行 | 只出结果不落库 | 正式跑之前必须跑一次 |
必须强调测试运行。测试运行会输出一份清单，列出哪些行项目被匹配、哪些没匹配上、没匹配的原因是什么。没匹配上的原因通常分三类：金额不相等、排序字段不一致、找不到对手方。这三类要分开统计，金额不相等往往是业务本身的问题，排序字段不一致才是规则的问题。
正式运行时建议按科目分批。一次选中几百个科目跑，锁的范围大、日志难读、失败也不好回退。跑完立刻看两件事：生成的清账凭证数量是否符合预期，以及有没有科目在日志里报错。有报错的科目单独拎出来手工处理，不要重跑整批，重跑会产生重复清账凭证的风险。
4.3 用批量输入/程序化方式扩量：从手工 F.13 到定期作业
数据量上来之后，靠人守着 F.13 不现实。常规做法有三层。
第一层是后台作业。用 SM36 建周期性作业，把 F.13 挂上去，按周或按日跑，跑完由系统发作业日志。这一层解决的是“有没有按时跑”的问题。
第二层是分批切片。作业里的公司代码、科目区间、会计年度做成变式，一个变式对应一批，多个作业错开时间跑。切片的粒度按科目余额和行项目数量定，行项目超过十万的科目单独一个变式，避免一个作业卡住整条链。
第三层是程序化调用。当匹配逻辑超出 OB74 能表达的范围，比如要按自定义字段配对、要按业务单据号模糊匹配，就得自己写程序。这一类需求常见的做法是调用清账相关的 BAPI（函数名以系统里 SE37 查到的为准，POSTING_INTERFACE_CLEARING 是其中一类），或者在 ABAP 里直接构造清账凭证。这条路能解决复杂场景，但代价是要自己处理锁、更新任务、错误回落。我的建议是：能用配置解决就不要写程序，能写报表辅助判断就不要写程序直接清账，因为程序清错账的回滚成本远高于手工清错。
不管走哪一层，都要留一个“后悔药”：清账凭证的凭证类型单独设，编号范围独立，这样一旦发现某批清账有问题，可以按凭证类型和时间范围快速捞出来，用反清账重置，而不是一笔一笔手工找。
5. 清账避坑与排查：五条翻车记录
5.1 清完账余额没变，未清项反而多了两笔
现象：清账凭证生成了，科目余额和清账前一模一样，未清项清单里却多出两笔新的。
原因：操作时误用了剩余清账，差额被系统当成新的未清项生成出来，而操作人以为做的是部分清账。
解决：先按清账凭证号去行项目里看凭证流，确认清账凭证的金额和原凭证金额是否相等。不相等就是走了剩余清账，用反清账重置后重新做，这次改成部分清账，或者在剩余清账界面把剩余金额填成零。事后复盘时把这两种模式的界面截图贴进操作手册，比口头讲十遍管用。
5.2 F-03 进去看不到任何未清项
现象：明明科目有余额、有行项目，F-03 打开却是空清单。
原因：排前三的是科目主数据没勾“未清项管理”、行项目已经被全部清掉、查询的会计年度选错了。还有一种不常见但更麻烦的：行项目被做了删除标记或者已经归档，清单里直接不显示。
解决：先用 FS00 看主数据标志，再用 FBL3N 或 FAGLL03H 看该科目在目标年度到底有没有行项目。如果行项目存在但 F-03 看不到，检查是不是全部已清（AUGDT 有值）或者被标记删除。归档导致的看不到，要走归档查询，不能指望在线清单。
5.3 自动清账跑完，配错了对象
现象：F.13 跑完，两笔本来不该配在一起的行项目被清掉了，而且金额刚好相等。
原因：OB74 的排序规则太粗，只用金额做匹配，加上容差设得宽，同金额的多笔业务就被随机配对了。
解决：立即用反清账重置这批清账凭证（按凭证类型和时间范围筛），然后收窄规则，至少加上分配号或参考字段，同时把容差调回合理范围。规则调整后必须先在测试环境用历史数据验证，不要直接在生产上试。
5.4 清账后报表和业务系统对不上
现象：财务这边显示某笔应收已清，业务系统里还是未收状态，两边对不上。
原因：清账动作只发生在财务侧，没有回写业务单据状态；或者自建报表直接读 BSIS/BSAS 兼容视图，S/4HANA 下取数和 ACDOCA 不一致。
解决：确认接口有没有回写逻辑，没有的话要么补接口，要么在业务侧按凭证号做人工核销。报表侧改成直接查 ACDOCA，按 AUGDT 和金额判断清账状态，不要依赖兼容视图的物理表语义。
5.5 清账日期落到了不该落的期间
现象：保存时报期间未开放，或者勉强存下去了，但期末报表里这笔清账跑到了下一个期间。
原因：清账日期默认取当前日期，做补账时没人改它；跨期清账时清账日期和过账日期没有分开设置。
解决：清账前先确认目标期间是否开放，再把清账日期手工改到业务所属期间，过账日期单独设置。已经错了的，用反清账重置后重做，不要试图用调整分录去补，那样会让凭证流越来越乱。
6. 把清账做成可验证的：一套自检清单与两个查询技巧
清账这件事，做完不难，做对且能证明自己做对了才难。我习惯在每次批量清账前后各跑一遍自检，清单不长，但能拦住大部分返工：
| 检查项 | 检查方法 | 异常信号 |
|---|---|---|
| 科目主数据 | FS00 看行项目管理和未清项管理 | 任一未勾选，F-03 必然为空 |
| 容差与差异科目 | OBA0 及客户供应商容差组 | 只配容差不配科目，保存报错 |
| 清账凭证类型 | 按凭证类型统计清账凭证数 | 类型混用，事后无法批量筛选 |
| 期间开放 | 会计期间配置 | 清账日期落在关闭期间 |
| 自动清账规则 | OB74 规则与测试运行日志 | 匹配率异常高或异常低 |
第一个查询技巧是定位“清了但没清干净”的行项目。部分清账之后，行项目既有 AUGDT 又有未清余额，这类数据在报表里最容易漏。用下面这段 Open SQL 可以直接捞出来：
" 查出指定公司代码、科目、年度下已发生清账但仍有余项的行项目 SELECT rbukrs, " 公司代码 racct, " 科目 belnr, " 会计凭证号 buzei, " 行项目号 augdt, " 清账日期 augbl, " 清账凭证号 augcp, " 清账过账期间 hsl, " 本币金额 wsl " 外币金额 FROM acdoca INTO TABLE @DATA(lt_partial) WHERE rbukrs = @iv_bukrs AND racct = @iv_racct AND gjahr = @iv_gjahr AND augdt <> @space AND hsl <> 0.这段逻辑的关键在于最后两个条件：AUGDT 不为空说明已经发生过清账动作，HSL 不为零说明这笔行项目自己还有余额没有配平，两者同时成立就是部分清账的典型特征。参数上 iv_bukrs、iv_racct、iv_gjahr 分别对应公司代码、科目、会计年度，实际使用时把科目换成区间能一次扫一批。注意 HSL 是取本币金额，如果业务以外币为主，判断条件要换成 WSL，或者两个都判。
第二个技巧是对账龄。清账之后账龄分析要重算，不能沿用清账前的快照。做法是按 AUGDT 分组统计每笔清账的“原始凭证日期到清账日期”的天数，再和业务侧的收款天数对比，差值持续偏大的科目，往往就是清账规则或者业务流程出了问题。
我自己的习惯是：每次调整 OB74 规则或者容差配置，都先在测试环境跑一遍最近三个月的历史数据，把匹配结果和人工清账结果做一次差异比对，差异清单留档。这条规矩救过我两次，一次是规则里漏了反记账标志，导致红字发票被配到正常发票上；另一次是容差调宽之后，汇率尾差被系统当成容差差额吃掉了。清账这种动作，做对了没人夸，做错了要花几倍时间回滚，慢一点把规则和自检做实，比事后救火划算得多。希望帮到你。
本文还有配套的精品资源，点击获取
