SAP成本中心结算：成本动因建模与四类结算机制原理-育师

简介：本资源是一份聚焦SAP FICO模块中成本中心会计核心机制的深度解析教程，专为具备ERP基础、正在实践或深化SAP成本核算的企业财务人员与系统管理人员设计。内容紧扣成本中心结算这一关键业务场景，系统拆解“推”与“拉”两种成本结转逻辑，详述分配、分摊、定期重过账及间接作业分配的操作原理、配置路径（如KSV1定义循环）、参数含义（如累计分配、迭代、对象货币）与典型应用差异，并辅以真实凭证截图与多期追踪因素计算示例，助力读者准确归集跨部门成本、提升内部成本透明度与核算精度。资源为单文件PDF，共1个，大小1.11MB，结构完整、图文并茂，便于随时查阅与实操对照。目前已有1882人学习下载，是理解SAP成本流动本质与落地期末结算配置的高实用性参考资料。

1. 成本中心结算：为什么“推”和“拉”不是操作习惯问题，而是成本动因建模的底层分水岭？

你有没有遇到过这种场景：生产管理部门当月发生工资50万元，系统自动结转到三个车间——但财务总监突然问：“这50万里，到底有多少该算进缸体成型？多少该算进机械加工？依据是什么？”你翻遍KSV5执行日志，只看到一行“分配完成”，却答不出“为什么是30%、20%、50%”。更糟的是，下个月追踪因素（比如员工数）从30/20/50变成28/22/50，分配金额剧烈跳变，报表分析直接失真。这不是配置疏漏，而是你把成本中心结算当成了“期末点按钮”的流程，而没意识到：SAP成本中心结算的本质，是一套可验证、可追溯、可审计的成本动因建模引擎——它不记录“谁花了钱”，而强制建模“钱为什么流到这里”。分配（Distribution）、分摊（Assessment）、定期重过账（Periodic Reposting）、间接作业分配（Indirect Activity Allocation）这四类机制，表面是事务码KSV5/KSU5/KSW5/KSC5的差异，底层却是对“成本因果关系”的四种不同数学表达：分配保留原始成本要素结构，是对线性比例模型的刚性执行；分摊用次级成本要素打包，是对成本归集逻辑的抽象封装；定期重过账抹除发送方贷方余额，是对“记账便利性”向“业务真实性”的妥协让步；而间接作业分配通过反向计算数量，则是在作业价格已知前提下，对“隐性服务量”的统计学反演。本文不教你怎么点菜单，而是带你钻进KSV1循环定义界面背后——看清楚每一处“可变部分类型”下拉框、每一个“量度负方向跟踪因素”选项，究竟在替你回答哪个成本会计学根本命题。这份教程的价值，不在截图有多全，而在它把SAP FICO模块中那段最易被当成黑匣子的结算逻辑，还原成一张可推演、可证伪、可调试的因果图谱。

1.1 “推”与“拉”的本质：不是方向选择，而是责任主体的会计学锚定

在SAP成本中心结算中，“推”（Push）和“拉”（Pull）常被简化为“谁发起结算”的操作区别。但若仅止于此，你就永远无法解释：为什么生产订单能作为“拉”方式的接收方，而成本中心之间却只能用“推”？答案藏在CO模块的凭证生成逻辑里。所有结算动作最终都生成CO凭证（Controlling Document），而CO凭证的借贷方必须满足一个铁律：借方代表成本“归属对象”（Cost Object），贷方代表成本“来源对象”（Source Object）。在“推”方式中（如KSV5分配），发送方成本中心是贷方主体，它主动将已发生的成本“推”给接收方——此时接收方可以是另一个成本中心（同级归集）、内部订单（项目归集）或WBS元素（PS模块集成）。关键在于：接收方在此刻尚未产生任何成本动因，它只是被动接受成本归属权的转移。而“拉”方式（如KB21N直接作业分配或KSC5间接作业分配）则截然相反：接收方（如生产订单）先声明“我需要X单位作业”，系统据此倒推发送方（如设备维护中心）应提供多少服务量，并按作业价格生成贷方——此时贷方主体是作业类型（Activity Type），而非成本中心本身。这意味着，“拉”的驱动源是接收方的业务需求（如生产订单的BOM用量、工艺路线工时），其会计学意义是“成本归属由业务活动触发”，而“推”的驱动源是发送方的成本发生事实（如人事部工资过账），其意义是“成本归属由费用发生地决定”。这种区分直接决定了后续所有配置的合法性边界：当你在KSV1中尝试把生产订单设为“推”方式的接收方时，系统报错“接收方类型不支持”，这不是UI限制，而是CO凭证引擎拒绝生成一个违背“贷方必须是成本发生源”原则的凭证。真正的分水岭，在于你是否在建模之初就明确：这笔成本的终极归属，是由业务活动驱动（拉），还是由费用发生地驱动（推）？

