简介：SAP FI模块中的清账流程，是总账会计、财务顾问及FI初学者必须掌握的核心操作之一。这份PPT围绕开放项目（Open Items）管理展开，系统梳理账户间清账与同一账户内清账的适用边界，并说明分配字段、检索码、手工清账与自动清账的配置思路；同时覆盖应收应付的收款与付款处理、清账后已清项重置、支付差额及容差组等常见业务场景。资源包内仅含1个PPT文件，约1.12MB，内容以章节化页面呈现，便于按主题查阅或用于内训演示。目前已有4629人学习下载，适合需要理解清账逻辑、对照实际操作或准备SAP财务培训的读者。借助其中的概念对比与流程要点，可快速建立从开放项目产生到清账、重置及后续冲销的完整知识框架。

1. 清账不是点个按钮：SAP 财务里最容易被低估的一步

接手一个余额对不上的账套，十次里有七八次问题不在凭证录错，而在 SAP 财务的清账环节没做干净。清账（Clearing）说穿了就是把借贷两边能对上的行项目配成一对，让它们从「未清」翻成「已清」，账龄表、资产负债表、客户对账单才有意义。未清项清不掉，凭证归档不了，账龄永远停在上个月。

这份资料把清账拆成四块：Clearing Open Items、Incoming and Outgoing Payment、Payment Differences、Exchange Rate Differences，覆盖了账户间清账和同账户清账两条主线，以及手工、自动两种执行方式。适合刚接手 FI 模块的顾问、要把月结流程固化下来的财务关键用户，以及被「已清项不能冲销」卡过的人。

2. 两条清账主线：Post with Clearing 与 Account Clearing 到底差在哪

很多人把这两个当成同一个动作的不同叫法，结果在报表里找不到自己刚清掉的那笔钱。这两条路的底层机制不一样：一条是生成新凭证去清旧凭证，一条是只改行项目状态、不落新凭证。选错了，不只是看不到结果，后续冲销、审计追溯全部要返工。

2.1 Post with Clearing：跨科目、跨币种，清完留下一张清账凭证

Post with Clearing 的本质是一次「带清账的过账」。你在录入一张新凭证的同时，把一批未清项挂上去做对冲，系统保存时会额外生成一张清账凭证（Clearing Document），并回写原凭证行项目的清账凭证号和清账日期。这一步的关键特征是：它产生行项目，凭证里看得见，报表里也追得到。

它的三个能力边界值得记住：

部分清账是最容易翻车的地方。举个具体场景：客户发票 100 万，这次只收到 60 万，你走部分清账，回头在客户行项目报表里查这张发票，看到的是 40 万——那 60 万去哪了？它没有消失，也没有变成一条独立的已清记录，而是被「削」掉了。想看到这 60 万的去向，只能打开清账凭证看行项目。这是设计如此，不是系统丢了数据。月结时如果有人拿报表金额跟凭证金额对不上来问你，八成就是这一条。

跨币种清账要额外留个心眼：外币发票用本币收款时，清账凭证里会自动算出实现汇兑损益，走的是汇兑损益的科目确定配置。如果这个科目确定没配好，凭证保存会直接报错，报错信息通常指向某一方缺少科目。这类报错不要急着改凭证，先去查科目确定的配置。

常用入口：客户侧 F-32，供应商侧 F-44，总账侧 F-04 或 FB05。三者界面结构一致，只是默认带出的往来对象不同。

2.2 Account Clearing：同一个账户内部对冲，账面上不留行项目

Account Clearing 解决的是另一类问题：钱没有真的收进来或付出去，只是账面上一正一负需要互相抵消。典型场景有三种：

1. 一张未清发票配一张相关的贷项凭证（credit memo），金额能对上；
2. 同一笔业务被录了两次，一借一贷重复记账；
3. 预收款（payment on account）挂在客户上，现在要拿它去冲一张发票。

