単価と数量の取り違えが合計一致のまま通る
単価と数量を逆に読み取っても、合計金額は変わりません。総額のチェックだけでは検知できず、明細行の突合を省くと、誤った数量のまま計上されます。
GENZ, Inc.
支払業務を止めずに
請求書受領システムを
支払業務を止めずに
請求書受領システムを第三者の視点で検証します
受領経路と取引先、請求書の様式が増えるほど、検証すべき組み合わせは膨らみます。GENZは第三者の視点で、検証範囲と優先順位の決め方を一緒に作ります。
支援事例
支援実績5,000件以上
請求書受領システムでよくある不具合
請求書受領システムの不具合は、データ化・会計連携・承認ワークフローの各段で起き、支払漏れや二重支払として表面化します。ここでは、合計金額の一致や正常系の検証では見落とされやすい不具合を挙げます。
単価と
端数処理の順序違いで消費税額がずれる
端数処理の順序が会計システム側と異なると、消費税額がずれます。差異は小さくても計上額と支払額が合わず、月次の修正仕訳が発生します。
承認金額の境界で上位承認を経ずに計上される
境界値ちょうどの金額で分岐条件が誤っていると、上位承認を経ずに計上されます。金額階層ごとに境界値を試さないと、この誤りは検知できません。
連携失敗後の再送で請求書が二重計上される
連携エラー後の再送で同一の請求書が二重に送信されると、二重計上から二重支払へ進みます。エラーを意図的に発生させて検証しないと気づけません。
同じ請求書が受領経路ごとに別件で登録される
紙とメール添付など複数の受領経路で同じ請求書が届くと、別件として登録されます。経路をまたぐ重複チェックがないと、二重支払が起きます。
残存した不具合により生じる問題
受け入れテストを終えても、残った不具合は支払・決算・監査という形で表面化します。放置した場合に業務へどう影響するかを、局面ごとに整理します。
静的テスト（レビュー）でおさえるべき観点
受領経路が混在する受領システムでは、経路ごとの項目対応表が増え、仕様書と実機の照合が後工程へ先送りされます。受け入れテストの前に、設計書と設定値を突き合わせる静的テストの観点を整理します。
照合しないと、受け入れテストの段階でどの経路のどの項目を確認すればよいかが決まらず、合否基準のないまま検証が進むおそれがあります。
受領経路ごとの項目対応表を、DB設計書の項目定義と照合する
紙・メール添付・デジタル受領・代理受領の経路ごとに、どの項目がどの項目定義へ入るかの対応表を、DB設計書と照合します。経路の数だけ表が増えるため、未対応の組み合わせをここで検出します。
確認する資料
- 項目対応表
- DB設計書
- 受領経路一覧
端数処理の順序の相違は計上額の差異として表面化し、修正仕訳が月次の締め作業へ割り込むおそれがあります。
税率区分と端数処理の順序を仕様書の算出式と照合する
消費税の税率区分と端数処理（切り捨て・切り上げ・四捨五入）の適用順序を、仕様書の算出式と照合します。順序が違えば計上額が変わるため、端数が出る金額での確認条件を定めます。
確認する資料
- 算出仕様書
- 税率区分表
- 端数処理定義
分岐条件の設定誤りがあると、本来の承認者を通らないまま支払データが作成され、内部監査で証跡を求められたときに説明できないおそれがあります。
承認ルートの分岐条件を、職務権限規程の金額の階層と設定値で照合する
承認ルートの分岐条件（金額の階層・部門・取引先の属性）の設定値を、職務権限規程と照合します。分岐となる金額の境界値で、設定画面の値と規程の数値が一致するかを確認します。
確認する資料
- 職務権限規程
- 承認設定一覧
- 分岐条件表
連携仕様の不一致は連携エラーとして稼働後に表面化し、受領側と会計側のベンダー間で原因調査が往復するおそれがあります。
会計連携の仕様をAPI定義と受け入れ側で照合する
受領システムから会計システムへ渡すデータの項目・型・必須条件を、API定義と受け入れ側の仕様で照合します。連携方式がAPIかCSVかで確認箇所が変わるため、自社の方式で項目を洗い出します。
確認する資料
- API定義書
- 連携仕様書
- 受入条件書
再送と重複検知の規則が未定義のままだと、二重計上や支払漏れを支払期日の後に発見するおそれがあります。
連携失敗時の再送条件と重複検知の規則を、運用手順書の記述と照合する
連携失敗時に何回・どの間隔で再送するか、同一請求書をどう重複検知するかの規則を、運用手順書の記述と照合します。規則が文書にないまま稼働すると、二重計上を手作業で洗い出すことになります。
確認する資料
- 運用手順書
- 再送条件定義
- 重複検知規則
- エラー対応手順
動的テストの設計・実行のポイント
動的テストは、データ化と税額算出のユニットテストから、月次の締めを想定した受け入れテストまで、四つの工程で設計します。
STEP 01
ユニットテスト同値分割と境界値分析で入力を分ける
どう確かめるか
データ化と税額算出のユニットテストを、同値分割と境界値分析で設計する
AI-OCRの読み取り結果は入力画像や様式で変わるため、合否判定には項目別の基準が必要です。税率区分と登録番号の有無で入力を同値分割し、端数処理は境界値で計上額への影響を検証します。
- 01税率区分と登録番号の有無で入力データを同値分割する
- 02消費税の端数処理に境界値を設定して計上額を検証する
- 03AI-OCRの読み取り項目ごとに合否の判定基準を定める
OUTPUT項目別の合否判定基準
STEP 02
統合テスト仕様書と実機の挙動を照合する
どう確かめるか
システム間連携と再送の挙動を確かめる統合テスト
データ化した請求書情報が会計システムへ渡る経路が出力の境界です。項目対応が仕様どおりに変換されるかを照合し、同一請求書の再送を発生させて、重複検知で二重計上を防げるかを検証します。
- 01受領システムから会計システムへの項目対応を仕様書と照合する
- 02同一請求書の再送を発生させて重複検知の挙動を検証する
- 03連携エラー時の通知と再処理の手順を確認する
OUTPUT連携と再送の検証記録
STEP 03
システムテスト業務の流れに沿って例外も通す
どう確かめるか
受領から支払データ作成までを業務シナリオと異常系で通す
紙・メール添付・デジタル受領など経路が混在するため、受領から支払データ作成までを経路別のシナリオで通します。承認ワークフローの分岐条件と締め日をまたぐ処理には異常系の観点を加えます。
- 01受領経路ごとに受領から支払データ作成までを通す
- 02承認ワークフローの分岐条件を組み合わせて検証する
- 03締め日をまたぐ計上と支払のシナリオを検証する
OUTPUT業務シナリオの通過記録
STEP 04
受け入れテストと回帰テスト締め日をまたぐ期間で合否を決める
どう確かめるか
月次の締めを想定した受け入れテストと、機能更新後の回帰テストを実施する
本番に近いデータで月次の締めを想定した受け入れテストを行い、仕訳一覧と支払データを確認します。稼働後はSaaSの機能更新のたびに回帰テストを実施し、既存の処理への影響を確かめます。
- 01本番に近いデータで仕訳一覧と支払データの作成を確認する
- 02合格基準と判定の記録をリリース判断の材料へまとめる
- 03SaaSの機能更新後に回帰テストの範囲を決めて実施する
OUTPUTリリース判断の根拠資料
GENZが代行する請求書受領システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 検証範囲と優先順位を根拠つきで絞り込めます
- 項目別の合否判定基準で読み取り精度を判断できます
- 締め期間に重なる実行と不具合票の起票を任せられます
- 既存の開発体制を変えずにテスト計画へ組み込めます
請求書受領システムの検証をGENZへ任せる理由
受領経路・取引先・請求書パターンの組み合わせが膨らむ中で、どこを検証範囲に入れ、どこを外すかを根拠つきで決める設計そのものを、GENZが引き受けます。
検証範囲と優先順位を設計する
受領経路と取引先、請求書パターンの組み合わせを洗い出し、支払業務への影響度で検証範囲と優先順位を設計します。
データ化から支払データ作成までを検証
AI-OCRによるデータ化の項目別の判定基準を定め、境界値と異常系の観点で、支払データ作成までを検証します。
既存の体制にそのまま組み込む
既存の開発体制とテスト計画に接続する形で参画します。体制の作り替えは不要で、スプリントと並行して実施できます。
テスト項目書・不具合票・報告書を納品
テスト項目書・不具合票・報告書を納品物として残します。リリース判断の材料と、監査への説明に使える記録です。
ご相談から納品までの流れ
ご相談から報告書の納品までの流れを、工程ごとに順を追ってご説明いたします。
ヒアリング
受領経路の内訳・連携先・切替日を伺い、社内で消化できる範囲を整理します。
テスト設計と見積もり
AI-OCRの判定基準と受領経路から、テスト設計と必要工数を提示します。
テストの実施と結果の共有
テスト項目書に沿って検証し、不具合票と結果を随時共有します。
報告書の納品と再確認
リリース判断の材料となる報告書を納品し、結果の読み方を再確認します。
検証範囲の整理からご相談いただけます
請求書受領システムの検証範囲と優先順位から、GENZへご相談ください
受け入れテストの計画前でも、社内で工数を消化できないと判明した後でも構いません。受領経路と請求書パターンから検証範囲と優先順位を整理し、リリース判断の材料としてお渡しします。