1.2 四类结算机制的数学本质：从线性映射到隐变量反演

分配、分摊、定期重过账、间接作业分配，表面是四个事务码，底层却是四种不同的数学映射关系。理解它们的数学本质，才能避开“参数调不准”的玄学困境。

分配（Distribution）是线性比例映射：设发送方总成本为 $C_s$，接收方 $i$ 的追踪因素为 $t_i$，则分配给 $i$ 的成本为 $C_i = C_s \times \frac{t_i}{\sum t_j}$。这个公式要求所有 $t_i$ 必须同质可加（如都是“员工数”或都是“实际工时”），且不能为负——否则分母为零或结果无经济意义。KSV1中“量度负方向跟踪因素”的6种选项，本质是对 $t_i$ 为负时的数学补丁：选“4负向跟踪因素到零”，就是强制将所有 $t_i < 0$ 置为0，使映射退化为 $C_i = C_s \times \frac{\max(t_i,0)}{\sum \max(t_j,0)}$；选“3绝对值”，则是 $C_i = C_s \times \frac{|t_i|}{\sum |t_j|}$。没有哪种“更正确”，只有哪种更符合你的成本动因假设。
分摊（Assessment）是向量空间投影：分摊不保留原始成本要素，而是将发送方所有初级成本（向量 $\vec{C_s} = [c_1, c_2, ..., c_n]$）打包，用一个次级成本要素（如9001000010“劳务成本”）作为投影轴，将整个向量“压扁”成一个标量 $C_{assess}$，再按接收方追踪因素比例分配。这相当于在n维成本空间中，用一条直线（次级成本要素轴）去近似描述原向量。KSES中定义的“分配结构”，就是在告诉系统：对人工成本子集 $\vec{C}{labour}$，用次级要素9900010003投影；对其他成本子集 $\vec{C}{other}$，用9900010004投影——这是对成本异质性的分层降维。
定期重过账（Periodic Reposting）是状态机修正：它不生成新凭证，而是直接修改现有凭证的行项目。KSW5执行后，发送方成本中心的厂房折旧费借方余额从+50000变为0，不是因为贷记了50000，而是系统将原凭证的借方行项目标记为“已重过账”，并在接收方新建借方行项目。这本质上是一个状态转换：[Original Posting: Debit 50000] → [Reposted: Void Original, Create New Debits]。其代价是丢失原始凭证的审计链，但换来的是对“先集中记账、后按规则拆分”这类高频业务的效率保障。
间接作业分配（Indirect Activity Allocation）是隐变量反演：已知作业价格 $p$（如1.5 CNY/MIN），接收方追踪因素 $t_i$（如设备运行时间1000MIN），权数 $w_i$（如10），所有因素 $T$（如100），则反推的作业分配数量为 $q_i = t_i \times w_i / T$，再得成本 $c_i = q_i \times p$。这里 $q_i$ 是不可观测的隐变量（实际维护时间），$t_i$ 是可观测代理变量（设备运行时间），而 $w_i/T$ 是校准系数。KSC1中“参考加权因素”的设置，就是在拟合这个校准系数——它不是配置，而是基于历史数据的回归建模。

