简介面向SAP物料管理MM模块顾问与后勤发票校验操作人员这份文档系统梳理了发票校验的完整知识链条涵盖后台容差配置、供应商容差、校验条件、凭证类型及默认税代码并详解有差异/无差异发票校验、预置发票、后台发票校验及BAPI调用时的常见报错与解法。包体为1份doc文档大小71KB适合作为SAP培训或项目实施的速查参考。已有320人学习下载兼顾入门概念与实战排错可帮助读者规避收货参考年度错误、发票冻结下达等问题。1. 发票校验为什么是 SAP 里最容易被低估的过账动作做 SAP 的人十有八九都在 MIRO 上栽过跟头采购订单、收货单、发票三张单据摆在那里数量对不上、价格差两分钱、超了容差被冻结财务月结卡在最后一步。发票校验Invoice Verification在 SAP 里属于物料管理MM模块但它的产出直接送到财务和成本控制——付款信息、发票评估、GR/IR 清账全从这一个动作开始。它不是简单的把发票金额敲进去过账而是一套受容差、参考、税码、凭证类型共同约束的校验逻辑。这份笔记能帮你把 MIRO、MIR4、MIR7、MIRA 这一整条链路跑通也能让你在 BAPI 外部创建发票时少掉一层皮。适合刚接手后勤发票校验的 MM 顾问、做 FICO 集成的财务顾问以及被输入有效收货的参考这个报错折磨过的人。2. 后台配置先做对容差、供应商容差组、条件、凭证类型与税码发票校验的过账行为绝大多数不是在前台写死的而是后台五件事决定的。配置顺序乱、漏配一项后面在 MIRO 里看到的现象就很奇怪有时候超两块钱就冻结有时候超五千也能过同一个供应商换个公司代码规则又不一样。先把后台逻辑理顺前台操作才有意义。2.1 OMR6 容差配置BD/DQ/PP/VP 四种容差分别管什么容差配置的入口是 OMR6容差是基于公司代码的配置因为发票是根据公司代码开具的。配置界面上有上限、下限、检查限制和百分比几个维度核心要理解的是四种容差键各自管什么。容差键中文叫法管什么常见配置口径BD自动形成小的差异小额差异自动过账不冻结发票金额限制如 10 元或百分比 0.1%DQ超出金额数量偏差发票数量与收货数量的偏差比例比如 5% 以内不冻结PP价格变化发票单价与采购订单净价的偏差常见 3% 到 5%VP移动平均价格差异移动平均价物料发票价与收货评估价的差异按物料类别分组这里有一个容易混淆的点BD 不是不检查的意思而是小的差异自动处理——系统把金额很小的差异自动记到一个费用科目或自动记账科目不走冻结流程。很多企业以为设置了 BD 就不用管小额差异了结果月结时差异科目上挂了一堆几块钱的凭证对账时说不清来源。我一般会在配置时建议企业把 BD 的金额限制设成一张发票上允许的最大小额差异同时要求财务每月核对一次差异科目余额。DQ、PP、VP 才是真正决定发票要不要冻结的容差。配置时要注意系统判断差异是同时看金额限制和百分比的两个条件哪个先触发按配置里的检查限制决定。常见做法是把百分比设为主判断条件金额限制设成一个兜底值避免大金额发票在低百分比下产生过大的绝对差异也放行。配置完一定要用测试发票跑一遍别只盯着配置界面看数字。2.2 供应商容差组XK02 里的组与公司代码的约束供应商容差的配置路径是物料管理 - 后期发票校验 - 收到的账单 - 配置指定供应商容差。供应商特定的参数设置是在发票校验中单独给某个供应商定义的一套容差行为。关键约束是在一个公司代码中只能将一个容差组分配到一个供应商。实操中我在供应商主数据里看这个字段用的是 XK02集中维护界面里能找到容差组。不同公司代码下同一个供应商可以有不同的容差组因为容差组和公司代码是绑定的。供应商容差组典型的用法是给核心大供应商单独建一个组容差收紧到 1%给零散供应商用标准组放到 5%。这样做的好处是采购谈好的价格约束能在发票环节落地而不是靠财务人员每天手工盯差异。有一点要提醒修改供应商容差组后对已经存在但尚未过账的发票容差判断以配置生效时的系统行为为准不一定会追溯。如果发现改了配置但发票还是按旧规则冻结别急着怀疑配置没保存先去 MRBR 里把已经冻结的发票重新下达一次让系统按新容差再算一遍。这个顺序反了你会在配置上浪费一个小时。2.3 发票校验条件、凭证类型与默认税代码三条配置路径一次理清发票校验条件、凭证类型、默认税代码这三项配置路径都在物料管理 - 后期发票校验下面但属于不同节点一次理清楚能省很多回头路。第一条发票校验条件物料管理 - 后期发票校验 - 信息确认 - 维护条件 - 修改-发票校验。这里维护的是发票校验用的条件记录比如计划交货成本、特殊运费条件等。条件技术在 SAP 里是通用的发票校验也复用了这套逻辑。配置时一般复制标准条件类型再按公司需求调整金额和有效期。注意条件记录的生效日期跨年时如果条件有效期断了发票校验会带不出应有的条件金额。第二条凭证类型物料管理 - 后期发票校验 - 收到的账单 - 号码分配 - 维护科目凭证的编号范围。标准系统里有 RE发票和 RG贷项凭证很多企业会自定义 Z 开头的凭证类型。配置的核心是给每种凭证类型分配独立的号码段避免跨年跳号。第三条默认税代码物料管理 - 后期发票校验 - 收到的账单 - 维护税代码的缺省值根据公司代码设置。比如 J1 是进项税按公司代码维护后发票校验时系统会默认带出。如果供应商主数据里也维护了税代码优先用供应商的如果两边都没有才会落到这个默认值。税代码配错导致的差异在发票校验里最容易伪装成价格差异排错时先看一眼带出来的税码对不对。2.4 基于收货的 IV标志PO 行项目上的前置开关后台配置做得再全采购订单上行项目没设置正确发票校验照样出问题。这里的开关就是 PO 项目明细发票页上的基于收货的 IV字段需要设置为 X。我在做发票校验时发现过一个典型的错误MIRO 里选采购订单明明有收货记录却提示没有可参考的行项目查了一圈最后发现就是这个标志没勾。这个字段的含义是这张采购订单的发票校验必须基于收货记录发票数量不能超过累计已收货数量。勾上之后发票校验就强制以收货单为参考防止供应商发票数量大于实际到货。实物采购的 PO 我建议一律勾上服务类的 PO比如外包运维可以不勾但前提是配好了服务确认单用服务确认来约束开票数量。如果发现一批历史 PO 都没勾也不用慌批量修改可以用 ME32L 或 LSMW 去更新改完后新发票立即按新逻辑校验旧发票走差异流程处理。3. MIRO 有差异发票校验从凭证类型到差异科目的完整过账路径MIRO 是后勤发票校验的主事务码路径是后勤 - 采购 - 后勤发票校验 - 凭证输入 - 输入发票。有差异的发票校验差异分为数量差异、价格差异、计划差异、采购订单价格数量差异和质量检查每一步处理方式都不一样。3.1 凭证类型与借贷方向贷项凭证、发票与混合结算进入 MIRO 后先输入公司代码然后选择凭证类型贷项凭证或发票。判断逻辑很直接——结算总金额为负就是贷项凭证为正是发票。但这里有个容易懵的场景一张凭证里既包含进货又包含退货也就是混合结算。如果直接输入采购订单号带行项目系统会报错或只带出部分行。这时要点采购订单号右边的按钮进入把退货的行项目选成贷向进货的行项目选成借向方向不指定发票就校验不过去。一个值得注意的现象SAP 系统外创建发票时比如调 BAPI BAPI_INCOMINGINVOICE_CREATE这时候不需要指定退和进的凭证方向SAP 会自动记入。原因在于界面操作时系统需要你明确每一行的借贷语义而 BAPI 接口是按行项目净额逻辑直接记账的系统根据正负金额自动判定。所以如果你的接口团队在报方向不明确的错误让他们确认一下是不是沿用了界面操作的习惯在 BAPI 参数里强行传了方向字段。3.2 差异科目怎么选借贷方向与正常发票相反的记账规则有差异的发票想过账两种路径一是在容差范围内系统自动处理二是超过容差但公司接受计入差异科目。选择后者时进入发票的总账科目页输入差异科目。这里的关键点是借贷方向差异的借贷方与正常发票里的借贷相反。比如贷项凭证的差异要记入借方。很多新手在这里借反导致发票过了账但差异科目的余额方向跟财务预期完全相反月底对账又是一笔糊涂账。差异科目不是随便输的。先确认公司对差异的记账规则是集中归集到一个采购差异科目还是按差异类型分开。仓库里常被翻出来的就是会计凭证确认和替代规则——发票校验过账时这些规则照样生效如果你在差异科目上配了替代逻辑比如按物料组替代到不同科目在 MIRO 里输入差异科目后过账前最好先模拟一下看到底落到哪个科目。别等过了账再看 FI 凭证那时候修改成本就高了。3.3 付款冻结、付款方式与基线日期过账前的三个必设项刚做完的发票一般要把付款设置为冻结付款方式也要设置通常是账扣还要填基线日期——这是财务起始处理付款日期。这三个字段在 MIRO 界面的付款页签里很多人嫌麻烦不填结果发票过账后立刻进了付款计划钱提前付出去了。付款冻结的意思是发票可以正常过账但付款环节不允许执行直到有权限的人解除冻结。这在供应商发票有争议、还在核对差异时特别有用。基线日期直接影响付款条款的计算。比如供应商的付款条件写着月结 30 天系统从基线日期往后推 30 天计算到期日。如果基线日期填成了发票日期账期就从发票日算如果填成收货日期账期就从收货日算——这俩之间可能差好几周。我一般建议把基线日期与收货日期或发票过账日期保持一致具体听财务的账期政策。过了账发现冻结状态不对用 MIR4 查看发票凭证在凭证流里还能看到后续状态。付款冻结在 MRBR 里统一管理到时候一步到位。4. 无差异、预制与后台校验三种模式的适用边界不是每张发票都有差异要处理。无差异发票、预制发票、后台发票校验这三类场景覆盖了日常绝大部分工作量。它们的流程主线一样但应用场景和操作细节各有边界理解边界比记住事务码更重要。4.1 无差异发票校验和上一章的流程差在哪无差异发票校验的过账流程与有差异时本质一致MIRO、选采购订单、核对数量金额、过账。差别在于数量、金额与采购订单和收货记录完全对得上不需要额外处理差异科目。但无差异不代表没有检查点发票日期、记账日期、税代码这三个字段照样要确认。税代码尤其容易被忽略——发票金额与 PO 一致但税码带错了系统会拆出税差异原本无差异的发票硬生生变成有差异。实操里我发现无差异发票翻车最多的不是金额而是参考。比如发票上有多个采购订单行项目某个行项目没勾基于收货的 IV系统按订单数量放行但实际收货数量不足过账后 GR/IR 挂着差额。所以即便是无差异流程我在过账前也会扫一眼收货数量/订单数量/发票数量三个数的关系。无差异流程最大的价值是效率但效率的前提是 PO 和收货的源头数据干净。4.2 MIR7 预制发票可反复修改、不过账的发票请求单MIR7 是预制发票的事务码路径后勤 - 采购 - 后勤发票校验 - 凭证输入 - 输入发票 - 预制发票。SAP 的预制发票相当于一张发票请求单保存后不自动过账而且支持多次修改。适用场景很明确供应商发票已经拿到但采购订单对应的收货还没完成或者数量还在确认中这时可以先预制等条件满足再过账。预制发票在 MIR7 里保存后生成一个预制凭证号业务人员可以反复改行项目、金额、税码改完再存。过账时回到 MIRO选择预制发票功能把预制凭证调出来确认无误后过账。有一个细节预制发票不产生会计凭证所以财务在总账里看不到任何动静别拿着 FB03 去查预制状态——要去 MIR7 里按预制凭证号查。预制发票和正式发票共用同一个凭证类型号码段所以号码段配置里要给预制预留空间不然号段耗尽会引起并发冲突。团队里有人频繁用 MIR7我一般建议定期清理长期不处理的预制凭证免得账龄分析里混进一堆已过期的发票请求单。4.3 MIRA 后台校验与 WC23 后台检查把容差交给系统判断后台发票校验的事务码是 MIRA路径后勤 - 采购 - 后勤发票校验 - 凭证输入 - 输入后台校验的发票。它的逻辑是发票在后台进行检查如果在容差范围之内直接在后台过账超出容差挂起等待人工处理。这个模式适合批量录入的场景比如 EDI 发票、电子发票文件导入量大且差异率低的供应商。这里有个配置边界要注意MIRA 后台校验的判断标准完全来自后台配置的容差前台能做的只是设定运行参数。启动后台作业后系统按容差自动判定过账或挂起挂起的发票会进到待处理列表人工干预还是走 MRBR 那一套。与 MIRA 搭配使用的是 WC23用来在后台检查发票的正确性——它更像一个批量检查工具把发票的完整性、参考关系、科目状态逐项过一遍输出问题清单适合每个月末集中检查一次当月所有发票。需要提醒的是预制发票不能走 MIRA 后台校验它必须经过 MIRO 手动调出过账。如果你的流程里大量使用预制发票又想自动化得先改流程把预制环节去掉或者做接口在后台把预制转正式。5. 发票校验避坑记录从跨年 BAPI 报错到五类常见翻车发票校验的坑大多数不是概念问题而是参考关系和状态问题。这里把我在外部 BAPI 做发票校验和日常排错时遇到的高频问题按现象 - 原因 - 解决整理出来每条都是实际翻车换来的经验。5.1 输入有效收货的参考 (行 000001)参考年度填错现象外部用 BAPI 做发票校验调用 BAPI_INCOMINGINVOICE_CREATE 时报错输入有效收货的参考 (行 000001)。同一张发票在 SAP GUI 的 MIRO 里手动做一点问题没有换了外部接口就报错。原因排查了很久才发现不是 SAP 跨年度配置的问题而是参考年度填错了。那次做的收货是 2007 年的BAPI 行项目里的参考年度却填了当前年度 2008。系统按年度去找收货记录参考年度不对就没有匹配行于是报没有有效收货参考。GUI 操作时系统会自动带出正确的年度外部调用 BAPI 时不会自动帮你填必须显式传参。解决把 BAPI 里的参考年度改成收货物料凭证的年度。我最终取收货日期作为参考年度来源问题随即消失。从那以后我养成一个习惯任何外部发票校验的接口参考年度一律从收货记录取绝不从系统当前日期取跨年期间尤其要查一遍。5.2 冲销凭证又被冲销另一个隐藏的输入有效收货的参考现象还是报输入有效收货的参考但这次参考年度核对没错收货单也确实存在就是过不了。原因后来查冲销历史发现参与发票校验的那张收货单被冲销了而这个冲销凭证又被冲销了。SAP 里这种冲销之后再冲销的操作会把原始凭证的状态翻转回来但发票校验的判断逻辑里这种被反复冲销过的收货单不再被识别为有效参考。解决检查收货单的冲销历史。用 MR8M 或 MIGO 的显示功能看物料凭证被冲销过几次确认有效收货行到底是哪一张然后让接口换用未被冲销的收货单做参考。如果收货本身没错但状态复杂考虑先做收货冲销重做把有效收货记录理顺再跑发票校验。这条经验让我在 BAPI 排错时多了一个检查项不只查收货存不存在还要查收货状态干不干净。5.3 基于收货的 IV标志没勾PO 行项目上的经典坑现象MIRO 里输入采购订单号系统提示找不到可参考的收货但明明 MIGO 已经做过收货了。偶尔还能遇到发票数量超过收货数量也能被系统接受的情况事后在 GR/IR 上挂了一堆差异。原因采购订单行项目的发票页签里基于收货的 IV字段是空的。这个标志没勾系统在发票校验时不会强制按收货记录约束导致要么参考关系建立不起来要么数量控制失效。解决在 PO 行项目上把基于收货的 IV设置为 X。批量处理用 ME32L 逐个改或者 LSMW 批量更新。改完标志后新建的发票立即生效已过账的发票按差异流程处理。这个教训我是真金白银踩过的——当时查了一圈配置、容差、权限最后发现源头就是 PO 上一个勾没打。现在我会在项目上线前做一轮 PO 字段检查专门扫这个标志。5.4 容差超限触发发票冻结MRBR 下达与 MIR4 追踪现象发票在 MIRO 里过账时没有报错但产生了冻结标志付款环节也暂停了。供应商打电话来催款财务才发现发票被卡住。原因发票差异超过了容差配置的边界系统按规则冻结发票。这是容差配置在工作不是故障。但很多企业不了解冻结发票的处理路径发票就在后台静静地躺着。解决用 MRBR 下达冻结的发票这个事务码专门处理发票冻结的下达。先运行 MRBR 检查系统列出符合条件的冻结发票确认差异可以接受后在这里释放冻结并模拟过账。下达完成后用 MIR4 显示发票凭证通过后继凭证可以看到生成的 FI 凭证。如果企业配了 SAP workflow 的审批流MRBR 的下达动作会和审批流联动冻结发票会进入待审批列表而不是直接下达。发票清单用 MIR6 查按供应商、日期范围拉出所有发票核对哪些冻结、哪些已过账月结前跑一遍很管用。5.5 MIRO 拆分增强后无法清账一个容易被忽略的后续问题现象发票在 MIRO 里做了拆分过账凭证生成成功但后续在 FBL5N 里做客户或供应商清账时发现部分未清项配不上余额对不齐。这个现象在启用 MIRO 拆分增强的项目里出现频率不低。原因拆分逻辑写在 MIRO 的增强里比如按成本中心、按物料组拆分到多行科目但拆出来的行项目在参考关系上没有继承原始凭证的完整引用导致清账时系统找不到对应的未清项。问题不一定出在过账动作本身而是拆分增强里行项目分配字段的传递不完整。解决检查拆分增强里行项目保留的参考和分配字段确保每一行都带上了原始的采购订单、收货和发票参考过账后立刻在 MIR4 里查看后继凭证和 FI 凭证做一次比对确认未清项结构正常。清账异常时先用 FB03 查行项目再用 FBL5N 看未清项逐行核对参考关系。这类增强问题排查成本高我的建议是增强开发完必须做过账 - MIR4 看后继 - FBL5N 清账三步联测别只验证到过账成功为止。6. 外部 BAPI 创建发票参考年度从收货单取别从系统日期取外部系统通过 BAPI_INCOMINGINVOICE_CREATE 创建发票是顾问工作中绕不开的需求。接口本身不复杂但参考年度的传参逻辑一错就回到 5.1 节那个输入有效收货的参考的报错里。这里分享一个我固定使用的取数方式先读收货物料凭证的年度再传给发票行项目而不是用系统当前日期。 从物料凭证取收货年度避免手工填错参考年度 SELECT SINGLE mjahr INTO lv_ref_year FROM mseg WHERE mblnr lv_gr_number 收货物料凭证号 AND zeile lv_gr_line 收货行项目号 AND bukrs lv_company. 公司代码 发票行项目的参考年度一律用上面取到的收货年度 ls_item-ref_year lv_ref_year. APPEND ls_item TO lt_item.这段代码的逻辑是发票校验要找有效收货的参考系统定位收货记录靠的是物料凭证号、行项目、公司代码和年度。年度是定位索引的一部分填错了就找不到对应的收货行。从 MSEG 里按 mblnr、zeile、bukrs 三个条件取 mjahr保证参考年度与收货记录的实际年度严格一致不用 sy-datum 取当前年份是因为跨年场景下发票过账年度与收货年度经常不一致——2007 年的收货2008 年才开票参考年度必须是 2007。参数上mblnr 对应收货物料凭证号zeile 对应行项目号bukrs 对应公司代码这三个字段在发票行项目里都会用到接口实现时先从采购订单的收货历史中查出来。还有一个配合习惯外部调用 BAPI 之前先检查一下参与校验的收货单有没有被冲销过。用 MSEG 或 MIGO 的显示历史确认收货状态干净再调 BAPI。这样能把 5.2 那种冲销再冲销的隐藏问题拦在报错之前。从那以后我每次写发票校验的接口程序都强制走一遍取 MSEG 年度 - 查冲销历史 - 再调 BAPI的顺序跨年、换系统、换供应商都没再出过这个报错。发票校验的坑大都集中在参考和状态上把这两个点看牢MIRO 和 BAPI 两条路都会顺畅很多希望帮到你。本文还有配套的精品资源点击获取
