コラム

業務知識に基づくデータ突合の自動化

～NaU Rulebook DataCheckerの裏技～

Vol.017　2023年7月19日

弊社へのお問合せが多い業務のひとつに「データ突合」があります。以下は頻度の高い業務の例です。
最近はDXの一環としてデータ突合自動化のニーズが増えている印象があります。

入金消込／支払消込（経理）
売掛金照合（卸売業）
オーソリ・売上突合（クレジットカード）
入金消込（クレジットカード）

データ突合自動化実現上の課題

いざデータ突合自動化を実現しようとすると簡単でないことに気づかれるケースが多々あります。データ突合の本質は「種類の異なるデータを関係性に基づき紐づける」です。この「データ」と「関係性に基づく紐づけ（データ突合の業務知識）」は業種・業務や企業により様々です。そのためデータ突合をプログラム等で自動化する際に以下のような課題があがります。

突合条件が明文化されていない（業務知識の属人化）
突合条件の変更頻度が高い（プログラム保守コスト増加）
突合条件が複雑でプログラム化の難易度が高い（プログラム開発の長期化・不具合多発・開発コスト高）

これらの課題はありますが諦める必要はありません。データ突合業務にも弊社ルールエンジンは有効です。

ルールエンジンによるデータ突合自動化システム構成例

突合するデータ間の関係性が比較的簡易なものであれば、ルールエンジン「NaU Rulebook」が最適です。
一方で、データ間が多対多の関係になるなど複雑な場合は、ルールエンジン「NaU DSP」で対応します。

※多対多とは、例えば、数枚の売上伝票の組合せと数枚の入金結果の組合せで金額一致を図る、などです。

下図は、NaU RulebookとRPAによる簡易なデータ突合自動化システムの構成例です。

NaU Rulebook（DataChecker）によるデータ突合機能の実現

NaU Rulebookでデータ突合の自動化を行う場合、データチェック機能（DataChecker）を使用します。このDataCheckerは元々は複数の項目で構成される書類などのデータの記載チェックや書類間の記載内容の整合性チェックを簡易に実現するための機能でしたが、この書類間の整合性チェックの処理方式を流用するとデータ突合を簡易に実現できます。

例えば、下図のような入金データと取引データがあるとします。

以下のような突合条件を想定すると、DataCheckerではルール定義書（パラメータ定義シート）に下表のような1行を記述するだけです。

取引データの取引先と入金データの振込人名義が等しい
取引データの取引日が入金データの振込日よりも前の日付
取引データの取引日が入金データの振込日から30日以内
取引データの取引額と入金データの入金額が等しい

このルールを実行すると下図の結果が得られます。識別子が等しい項目間で取引データと入金データの対応関係を示しています（赤枠と青枠の2件が突合したことを示している）。

※画面はNaU Rulebook開発者画面です。本番稼働時はAPIでアクセスします。

導入期間

弊社ルールエンジンによるデータ突合自動化の導入期間については様々ですが、先に示した業務例においては概ね3～6カ月程度の導入期間で導入が可能と思っております。

まとめ

今回は、ルールエンジンによるデータ突合自動化の実現について紹介しました。
皆様の業務のなかでデータ突合自動化を検討される際の参考になれば幸いです。また、ここに記載していないより具体的なノウハウもありますので、弊社にお気軽にお尋ねください。