提示：当你发现分配结果与业务直觉严重偏离时，先别急着调参数。打开KSV1的“接收方追踪因素”标签，用事务码KA03查一下各接收方的 $t_i$ 实际值。90%的“玄学问题”，根源是追踪因素本身采集错误（如统计关键指标未维护、作业类型未激活计划值）。

2. 分配（Distribution）机制深度解析：为什么“累计”不是性能优化，而是成本动因的时间平滑器？

分配是成本中心结算中最基础也最易被误解的机制。很多人把它当作“按百分比分钱”的简单工具，却忽略了SAP在KSV1中埋下的“累计（Cumulation）”开关——它绝非为了提升大数据量下的执行速度，而是为了解决一个尖锐的会计学矛盾：如何在成本动因短期剧烈波动时，维持成本归属的长期合理性？本章将撕开KSV1界面，逐层解析分配循环的数学内核、配置陷阱与调试方法。

2.1 循环抬头参数：每个开关都在回答一个成本建模命题

KSV1循环抬头中的参数，表面是配置项，实则是成本会计学家向系统提出的命题。我们逐个解构：

开始日期（Valid From）：这不是简单的生效时间，而是成本动因基期的锚点。系统在计算“累计”时，会从该日期起始的所有期间追踪因素求和。若你将开始日期设为2024.01，但2024.01的追踪因素因主数据未维护为空，则累计分母为0，导致分配失败。正确实践是：开始日期必须早于第一个有有效追踪因素的期间。
迭代（Iteration）：当某成本中心既是发送方又是接收方时（如A部门管理费分配给B、C，B又将部分费用回分给A），系统需多次循环直至收敛。但迭代不是无限进行的——SAP默认最大迭代次数为99，且每次迭代后发送方剩余金额若小于0.01（系统最小货币单位），即停止。关键洞察：迭代次数本身是成本闭环程度的量化指标。若某循环稳定在3次迭代，说明A→B→C→A的费用回流路径清晰；若始终卡在99次，往往意味着追踪因素存在逻辑死锁（如A按员工数分给B，B又按面积分回A，而员工数与面积无相关性）。
累计（Cumulation）：这才是本节核心。不启用累计时，每期分配独立计算：第2期发送方金额2000，接收方A/B追踪因素为100/0，则A得2000，B得0。启用累计后，系统计算的是“历史累计发送总额”与“历史累计追踪因素”的比值。如示例中，第1期发送1000（A:0, B:100），第2期发送2000（A:100, B:0），则累计发送3000，累计追踪因素A:100, B:100，故第2期分配给A的金额 = (3000 × 100/200) - 第1期已分0 = 1500。这本质上是用移动平均法平滑成本动因的脉冲噪声。当某车间因设备检修导致当月工时归零时，“累计”避免了成本全部甩给其他车间的荒谬结果。
对象货币（Object Currency） vs 业务货币（Business Currency）：这是多币种环境下的致命陷阱。对象货币指成本中心主数据中设定的“控制范围货币”（如USD），业务货币指FI过账时使用的“本地货币”（如CNY）。若勾选“对象货币”，系统强制将所有发送方成本按汇率折算为USD后再分配；若勾选“业务货币”，则直接用CNY原币分配。后果差异巨大：当汇率单月波动10%时，“对象货币”分配会使接收方收到的金额随汇率浮动，而“业务货币”则保持业务实质不变。选择依据不是技术偏好，而是会计政策——若公司要求成本核算以控制范围货币为准，则必须用对象货币。

2.2 循环段配置：追踪因素不是数据源，而是成本动因的代理变量

KSV1中“增加段”后的配置，才是分配逻辑的真正心脏。其中“接收方规则”与“可变部分类型”的组合，决定了成本动因的建模精度。

