企业官网建设流程全解析

简介：围绕SAP FI模块清账流程整理的一份专题课件，面向财务顾问、实施人员及会计信息化学习者，帮助梳理未清项管理、手工与自动清账、支付处理及已清项重置等核心知识。包内为1个PPT文件，压缩后约1.12MB，内容以概念讲解和流程要点呈现，便于课堂培训或自学时按章节查阅。已有4628人学习下载。课件从开放项目、账户间清账与同一账户内清账的差异切入，延伸到分配字段、检索码、容差组、进项与出项支付及清账后冲销前的重置操作，并配有客户行项目、清账凭证等要点提示。适合希望系统理解SAP清账逻辑、补齐FI操作细节的读者用作知识框架与复习提纲。

1. 未清项为什么卡住归档：清账到底在“清”什么

在 SAP 财务模块里，一张发票过账之后，真正让它“消失”的并不是付款，而是清账。很多人默认付款凭证一过账，应收应付就自动干净了——事实正好相反：付款只是产生了一条新的贷方行项目，原来那条借方未清项照样躺在系统里，直到清账动作把两条记录“配对”上，它才会从 Open Item 变成 Cleared Item。这就是为什么月末跑账龄分析时，钱明明已经收到，客户余额还是挂着，凭证也没法归档。

清账表面上只是一个打勾动作，底层却是一次凭证生成、状态迁移和索引匹配的组合操作。搞懂它，你才能解释清楚三个反复出现的问题：为什么有的清账在报表里看不见、为什么自动清账总漏掉几条、为什么已清项不能直接冲销。这三件事背后是同一套机制。

2. 清账的两种形态：为什么 Post with clearing 有行项目、Account clearing 没有

清账在系统里从来不是“删除原凭证”，这一点先要钉死。原发票凭证一旦过账就是账本的一部分，谁也不能改它。所谓清账，是在原凭证的行项目上写两个字段——清账日期和清账凭证号，让这条行项目的状态从“未清”翻转为“已清”，然后再决定要不要额外生成一张凭证来承载差额。

这两种形态的差异，根子就在这里。

2.1 Post with clearing：差额需要一张新凭证来承载

账户间清账（Post with clearing）通常发生在不同科目、不同账户类别，甚至不同币种之间。比如用银行存款清掉客户应收，借方是银行科目、贷方是客户应收，两边科目不同，借贷虽然平衡，但凭证头必须是一张新凭证，因为原发票凭证里根本没有银行那一行。

系统做的事分两步：先给被清项打上清账标记，再生成一张清账凭证（Clearing Document），把这次的对手方分录装进去。原发票的行项目内容一个字符都不动，只是多了清账日期和清账凭证号。

" 清账过账的示意逻辑：改状态 + 生成新凭证，而不是删除或修改原凭证 DATA: lv_clear_doc TYPE bkpf-belnr, lv_bukrs TYPE bkpf-bukrs. " 第一步：在原未清项上写入清账标记 " augbl = 清账凭证号，augdt = 清账日期，augcp = 清账过账日期 UPDATE bseg SET augbl = @lv_clear_doc augdt = @sy-datum augcp = @sy-datum WHERE bukrs = @lv_bukrs AND belnr = @lv_invoice_no " 原发票凭证号 AND gjahr = @lv_gjahr AND buzei = @lv_item_no. " 原发票行号 " 第二步：仅 post with clearing 才生成新凭证 " 借贷差额由这张新凭证承载，原凭证保持只读 " 具体过账走标准过账接口，此处只表达调用时机 IF lv_clearing_type = 'POST_WITH_CLEARING'. PERFORM post_clearing_document USING lv_bukrs lv_clear_doc. ENDIF.

代码里最关键的参数是augbl和augdt：前者记录“我被哪张凭证清掉的”，后者记录“什么时候清掉的”。有了这两个字段，任何一条行项目都能反查出自己的清账凭证，这也是后面做重置和冲销的唯一入口。belnr、gjahr、buzei三个字段一起定位到唯一一条行项目，缺一个就会误伤同号的其他凭证。

注意，第二步的生成动作是可选的。这就是两种清账形态的分水岭。

