简介围绕SAP FI模块清账流程的PPT课件面向财务模块初学者及需要梳理未清项处理的财务顾问系统讲解清账概念、方法与操作要点。包内为1个PPT文件压缩包约1.12MB篇幅集中适合按章节快速查阅或培训时参考。已有4628人学习说明其内容在入门与实务衔接上具有一定参考价值。内容覆盖账户间清账与同一账户内清账的差异、分配字段与检索码的设置、手工清账和自动清账的适用条件以及应收应付收付款清账、清账后重置与冲销、支付差异和汇率差异等知识点对清账是否产生行项目、凭证归档限制等易混点也有辨析。读者可借此建立从开放项目到清账凭证、再到已清项重置的完整认识并理解自动过账与容差组在支付差异处理中的作用适合作为SAP财务清账专题的入门提纲和复习材料。1. 清账在 FI 里的位置一张从凭证到报表的路线图把「SAP 财务 清账」拆开看它其实是一张很小的图凭证进来产生 open item清账把它变成 cleared item报表才敢取数。可真复习起来它牵扯的东西比想象中多——应收应付子账、总账、支付事务、容差组、重置与冲销全串在这条线上。我习惯把它画成三层最上面是未清项的生命周期中间是两条清账路径账户间与账户内底下是差额处理和重置。这三层通了剩下全是参数和例外项。这份笔记写给已经录过凭证、正在系统啃 FI 或者要上机考核的人零基础读会有点跳但对着系统界面翻一遍能接上。2. 清账的两条路Post with clearing 与 Account clearing 怎么分清账在系统里不是一个按钮而是两组行为差别大到能决定你报表长什么样。这一步分不清后面所有参数都会记串。2.1 未清项的生命周期为什么不清账就归档不了原话是带未清项的凭证不能归档会一直留在系统里直到所有 open item 被清掉。这句话是整章的起点。凭证被过账那一刻它的行项目就带着「未清」标记进了子账清账不是删掉它而是给它打上清账凭证号、清账日期然后从「未清表」挪到「已清表」。所以你在系统里查同一张发票清账前后查的是两张不同的表。下面这段查询能直观看出「挪表」这件事客户未清项在 BSID清完进 BSAD-- 清账前客户未清项augdt / augcp 通常是空的 SELECT kunnr, belnr, buzei, dmbtr, augdt, augcp FROM bsid WHERE bukrs 1000 AND kunnr 0000100001; -- 清账后同样的行项目出现在已清项表带上清账日期与清账凭证号 SELECT kunnr, belnr, buzei, dmbtr, augdt, augcp FROM bsad WHERE bukrs 1000 AND kunnr 0000100001;字段含义belnr是会计凭证号buzei是行项目号两者组合才能唯一锁定一条未清项dmbtr是本币金额augdt是清账日期augcp是清账凭证号这两个字段就是「这条项已经被清掉」的证据。供应商侧把 BSID/BSAD 换成 BSIK/BSAK总账侧换成 BSIS/BSAS逻辑完全一样。提示复习时把这六张表的对应关系背成一组比单独记「未清项」三个字有用得多。2.2 账户间清账跨科目、跨币种、可部分清Post with clearing 是大多数人脑子里「清账」的默认样子。它的三个特征要按顺序记第一可以全部清也可以部分清部分清的结果在报表上看不出来但在凭证里能看出来——系统清掉原 invoice再生成一张新凭证承载剩余部分第二可以同时在不同科目、不同账户类别、任何币种之间做清账不要求两边科目一致第三它会生成一张 clearing document清账凭证这张凭证在客户行项目清单里是有 line item 显示的。这三点合起来说明一件事Post with clearing 是「有痕迹」的清账。痕迹体现在凭证上也体现在报表的行项目明细里。凡是需要对账、需要解释「这笔钱冲的是哪张票」的场景基本都走这条路。2.3 同一账户内清账没有 line item 的「隐形」清账Account clearing 完全是另一种性格。它用于手工把一张未清发票和一张相关的贷项备忘录、或者一笔 payment on account 对上也用于处理重复记账。它的作用范围被限制在同一个账户内基于 G/L account 和 sub ledger 做清账最关键的一条是清账不产生 line items。这条「不产生行项目」是它最容易翻车的地方。很多人在客户行项目清单里找不到清账痕迹就以为操作没成功反复重做结果做出一堆重复数据。正确理解是操作成功了只是它不给你留行项目这一层证据。所以对比记忆时要抓死这一句——Post with clearing 有 line item 显示Account clearing 没有 line item 显示。2.4 两条路的对比与选型判断把上面的差异压成一张表复习时先看表再回原文对比维度Post with clearing账户间清账Account clearing账户内清账清账范围可跨科目、跨账户类别、跨币种限定在同一账户内清账比例可全部清也可部分清以手工配对为主是否生成清账凭证生成 clearing document不生成行项目形式的清账凭证行项目显示客户行项目清单中有 line item无 line item典型场景发票与收款、发票与贷项跨科目对冲发票与贷项备忘录、payment on account、重复记账底层依据凭证层面对冲G/L account 与 sub ledger选型其实就一句判断需要留痕、需要跨科目或跨币种、需要部分清走 Post with clearing只是同一账户内把两笔互相对上、不想多出凭证走 Account clearing。两种方式都可手工也可自动这一点别记反——手工与自动是执行手段账户间与账户内是清账形态两个维度是正交的。3. 手工清账与自动清账条件、例外与银行对账场景形态分完接下来是执行手段。手工清账的重点在流程顺序自动清账的重点在准入条件和排除清单这两块考得最细。3.1 手工清账的三步表头、选点、模拟保存手工支付流程在原文里被压成三步但每一步都有可考的点。第一步是录 document header表头里要装的不是普通凭证那几栏而是 Payment Header、Bank Data、Open item selection 三块内容——支付头决定这是一笔收还是付银行数据决定钱走哪个账户未清项选择决定这次要清哪些。第二步是选 open item把待清的行项目勾进来。第三步是模拟simulate再保存模拟这一步不能跳它会先把过账结果摊开给你看包括自动生成的清账分录和可能出现的差额。顺序记忆的抓手是「先定钱从哪来再定清哪几笔最后看结果对不对」。这三步里最容易省掉的是模拟而省掉模拟恰恰是后面差额处理出问题的源头——差额一旦保存下去就得走重置才能改等于给自己加了一道工序。3.2 自动清账的两个前提与五类清不掉的项目自动清账不是随便就能跑它有两个硬条件一是 open item basis 要成立二是要清账的账户必须先定义出来。这两个条件是准入门槛缺一个就跑不起来。更常考的是排除清单也就是哪些项目自动清账碰不了noted items批注/备忘项statistical posting统计性过账down payment预付款bills of exchange汇票items with withholding tax entry带预提税款的行项目这五类为什么清不掉逻辑不难推前两类本身不具备实际结算意义预付款和汇票是流程中间态还没走到正式结算带预提税的行项目金额构成不完整自动匹配算不平。它们的共同点是「金额或状态不满足一一对应」。记住这个共性比死背五条更稳。自动清账最典型的用途是银行对账未达账项靠它批量处理此时 assignment 字段扮演的角色就是那个用来对上的识别号银行流水带过来的号和系统里未清项上的号一致就能自动配上。3.3 Assignment 与 sort key清账的检索身份证这两个字段经常被当成一个东西其实分工不同。Assignment field 是分配字段由最多 4 个字段组合而成总长上限 18 个字符它的作用是在清账时把两边对上属于「匹配用」。Sort key 是检索码可以按 PO、成本中心COC等维度设置作用是让行项目在清单里按你想要的顺序排列、方便查找属于「排序用」。两种方式——手工清账和自动清账——都可以用这两个字段所以别把它们绑在某一种清账形态上。配置时的现实约束是 18 个字符这个天花板。想塞进去单号、行号、日期、公司代码四段就得先算字符数超了就只能在组合方式上做取舍。这是实打实的踩坑点很多自动清账匹配率上不去最后查出来是 assignment 拼出来的串超出长度被截断了。3.4 收付款清账AR 与 AP 的对称结构Incoming payment 用在应收账款清的是未清的借方金额outgoing payment 用在应付账款清的是未清的贷方金额。客户付款时经常顺手利用现金折扣所以收进来的金额未必等于发票金额差额就落到后面的容差逻辑里。清账时会自动过账用到的科目就是为收付款设置的那个 G/L account支付/银行相关科目这一点是「清账会产生自动分录」的出处。接口层面做清账骨架基本固定成四段 清账接口的典型四段式START - 填 POSTAB - CLEARING - END CALL FUNCTION POSTING_INTERFACE_START EXPORTING i_client sy-mandt i_function C. C 清账类过账 每条待清行项目压进 POSTAB由记账码决定借贷方向 POSTAB-bukrs 1000. POSTAB-belnr 5100000123. 待清发票号 POSTAB-buzei 001. 待清行项目号 POSTAB-bschl 15. 记账码示例客户收款方向 APPEND POSTAB TO gt_postab. CALL FUNCTION POSTING_INTERFACE_CLEARING EXPORTING i_auglv lv_auglv 清账事务码按系统内配置取 i_bukrs 1000. CALL FUNCTION POSTING_INTERFACE_END.说明belnr加buzei才是待清项的唯一定位只给凭证号会报找不到行项目bschl记账码决定这条是借还是贷方向错了整个清账会平不了i_auglv是清账事务码不同业务收款、付款、转账取值不同实际以系统内配置为准。接口内部同样会走模拟与保存两步失败时不要只看返回码要把 POSTAB 里回填的消息表逐条翻一遍。4. 差额与容差Payment Differences 的容忍逻辑清账很少刚刚好平。差额处理这块内容不多但层级关系密属于「记一半等于没记」的典型。4.1 差额从哪来折扣、汇率、部分付款常见的三类来源客户享受现金折扣导致收款小于发票汇率差异Exchange Rate Differences导致外币清账时本币金额对不上以及部分付款和重复记账带来的余额。前两类在原文里直接点名第三类由 Account clearing 的用途反推而来。差额处理的本质不是消灭差额而是决定这笔差额由谁承担、记到哪个科目——在容差内系统自动过在容差外就得人工判断。4.2 tolerance group 的三层归属容差组tolerance group的定义挂在三个层级上这是必须背全的部分归属层级挂载对象影响范围用户/员工主数据用户employee主记录该用户录入清账时适用的容差总账科目主数据G/L account 主记录该科目上清账产生的差额容差客户/供应商主数据往来对象主记录该客户或供应商的收款差额容差定义步骤是三步走先 define tolerance group再按 group key4 位字母加公司代码、再加货币代码三元定位最后 assign 到上述三种对象上。三元定位这一点常被简写成「按公司代码设」一简写就丢分——同一个 group key 在不同货币下可以是不同的容差值这个设计是为了让外币清账和高通胀币种能分开控制。4.3 容差内自动过账容差外人工处理差额落在容差范围内时系统控制两类科目的自动过账cash discount adjustment现金折扣调整和 unauthorized customer deductions未授权的客户扣款。这两类名字看着像业务概念实际是系统里预设的过账去向容差内的差额自动归到它们身上不用人工干预。超出容差范围就不自动过账了转为手工处理。手工处理意味着操作者要自己决定差额记哪、要不要拆分、是否需要先挂账再核销。这里的分界线只有一条金额是否在容差内。判断依据单一反而不容易错容易错的是容差本身配错了层级或者币种导致本来该自动过的跑到手工里来。5. 易漏点清账复习里最容易翻车的五个地方这一章是按「踩过才知道」的思路排的五条都属同一类问题概念都听过但边界记岔了。5.1 把 Account clearing 当成「操作没成功」易漏点在客户行项目清单里找不到清账行项目就判定清账失败重复执行。为什么漏两条清账路径的差异被压缩成「一个有行项目、一个没有」这一句背的时候只记住结论没记住它意味着什么。清单里看不到不等于系统里没发生。怎么补把「有没有 line item」当成判定两条路径的检验点而不是操作结果。查证据时不要只盯行项目清单Post with clearing 去看清账凭证Account clearing 去看子账上的清账标记和清账日期字段两边各有各的落点。5.2 忽略 reset 才能 reversal 的顺序易漏点清完发现错了直接去冲销系统不让然后卡住。为什么漏清账和统计性科目不能直接 reversal必须先 reset。reset 时清账数据clearing data先被从行项目上移除移除之后才轮到冲销。这个「先移除、后冲销」的两段顺序在笔记里常被压成一句「要先重置」。怎么补把顺序写成动作序列记——reset 摘掉清账数据行项目回到未清状态此时才具备 reversal 的条件。反过来做一定失败。这也是清账唯一一颗后悔药用之前想清楚要重置到哪一步。5.3 自动清账的排除项记成「都能清」易漏点把 noted items、statistical posting、down payment、bills of exchange、带预提税的行项目误当成可自动清账对象。为什么漏五条清单是并列的硬背容易串行而且预付款、汇票在业务上看着「像」可以结算的东西直觉会带偏。怎么补不要背清单背共性——金额或状态不满足一一对应的项目自动匹配一定配不上。批注项和统计性过账本身无实际结算意义预付款和汇票还在流程中间态带预提税的行项目金额构成不完整归到「不完整、不对应」这一条理由下五类自然就出来了。5.4 把 assignment field 和 sort key 混成一个字段易漏点以为 sort key 就是用来做清账匹配的或者以为 assignment 只用于显示。为什么漏两个字段都出现在行项目上都跟「找得到、对得上」有关名字又不直观。实际上 assignment 是匹配用由最多 4 个字段组合、总长 18 字符封顶sort key 是检索码可按 PO、成本中心等设置用于排序查找。怎么补记一句分工——assignment 负责「对上」sort key 负责「排好」。再补一个实操约束18 个字符是硬上限拼字段之前先算长度超长被截断是自动清账匹配率低的常见原因。5.5 容差组只记层级不记三元定位易漏点容差组的定义只记住「用户、总账科目、客户/供应商」三层归属漏掉 group key、公司代码、货币代码这三元定位。为什么漏三层归属结构清晰、好背三元定位是一串参数看起来像细节。但容差值本身是按这三元存的层级只是「挂给谁」。怎么补把容差组拆成两个问题分别答——容差存在哪group key 4 位字母 公司代码 货币代码容差挂给谁用户、G/L 科目、客户/供应商三类主数据。两个问题分开记就不会互相覆盖。顺便记住容差内自动过账的两个对象现金折扣调整与未授权的客户扣款。6. 复习清单把清账这张图自己走一遍临考前我不建议再从头读一遍效率太低。更划算的做法是拿一张白纸按下面的顺序把整条线默画出来画到哪一步卡住就回对应章节补那一块。顺序要默出来的内容卡住说明什么1未清项到已清项的表迁移BSID→BSAD 等三组生命周期没通2两条清账路径的三点差异范围、凭证、行项目形态没分清3手工清账三步与自动清账两个前提执行手段混了4自动清账五类排除项及其共性只背了清单没背理由5assignment 与 sort key 的分工和 18 字符上限字段混淆6容差组的存储三元与归属三层参数记了、层级漏了7reset 与 reversal 的先后顺序后处理没看默完之后再做一件事把「易漏点」那五条当成自测题逐条问自己能不能说出「为什么漏」。能说出原因说明是真懂了只能说结论说明还是背的换个问法就会翻车。还有一个具体的查漏动作找一张客户未清项清单随便挑三条分别判断该走 Post with clearing 还是 Account clearing并说出判断依据。三条里有一条判断犹豫就回第 2.4 节那张对比表重看。这个方法比刷题有效因为它是拿具体数据逼你做选择而不是让你复述定义。最后给一个血泪经验清账这块的失分十有八九不在主流程而在后处理——重置、冲销、差额去向这三块。主流程走一遍就会后处理得错一遍才记得住。所以我后来给自己定了个习惯每次动清账之前先在纸上写清楚「如果这一步错了我要怎么退回去」退路想明白了再点保存。从那以后我每次做清账相关的练习都强制走一遍这个「先想退路」的动作重复几次之后reset 和 reversal 的顺序再没记反过。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?