接收方规则 = 可调整份额（Variable Share）：这是唯一能实现动态分配的选项，其效果完全取决于“可变部分类型”的选择。例如：
- 选“1 实际成本”：系统取接收方成本中心在指定成本要素（如5101010000工资）上的实际发生额作为 $t_i$。这适用于“谁花得多，谁承担多”的场景（如IT部门按各部门当月IT服务费分摊）。
- 选“5 实际统计关键指标”：系统取接收方在指定统计关键指标（如“员工数”）上的数值。这适用于“谁人多，谁承担多”的场景（如行政部管理费按员工数分摊）。注意：统计关键指标必须在KS01中为各成本中心维护，且维护期间必须覆盖分配期间，否则 $t_i=0$ 导致分配失败。
“量度负方向跟踪因素”的实战抉择：当 $t_i$ 出现负值（如某车间当月产量为负——退货冲销），不同选项导致完全不同的经济含义：
```
# 假设发送方总成本 Cs = 5000 # 接收方追踪因素: A=-100, B=200, C=-50, D=0 # 选项4 "负向跟踪因素到零": t_i' = [0, 200, 0, 0] -> sum=200 # 则 A得0, B得5000*(200/200)=5000, C得0, D得0 # 选项3 "绝对值": t_i' = [100, 200, 50, 0] -> sum=350 # 则 A得5000*(100/350)=1428.57, B得2857.14, C得714.29, D得0
```
选择逻辑：若负值代表“反向受益”（如退货车间应减少分摊），选选项4；若负值是数据录入错误或异常值，选选项3用绝对值消除符号干扰。

2.3 避坑：分配执行中的5个血泪经验

在真实项目中，分配失败往往不是配置错误，而是成本动因数据链的断裂。以下是某跨国制造企业实施FICO时踩过的5个典型坑，附带根因与解法：

现象：KSV5执行成功，但接收方报表（S_ALR_87013611）中无分配金额，发送方报表中贷方也未生成。
原因：发送方成本中心主数据中“成本中心类型”未勾选“允许分配”（Allow Distribution）。此标志在KS02中维护，若未启用，系统在KSV5执行时静默跳过该成本中心，不报错也不记日志。
解决：事务码KS02进入发送方成本中心主数据，在“控制”标签页勾选“允许分配”。
现象：分配结果中，某接收方金额为0，但其追踪因素（如员工数）在KA03中查询为正数。
原因：追踪因素的“期间”不匹配。KSV5执行时读取的是“当前期间”的追踪因素，但KA03默认显示“当前期间+1”。例如执行2024.03分配，系统读取2024.03的员工数，而KA03显示的是2024.04的计划值。
解决：在KA03中，点击“期间”按钮，手动切换至2024.03，确认员工数是否为0。若为0，需在KP26中为该成本中心维护2024.03的统计关键指标值。
现象：启用“累计”后，第1期分配正常，第2期分配金额异常巨大（如达发送方总额的200%）。
原因：“累计”功能依赖发送方成本中心的“累计余额”字段。若该字段在前期因系统升级或主数据迁移被清空，则第2期累计分母为0，系统按默认值1计算，导致分子/1=巨额结果。
解决：运行事务码KSV8（重置累计余额），选择对应循环和期间，系统将重新计算历史累计值。
现象：分配循环中设置了多个段，但KSV5执行后，仅最后一个段生效，前几个段无记录。
原因：段的执行顺序由“段名”字母序决定，而非创建顺序。“段名”若为Z01、Z02、Z03，则按Z01→Z02→Z03执行；若为A01、Z01，则Z01先于A01执行。当某段将发送方成本全部分配完后，后续段因发送方余额为0而跳过。
解决：在KSV1中，将段名统一改为数字序号（如001、002、003），确保执行顺序可控；或在“发送方规则”中为各段设置不同“发送者比例”，避免全额分配。
现象：使用“固定比率”发送规则时，输入单价后，系统提示“单价必须大于0”。
原因：“固定比率”模式下，系统将“发送方值”标签页中的“单价”与接收方追踪因素相乘。若单价为0（如未维护），则发送金额恒为0。但SAP校验逻辑过于严格，即使单价为0.0001，也因浮点精度问题被判定为0。
解决：在“发送方值”标签页，将单价设为0.000001（最小有效值），并确保接收方追踪因素足够大（如员工数>100），使计算结果大于0.01。

