SAP F110自动付款全流程解析：从FBZP配置到底表避坑

简介：本资源面向SAP FICO顾问、财务信息化实施人员及企业财务运维人员，聚焦自动付款（F110）从系统配置到测试验证的完整落地过程，帮助解决银行主数据维护、收付程序设置与付款凭证生成中的配置难点。包内共1个docx文档，约11.4MB，以图文操作说明形式呈现，内容按系统配置、T银行汇款演示、W银行承兑汇票演示及其它补充四大模块展开，涵盖FI01维护银行主数据、FI12_HBANK创建开户行、NWBC创建银行账户标识、FBZP维护收付程序设置，以及FBL1N查询未清明细、F110创建付款建议与生成凭证、S_P99_41000099检查付款建议清单等关键事务码操作，并展示测试数据与底表存储细节。目前已有396人学习下载，适合需要对照实操、梳理配置路径与排错思路的读者参考。

1. 从一张付款建议清单说起：SAP F110 自动付款到底在解决什么

供应商催款邮件堆到第三页，财务还在 FBL1N 里一条条翻未清项、手工勾选、逐笔做 F-53，这种场景在上了 SAP FICO 但没把自动付款跑通的公司里太常见了。SAP F110 这个事务码，本质是把「选未清项 → 算付款金额 → 定付款方式 → 生成付款建议 → 跑出付款凭证」这一整条链路交给系统批处理，配置一次、复用多年。它适合两类人：一类是刚接手 FICO 模块、需要把供应商付款从手工切到自动的顾问；另一类是已经在跑 F110、但遇到「建议清单为空」「银行确定报错」「凭证生成失败」想搞清楚底表逻辑的运维。这篇笔记按配置、演示、底表、避坑的顺序拆，配置部分给到 FBZP 每个层级的参数含义，演示部分用 T 银行汇款和 W 银行承兑汇票两条真实路径走一遍，最后落到 F110 跑完后钱到底写进了哪几张表。

2. 配置链路拆解：从 FI01 银行主数据到 FBZP 收付程序

自动付款能不能跑通，八成取决于配置阶段有没有把「银行、账户、供应商、支付方式、银行确定」这五层串起来。很多人一上来就打开 FBZP 填参数，结果 F110 跑出来建议清单是空的，回头查半天发现是供应商主数据里付款方式没维护。所以配置顺序不能乱，下面按依赖关系一层层来。

2.1 FI01 维护银行主数据与 FI12_HBANK 创建开户行

FI01 建的是「银行」这个主体，比如「中国银行长春分行」，它记录的是银行代码、SWIFT、地址这些公共信息，跟公司代码无关。FI12_HBANK 建的是「开户行」，也就是你的公司在某家银行开的具体账户，它挂在公司代码 + 银行代码 + 账户标识下。两者的关系是：FI01 定义银行，FI12_HBANK 定义「谁在这家银行开了户」。

操作上，FI01 进去后填银行国家、银行代码，系统会带出银行名称，SWIFT 码按实际填。FI12_HBANK 进去后选公司代码，填银行代码、账户标识（就是那个 5 位的 account ID）、账户号码、控制键。这里有个容易翻车的点：账户标识一旦被 F110 的银行确定引用过，再改就会影响已有配置，所以建之前想清楚命名规则。

# FI01 银行主数据维护路径 SPRO → 财务会计 → 银行会计 → 银行主数据 → 定义银行 # 或直接事务码 FI01 # FI12_HBANK 开户行维护 FI12_HBANK # 输入：公司代码 + 银行代码 + 账户标识 # 关键字段：Account number（银行账号）、Control key（控制键）、Bank account name

FI01 和 FI12_HBANK 的区别是新手最容易混的：FI01 是「银行」这个外部实体，全公司共用；FI12_HBANK 是「我司在某银行开的户」，跟公司代码绑定。F110 付款时银行确定找的是 FI12_HBANK 里的账户标识，不是 FI01 的银行代码。所以如果 F110 报「银行确定失败」，先查 FI12_HBANK 里这个账户标识建了没有。

2.2 供应商付款信息维护：LFB1 里的付款方式与银行明细

供应商主数据里跟自动付款直接相关的是 LFB1（公司代码层）的付款数据。进 XK02 或 BP 事务码，到供应商的公司代码视图，找到「付款交易」区域，这里要维护三个东西：付款方式（Payment method）、银行明细（Bank details）、付款条件（Payment terms）。