2.2 Account clearing：净额为零，所以不需要行项目

同一账户内清账（Account clearing）处理的是另一种场景：一张未清发票和一张相关的贷项凭证，或者一笔预付冲应收，它们挂在同一个客户或同一个总账科目下，借贷方向相反、金额可以对上。清完之后，这个账户下的净额变化为零，系统没有任何差额需要往新凭证里塞。

既然没有差额要承载，就没有生成凭证的理由。系统只做第一步——把两条行项目的清账字段写上，让它们同时从“未清”翻成“已清”。结果就是你在凭证流里看不到一张新的清账凭证，报表上也没有新的行项目，只有原凭证的状态变了。

这就是“Account clearing 没有 line item 显示”的真正原因，不是什么特殊配置，而是账务逻辑上根本不需要。理解这一点之后，很多看似玄学的现象就通了：为什么部分清账在报表里看不到明细，因为部分清账本质上也是同账户内的净额处理，系统只改状态、不生成承载凭证，想看细节只能进凭证行项目里翻。

2.3 部分清账和跨币种清账：同一套机制的两种边界用法

部分清账（Partial Clearing）指一张发票只被清掉一部分金额，剩余部分继续挂在未清项里。系统在处理时会把原发票“清掉”，再按未清余额生成一张新的未清项，所以你在余额报表上看到的是新凭证，而不是原发票被改小了。这跟“修改原凭证”是两回事，前者是追加，后者在账务系统里根本不允许。

跨币种清账则把差额问题推到汇率上。用美元科目清欧元应收，即使金额看起来对得上，按清账日的汇率折算后必然产生差额，这部分走 Exchange Rate Differences，同样需要一张清账凭证来承载。也就是说，跨币种场景基本都会退化成 Post with clearing 的形态，因为差额客观存在。

提示：判断一次清账会不会产生新凭证，看的是清完之后这个账户的净额是否为零。净额为零走 Account clearing，净额不为零走 Post with clearing。

3. 配对靠什么：Assignment 字段、Sort key 与自动清账的匹配算法

清账的难点从来不是“打标记”，而是“怎么知道这两条记录该配成一对”。金额相同、日期相近的未清项可能有一大把，系统必须靠一组预先埋好的索引字段来做匹配，否则自动清账就是随机配对。

3.1 Assignment 字段：18 个字符装下整条业务线索

分配字段（Assignment Field）挂在行项目层面，最长 18 个字符。业务上常见的做法是把最多 4 段信息拼进这一个字段，比如单据号、公司代码、年度、行号，拼成一条能唯一定位的字符串。它之所以重要，是因为它是自动清账最主要的匹配依据之一。

18 个字符这个长度限制不是随手定的，它对应的是旧式单据编号体系的容量上限，塞得下大多数业务单据号，又足够短到能做索引。血泪经验是：一旦业务部门要求的拼接规则超过 18 位，后半截会被静默截断，匹配就永远对不上，而且系统不会给你任何报错。

" 过账时给行项目写分配字段的示意 " 拼接规则：单据号(10) + 年度(4) + 行号(3)，总计 17 位，留 1 位余量 DATA(lv_assign) = |{ lv_bill_no }{ lv_gjahr }{ lv_item_no }|. " 长度校验必须自己做，系统不会因为超长而报错 IF strlen( lv_assign ) > 18. lv_assign = substring( val = lv_assign len = 18 ). " 截断是坑，能提前拦就提前拦 ENDIF. ls_item-zuonr = lv_assign. " zuonr 即分配字段

zuonr是分配字段在行项目表里的技术字段名，strlen判长这一步很多人省掉，结果就是前半年跑得好好的，某天单据号位数进位之后自动清账大面积失效，排查起来要翻几百条行项目才能定位。

3.2 Sort key：决定过账时往 Assignment 里填什么

检索码（Sort Key）容易和分配字段搞混，但它们的层级完全不同。分配字段是行项目上的一个值，检索码则是主数据层面的一项配置——配在客户或供应商主数据上，决定“过账的时候，把哪些字段自动填进分配字段”。