3. 分摊（Assessment）机制深度解析：为什么次级成本要素是成本归集的“语义封装”？

如果说分配是“原样转发”成本，那么分摊就是“打包重命名”成本。其核心动作——用类型为42的次级成本要素（Secondary Cost Element）替代原始初级成本要素（Primary Cost Element）——看似只是凭证上的一行代码变更，实则承载着SAP成本会计最精妙的语义设计：次级成本要素不是技术占位符，而是成本归集逻辑的契约化声明。本章将穿透KSU1界面，揭示分摊如何用“一个要素”封装“一类业务”，以及为何KSES中“分配结构”的配置，本质是在构建成本语义的领域模型。

3.1 次级成本要素：成本归集的语义原子与业务契约

在SAP中，成本要素（Cost Element）分为两类：初级（类型01，对应FI过账的GL科目）和次级（类型42，仅用于CO内部流转）。分摊强制使用次级成本要素，这一设计绝非技术限制，而是会计语义的硬性约束。

语义原子性：一个次级成本要素代表一种不可再分的成本归集逻辑。例如，要素9001000010“劳务成本”不是泛指所有人工，而是特指“由生产管理部门提供、经分摊逻辑计算、最终计入生产成本的管理服务成本”。它与初级要素5101010000“工资”有本质区别：后者记录“发生了什么”（人事部发了工资），前者声明“意味着什么”（这笔工资是为生产服务的间接投入）。当接收方报表显示“劳务成本 +18000.00”，审计员无需追问“这18000来自哪些工资明细”，因为要素9001000010本身已承诺了其归集口径。
业务契约性：次级成本要素的创建（事务码KA06）必须绑定“成本要素类别”（Cost Element Category）。类别42（次级成本要素）下又细分用途，如：
- 类别43：间接费用（Overhead）
- 类别44：管理费用（Administrative Expenses）
- 类别45：销售费用（Sales Expenses）这些类别不是标签，而是SAP内置的业务规则引擎。例如，类别43的要素可用于分摊，但不能用于作业分配（KSC1要求作业类型分类为02/03）；类别44的要素在利润中心会计中会被自动归入“管理费用”行项目。选择错误的类别，会导致后续报表（如01-利润中心报表）分类错误，且无法通过后台修复。

3.2 分配结构（Allocation Structure）：成本语义的领域建模工具

KSES中定义的“分配结构”，是分摊机制最强大的扩展点。它允许你为不同性质的初级成本，指定不同的次级成本要素，从而实现“一果多因”的语义建模。

结构设计逻辑：以某汽车厂品质检测部为例，其初级成本包含：
- 人工成本（5101010000~5101120000）：应归集为“品质检测-人工成本”（9900010003）
- 设备折旧（5101420200）：应归集为“品质检测-设备成本”（9900010005）
- 外协检测费（5101300000）：应归集为“品质检测-外协成本”（9900010006）在KSES中，你创建分配结构Z2，定义三行规则，每行将一个成本要素范围映射到一个专属次级要素。这不再是技术配置，而是将“品质检测成本”这一业务概念，分解为三个具有不同经济属性的子概念。
执行时的语义解析：当KSU5执行分摊时，系统对发送方成本中心的所有初级成本行项目扫描：
```
-- 伪代码：系统如何解析分配结构 FOR each primary_cost_item IN sender_cost_center SELECT secondary_cost_element FROM KSES_allocation_structure Z2 WHERE primary_cost_item.cost_element BETWEEN range_start AND range_end; IF found THEN POST to receiver: Debit secondary_cost_element, Credit secondary_cost_element; END IF; END FOR;
```
关键点在于：分摊凭证的贷方永远是同一个次级要素（如9001000010），但借方却可能是9900010003、9900010005、9900010006等多个要素。这保证了接收方报表能清晰区分“人工服务成本”、“设备服务成本”、“外协服务成本”，为后续的作业价格计算（KP26）和成本分析（S_ALR_87013611）提供语义纯净的数据源。

3.3 避坑：分摊执行中的4个高危陷阱