付款方式就是 B（汇票）、C（支票）、E（银行转账）、T（银行汇款）、W（银行承兑汇票）这些，F110 的支付方式配置里会引用。银行明细里填供应商的收款银行、账号、账户名，注意超过 18 位的银行账号要填在「参考明细」字段里，直接填账号字段会被截断。付款条件决定基准日期和账期，F110 算到期日靠的就是它。

提示：供应商主数据里的付款方式如果没勾，F110 跑的时候这个供应商的未清项根本不会进建议清单，而且不会有明显报错，这是最隐蔽的坑之一。

2.3 FBZP 收付程序设置：五个层级的参数怎么填

FBZP 是自动付款配置的核心，它分五个层级，从上到下依次收窄：所有公司代码 → 付款公司代码 → 国家的支付方式 → 公司代码中的支付方式 → 银行确定。每一层管的东西不一样，填错了 F110 要么跑不出建议，要么跑出来但银行确定失败。

所有公司代码层：这里设的是付款程序的全局参数，比如「付款建议的最长提前天数」「下次付款运行的日期」。提前天数决定 F110 选未清项时往前看多少天，设太短会漏掉快到期的项，设太长会把不该付的也拉进来。

付款公司代码层：指定哪些公司代码参与自动付款，以及每个公司代码允许的最大付款金额、货币限制。如果某个公司代码在这里没维护，F110 跑的时候直接跳过。

国家的支付方式层：这是按「国家 + 支付方式」配的，比如中国的 E（银行转账）、T（银行汇款）、W（银行承兑汇票）各自一套参数。这里有个关键勾选项——「银行细目」，勾了 F110 会检查供应商主数据里银行明细字段有没有值，没值就报错。一般电汇建议勾，其他付款方式不建议勾任何内容，否则供应商主数据稍微不全就卡住。

公司代码中的支付方式层：把「公司代码 + 支付方式」绑定，指定这个公司代码用这种支付方式时，走哪个付款公司代码、哪个开户行账户标识、哪种格式（比如中国的 CT 格式）。F110 的银行确定就是从这里找账户标识的。

银行确定层：定义「付款方式 + 公司代码 + 货币 + 金额范围」对应哪个开户行账户标识。比如 T 银行汇款、金额小于 100 万、人民币，走账户标识 100001。这一层是 F110 生成付款凭证时真正决定借贷方银行科目的地方。

# FBZP 配置路径 SPRO → 财务会计 → 应收账款和应付账款 → 业务交易 → 自动付款 → 收付程序 → 收付程序设置 # 或直接事务码 FBZP # 五个层级依次配置： # 1. 所有公司代码 - 全局参数 # 2. 付款公司代码 - 公司代码级参数 # 3. 国家的支付方式 - 按国家+支付方式 # 4. 公司代码中的支付方式 - 公司代码+支付方式绑定 # 5. 银行确定 - 决定借贷方银行科目

配置完 FBZP 后，建议用 F110 的「显示付款建议」先跑一次空运行，看建议清单里有没有数据、金额对不对、银行确定有没有报错，确认无误再正式生成凭证。空运行不产生凭证，是验证配置最安全的方式。

3. T 银行汇款全流程演示：FBL1N 到 F110 生成凭证

配置跑通后，用 T 银行汇款这条路径走一遍完整流程。T 是银行汇款，走的是电汇逻辑，供应商主数据里付款方式要勾 T，FBZP 里 T 的银行细目建议勾上，因为电汇对银行账号准确性要求高。

3.1 FBL1N 查询供应商未清明细

FBL1N 是供应商行项目查询，进的时候选「未清项」，输入供应商编号和公司代码，就能看到这个供应商所有没付的发票。重点看三列：到期日、金额、付款方式。到期日决定 F110 会不会选中它，付款方式决定走哪条付款路径。如果这里付款方式是空的，F110 跑的时候这条项会被跳过。

# FBL1N 查询供应商未清项 FBL1N # 选择：供应商未清项 # 输入：供应商编号、公司代码 # 关键列：到期日（Due date）、金额、付款方式（Pmnt method）

查询结果里如果发现某条发票的付款方式跟预期不符，回 XK02 改供应商主数据，或者直接在发票层面用 FB02 改付款方式字段。FBL1N 只是查询，不改数据。

3.2 F110 创建付款建议：参数页与状态页怎么填

