期末監査で、仕訳テストの母集団が提示される。当期に転記された伝票タイプSAの手入力仕訳、1,842件。 監査人が抽出条件を挙げていく。決算日から三営業日以内に転記されたもの、摘要欄が空欄または十文字未満のもの、入力者と承認者が同一のもの。抽出結果は214件で、そのうち147件について証憑の提示を求められる。 経理課長が答える。このうち大半は在庫システムからの取込みで、手入力ではありません。 監査人が返す。伝票タイプが同じなので、こちらでは区別できません。 この会話が毎期繰り返される会社では、問題は仕訳の件数ではない。どの口から入ったのかを、システムの側が記録していないことにある。
減らすべきは件数ではなく、経路の数である
手入力仕訳の削減を掲げるプロジェクトは、たいてい件数の目標を置く。年間2,000件を1,200件に、という形である。そして達成されない。
達成されない理由は、件数が業務量に比例しているからだ。引当金の計上、経費の振替、部門間の付替え、税効果、連結修正。 どれも必要な処理で、削るなら業務そのものを変えるしかない。件数を目標に置いた瞬間に、統制の議論が業務改善の議論にすり替わる。
代わりに絞れるのは、入力の経路である。S/4HANAで総勘定元帳に伝票が立つ口は、大きく三系統ある。
一つ目が、画面からの直接起票。 Fioriなら「Post General Journal Entries」（アプリID F0718）、SAP GUIならFB50やF-02、いったん保留にするならFV50である。二つ目が、表計算からの一括取込み。 「Upload General Journal Entries」（アプリID F2548）は、スプレッドシートから複数の総勘定元帳伝票をまとめてアップロードするアプリで、テンプレートはxlsxまたはCSVで取得できる。アップロードされた伝票は保留状態に入り、「Post General Journal Entries」で保留状態の伝票を表示して転記する。検証を挟むなら「Verify General Journal Entries」（アプリID F2547）が入る。 三つ目が、サブシステムからのインタフェースである。 販売、購買、経費精算、給与から、BAPIやIDocで自動転記される。
この三つは、必要な統制がまったく違う。 三つ目は事前に作り込んだロジックが動くだけなので、統制はプログラムと変更管理に置く。一つ目は人が数字を打つので、統制は権限と承認に置く。二つ目は、両方の性質を持ちながら、どちらの統制も効きにくい。 ここが最も危ない（SAPの権限設計と職務分掌（SoD）、内部統制を仕組みで担保する実務と判断基準）。
伝票タイプを分けていない会社は、後から経路を追えない
三系統に分けたところで、転記された後の伝票を見て経路が分かるかというと、多くの会社では分からない。伝票タイプが全部SAだからである。
伝票タイプは番号範囲と結びついており、経路ごとに別のタイプを割り当てておけば、伝票番号を見るだけでどの口から入ったかが分かる。分けていない会社では、監査人が母集団を作れないので、手入力ではない仕訳まで全部が手入力の母集団に入る。 冒頭の1,842件が、まさにこの状態である。
分けるべき粒度は、経路そのものである。直接起票、アップロード、インタフェース、そしてインタフェースの中でも販売、購買、経費、給与の別。 ここまで分けておくと、監査の母集団は直接起票とアップロードだけになる。それだけで、提示を求められる証憑の量が桁で変わる。
そして分けるのは、稼働してからでは難しい。番号範囲の変更は期首でしかできず、過去の伝票は遡って振り替えられない。 移行の設計で決めておくべき事項の一つがここにある（SAP移行を機に勘定科目体系（COA）を再設計し、全社で数字の意味をそろえる）。
「アップロードなら安全」は逆である
アップロードを推奨する会社は多い。画面で一件ずつ打つより速く、Excelで検算できて、テンプレートで書式が揃うからである。 ここまでは正しい。
問題は証跡の位置にある。アップロードで転記された伝票は、SAPの中では通常の伝票と同じように記録が残る。誰がいつ転記したかも残る。 残らないのは、アップロードされる前のファイルで何が起きたかである。
テンプレートに数字を入れたのは誰か。入れた後で誰かが一行だけ書き換えたか。前月のファイルを上書きして作ったのか。これらはすべてSAPの外側の話であり、SAPの監査証跡には現れない。 直接起票なら、画面に打った人と時刻が記録される。アップロードは、その一点だけが直接起票より弱い。
ここで電子帳簿保存法の要件が効いてくる。国税庁は、いわゆる優良な電子帳簿の要件として、電子帳簿保存法施行規則第5条第5項に従った保存を求めており、その中に、全ての取引に係るデータの訂正又は削除の履歴が確保できることが含まれる。 この要件を満たして所轄税務署長に届け出た帳簿については、記録された事項に関し申告漏れがあった場合の過少申告加算税が5パーセント軽減される。SAPの中は、この訂正削除の履歴という点で強い。転記済み伝票は削除できず、逆仕訳で消す。 だから履歴は残る。残らないのは、やはりアップロード前のファイル側である。
したがってアップロードを使うなら、検証を挟む運用にする。 「Verify General Journal Entries」で第二の目を通し、承認者は転記済みの伝票ではなく、アップロードされた元ファイルと照合する。そしてその元ファイルを、伝票番号と紐づけて保管する。 ここまでやって、ようやく直接起票と同じ強度になる（電子帳簿保存法のスキャナ保存・電子取引を月次決算の工程に組み込む手順）。
摘要欄を空にできる設定が、毎期の監査工数を作っている
最後は、手間が最も小さく効果の大きい一手、摘要欄の必須化である。
適用指針A41項が挙げる不適切な仕訳の特性のうち、期末又は締切後の仕訳入力のうち摘要欄の説明が不十分な仕訳入力という条件は、SAP側の設定で消せる。 明細テキストを入力必須の項目として扱う設定にすれば、空欄の伝票は転記できない。
多くの会社がこれを入れていない理由は単純で、現場から遅くなると言われるからである。 実際は、月末に147件の証憑を探し直す時間のほうが長い。
必須にするだけでは足りない場合は、内容の側にも条件を置く。十文字未満を弾く、案件番号や稟議番号の書式に合っているかを検証する、といったチェックを入力時に走らせる。 検証ルールと代入ルールは、まさにこのための機能である。
そのうえで、入力者と承認者が同一になる経路を残さない。 A41項の一覧にこの条件そのものは載っていないが、冒頭の場面のように監査人が抽出条件に加えることがあり、少人数の経理では最も守りにくい線でもある（少人数経理の職務分掌、3〜5人でどこまで内部統制を効かせられるか）。
- 直接起票、アップロード、インタフェースのそれぞれに、別の伝票タイプと番号範囲を割り当てたか
- インタフェースは連携元（販売・購買・経費・給与）ごとにさらに分けたか
- 直接起票を許す職位と、勘定科目・原価センタの範囲を限定したか
- アップロードに検証ステップを挟み、元ファイルを伝票番号と紐づけて保管する運用を決めたか
- 明細テキストを入力必須にし、文字数と書式の検証ルールを置いたか
- 入力者と承認者が同一になる経路が残っていないかを、権限側で確認したか
- 決算日以降に転記できる伝票タイプと期間を、期間オープン管理と合わせて決めたか
- 監査人が毎期使う抽出条件を、自社の月次モニタリングとして先に実施する担当を決めたか
手入力仕訳の統制で決める三つのこと
第一に、削減の目標を件数から経路に置き換える。 手入力仕訳の件数は引当金、振替、付替え、税効果、連結修正といった必要な処理の量に比例しており、件数目標は統制の議論を業務改善の議論にすり替える。絞れるのは口の数のほうである。 S/4HANAで総勘定元帳に伝票が立つのは、画面からの直接起票（Fioriの「Post General Journal Entries」＝アプリID F0718、GUIならFB50やF-02、保留ならFV50）、表計算からの一括取込み（「Upload General Journal Entries」＝アプリID F2548。テンプレートはxlsxまたはCSVで取得でき、アップロードされた伝票は保留状態に入る）、そしてサブシステムからのインタフェースの三系統である。必要な統制は三つとも違う。
第二に、経路ごとに伝票タイプと番号範囲を分ける。 全部をSAで転記している会社では、転記後の伝票を見ても経路が分からないため、インタフェース由来の伝票まで手入力の母集団に入る。監査基準報告書240第31項は、経営者による内部統制を無効化するリスクに対する監査人の評価にかかわらず、総勘定元帳に記録された仕訳入力や財務諸表を作成する過程における修正の適切性を検証する手続を立案し実施することを求めており、この手続は内部統制の評価がどれだけ良好でも省略されない。 母集団の設計は、こちらで先に済ませておける。番号範囲の変更は期首にしかできず、過去の伝票は遡って振り替えられないため、移行の設計事項として扱う。
第三に、アップロードを検証付きの経路として作り直し、摘要欄を必須にする。 アップロードは速くて書式が揃うが、アップロード前のファイルで何が起きたかがSAPの監査証跡に現れないという一点で、直接起票より弱い。「Verify General Journal Entries」（アプリID F2547）で第二の目を通し、承認者は転記済み伝票ではなくアップロード元のファイルと照合し、そのファイルを伝票番号と紐づけて保管する。 電子帳簿保存法の側から見ても、優良な電子帳簿の要件には全ての取引に係るデータの訂正又は削除の履歴が確保できることが含まれ、これを満たして届け出た帳簿には過少申告加算税5パーセントの軽減がある。SAPの中は履歴が残る。切れているのは外側である。 そして適用指針A41項が挙げる不適切な仕訳の特性のうち、摘要欄の説明が不十分という条件は明細テキストの入力必須化と検証ルールで消せる。入力者と承認者が同一になる経路は一覧には無いが、監査人が条件に加えることがあるので、権限の側で塞いでおく。
売上高640億円の化学メーカー。S/4HANAの稼働から三年目で、経理部は本社12名、工場3拠点に各2名を置いている。毎期の監査で仕訳テストの母集団が大きく、期末の二週間が証憑探しで潰れていた。 当期の母集団は伝票タイプSAの2,310件、抽出後の提示依頼は179件である。CFOがまず調べさせたのは、179件の内訳だった。 結果は、在庫システムからの取込みが74件、経費精算システムからの取込みが33件、給与システムからの取込みが19件、残る53件が実際の手入力だった。 つまり126件は、証憑を探す必要のないものである。しかし伝票タイプが同じであるため、経理側で母集団から外す説明が毎期成立していなかった。 改修は三段階で進めた。第一段が伝票タイプの分割で、翌期首から直接起票をSA、アップロードをSU、在庫連携をSI、経費連携をSE、給与連携をSPに分け、番号範囲も別に切った。 過去の伝票は遡って振り替えられないため、当期分は従来どおりの説明を続けている。第二段がアップロードの作り直しである。 従来は担当者がテンプレートに入力して「Upload General Journal Entries」で取り込み、そのまま転記していた。元ファイルは各自のフォルダに残っているだけで、伝票番号との紐づけはない。 変更後は、アップロード後に「Verify General Journal Entries」で課長が検証する運用にし、元ファイルは伝票番号を付けて共有フォルダの月次領域に保管することにした。検証時に照合するのは転記結果ではなく、元ファイルと承認済みの計算根拠である。 第三段が明細テキストの必須化で、あわせて十文字未満を弾く検証ルールを入れた。現場からは反発があった。工場経理の一人が、月末に80件打つのに全部説明を書くのは無理だという意見を出している。 実際に測ったところ、80件のうち68件は毎月同じ振替で、書く内容も同じだった。定型の12種類について文言をあらかじめ登録し、選択で入るようにして解決している。 翌期の監査では、母集団が伝票タイプSAとSUの364件になり、抽出後の提示依頼は27件だった。期末に証憑を探す時間は、経理部全体で延べ96時間から18時間に減っている。 監査法人の主査が経理部長に言った一言が、この案件の要点を言い当てている。去年までは、まず何が手入力かを決めるところから始めていた。今年はそこが最初から決まっている。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