走 F-03，输入总账科目，系统把该科目下的借方和贷方未清项列出来，你挑出要配对的那几条，配平后保存。它和 Post with Clearing 最大的区别在于：不产生新的行项目。凭证层面你看不到一张独立的「清账凭证」，行项目的清账状态被就地更新。所以它的追溯性天然弱一截——事后想搞清「这笔是什么时候被谁清掉的」，只能靠行项目上的清账日期和清账凭证字段去反查，而不是打开一张凭证从头读到尾。

这带来两个实际操作上的约束。第一，Account Clearing 不适合做差额处理：金额配不平就保存不了，没有容差、没有差异科目可以挂，要么改金额，要么退回去用 Post with Clearing。第二，它只在你指定的那一个账户内生效，跨科目一律走不通——想拿客户贷方去冲总账借方，系统会直接拦住你。

还有一点容易被忽略：Account Clearing 能不能用，取决于这个科目是不是「未清项管理」的科目。总账科目主数据里有个行项目管理标识，没勾上的科目根本不会产生未清项，自然也就谈不上清账。有人拿到一个新科目，F-03 进去空空如也，第一反应是权限问题，其实是主数据没开行项目管理。查这个比查权限快得多。

2.3 判定表：拿到一笔业务先问三个问题

选哪条路，其实不用记概念，按顺序问三个问题就行：

三个问题一路问下来，答案基本唯一。真正容易出错的是第二问：很多人以为「金额差一点」也能走 Account Clearing，实际上只要差一分钱都保存不了，系统会提示借贷不平衡。这时候不要试图去调金额凑平，那是在给自己埋雷——正确做法是退回上一步，改用带清账的过账，把差额明确地过到一个差异科目上。

还有一种混合场景：先用 Account Clearing 把重复记账冲掉，剩下的真实未清项再用收付款清。这两步不冲突，但顺序要对——先把脏数据清掉，再做真实收付，否则收付款界面里会混进一堆本该被冲销的重复项，选错一次就得走重置流程。

3. 手工清账全链路：从一张发票到 F-28 收款清账

手工清账是自动清账的地基。自动清账跑不通，绝大多数时候不是规则写错了，而是手工这一遍的字段填法本来就不规范。这一章按真实操作顺序走一遍：主数据准备、抬头录入、行项目选择、差额处理、保存与验证。

3.1 前置准备：主数据里那三处没配好就别急着清

动手之前先确认三件事，这三件事任何一件缺失，后面的操作都会在中途卡住。

第一，往来对象主数据完整。客户或供应商的公司代码段必须存在，且不能有冻结标识。冻结标识分好几种，其中过账冻结会直接拦住收付款录入，报错信息只说「账户被冻结」，不会告诉你是哪一种冻结，需要在主数据里逐项看。

第二，容差组（Tolerance Group）已指派。容差组决定系统能自动接受多大的收付差额。资料里写得很清楚，容差组有三个指派层级：用户（员工）主数据、总账科目主数据、客户/供应商主数据。三层都可能有值，实际生效的是最具体的那一层。配置时按「组键（4 位字母）+ 公司代码 + 币种」的组合来定义，组键是自建的四个字母，不是系统预置的固定值。

容差组内部又区分三种用途，这决定了差额发生时系统怎么处理：

第三，账龄基线先跑一遍。清账前用 FBL5N（客户行项目）或 FBL1N（供应商行项目）把当前未清项导出来，留一份基线。这不是流程要求，是我自己的习惯——清完账发现金额不对，手里没有清账前的快照，就只能靠猜。

3.2 抬头三块数据：Payment Header、Bank Data、Open Item Selection

以 F-28 收款为例，抬头录入分成三块，每一块都有它自己的坑。

Payment Header：凭证日期、过账日期、公司代码、币种、金额。这里最常错的是币种——如果发票是外币，收款也必须是同一外币，用本币收款会直接变成跨币种清账，产生汇兑差异，这笔差异其实是虚假的。过账日期决定这笔清账落在哪个会计期间，跨期清账要特别小心，一旦过到已关闭的期间会直接报错。

