【ITニュース解説】GST Reconciliation Software: GSTBot

インドでは、物品サービス税（GST）という消費税制度が導入されている。このGSTの申告手続きにおいて、多くの企業、特に中小企業（SMB）が直面している大きな課題がある。それは、自社の購買記録と、税務当局が発行する「GSTR-2B」という書類に記載されているサプライヤーからの請求書データを照合する作業、つまりリコンシリエーションだ。GSTBotというソフトウェアは、この手間のかかる照合プロセスを劇的に改善するために開発された。

一般的な中小企業では、月に何百もの購買請求書をスプレッドシートやPDF形式で管理している。一方、税務ポータルからは、各サプライヤーが申告したすべての請求書がリストアップされたGSTR-2Bファイルが提供される。これらの二つのデータセットは、実際には完璧に一致することは稀だ。例えば、金額がわずかに四捨五入されていたり、サプライヤーの名称が表記ゆれで異なっていたり、あるいはサプライヤー側の申告遅延によって一部の請求書がまだポータルに表示されていなかったりする。従来のリコンシリエーションツールは、このようなデータに対して、文字列の完全一致を厳しく要求する傾向があった。そのため、少しでも違うデータはすべて「例外」としてフラグが立てられ、結局、利用者が一つひとつ手作業で確認し、どのデータが正しいかを判断しなければならなかった。この手作業のプロセスは非常に時間と労力がかかり、中小企業の経理チームにとって一ヶ月近くかかることも珍しくなかった。これが、GSTBotが解決しようとしている中心的な問題だ。

GSTBotが提供する解決策は、「許容誤差（tolerance）」に基づく照合戦略にある。これは、金額が完全に一致していなくても、設定された一定の割合（例えば0.01%、つまり1%）以内の差であれば、その請求書を一致とみなすというものだ。この許容誤差は、ユーザーインターフェース（UI）を通じて、あるいはシステムの設定変数として自由に調整できる。この柔軟なアプローチにより、手作業で発生していた多くの「例外」が自動的に処理されるようになり、経理チームが手作業で行う照合作業の負担を大幅に軽減できる。GSTBotが動的なアルゴリズムで、手動での作業をたった数秒で処理できるのはこのためだ。

GSTBotは、複数の技術要素を組み合わせて構築されている。ユーザーが直接操作する画面、つまりフロントエンドは、ReactというJavaScriptライブラリとViteという高速な開発ツールを使って構築されている。このフロントエンドは、照合が完了した後に、結果を分かりやすいテーブル形式で表示する。このテーブルでは、ベンダー名や金額、あるいは例外の種類などでデータをフィルタリングできる機能が提供されている。一致した請求書ペアは明確に表示され、もし一致しなかった請求書があれば、それは別のパネルに表示され、「ベンダー名のスペルを確認してください」や「サプライヤーに不足している請求書の申告を依頼してください」といった具体的な推奨アクションが示される。さらに、一致した請求書の割合を示すスコアも表示されるため、経理チームは現在の照合状況を素早く把握できる。

システムの裏側で動くバックエンドは、主にPythonというプログラミング言語で実装されている。WebアプリケーションのAPI（アプリケーション・プログラミング・インターフェース）層、つまりフロントエンドからのリクエストを受け付けたり、データを提供する部分は、FastAPIというフレームワークが担当する。例えば、ユーザーが照合開始ボタンをクリックすると、FastAPIのAPIエンドポイントがそのリクエストを受け取る。この照合処理は時間がかかる可能性があるため、Webアプリケーションがフリーズしたり、応答しなくなったりするのを防ぐために、Celeryというタスクキューシステムが利用されている。FastAPIは、重い照合処理を直接実行するのではなく、Celeryにそのタスクを渡し、Celeryのワーカープロセスがバックグラウンドで実際の処理を行う。これにより、APIは常に迅速に応答し、ユーザーは照合が完了するのを待つ間も他の作業を続けられる。

実際のデータは、PostgreSQLというリレーショナルデータベースに保存されている。ここには、自社の請求書データ、GSTR-2Bのデータ、そして照合過程で発生した例外記録などが格納される。請求書の金額やベンダー名などのフィールドにはインデックスが設定されており、これにより大量のデータの中から特定の情報を素早く検索できる。また、Redisという高速なインメモリデータストアがキャッシュとして利用されている。これは、特にGSTR-2Bファイルのように頻繁にアクセスされる可能性のあるデータを一時的に保存し、データベースへの負荷を軽減することで、システムの全体的なパフォーマンスを向上させる役割を果たす。

照合の中心となるアルゴリズムは、意図的にシンプルに設計されている。各自社請求書に対して、GSTR-2Bのエントリを一つずつ調べていき、許容誤差の条件を満たす最初の一致を見つける。もし一致するエントリが見つかれば、そのペアは「一致」として記録される。もし許容誤差内で一致するエントリが一つも見つからなかった場合は、その請求書は「例外」としてデータベースに記録され、後でユーザーによる手動確認のために表示される。このシンプルな設計は、アルゴリズムの動作を理解しやすく、また必要に応じて調整や監査が容易に行えるという利点がある。

GSTBotは、インドの中小企業にとって非常に大きな意味を持つ。手動での照合プロセスにかかる費用は、月に数千ルピーにも達することがあるが、GSTBotは作業の約90%を自動化することで、このコストを大幅に削減する。さらに、照合されなかった請求書に対しても、明確で具体的なアクションが提示されるため、手動レビューの効率も向上する。前述の通り、許容誤差を柔軟に調整できるため、サプライヤーから提供されるデータの品質に左右されずに、ツールを最適に活用できる。結果として、GSTBotは既存の会計ワークフローの自然な延長として機能し、複雑なエンタープライズシステムを導入するような負担を感じさせない。

GSTBotはオープンソースプロジェクトとしてGitHubで公開されており、MITライセンスの下で誰でもコードを利用し、貢献できる。コードベースは、新しい照合ロジック、例えばベンダー名の表記ゆれをより高度に検出する「あいまいマッチング」機能などを、システムの核心部分に影響を与えることなく追加できるように設計されている。プロジェクトは活発にメンテナンスされており、照合アルゴリズムの改善や、新しい法令順守機能の追加に貢献したい開発者を歓迎している。GSTBotは、技術がビジネスの現実的な課題をどのように解決し、効率化に貢献できるかを示す好例と言える。