换句话说，Sort Key 是规则，Assignment 是结果。你在主数据里把 Sort Key 设成对应采购订单号，那以后这个供应商的每笔过账，分配字段会自动带出 PO 号；设成成本中心，就带成本中心。它同样可以用在手工清账时做检索，输入检索码就能把相关未清项筛出来。

这个设计动机很清楚：清账匹配需要业务语义，而业务语义在不同企业、不同供应商之间差别很大，硬编码一套规则必然不够用。把它下沉成主数据配置，等于让每个供应商、每个客户自己声明“我这类单据该怎么被找到”。

3.3 自动清账：先分组，再在组内做借贷对冲

自动清账的前提条件有三条：一是必须基于未清项（open item basis），二是要清账的账户必须事先定义，三是匹配规则要能落到具体字段上。三条缺一条，自动清账就跑不起来或者跑出来是错的。

有几类行项目是明确不参与自动清账的：批注项（noted items）、统计性过账、预付款、汇票，以及带预提税分录的行项目。原因不难推：这些行项目的金额或状态本身就不代表一笔待结算的债权债务，硬把它们配对进去只会把账搅乱。

在实现上，自动清账的典型思路是按匹配键分组，组内做借贷对冲，对不平的留给人工。银行对账就是最典型的应用场景——未达账项要用自动清账处理，匹配键通常就是那个“账号”性质的标识。

" 自动清账的匹配骨架（示意） " 匹配键 = 分配字段 + 金额绝对值 + 币种，保证同键的条目才有配对资格 LOOP AT lt_open_items INTO DATA(ls_item). DATA(lv_key) = |{ ls_item-zuonr }/{ ls_item-dmbtr }/{ ls_item-waers }|. APPEND ls_item TO lt_bucket[ lv_key ]. " 同键条目落进同一个桶 ENDLOOP. LOOP AT lt_bucket INTO DATA(ls_bucket). " 桶内借贷合计相等才允许清账，否则整桶挂起转人工 IF ls_bucket-debit_total = ls_bucket-credit_total. PERFORM clear_bucket USING ls_bucket. ELSE. APPEND ls_bucket TO lt_manual_queue. ENDIF. ENDLOOP.

这里zuonr（分配字段）、dmbtr（本位币金额）、waers（币种）三个字段共同构成匹配键。少放金额，会导致一张 1000 的发票和两张 500 的发票被错误配对；少放币种，跨币种条目会被算进同一个桶，借贷永远对不平。lt_manual_queue是兜底出口，自动清不掉的必须落到人工队列里，否则这些未清项会安静地烂在系统里，直到下个月对账才炸出来。

4. 收付款清账：一笔 incoming payment 在系统里走了哪几步

收付款清账是清账机制最高频的落地场景。应收账款里的 incoming payment 清的是未清的借方金额，应付账款里的 outgoing payment 清的是未清的贷方金额，方向相反，流程骨架基本一致。

4.1 凭证头的三段录入：Payment Header、Bank Data、Open Item Selection

手工支付流程的第一步是录凭证头，这里面其实分了三块信息。Payment Header 装的是付款本身的信息（付款日期、金额、收付方）；Bank Data 装的是银行侧信息（银行科目、账户、起息日）；Open Item Selection 则是决定这次要清哪些未清项。

三段分开录入不是形式主义，是因为它们的来源和校验规则完全不同。银行数据来自对账单或银行接口，错了要退回银行侧核对；未清项选择来自系统内部的未清项清单，错了要退回业务侧确认。把它们混在一个界面里，出问题时就分不清责任边界。

未清项被选中之后，系统会把金额按选中项分配，这一步就是清账的实际动作。选中的项会被打上清账标记，没选中的继续挂着。

4.2 模拟过账：为什么这一步不能跳

清账涉及的操作不是单表的，它要同时改多条未清项的状态、生成一张清账凭证、可能还要算现金折扣和汇率差异、检查容差是否超限。任何一步出问题，写库之后再回滚的成本极高——凭证号已经占掉，序列号出现空洞，财务对账时又要解释半天。