Bank Data：银行科目、金额、起息日（Value Date）。银行科目必须是银行清算类科目，用错科目会导致银行余额调节表做不平。起息日和过账日期不同的情况很常见，系统不会拦你，但现金流量表会因此错位。

Open Item Selection：选择要清的未清项。这一步决定了后面界面里出现哪些行。

三块填完点回车，进入 Process Open Items 界面。这里是整条链路的核心。

3.3 Process Open Items：Assignment 与 Sort Key 怎么填

界面上半部分是未清项列表，下半部分是本次清账的行。上半部分有个细节：批注项目（Noted Items）也会显示出来，但它是被排除在自动清账之外的。手工操作时可以选，选之前想清楚这是不是你真的想清的那一笔。

两个字段值得单独说：

Assignment（分配字段），最多 18 个字符，可以由最多 4 个字段组合而成。它不是装饰字段，而是自动清账的匹配依据——资料里把它称作银行对账时的「聚号」，意思就是靠它把银行流水和账面未清项聚到一起。手工清账时如果这个字段留空，将来跑自动清账，这条记录就永远匹配不上。

Sort Key（检索码），决定行项目里默认带出哪些业务字段，比如采购订单号、成本中心等。它影响的是「日后能不能按业务维度查账」，不影响清账本身。配置时按业务需要选，不要图省事全留空——等业务方提「我要按 PO 号看未清项」的时候再补，历史数据的检索码是补不回来的。

界面上还有两个容易被跳过的字段：Text（文本）和 Reason Code（原因代码）。原因代码不是必填，但如果你们有差异分析需求，它是唯一的分类依据。我一般要求关键用户在处理差额时必填原因代码，否则月底分析差异构成只能靠翻凭证描述。

3.4 模拟、保存与差额处理：Simulate 这一步不要跳

填完行项目，先点 Simulate（模拟），再点保存。模拟会生成一张预览凭证，把你这次清账会产生的所有行项目全部列出来，包括自动算出的折扣、汇兑差异、差异科目。

这一步是后悔药。模拟结果里重点看三处：

• 有没有出现你没预期的行项目，尤其是有没有凭空多出一条差异行；
• 差额落到了哪个科目，是不是你想要的折扣调整科目或扣款科目；
• 清账后原发票的剩余金额，部分清账时这个数字必须和你心里的预期一致。

模拟没问题再保存。保存后系统给出凭证号和清账凭证号，两个号都要记下来——清账凭证号是后续做重置和追溯的唯一入口。

差额处理有一个原则：容差内的差额交给系统自动过账，容差外的差额不要硬凑。超出容差时有两个正当选择，一是改走部分清账，把这次收到的金额如实清掉，剩余继续挂未清；二是手工指定一个差异科目，把差额明确落账。硬凑金额（比如在文本里写「差额暂挂」然后调平）是最坏的做法，它会让差异从账面上彻底消失，等到审计问起「这笔 37 块钱差在哪」的时候，你连线索都没有。

3.5 汇兑差异和支付差异：别把两类差异混成一类

外币业务清账时，除了支付差异，还会产生汇兑差异。这两类差异性质完全不同，处理方式也不同。

支付差异（Payment Difference）是金额层面的：发票 10000，实际收到 9950，差的 50 是折扣、扣款或者对方少付。它由容差组控制。

汇兑差异（Exchange Rate Difference）是汇率层面的：发票日汇率和收款日汇率不同，本币金额自然对不上。它不由容差组控制，而是由汇兑损益的科目确定决定，系统自动计算、自动过账。

混在一起的典型后果是：本币差额里既有汇兑又有折扣，你按容差组去判断，看起来「在容差内」，自动过账了，结果汇兑损益被记进了折扣调整科目，月末汇兑损益表对不上。处理外币清账时，先把汇兑差异单独算出来看一遍，再判断剩下的金额是否在容差内，顺序不能反。