分摊的“打包”特性使其错误更隐蔽，往往在报表分析阶段才暴露。以下是某集团财务共享中心总结的4个致命陷阱：

现象：KSU5执行成功，但接收方报表中，次级成本要素借方金额为0，而发送方报表中，初级成本要素贷方也未生成。
原因：发送方成本中心主数据中“成本中心类型”未勾选“允许分摊”（Allow Assessment）。与分配类似，此标志在KS02中维护，且独立于“允许分配”标志。未启用则静默跳过。
解决：事务码KS02，进入发送方成本中心主数据，“控制”标签页勾选“允许分摊”。
现象：分摊后，接收方报表显示多个次级成本要素（如9900010003、9900010004），但金额均为0。
原因：分配结构（KSES）中定义的成本要素范围，与发送方实际发生的初级成本要素不匹配。例如，结构中定义“5101010000~5101120000”为人工成本，但发送方实际过账的是5101010001（工资-基本）、5101010002（工资-奖金），而5101010001不在范围内。
解决：在发送方成本中心报表（S_ALR_87013611）中，导出所有初级成本要素，与KSES中定义的范围逐条比对；或使用事务码KA03，按成本要素查询发送方明细，确认要素编码。
现象：启用“累计”分摊后，某接收方当期分配金额为负数。
原因：“累计”分摊的计算逻辑是：当期分配 = 累计应分 - 历史已分。若历史已分金额大于累计应分（如因前期追踪因素录入错误导致累计应分被高估），则当期分配为负。SAP允许负分配，但接收方报表中会出现贷方次级成本要素，违反“成本归集”语义。
解决：运行事务码KSU8（重置分摊累计），选择对应循环和期间；或在KSV1中为该接收方单独创建一个“冲销段”，用固定金额分配负值。
现象：分摊凭证（KSB1）中，贷方次级成本要素的金额，与发送方初级成本要素借方总和不等。
原因：分摊只处理“实际过账”的初级成本，不处理“计划值”或“统计过账”。若发送方存在大量统计过账（如用成本要素5101990000“统计-管理费”过账），这些金额不会被分摊。
解决：在KS02中，为发送方成本中心主数据勾选“允许统计过账分摊”（Allow Statistical Assessment）；或改用“分配”机制处理统计过账。

4. 定期重过账（Periodic Reposting）与间接作业分配（Indirect Activity Allocation）：当“推”与“拉”的边界开始模糊

定期重过账（KSW5）和间接作业分配（KSC5）常被归为“高级结算”，因其打破了分配与分摊的常规范式。KSW5的“抹除发送方余额”看似是技术捷径，KSC5的“反向计算数量”看似是数学技巧，但二者共同指向一个深层命题：当成本动因无法被直接观测或计量时，SAP如何用可验证的代理变量，重建成本归属的因果链？本章将揭示，KSW5不是分配的快捷方式，而是对“记账权”与“归属权”分离的制度设计；KSC5不是作业分配的替代品，而是对“隐性服务量”的统计学建模。

4.1 定期重过账：抹除余额背后的“权责发生制”妥协

KSW5最令人困惑的特性，是执行后发送方成本中心的初级成本借方余额直接归零，而不生成贷方凭证。这违背了“有借必有贷”的复式记账常识，其根源在于SAP对“权责发生制”的弹性解释。

业务本质：定期重过账解决的是“集中记账，分散归属”的现实困境。例如，全厂水电费由行政部统一支付，但需按各车间面积分摊。若每月手工用KB11N重过账，工作量巨大且易错。KSW5的设计哲学是：承认行政部“代付”行为的临时性，将成本归属权直接赋予接收方，行政部仅作为资金通道。因此，系统不生成“行政部贷方”凭证，而是直接修改原始凭证，将借方从“行政部”转移到“各车间”——这本质上是将一笔“预付款”凭证，重构为多笔“终局归属”凭证。

技术实现：KSW5执行时，系统调用函数模块K_KSW5_POSTING，其核心逻辑是：