F110 进去后先填「参数」页：运行日期、标识（就是这次运行的 ID，比如 RUN001）、公司代码。然后填「状态」页：这里选「创建付款建议」，系统会按 FBZP 的配置去 FBL1N 里捞符合条件的未清项。

参数页里有个「付款方式」选择，可以限定只跑 T 这一种，也可以全跑。第一次跑建议只选一种，方便排查。运行日期填当天，标识自己定一个能记住的，后面查建议清单和生成凭证都要用这个标识。

# F110 创建付款建议 F110 # 参数页：运行日期、标识（如 RUN001）、公司代码 # 状态页：选择「创建付款建议」 # 执行后系统生成建议清单，状态变为「付款建议已创建」

跑完后系统会给一个日志，里面显示选了多少条未清项、总金额多少、有没有被跳过的。如果建议清单是空的，先看日志里有没有「供应商付款方式未维护」的提示，再查 FBZP 的银行确定层有没有配这个公司代码 + 支付方式的组合。

3.3 S_P99_41000099 检查付款建议清单

S_P99_41000099 是付款建议的查询报表，输入 F110 的运行标识，就能看到这次建议里有哪些供应商、哪些发票、每笔付多少、走哪个银行账户。这个报表比 F110 自带的日志详细，能看到每一条的付款方式和银行确定结果。

重点检查三件事：金额对不对（有没有把不该付的拉进来）、银行账户对不对（银行确定有没有选错账户标识）、付款方式对不对（T 的项有没有混进 E 的）。发现不对，回 F110 用「删除付款建议」把这次运行删掉，改完配置重新跑。

3.4 F110 生成付款凭证：从建议到实际凭证

建议清单确认无误后，回 F110，同一个运行标识，状态页选「生成付款凭证」。系统会把建议清单里的每一条转成实际的付款凭证，借贷方是供应商应付和银行科目。生成后可以用 FB03 查凭证，或者用 FBL1N 看供应商未清项是不是已经清了。

# F110 生成付款凭证 F110 # 输入同一个运行标识（如 RUN001） # 状态页：选择「生成付款凭证」 # 执行后系统生成付款凭证，供应商未清项被清

生成凭证后，F110 的状态会变成「付款已执行」。这时候钱在系统里已经付出去了，但实际银行转账还没发生，需要后续用 FF.5 或银行对账单做清算。这一步是很多新手忽略的：F110 生成的是会计凭证，不是银行指令，真正的付款动作在银行端。

4. W 银行承兑汇票路径：与 T 汇款的关键差异

W 银行承兑汇票跟 T 银行汇款在 F110 里的流程框架一样，但配置和银行确定逻辑有差异。W 走的是票据逻辑，供应商主数据里付款方式勾 W，FBZP 里 W 的银行细目一般不勾，因为承兑汇票对银行账号的校验要求跟电汇不同。

4.1 W 路径的 FBZP 配置差异

W 在「国家的支付方式」层里，参数跟 T 不一样。T 勾银行细目，W 不勾。W 的格式（Format）通常走中国的票据格式，跟 T 的 CT 格式不同。银行确定层里，W 对应的账户标识是承兑汇票专用账户，跟 T 的电汇账户分开。

如果公司同时有 T 和 W 两种付款方式，FBZP 里要分别配，不能共用一套参数。F110 跑的时候按供应商主数据里的付款方式自动分流，T 的走 T 的账户，W 的走 W 的账户。

4.2 W 路径的 F110 运行与建议修改

W 的 F110 运行步骤跟 T 一样：FBL1N 查未清项 → F110 创建建议 → S_P99_41000099 检查 → F110 生成凭证。差异在建议清单里，W 的项会显示票据相关的字段，比如票据号、到期日。如果建议清单里某条 W 的项金额不对，可以在 F110 里用「修改建议」功能单独改这一条，不用删掉整个运行重跑。

# F110 修改建议 F110 # 输入运行标识 # 状态页：选择「修改建议」 # 在建议清单里找到要改的项，修改金额或银行账户 # 保存后重新生成凭证

修改建议这个功能在实际运维里很有用，比如某条发票金额有争议、暂时不想付，可以在建议清单里把它删掉，只生成其余部分的凭证。但要注意，修改建议只影响本次运行，不改供应商主数据。

5. 底表存储与避坑：F110 跑完后钱写进了哪几张表

F110 跑完后，数据落在几张核心底表里，搞清楚这些表，排查问题就不用只靠日志了。同时把配置和运行阶段最常见的几个坑列出来，每条按现象、原因、解决写。