模拟（Simulate）做的事就是把这套逻辑在内存里完整跑一遍，但不写库，把结果摊给你看：会清掉哪几条、会生成什么分录、折扣算出来多少、有没有超出容差。这一步是黑匣子变透明的地方，也是踩坑最少的人往往最重视的一步。

" 收付款清账后的分录形态（示意） " 场景：客户应收 1000，实付 980，差额 20 落在容差内 " 借：银行存款 980 " 借：现金折扣调整（容差内自动） 20 " 贷：应收账款 1000 " 三个科目缺一不可： " 银行科目来自 Bank Data 中的银行账户配置 " 折扣科目来自容差组的自动过账配置 " 应收科目来自被选中的未清项

分录里的银行科目，就是系统配置中用于收付款的那个总账科目。它不是在清账那一刻临时决定的，而是在录入 Bank Data 时就已经绑定了。容差内产生的折扣差额会自动过账到折扣调整科目，容差外则不会自动过账，直接拦下来转人工——这条分界线由容差组决定，下一章展开。

4.3 清账凭证与未清项的对应关系

一笔收付款清账完成后，你能在系统里查到的东西有三样：原未清项上多出来的清账日期和清账凭证号；一张新的清账凭证，里面装着银行侧和折扣侧的分录；以及更新后的余额。这三样东西通过清账凭证号串在一起，构成了完整的凭证链。

账龄分析跑的是未清项清单，所以清掉的项会立刻从报表上消失；凭证流查的是凭证之间的引用关系，所以清账凭证和原发票会互相关联。这两个视图看起来描述的是同一件事，实际查的是两套数据，混着看就会产生“明明清了怎么报表上还有”的错觉。

5. 清账避坑：从差额容差到重置已清项的排查清单

清账出错的表现形式非常集中：要么清不掉，要么清错了，要么清完改不了。这三类问题背后分别对应配置、数据和时序，下面按现象、原因、解决三层拆开讲。

5.1 差额去哪了：Payment Difference 与 Exchange Rate Difference 的分流

付款金额和发票金额对不上是常态，客户会因为折扣、运费、质量扣款少付一点。系统允许在过账时定义一个可容忍的误差范围，这个范围就是容差，清账产生差额时按它决定是自动处理还是拦下来。

容差组的挂载点有三处：用户（员工）主数据、总账科目主数据、客户或供应商主数据。定义步骤是先建容差组，再按组键（4 位字母）、公司代码、币种的组合来定义具体阈值，最后把容差组分配给这三类对象中的一类或多类。

组键必须是 4 位字母，这个限制看着琐碎，实际是给不同业务线留命名空间的——按业务类型分段，比一长串描述性名称好维护得多。分配对象不同，生效范围也不同：挂在用户上只影响这个人的操作，挂在科目上影响所有走这个科目的清账，挂在客户供应商上则跟着这个往来单位走。

容差内的差额，系统会自动过账“现金折扣调整”和“未授权的客户扣款”这两类分录；超出容差的，一律不自动过账，必须人工处理。这条规则的设计意图很明确：小额差异高频且无害，自动化能省大量人力；大额差异低频且可能是错的，必须有人看一眼。

-- 排查用：找出从未被清账、且没有分配字段的客户未清项 -- 这类条目是自动清账漏清的典型嫌疑对象 SELECT kunnr, belnr, gjahr, buzei, dmbtr, zuonr, augdt FROM bsid WHERE bukrs = '1000' AND augdt = '00000000' -- 清账日期为空，说明从未被清 AND zuonr = '' -- 分配字段为空，自动匹配无从下手 ORDER BY kunnr, belnr;

augdt = '00000000'是判断未清的标准写法，日期字段在未赋值时就是这个零值。zuonr = ''筛出来的是没有分配字段的条目，它们几乎不可能被自动清账命中，只能靠人工按金额和日期去凑。

5.2 五条踩坑记录

踩坑一：清账后想冲销原发票，系统直接拒绝。

现象是选中原发票做冲销，报错说该凭证已被清账，不允许 reversal。原因是已清项的行项目上挂着清账凭证号，直接冲销会导致清账凭证变成孤儿，借贷关系断裂。正确做法是先做重置（Reset），把清账数据从行项目上移除，让状态回到未清，然后再冲销。顺序反了，系统不会给你后悔药。

