一位做设备出口的财务经理上周拿着打印出来的客户对账单找我，说合同明明写的是"30%预付、40%发货后付、30%验收后付"，系统里配了个付款条件，结果发票过账出来还是一条未清项，到期日按 90 天算。这种问题我在 FICO 实施里遇到过不止一次，根源不是顾问水平不行，而是"SAP 分期付款"这五个字底下藏着至少三套完全不同的机制，很多人一开始就把它们混成了一件事。
这篇东西想聊的是其中最容易被误用、也最难配干净的一套：分期付款条件（Payment Terms with Installments）。它解决的是"一张发票、全额过账、但未清项按合同拆成多期"这个需求。我会把它拆成八个要件逐个讲清楚定义方法，然后走一遍 OBB8 与 OBB9 的实际配置路径，再讲清楚过账之后系统到底把数据写成了什么样、为什么你配好的条件会"不生效"、以及长期运维里那些书上不写但会咬人的细节。适合 FICO 顾问、财务共享中心的运维同学、以及需要跟顾问对齐需求的财务 BP 读，完全没碰过付款条件配置的人也能跟上，因为我会尽量用"到期日应该长什么样"这种可验证的方式来讲，而不是堆字段名。
1. 分期付款条件、开票计划、付款计划：长得像，落点完全不同
1.1 三个功能在系统里的物理落点
分期付款条件的配置存在付款条件主表和它的分期明细表里，日常通过付款条件维护事务和分期条件维护事务来改。它的作用点是 FI 凭证的行项目：一张发票是一张发票，金额是全额，税额一次算完，但在客户或供应商的未清项里，这一条会被拆成 N 条，每条有自己的金额和到期日。这是它的核心价值，也是它唯一能做对的事。
**开票计划（Billing Plan）**在 SD 侧，配置的是开票计划类型（按日期或按里程碑）。它的结果是产生 N 张发票，每张发票有自己的金额、自己的税、自己的会计凭证。收入确认跟着每张发票走。里程碑开票还需要配合里程碑的使用决策和开票计划的确定程序，链条更长。
**付款计划（Payment Plan）**更轻，它不产生任何新的会计凭证，只是在已有的未清项上挂一层计划表，记录"未来几期分别付多少、什么日期付"。原始未清项还在那里，计划是附加信息，客户真按计划付了，你再逐笔清账。它常用于应收账款重组、欠款展期，而不是新业务的条款设计。
1.2 什么业务该落到分期付款条件上
判断标准其实只有一句：发票是一次性开出去的，钱是分次收回来的，那就用分期付款条件。
反过来，发票本身就是分次开出去的，钱跟着发票走，那就是开票计划。像"签订后开 30% 预付款发票、发货后开 40%、验收后开 30%"这种，每一笔的税基和收入确认时点都不一样，必须用开票计划，用分期付款条件是把业务硬塞进技术方案里。
还有一种更常见的"两不像"：合同是分次开票，但客户喜欢按月付。这时候正确做法是开票计划加正常的月结付款条件，而不是去配一个五期六期的分期条件。
1.3 选错之后的返工成本
我见过的一个真实场景值得摆出来。一家做产线集成的公司，合同约定签订付 30%、到货付 40%、验收付 30%。财务为了省事，配了个三期的分期付款条件，开票时点全部压在验收之后，理由是"合同金额要等验收才能确定"。
跑了一个季度问题就来了：增值税的纳税义务发生时点、采购方的进项税抵扣时点、项目收入的完工百分比确认，三套口径全对不上。最后不得不改成 SD 里程碑开票计划，历史凭证冲销重开，客户那边还要重新签补充协议确认之前的开票有效。返工的工时成本不说，客户关系上的损耗更贵。
所以我一直建议：动配置之前先在纸上画一张时间轴，把"发票在哪个时点开、钱在哪个时点收、义务在哪个时点履行"三件事分别在轴上标出来。三条线重合，用分期付款条件；发票线和收款线不重合，用开票计划。
2. 拆开看：一个分期付款条件由哪八个要件组成
我习惯把付款条件当成一个"合同条款的机器可读版本"，它由若干独立要件拼装而成。分期付款条件比普通付款条件多一层，因为账期从"一条"变成了"一组"。下面逐个说。
2.1 要件一：付款条件代码本身，它是客户端级对象
付款条件代码是 4 位字符，存在客户端级的配置表里，不区分公司代码。这一点决定了很多事：你在 A 公司代码建的条件，B 公司代码立刻就能用；你在任何地方改了它的天数，所有还没过账的新凭证都会跟着变。
它还带来一个运维上的硬约束：已经被凭证引用过的条件删不掉，系统会提示正在使用中，只能改描述或者打删除标记。所以命名规范和"新建前先搜一遍"不是洁癖，是纪律。我见过有人随手建了个代码，两年后清理主数据时发现删不掉，只能一直挂着。
另外这个 4 位编码里，有些版本会看到一个"公司代码特定"之类的勾选项，勾上之后维护逻辑会复杂一层。除非业务上确实存在"同一套条款在不同公司代码下必须表现不同"的硬需求，否则不要碰它，运维成本会翻倍，而且交接时会坑到下一任。
2.2 要件二：基准日期的确定规则
所有账期都是从基准日往后算的，而基准日有三个来源可选：凭证日期、过账日期、录入日期。这一项在付款条件里指定默认值。
我的建议是绝大多数场景都用过账日期，理由很实际。凭证日期是业务发生时点，跨月补录凭证的时候会漂得很厉害；录入日期更糟，同一张发票今天录和下周录，到期日能差出一周，客户对账时会直接质疑。过账日期虽然也不完美，但至少和会计期间对齐，月结时容易解释。
这里有个分期特有的细节：每一期其实可以挂自己的基准日。绝大多数实施我都建议所有期次统一用同一个基准日，也就是发票的基准日。如果给不同期次设了不同的基准日，到期日计算会变成两层偏移叠加，一旦客户质疑某期为什么晚了两周，你得翻三层配置才能解释清楚。
还有个小坑值得提前知道：清账相关的配置会影响部分付款之后剩余项目的基准日是否重算。如果重算了，分期还款表会在第一次部分付款之后整体后移，客户拿到的到期日和合同完全对不上。上线前务必拿一笔测试凭证走一遍"部分付款"，观察剩余未清项的基准日有没有变化。这个点每年都能坑到人。
2.3 要件三：期次比例，100% 的整除问题
每一期要定义它在总额里的百分比。这个字段的约束很硬：所有期次加起来必须正好等于 100%，差 0.001 都会被系统打回来。
问题出在除不尽的时候。三期平分就是 33.333...%，四期平分 25% 反而没事，六期平分 16.666...%。实务上的处理办法是把余数丢给最后一期：三期写 33.33%、33.33%、33.34%，如果百分比字段支持三位小数就写 33.333%、33.333%、33.334%。
金额侧的舍入也在这里：系统按比例算出每期金额，然后舍入到货币的小数位，尾差通常落在最后一行。也就是说一张 10,000.01 的发票拆三期，你可能会看到 3,333.33、3,333.33、3,333.35 这样"第三期多两分"的结果。这不是 bug，是舍入规则，但对账的时候必须提前跟客户说清楚，否则每季度都会有人来问这两分钱。
2.4 要件四：每期的账期，天数、附加月、固定日三个字段叠加
这是最容易配错的一组字段。每期的账期由三部分组成：天数（从基准日往后推多少天）、附加月（再往后推几个月）、固定日（把日期归到当月的某一天，填 31 通常被当作"月末"处理，但不同版本和不同天数的月份下行为需要实测确认）。
以我接触过的版本为例，这三个字段是叠加作用的，语义上大致是：基准日加天数得到基础到期日，再用附加月把月份往后推，最后用固定日把日期归位。举一个具体的例子：基准日 2025-03-18、天数 30、附加月 1、固定日 15，最终到期日会落在 2025 年的 4 月中旬到 5 月中旬这个区间，具体是哪一个，我不建议背，建议用一笔测试凭证倒推。倒推的方法很简单：建一个临时条件，只填这三个字段，过一张 1 元的模拟凭证，用 FB03 看系统算出来的到期日，一秒钟就验证完了，比翻文档快十倍。
分期场景下有个额外的坑：附加月和固定日是对每一期分别生效的。如果你的三期都填了"附加月 1"，那么越靠后的期次被推得越远，90 天那期可能直接飘到下下个月的中旬。所以分期条件里，附加月和固定日我一般只用在第一期，后续期次只留天数和比例，账期干干净净。
2.5 要件五：每一期要不要挂现金折扣
普通付款条件的经典结构是"8% 15 天 / 4% 30 天 / 45 天净额"，也就是前两行给折扣百分比和天数，第三行只给天数，代表净到期日。分期条件同样可以给每一期单独挂折扣，这意味着你可以做出"前两期各 5% 折扣、第三期无折扣"这种条款。
但我的实务建议是：分期付款条件的各期默认都不挂折扣。原因在于折扣是逐期独立判断的，客户只要把第一期提前付了就能拿第一期的折扣，而你原本的商务意图可能是"全额提前结清才给折扣"。折扣需求交给单独的提前结清协议去谈，条款上更清晰。
顺便提醒一句，现金折扣的计算基数（按含税额还是净额）是在公司代码层配置的，配错会让所有带折扣的付款条件都算歪，检查付款条件时顺手看一眼这个设置，能省掉一轮扯皮。
2.6 要件六到八：分期标志、账户类型限制、净额条款的组合约束
这三个要件放一起说，因为它们的组合关系比单个字段本身更重要。
分期标志是整个机制的总开关。它决定这张凭证的未清项拆还是不拆。这里有个反直觉的地方：勾上分期标志之后，条件头部的"天数 / 百分比"那几行通常就不再是账期依据了，账期改由分期明细逐期提供；头部保留下来真正起作用的是基准日默认值、固定日和附加月。保存之后回头看一遍画面，比看任何文档都清楚。
账户类型限制决定这个条件只能用在客户还是只能用在供应商。分期的客户条款和供应商条款在实务里往往是两套完全不同的东西（客户是收款节奏，供应商是付款节奏），代码上分开、权限上分开，能减少大量误用。我的做法是强制分开命名，客户侧一个前缀，供应商侧一个前缀，让业务人员在选择的时候一眼能认出来。
净额条款指最后一期的到期日必须是全额已到期的日期，它和分期比例的合计 100% 是一对：比例保证金额拆干净，净额天数保证没有哪一期"永远不到期"。这两个要件对不上，就会出现"第三期 30% 永远挂在未清项里"的情况，对账时非常难查。
3. 从零配一个 30/60/90：OBB8 与 OBB9 的实操路径
3.1 进配置前先确认两件事
第一，确认你操作的是哪个客户端。付款条件是客户端级配置，在测试客户端建的条款，生产客户端是看不到的，必须走传输请求。第二，确认请求号。OBB8 和 OBB9 都是表维护事务，改动会自动写进当前打开的定制请求。如果没有打开任何请求，系统可能提示你创建一个，这时候千万别随手建个名字叫"临时"的请求，否则上线时你会在几百个请求里找它。
3.2 第一步：维护条件头
进入付款条件维护事务，列表里是按代码排序的已有条件。找到空行或者用工具栏的复制功能从一条相近的条件复制一份，能省掉重复输入。头部要填的东西按顺序是：4 位代码、描述（尽量写清楚"30/60/90 三期"这种信息，别只写"分期"）、账户类型限制、基准日期默认值（我建议选过账日期）。天数 / 百分比那几行在分期场景下留空或按原样保留都可以，反正勾上分期标志之后它们不参与账期计算。
填完之后先回车，让系统做一次字段校验，再进下一步。
3.3 第二步：进入分期明细
勾上"分期付款"标志，然后按回车，画面通常会展开分期明细区。如果在你这个版本里头像里没找到这个展开区，那就直接进独立的分期付款条件维护事务，两者的底层数据是同一份。这一步不要盲信文档，进系统看一眼实际画面，比什么都准。
进入分期明细之后，输入同一个付款条件代码，然后逐期填。这里的经验是：先把比例填整齐，再回头填天数，因为比例的合计 100% 是最容易触发校验的，先把它定下来能减少反复。
3.4 三期条件的字段示例
以"30/60/90 三期，比例 30/40/30，基准日过账日期，全部无折扣"为例，填法大致如下。注意每一期的到期日都是"基准日 + 该期天数"，所以三期之间的间隔是 30 天、30 天、30 天，累计是 30/60/90。
| 期次 | 比例 | 天数 | 附加月 | 固定日 | 现金折扣 |
|---|---|---|---|---|---|
| 第 1 期 | 30.00% | 30 | 0 | 空 | 不挂 |
| 第 2 期 | 40.00% | 60 | 0 | 空 | 不挂 |
| 第 3 期 | 30.00% | 90 | 0 | 空 | 不挂 |
如果业务要求"每期都在当月 15 日或次月 15 日结算"，那就只给第 1 期加附加月 1 和固定日 15，后两期留空。这个配法我是踩过坑才总结出来的，后两期也加附加月的结果就是越推越远。
3.5 保存、传输与反向验证
保存之后，做一次反向验证：找一张测试用的客户或供应商，用发票录入事务过一笔 3,000 元的凭证，付款条件填你新建的代码，过账。然后用凭证显示事务打开这张凭证，看未清项是不是三条，金额是不是 900 / 1,200 / 900，三个到期日是不是分别落在基准日加 30 / 60 / 90 上。
这一步不是形式，它是唯一能在上线前证明配置正确的手段。我见过太多"配置保存成功就当配好了"的案例，问题都是在第一个月的对账里才冒出来。
如果结果不对，别急着改配置，先用第二节里说的倒推法确认系统对天数、附加月、固定日的实际计算顺序，再反过来调字段。改配置之前先想清楚"我期望的到期日是什么"，不然就是瞎调。
4. 过账之后：未清项到底被拆成了什么样
4.1 用凭证显示事务看，你会看到什么
过账完成之后打开凭证，行项目区会看到同一个客户或供应商科目出现多条记录，行号不同，金额按比例拆开，每条有自己的基准日和到期日。发票的税额、总账科目、成本中心这些跟分期无关，只有客户或供应商这一行被拆了。
这里要澄清一个常见误解：分期付款条件不改变损益，也不改变税额。它只影响未清项和到期日。所以如果有同事问"分期之后利润表会不会变"，答案是绝对不会。这句话我每年都要解释好几遍。
4.2 关键字段是哪些
要证明分期真的生效了，看几个字段就够了：付款条件代码、基准日、每期的现金折扣天数与百分比、净额天数。这几个字段在凭证过账的瞬间就被固化到行项目上，之后改配置不会回头改它们。
如果要在数据库层面批量检查，可以按公司代码、凭证号、会计年度去查行项目表，重点看基准日、折扣天数、折扣百分比这几个字段在同一条凭证下是不是出现了多组不同的值。出现多组，说明拆分生效了。
4.3 收款清账：分期未清项的正确处理姿势
分期之后每一期都是独立的未清项，可以单独收款、单独清账。这是好事，也带来一个操作习惯上的要求：要教育客户按每期金额整额付款。
假设三期是 900 / 1,200 / 900，客户为了凑整数汇了 3,000，你还得手动去做部分付款加剩余项目，两次操作之后剩余未清项的基准日和到期日可能就变了。更麻烦的是客户汇了 1,000 元，既不是任何一期的金额，也不是任何组合，清账时你只能选"部分付款"，剩下的金额会生成新的未清项，越滚越乱。
所以在给客户发对账单的时候，我习惯把每一期的单据号、金额、到期日单独列一行，而不是只给一个发票总额。这一条小小的格式改动，能把月均的对账工时砍掉一半。
另外提醒一句，清账时"部分付款"和"剩余项目"这两个处理方式的选择会影响剩余未清项的生成方式，进而影响它是否继承原来的付款条件和基准日。团队里应该有统一的操作规范，不能各人凭手感选。
4.4 催款与到期日分析的分期行为
催款程序是按行项目算催款级别的，所以分期之后同一张发票可能被催多次，每次针对一期。这本身是合理的，但要注意催款函的格式：如果模板还是按发票号汇总结算，客户会收到一封看起来重复的催款函，投诉电话立刻就来。上线分期功能之前，把催款模板检查一遍。
到期日分析类的报表在分期下反而更好用，因为每一期有独立的到期日，可以精确地看出"未来 30 天、60 天、90 天各有多少应收"。这也是分期功能在现金流预测上的一个附带价值，财务计划岗会很喜欢。
5. 分期条件"不生效"的排查链路
5.1 第一跳：来源字段的优先级
付款条件在单据上不是只有一个来源。SD 侧的顺序大致是：客户主数据的销售视图 → 销售订单 → 开票凭证抬头。MM 侧的顺序是：供应商主数据 → 采购订单 → 发票校验。每一层都能覆盖上一层。
所以当你发现发票上的付款条件不是你配的那个，第一步不是怀疑配置，而是逐层往上看：客户主数据里是不是已经指定了一个默认付款条件？销售订单里有没有手工改过？发票校验时是不是被操作员覆盖了？
我的排查习惯是从最下游往上逆推，因为下游一定记录着最终生效的值，顺着它往上找，比从上往下猜快得多。
5.2 第二跳：主数据里两处付款条件打架
这是个经典问题，在 S/4HANA 里尤其常见，因为主数据搬到了业务伙伴（BP）上。客户 BP 的公司代码视图和销售视图里都有付款条件字段，供应商 BP 的公司代码视图和采购视图里也都各有一个。
FI 直接记账时取的是公司代码视图里的值，SD 开票时取的是销售视图里的值。如果这两个字段填的不一样，就会出现"同一张客户，直接开的发票是分期，销售开出来的发票不是分期"这种诡异现象。而且因为两个字段在两个不同的页签下，排查的人经常只看了一个就下结论。
我的建议是在主数据维护规范里写死一条：两处付款条件必须保持一致，并且在客户主数据新增的检查清单里加一项。这条规则看着笨，但能省掉大量排查时间。
5.3 第三跳：常见报错的逐个拆解
| 现象或提示 | 大概率原因 | 处理方向 |
|---|---|---|
| 提示各期百分比合计不等于 100% | 除不尽的场景没做尾差处理 | 把余数归到最后一期，如 33.33 / 33.33 / 33.34 |
| 保存时提示期次数超出限制 | 期次数量超过了当前版本允许的上限 | 合并期次，或者改用开票计划拆分业务 |
| 提示付款条件正在使用，无法删除 | 该条件已被凭证引用 | 改描述或打删除标记，不要硬删 |
| 配好了但发票上只有一个到期日 | 分期标志没生效，或来源被上层覆盖 | 按 5.1 的三层来源逐层核对 |
| 某一期永远不到期 | 该期比例或天数填错，或者净额天数缺失 | 检查比例合计与最后一期的天数 |
| 部分付款之后剩余项到期日变了 | 清账配置触发了基准日重算 | 走一笔测试凭证验证，再决定是否调整操作规范 |
5.4 历史凭证是改不回来的
这是我在培训里必讲的一条：付款条件的配置改动不会回溯修改已过账的凭证。到期日、折扣天数这些信息在过账那一刻就写进了行项目，之后你改配置，老凭证纹丝不动，新凭证立刻生效。
这个机制的好处是历史数据稳定，坏处是"配置漂移"——同一套代码在不同时期表现不同，几年后做审计追溯时很难解释。所以我坚持一个做法：任何付款条件的改动都要记录变更日志，写清楚改了什么、为什么改、影响哪个时间段之后的凭证。这不只是为了审计，也是为了半年后的自己。
6. 长期运维：命名规范、影响面与版本差异
6.1 4 位代码的命名方案
4 位字符要承载的信息量其实有限，所以必须做取舍。我给团队用的方案是：第 1 位表示方向和类型，第 2 到 4 位表示账期结构。
第 1 位：I 表示分期（Installment），N 表示普通净额条款，R 表示含质保金或保留金的条款，X 表示特殊用途一次性的条件。第 2 到 4 位用天数除以 10 的商来编码，比如 30/60/90 就写成 369，60/40 两期就写成 64，接上第一位就是 I369 和 I64。
这套方案的好处是看一眼就知道账期结构，不需要点进去查描述。缺点是表达不了比例信息，比例只能写在描述字段里。描述字段我建议写全，格式统一成"分期-期数-天数-比例"，比如"分期 3期 30/60/90 30/40/30"，检索和交接都方便。
6.2 变更与传输的影响面
付款条件的改动影响面比大部分配置都大，因为它跨公司代码、跨模块，还被主数据引用。改一个条件的天数之前，我会先做三件事：查这个代码被哪些客户和供应商主数据引用、查最近三个月的凭证里有多少条用了它、确认没有正在进行的合同把它写进了附件。
删除基本不用想，被引用过就删不掉。要做的是冻结：把描述前面加"停用-"前缀，或者把生效范围缩小。这比硬删有效得多。
传输方面，付款条件的改动会进定制请求，分期明细也在同一个请求里。但配置传输不会自动带上"业务口径的说明"，所以请求的描述字段要认真写，否则下一个环境的管理员看到"改了 20 张表"会一头雾水。
6.3 版本差异里值得注意的几个点
在 S/4HANA 上，主数据搬到了业务伙伴上，付款条件的维护入口从原来的客户主数据和供应商主数据变成了 BP 的角色视图，界面路径变了但底层字段还在。做惯 ECC 的人第一次上手会找不到入口，这个适应期大概半天。
配置侧的付款条件维护事务本身变化不大，但界面会提示你用 Fiori 应用去维护，后台还是同一套表。另外新版可能会在应用里把分期明细做成一个独立的页签，比老版的弹出窗口清楚很多。
如果你在做升级评估，我建议把付款条件单独列一项检查：列出生产环境所有在用的条件代码，逐个在生产或沙箱客户端里打开画面确认一下字段是否还完整、分期明细是否还读得出来。这项工作大概一天，能省掉升级后第一周的各种"为什么这个条件不对了"。
6.4 最后分享几条我自己在用的检查纪律
第一条，任何新建的分期条件都必须配一张模拟凭证，1 元也行，过账、看行项目、确认到期日，然后冲销。配置保存成功不等于配置正确。
第二条，分期条件的各期默认不挂现金折扣。折扣需求单独谈，条款清晰，运维省心。
第三条，主数据里两处付款条件必须一致，这一条我会写进客户主数据新增的标准作业里，作为必检项。
第四条，改配置前先看历史引用量，被几百个主数据和几千条凭证引用过的条件，改动要当成变更管理事项走，不能顺手就改。
实操这几年最深的一个体会是：付款条件这种"看起来只是几个数字"的配置，恰恰是最考验基本功的地方。它不复杂，但它把主数据、销售、采购、记账、清账、催款、报表全串在一起，任何一个环节理解偏了，出来的结果都不会报错，只会安静地算错，然后在下一次对账时集中爆发。所以配之前多想十分钟，比事后查三天划算得多。