4. 自动清账 F.13：银行对账场景的前置条件与排除清单

手工清账能解决个案，解决不了量。银行对账这类场景，一天几百笔流水，靠手工点是不现实的，必须上自动清账（F.13）。但自动清账不是「配好就能跑」，它的失败率往往来自前置条件不满足，而不是规则写得不好。

4.1 三个前置条件，缺一个就跑不起来

资料里把条件写得比较克制：open item basis、要清账的账户必须定义。展开成可执行的检查项是三件事：

第一，清账基础（Open Item Basis）要成立。也就是参与清账的科目必须开启了行项目管理。这个和 2.2 里说的是同一件事，但自动清账对它的依赖更硬——手工清账时你至少能看到界面，自动清账跑起来是黑匣子，科目不开行项目管理，日志里只会告诉你「没有可清项」，不会告诉你为什么没有。

第二，账户必须在配置里被显式定义。自动清账的配置是按公司代码 + 科目（或科目区间）组织的，没在配置里出现的科目，跑批时会被整段跳过。新开一个银行清算科目，忘了加进配置，是这个功能最常见的「不生效」原因。

第三，匹配字段要能对上。自动清账靠分配字段、参考号、金额、日期这些字段做匹配。前面 3.3 说过，手工清账时分配字段留空，自动清账时就匹配不上。所以自动清账能不能跑通，其实在手工录入阶段就已经决定了。

配置入口一般按「公司代码 → 清账科目 → 匹配规则」的层级组织，规则里可以指定允许多大的金额差异、允许多少天的日期偏差。这两个参数不要一上来就放宽，先按严的设置跑一遍模拟，看能匹配上多少，再逐步放宽——放宽容易，收回来难，因为一旦清错了，重置的成本远高于手工清。

4.2 五类不会被自动清掉的项目

这一条是资料里最有价值的部分之一，也是实际操作中最容易被误解的：自动清账不是「把所有未清项都清掉」，它有一份明确的排除清单。

这五类里，批注项目是最容易出问题的。有人在手工清账时随手点了个「批注」做标记，本意是「这笔先记着，回头再看」，结果自动清账跑完，这笔永远留在未清里，月结时被当成异常项查了半天。批注不是备忘录用，它会实质性地改变这笔记录的可清状态。

预提税那一条也值得多说一句。含预提税的项目被自动清账排除，不是系统的缺陷，而是设计使然——预提税的清账要同步处理税额的结转，普通清账跑了会把税基搞乱。如果你的业务里有跨境采购涉及预提税，自动清账跑完一定要单独核对这部分余额。

4.3 Assignment 当「聚号」用：银行对账的落地做法

资料里那句「用系统做银行对账，未达账项就要用自动清账，其 assignment 就是聚号」，是整个自动清账的落地核心。展开成可执行的做法是这样：

银行流水侧，每笔流水都有一个银行给的参考号（转账附言、汇款编号之类）。这个号要能落到账面未清项的分配字段上。

账面侧，收款录入时把银行参考号填进分配字段。18 个字符是硬上限，超了会被截断——这是后面避坑章节要展开的一条。

匹配侧，自动清账按分配字段做等值匹配，同时校验金额。金额不一致的，进入下一轮按金额+日期匹配，再匹配不上就留在未清里等人工。

这套做法能成立的前提是：业务方在录收款时就知道要填参考号。如果收款是出纳批量导入的，那就要在导入模板里预留这个字段，并且做一次字符长度校验。我见过的最典型的失败案例是，导入模板里参考号字段设成了 30 位，前 18 位一致、后面各不相同，导入 SAP 后全部截断成一样的前 18 位，自动清账一跑，几十笔流水被清到了一笔发票上。这类问题一旦发生，只能一笔笔重置，工作量比手工清还大。