LOOP AT gt_sender_items INTO ls_item. " 查找原始凭证行项目（如行政部水电费借方） READ TABLE gt_original_docs WITH KEY belnr = ls_item.belnr bukrs = ls_item.bukrs gjahr = ls_item.gjahr buzei = ls_item.buzei. IF sy-subrc = 0. " 直接修改原始凭证行项目的成本中心字段 MODIFY gt_original_docs FROM ls_modified_item. " 为各接收方创建新行项目 PERFORM create_receiver_items. ENDIF. ENDLOOP.

关键洞察：KSW5不生成新凭证号，而是复用原始凭证号（BELNR），仅修改其行项目。这保证了审计链的连续性——你仍能在FB03中看到同一张凭证，只是成本中心字段已更新。

4.2 间接作业分配：反向计算中的统计学建模

KSC5的“反向计算数量”，常被误认为是“绕过作业计量”的取巧。实则，它是SAP对“服务型成本中心”最严谨的建模方案——当直接计量服务量（如设备维护时间）成本过高时，用高相关性的代理变量（如设备运行时间）进行统计学反演。

建模逻辑：设接收方 $i$ 的代理变量为 $t_i$（设备运行时间），权数为 $w_i$，所有因素为 $T$，作业价格为 $p$，则分配成本 $c_i = (t_i \times w_i / T) \times p$。其中 $w_i/T$ 是校准系数，需基于历史数据拟合。例如，某厂维护中心历史数据显示：设备每运行100分钟，平均需维护5分钟，则 $w_i/T = 5/100 = 0.05$。KSC1中“参考加权因素”的设置，就是在固化这个回归系数。
执行验证：KSC5执行后，必须用事务码KSB1查看CO凭证，确认两点：
1. 贷方是作业类型（如LABO01），金额 = 总分配数量 × 作业价格；
2. 借方是各接收方成本中心，金额 = 各 $c_i$。若贷方是次级成本要素，则配置错误（KSC5强制要求作业类型分类为02或03）。

4.3 避坑：KSW5与KSC5的3个交叉陷阱

这两类机制常被混用，导致成本归属逻辑混乱：

现象：KSW5执行后，接收方报表中出现次级成本要素，而非原始初级成本要素。
原因：KSW5的接收方规则误选了“固定金额”或“固定百分比”，而非“可调整份额”。KSW5虽不生成次级要素，但若接收方规则为固定值，系统会用发送方的初级要素过账，但若发送方初级要素不存在于接收方主数据中，则自动替换为默认次级要素。
解决：在KSW1中，确保接收方规则为“1 可调整份额”，并正确维护接收方追踪因素。
现象：KSC5执行后，某接收方分配数量为0，但其追踪因素（如MACH01作业数量）在KA03中为正数。
原因：KSC5要求作业类型必须在KP26中维护“计划价格”，且价格版本必须与分配期间匹配。若未维护价格，系统默认价格为0，导致 $c_i = q_i \times 0 = 0$。
解决：事务码KP26，为作业类型MACH01维护2024.03的计划价格。
现象：同一成本中心既作为KSW5的发送方，又作为KSC5的接收方，执行后成本重复归属。
原因：KSW5和KSC5是独立的结算循环，系统不检查逻辑冲突。若行政部水电费先被KSW5分摊到车间，车间又用KSC5将“设备维护费”分摊回行政部，则形成成本循环。
解决：在IMG中，路径“控制→成本中心会计→实际过账→期末结算→结算顺序”，定义KSW5与KSC5的执行顺序，并在KSW1/KSC1中为相关成本中心设置“锁定标识符”，避免同一期间重复处理。

5. 成本中心结算的终极验证：从凭证链到业务动因的端到端追溯

所有配置的终点，不是KSV5执行成功的绿色对勾，而是你能从任意一笔接收方成本，逆向追溯到：原始凭证号、发送方成本中心、所用追踪因素、计算公式、以及该追踪因素在业务系统中的源头。这需要一套超越事务码的验证体系。本章将给出一套可落地的端到端追溯方法论，并分享我在某全球供应链项目中建立的“三阶验证法”。