5.1 F110 相关底表：REGUP、PAYR、PAYP 的分工

F110 的核心底表有三张：REGUP 存付款建议的行项目，PAYR 存付款运行的头部信息，PAYP 存付款凭证的明细。REGUP 是建议清单的底层数据，S_P99_41000099 查的就是它。PAYR 记录每次 F110 运行的标识、日期、公司代码。PAYP 是生成凭证后的明细，跟 BKPF、BSEG 关联。

排查思路：建议清单为空 → 查 REGUP 有没有数据 → 没数据查 FBL1N 和供应商主数据；有数据但凭证生成失败 → 查 PAYP 和 BKPF 的报错。

5.2 避坑记录：F110 配置与运行中的五个高频问题

现象一：F110 跑完建议清单为空，日志无报错。原因：供应商主数据 LFB1 里付款方式没维护，或者维护了但跟 FBZP 里配的支付方式不匹配。 解决：XK02 进供应商公司代码视图，检查付款方式字段，确保跟 FBZP「公司代码中的支付方式」里配的一致。

现象二：建议清单有数据，但生成凭证时报「银行确定失败」。原因：FBZP 的银行确定层没有配这个公司代码 + 支付方式 + 货币 + 金额范围的组合，或者配了但账户标识在 FI12_HBANK 里不存在。 解决：FBZP 银行确定层补配，确认账户标识在 FI12_HBANK 里已建。

现象三：供应商银行账号超过 18 位，F110 付款时账号被截断。原因：SAP 标准账号字段长度限制，超长账号直接填会被截。 解决：超 18 位的账号填在「参考明细」字段里，F110 付款时会带出参考明细。

现象四：F110 生成凭证后，供应商未清项没清掉。原因：付款凭证的过账码或特别总账标识配错，导致没有正确冲销应付。 解决：查 PAYP 和 BSEG，确认过账码是不是应付类的，特别总账标识对不对。

现象五：FBZP 里勾了银行细目，F110 跑的时候大量供应商报错。原因：银行细目勾选后，F110 强制检查供应商主数据银行明细字段，很多供应商没维护完整。 解决：电汇类付款方式建议勾，其他付款方式不勾；或者批量补全供应商银行明细后再勾。

注意：FBZP 改配置后，已经生成的付款建议不会自动更新，必须删掉重新跑。改配置前先确认没有正在运行的 F110 任务。

6. 进阶技巧：用 F110 空运行和底表查询做配置验证

配置改完不敢直接跑正式凭证，这是对的。我一般会走一套验证流程：先用 F110 空运行（只创建建议、不生成凭证），再用 S_P99_41000099 看建议清单，最后直接查 REGUP 底表确认数据落对了没有。这套流程走一遍，比看日志快得多。

空运行的操作是：F110 参数页填好，状态页选「创建付款建议」，但不要选「生成付款凭证」。跑完后 REGUP 里会有数据，PAYP 里没有。这时候用 SE16N 查 REGUP，按运行标识过滤，看每条的付款方式、金额、银行账户标识对不对。如果银行账户标识是空的，说明银行确定层没配好，回 FBZP 补。

# SE16N 查 REGUP 底表 SE16N # 表名：REGUP # 筛选条件：运行标识（LAUFD/LAUFI） # 关键列：VBLNR（付款凭证号）、LIFNR（供应商）、BUKRS（公司代码）、 # RZAWE（付款方式）、RBETR（金额）、UBNKY（银行账户标识）

查 REGUP 的时候重点看 UBNKY 这个字段，它就是银行确定的结果。如果 UBNKY 是空的，F110 生成凭证时一定报银行确定失败。另一个要看的是 RZAWE，确认付款方式跟预期一致，T 的项不能出现 E。

验证通过后再跑正式凭证生成，生成后用 FB03 查凭证，再用 FBL1N 确认供应商未清项已清。如果公司有多个公司代码，每个公司代码单独跑一次 F110，不要混在一个运行标识里，否则排查时分不清是哪个公司代码的问题。

还有一个习惯：每次改完 FBZP，先在测试客户端跑一遍空运行，确认 REGUP 数据正常再传到生产。生产环境直接改 FBZP 风险太大，一旦银行确定配错，F110 生成的凭证借贷方就错了，冲销起来很麻烦。从那以后我每次动 FBZP 都强制走一遍「空运行 → 查 REGUP → 确认 UBNKY → 再生成凭证」的流程，希望帮到你。

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