4.4 跑批参数：先模拟，再更新，最后读日志

F.13 的执行界面参数不多，但每一个都影响结果：

执行顺序我一般是三步：先跑模拟，把模拟清单导出成表；再人工抽查前 20 条，重点看金额差得多的和日期跨度大的；确认没问题再跑更新。跑完不要急着关界面，日志里会列出「已清」「未清」「异常」三类统计，异常的那部分是下一次排查的入口。

还有一个细节：自动清账跑完生成的是批输入会话时，会话本身还需要执行一次才会真正过账。有人跑完 F.13 看到「已完成」就去查报表，发现什么都没变，原因就在这里——会话还挂在系统里没执行。

5. 清账避坑与排查：五个真实踩过的坑

这一章的五条，每一条都是我在项目上真实处理过的。按「现象 → 原因 → 解决」写，方便直接对照。

5.1 已清项点冲销报错：先 Reset 再 Reversal

现象：客户发票录错了，想用 FB08 冲销，系统报错，提示该凭证已清账，不允许冲销。

原因：清账是一个不可逆的状态变更，已清项和统计性科目不能直接冲销。资料里写得很明确——清账和统计性科目不能直接 reversal，必须先 reset，才能 reversal。系统这么设计是为了保证清账关系的完整性，否则一冲销，对面那条被清的行项目就变成了孤儿。

解决：先用 FBRA 做重置（Reset Cleared Items）。重置的动作顺序是：先把清账数据从行项目上移除，让这些项目回到未清状态，然后再执行冲销。注意 FBRA 界面上有两个选项，一个是「重置并冲销」，一个是「仅重置」。如果这张清账凭证本身也要冲掉，选前者；如果只是想解除清账关系、保留凭证，选后者。选错的话，要么多冲了一张不该冲的凭证，要么重置完还得再跑一次 FB08。

重置之后还要检查一件事：被恢复成未清的原发票，金额是不是回到了清账前的状态。部分清账场景下，重置会把金额还原，如果还原后金额对不上原始发票，说明中间还有别的清账动作，要一并处理。

5.2 部分清账后在报表里找不到被清掉的那一段

现象：发票 100 万，部分清账 60 万，在客户行项目报表里查这张发票，显示未清 40 万，那 60 万的清账记录怎么都找不到。

原因：部分清账不产生独立的已清行项目。被清掉的那部分金额只在清账凭证里有体现，未清项报表展示的是剩余未清金额。资料里那句「报表中不能看，凭证中可以看」说的就是这件事。

解决：想看被清掉的部分，走两条路。一是打开清账凭证看行项目；二是用行项目报表切换到「所有项目」视图，再按清账凭证号筛选。日常对账时，如果需要向业务方解释，不要拿未清项报表去讲，直接给清账凭证的截图，省得来回扯。

5.3 容差组没配或配小了，收款差额挂成新的未清项

现象：收款时少收了几块钱，保存后发票确实清掉了，但客户余额里凭空多出一条几块钱的未清项。

原因：差额超出了容差组允许的范围，系统不能自动过账，于是把它挂在客户上变成了一条新的未清项。这条新未清项的金额通常很小，很容易在月结时被忽略，然后一直滚下去。

解决：分两步。第一步，查容差组配置，确认用户层级、科目层级、客户层级的容差组是否都指派了，生效的是哪一层。三层里有一层没配，实际生效的可能是个空容差，那就是零容忍，一分钱差额都会挂账。第二步，如果差额确实属于正常业务（比如固定比例的现金折扣），把容差规则调整到能覆盖；如果不属于正常业务，就别放宽容差，改走部分清账或者手工指定差异科目，让差额落在它该落的科目上。

顺手提一句：容差组是按「组键 + 公司代码 + 币种」定义的，跨币种场景下如果只配了本币的容差规则，外币收款还是会挂账。这个细节资料里没展开，但实际项目中踩到过。

5.4 分配字段超 18 字符被截断，自动清账清错对象

