支払日の朝に自動支払処理を回し、支払提案を確認する。例外として弾かれた明細が三十件ほど並ぶ。担当者はそれを印刷し、午後いっぱいかけてネットバンキングで一件ずつ振り込む。この光景は、稼働から何年経っても消えない会社と、半年で消える会社にはっきり分かれる。 分かれ目は例外の多さではない。例外の件数を、発生源に返す工程が月次にあるかどうかである。 手振込は支払業務の一部ではなく、設計の穴が出てくる出口だと扱っているかどうかで、翌年の姿が変わる。
「例外リストに載った」の中身は四つに分かれる
朝に印刷される例外の一覧は、原因の違う四つの束が一枚になっている。束ごとに、打ち手を持つ部署が違う。
第一に、取引先マスタの支払ブロックである。SAPの説明によれば、取引先マスタを支払プログラム向けにブロックした場合、支払プログラムは支払実行時にその口座の未消込明細を処理はするが、ブロックされた口座からは一切支払わない。 処理の対象からは外れていないため、明細は支払処理の記録に残る。ブロックキーはブロックの理由を表すために使うものであり、支払プログラムからブロックされている取引先の一覧を表示できる。 この束は、経理と購買のどちらかが意図的に置いた止めであり、外す判断も同じ側にある。
第二に、明細レベルの支払ブロックである。フィールドは BSEG の ZLSPR（Payment Block Key） で、仕入先明細に立つ。ここに入るキーには、請求書検証の差異によるもの、確率ブロックによるもの、担当者が手で置いたものが混在している。同じ欄に入っているので、一覧の見た目では区別がつかない。 区別するにはキーの意味を設計側で分けておく必要がある。
第三に、支払方法と銀行の決定が成立していない明細である。支払方法が明細にもマスタにも入っていない、通貨や国の組合せで許可された支払方法がない、支払銀行の残高や上限に当たっている。ブロックではないので、ブロックを外しても解決しない。 ここを第二の束と混ぜて「ブロックを外して回す」運用にすると、外す必要のないブロックを外す癖がつく。
第四に、転記ブロック（Posting block）が支払ブロックとして効いている明細である。SAPは、取引先に転記ブロックを設定した場合、その取引先の未消込明細を支払うこともできなくなり、転記ブロックが支払ブロックとしても働くと説明している。この束は、経理が支払を止めたつもりでなく、マスタの棚卸しで止めた口座が支払日に現れるという形で出てくる。
支払ブロックの二軸を、キーの設計で分ける
四つの束のうち、内部統制として一番危ないのは第二の束である。理由は、二軸のうち片方しか使っていないブロックキーが混ざるからである。
SAPの支払指図の仕組みでは、請求書の転記時にビジネストランザクションイベントが自動的に実行され、支払指図のカスタマイズを参照する。ブロックが必要な請求書であれば BSEG の ZLSPR にカスタマイズ由来のキーが埋まる。そのうえで、入力された支払ブロックが手動支払もブロックすることをシステムが確認する。加えてSAPは、手動の支払ブロックを設定している状態で、請求書明細の差異により自動でブロックがかかった場合、システムは会計伝票の仕入先明細に手動の支払ブロックを設定すると説明している。ブロック理由の定義そのものは、IMGの 財務会計 → 債権・債務 → ビジネストランザクション → 支払（Outgoing Payments）→ 手動支払（Manual Outgoing Payments）→ 支払ブロック理由のチェック（Check Payment Block Reason） で行う。手動支払の配下に置かれているという場所が、この設定の性格を表している。
現場でよくある誤りは、ブロック理由を「差異」「調査中」「保留」といった業務用語で増やし、二軸のフラグをすべて同じ組合せにしてしまうことである。理由の数を増やす前に、二軸の組合せを何種類持つかを決める。 実務で必要なのは、たいてい二種類か三種類しかない。
確率ブロックは、差異のない請求書に付く
第二の束のうち、最も滞留しやすいのが確率ブロックである。差異が一件もない請求書に付くため、調査すべき差異が存在せず、解除の判断根拠が現場にないからである。
SAPの説明では、差異や金額による自動ブロックに加えて、抜き取り検査のために請求書を無作為にブロックする確率ブロックの手続がある。カスタマイズで設定できるのは、確率ブロックを有効にするかどうかと、ブロックの確率である。確率は 閾値と割合で設定し、請求書の金額が閾値以上ならブロックされる確率は設定した割合と同じになり、閾値未満なら設定した割合に比例して計算される。SAPが挙げている例では、閾値が1,000ドルで割合が50%のとき、1,000ドルを超える請求書がブロックされる確率は50%、500ドルの請求書では25%になる。すべての請求書で確率を同じにしたい場合は、閾値をゼロに設定する。 そして確率ブロックは明細単位でなく 請求書全体に対して行われ、請求書を転記したときに確率ブロックが設定されると、システムは仕入先明細の Payment block 欄に自動的に R を設定し、個々の明細にはブロック標識が付かない。
設計上の含意は二つある。 一つは、確率ブロックの解除は差異調査ではなく承認行為だということ。差異がないのだから、内容を見て承認する担当と締切を決めなければ、支払日まで残る。もう一つは、閾値をゼロのまま稼働させると、少額請求書にも同じ確率でブロックが立つということである。少額の確率ブロックが例外リストの過半を占めている会社は珍しくない。
解除の権限と締切を、ジョブとして持つ
請求書検証によるブロックの解除は、SAPが用意している解除の仕組みに素直に乗せる。乗せていないのは、たいてい権限とジョブの二点である。
SAPの説明によれば、請求書の解除トランザクション MRBR は、差異によりブロックされた請求書、手動の支払ブロックを含む請求書、確率ブロックされた請求書を選択して一覧できる。自動解除では、システムがブロック理由ごとに まだ有効かどうかを確認し、有効でなくなっていればそのブロック理由を削除する。請求書のブロック理由がすべて削除されれば、請求書は解除される。 手動解除では、ブロックされた請求書の一覧が表示され、有効でなくなったブロック理由が色で示され、担当者は個々のブロック理由を削除するか、解除する請求書に印を付ける。自動解除をバックグラウンドで回す場合は、プログラム RM08RELEASE のジョブを設定する。
権限も明示されている。SAPは、解除時に M_RECH_EKG の活動2（購買グループの発注に係る請求書の解除）、M_RECH_EKG の活動3（購買グループの発注に係るブロック済請求書の一覧の表示）、M_RECH_SPG の活動2（ブロック理由の削除） の二つの権限オブジェクトをチェックすると説明している。一覧を見る権限と、ブロック理由を削除する権限が別のオブジェクトになっている。 ここを同一のロールに束ねている会社では、支払日の直前に「一覧を見に行った担当者がそのまま全部消す」という運用が成立してしまう。分けられる設計になっているものを分けないのは、設計の選択である（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
そのうえで、自動解除ジョブを支払処理の何時間前に回すかを決める。支払日の当日朝に回しても、残ったブロックを調べる時間がない。 支払日の三営業日前に回し、残った件数を発生源に返す時間を作る。
転記ブロックには、支払先代替という抜け道がある
止める側の設計には、もう一つ知っておくべき穴がある。転記ブロックをかけた取引先でも、金が出る経路が残る場合がある。
SAPの説明はこうである。取引先に支払ブロックを設定して支払を止めても、入庫時などにその取引先へ転記することはできる。 逆に取引先に転記ブロックを設定すると、その取引先の未消込明細を支払うこともできなくなり、転記ブロックが支払ブロックとしても働く。 ただし、その取引先に支払先代替（alternative payee）を登録している場合には、取引先に転記ブロックを設定したうえで、支払先代替へ支払を転記することによって支払を実行できる。 SAPはこの動きを、取引先に対して破産手続が開始された場合などの例として説明している。
製品としては正しい設計である。同時に、支払を止めたつもりの取引先に金が出る経路でもある。 支払停止の判断を経理が下し、マスタの転記ブロックだけをかけて安心している会社は、支払先代替が登録されているかどうかを見ていない。 支払停止の手順書には、転記ブロック、支払ブロック、支払先代替の三点を同時に確認する行を入れる。
取引先マスタのブロックには、範囲の制約もある。SAPは、一つの会社コードに対する支払ブロックは設定した時点で有効になり、取引先を複数の会社コードに割り当てている場合は、会社コードごとに同じ手順を繰り返してブロックする必要があると説明している。転記ブロックについては、特定の会社コードに対するものと、すべての会社コードに対するものがあり、購買ブロックは購買組織単位で設定する。そして、口座に未消込明細が残っているうちはブロックしない。 SAPは、口座がブロックされていると 未消込明細を消し込むことができないと明記している。棚卸しでブロックした口座の明細が消せなくなり、支払日に例外として現れるのはこの経路である。
手振込を認める代わりに、件数を数えて発生源へ返す
ここまでの整理を、月次の工程に落とす。やることは二つで、手振込を禁止しないことと、件数を発生源別に数えることである。
禁止しても消えない。支払期日は動かないので、経理は必ずどこかで振り込む。禁止すると、記録に残らない形で振り込まれるようになるだけである。 代わりに、手振込を一件ずつ記録し、月次で発生源別に集計する。区分は四つでよい。第一が 支払条件または支払方法の未設定。第二が 請求書検証の差異ブロックの未解除。第三が 確率ブロックの未解除。第四が 緊急、すなわち期日の設定誤りや発注そのものの遅れである。
区分ごとに返す先が違う。第一はマスタの整備で、購買のマスタ登録手順に支払条件と支払方法の必須化を戻す（SAPのマスタデータを稼働後に劣化させない｜登録権限とオーナーシップの決め方）。第二はMRBRの解除ジョブと締切の運用で、購買と検収の側に差異の解消期限を持たせる（請求書のOCR自動化はどこで止まるか｜三面照合と例外処理をERPのどちら側に置くか）。第三は確率ブロックの閾値と割合の見直しで、経理と情報システム部門が決める。第四は購買と現場の発注リードタイムの問題であり、経理の設定では一件も減らない。
四つに分けた瞬間に、経理が自分で減らせる件数と、そうでない件数が分かれる。 分けずに「手振込が三十件あります」とだけ報告している限り、相手は誰も動かない。
決めるのは三つ
第一に、ブロックキーの二軸を宣言する。 SAPの説明によれば、Pmnt block 欄のキーは、明細が支払プログラムに対してブロックされるかと、手動支払に対してブロックされるかの二つを指定し、ブロックキーは両方を含むこともできる。支払条件と支払期日は、支払プログラムに対するブロックには影響しない。 したがって「自動だけを止めるキー」が存在し、その明細はネットバンキングから出ていける。ブロック理由を業務用語で増やす前に、二軸の組合せを何種類持つかを決める。 SAPは請求書転記時に、入力された支払ブロックが手動支払もブロックすることをチェックするとしており、手動の支払ブロックがある状態で請求書明細の差異により自動ブロックがかかった場合、会計伝票の仕入先明細に手動の支払ブロックを設定する。ブロック理由の定義は、IMGの手動支払の配下にある支払ブロック理由のチェックで行う。
第二に、解除の権限と締切を、ジョブとして持つ。 MRBR は、差異によりブロックされた請求書、手動の支払ブロックを含む請求書、確率ブロックされた請求書を選択できる。自動解除ではブロック理由ごとに有効性を確認し、有効でなくなったものを削除して、すべて削除されれば請求書を解除する。バックグラウンドで回すにはプログラム RM08RELEASE のジョブを設定する。権限は M_RECH_EKG の活動2と活動3、M_RECH_SPG の活動2がチェックされ、一覧を見る権限とブロック理由を削除する権限は別のオブジェクトである。 確率ブロックは差異のない請求書に付くため解除の判断根拠が現場になく、閾値をゼロで稼働させると少額請求書にも同じ確率で立つ。閾値以上なら設定した割合、閾値未満なら割合に比例した確率になる。
第三に、手振込を禁止せず、件数を発生源別に返す。 支払条件と支払方法の未設定、差異ブロックの未解除、確率ブロックの未解除、緊急の四つに分ければ、経理が自分で減らせる件数とそうでない件数が分かれる。あわせて支払停止の手順書に、転記ブロックと支払ブロックと支払先代替の三点を同時に確認する行を入れる。SAPは、取引先に転記ブロックを設定しても、支払先代替を登録していれば支払先代替へ転記することで支払を実行できると説明している。 取引先マスタのブロックは会社コード単位で有効になるため、複数の会社コードに割り当てている場合は会社コードごとに設定する必要があり、未消込明細が残る口座をブロックすると明細を消し込めなくなる。