踩坑二：自动清账跑完，账单上还剩一大片。

现象是自动清账日志显示处理成功，但未清项清单几乎没变。原因通常是两条：分配字段为空，或者主数据上的 Sort Key 没配导致过账时压根没填。解决是从主数据入手，把 Sort Key 配成能带出业务单号的字段，再对历史数据做一次批量补填，之后重跑。

踩坑三：部分清账之后，报表上看不到剩下的余额。

现象是余额报表里的金额和凭证里的明细对不上。原因是部分清账把原发票清掉、按余额生成了新凭证，而新凭证的展示逻辑和原发票不同。解决是查凭证行项目而不是只看余额汇总，余额是净额视图，明细才是事实。

踩坑四：跨币种清账后凭空多出一笔差异。

现象是清账凭证里出现一条没有业务来源的分录。这多半是汇率差异，属于正常机制而不是报错。清账日的汇率和原发票过账日的汇率不同，折算差额必须落到汇率差异科目上，否则借贷不平。解决是确认汇率差异科目配置正确，而不是试图消掉这条分录。

踩坑五：容差外付款被系统卡住，业务方以为系统坏了。

现象是录入付款后无法保存，提示差额超出允许范围。原因是容差组没分配给当前用户或当前客户，或者分配了但组键、公司代码、币种三者没有完全匹配上。解决是按这三个维度逐个核对容差组定义，注意币种维度最容易被忽略——本币配了不代表外币也配了。

5.3 Reset 的时序：为什么必须先擦清账数据再冲销

重置已清项（Reset Cleared Items）的动作顺序是有严格要求的：先把清账数据从行项目上移除，包括清账日期、清账凭证号、清账过账日期，让行项目回到未清状态，之后才允许对原凭证做冲销。

这个顺序不是实现上的随意选择。清账数据本质上是原凭证和清账凭证之间的双向引用，如果先冲销原凭证，清账凭证那条引用就指向了一个不存在的对象，系统要么报错，要么在数据层留下悬空引用。先在行项目侧把引用擦干净，两边就都回到了可以独立处理的状态。

还要注意，清账凭证和统计性科目不能直接做冲销，必须先重置。统计性科目本身不参与余额计算，但它的清账状态一样会阻挡冲销动作，这一点经常被忽略，导致排查时在余额上兜圈子。

6. 为什么清账不直接删除：状态机、凭证链与不可回滚的账

把清账拆到这里，会发现整套机制背后只有一条铁律：账本只追加，不修改。清账不打删除标记、不改金额、不动原凭证的任何业务字段，它只是在行项目上追加两个状态字段，必要时再追加一张凭证。这个选择牺牲了“干净”——系统里会长期存在大量已清项和被引用关系，换来的是可审计、可追溯、可回滚到一个确定状态。

这个取舍也解释了开头那个现象：为什么未清项会阻止凭证归档。归档的前提是数据闭环——一条行项目如果还挂着未清状态，说明它的业务生命周期没走完，此时归档等于把一个悬而未决的状态冻结进历史。系统宁可让它留在生产库里，也不允许带着未结状态进归档。

从实现角度看，清账是一个典型的状态机：未清 → 已清 → 重置后回到未清。每一次状态跃迁都必须留下凭证或字段作为证据，且跃迁方向可逆、痕迹不可擦。这个模型的好处是任何时点的账面状态都可以从初始凭证加一串状态变更重放出来，坏处是链路长、依赖多，一个字段没配上就会在某个分支上卡住，前面那些踩坑记录基本都是这个代价的具体表现。

验证一套清账逻辑是否正确，我一般会用三个动作交叉检查：清完之后查行项目的清账日期和清账凭证号是否都填上了；查清账凭证的借贷是否平衡、对方科目是否落在预期科目上；做一次 Reset 再重新清账，看能不能复现同样的结果。三个动作都过，才算这套配置真的稳。

从那以后我每次碰清账相关的配置，都强制先把“清完之后能不能重置、重置完能不能重清”这条路走一遍，再交给业务用。账务系统里最贵的不是写错，是写错了还退不回去。希望帮到你。

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