现象：自动清账跑完，几笔金额相近但业务上毫无关系的收款被清到了同一张发票上。

原因：分配字段上限 18 个字符，录入时超长部分被静默截断，多笔流水的截断结果撞在了一起，自动清账按这个字段做等值匹配，自然就串了。

解决：短期靠重置（FBRA）把清错的逐笔解除，然后手工清。长期要做两件事：一是收款录入界面加输入长度校验，超过 18 位直接拦下来；二是把分配字段的构成规则固定下来（比如「客户号后 6 位 + 流水号 12 位」），让业务方按规则生成，而不是随手填。资料里提到分配字段最多可由 4 个字段组合而成，这个「组合」能力正是用来做规则化的，别浪费。

5.5 预提税项目被排除在自动清账外，余额长期沉淀

现象：自动清账跑了几个月，某个供应商的未清余额一直下不去，逐条查发现都是含预提税的项目。

原因：含预提税的项目在自动清账的排除清单里，这不是 bug，是设计。它的清账要同步处理税额结转，普通清账跑不了。

解决：单独建一个处理流程，把这部分项目筛出来手工清，或者在月结清单里单列一项定期核对。别指望调规则能让它们被自动清掉——真调通了反而是隐患，税额结转会出问题。

6. 清账后的验证：用行项目表和自检清单收口

清账做完不等于做对。我习惯在每次批量清账之后跑一遍验证，验证不复杂，但能挡住绝大部分「清完了才发现不对」的情况。

第一个动作是查清账凭证本身。已清项的行项目上会留下清账凭证号和清账日期，这两个字段是追溯的唯一入口。查的时候有一个性能上的坑：行项目表是簇表，不带主键条件直接查会全表扫，生产环境上跑一次能卡住整个系统。实战里优先查已清项专用表（客户已清、供应商已清、总账已清这三类），它们带索引，速度快得多。

" 按公司代码 + 科目查已清项，优先走已清项表，避免直接扫行项目簇表 SELECT bukrs, " 公司代码 kunnr, " 客户号（供应商场景换成 lifnr） belnr, " 会计凭证号 gjahr, " 会计年度 augbl, " 清账凭证号，追溯的核心字段 augdt, " 清账日期，决定落在哪个期间 dmbtr " 本币金额 FROM bsad " 客户已清项；供应商用 bsak，总账用 bsas INTO TABLE @DATA(lt_cleared) WHERE bukrs = @p_bukrs AND hkont = @p_hkont AND augdt IN @s_augdt.

这段查询的用法是：给定公司代码、科目和清账日期区间，把这批清账结果拉出来，和清账前留的基线做减法。参数上要注意augdt用的是清账日期不是凭证日期，跨期清账时这两个日期会不同，用错字段会漏数据。金额字段用本币金额还是凭证货币金额，取决于你要核对的是本位币账还是外币账，别混用。

第二个动作是对账龄表。清账前后的账龄分布应该有明确变化，如果某个账龄区间的金额纹丝不动，说明那批项目根本没被清到，或者被清到了别的期间。这个检查比逐条核凭证快得多，也更容易发现批量性的问题。

第三个动作是抽样打开清账凭证，看差额落到了哪个科目。这一步主要是防容差组配置被误改——配置改动不会报错，只会在下一次清账时悄悄改变差额的落点。

下面这张自检清单我现在还在用，每次批量清账后过一遍，五分钟的事：

最后一个习惯，是从一次很难受的返工里养成的：任何批量清账之前，先把未清项导一份基线出来存好。那次是自动清账规则被同事改宽了，一下清掉两百多笔，等发现的时候基线已经没了，只能一笔笔从凭证里反推，整整花了两天。从那以后我每次跑批量清账前都强制走一遍「导基线 → 模拟 → 抽检 → 更新 → 对账龄」这五步，一步不跳。希望帮到你。

本文还有配套的精品资源，点击获取