技術懸念に立ち向かい 法改正を穏便に乗り切った話 2025年5月29日 株式会社 TOKIUM 開発部　TKチーム 高田 将人 1 

自己紹介 プロダクト本部 開発部 TKチーム 高田 将人 Takada Masato 2021年4月にTOKIUMに入社。 2024年6月からTOKIUM電子帳簿保存の開発チームの リーダーに就任 2025年1月からTOKIUM経費精算の開発チームに移動し リーダーに就任。 より便利にTOKIUM経費精算を利用いただけるよう 日々努めています！ 2 

3 目次 ・プロダクトの紹介（TOKIUM経費精算） ・インボイス制度概要 ・インボイス制度のプロダクトへの影響 ・負債の発覚 ・対応方針 ・税額計算が行われているフォーマットの洗い出し ・計算内容で分類 ・各分類について、税額出力のロジックを修正方針を検討 ・振り返り ・まとめ 

プロダクト紹介 TOKIUM経費精算 4 

5 プロダクト概要 事業詳細 / TOKIUM経費精算 ✓ 領収書をスマホで撮って、自動でデータ化 アプリ上で経費申請・承認が完結 ✓ 領収書原本は専用ポストに入れて回収 突合点検・10年間の原本保管を代行 ✓ 70種類以上の連携可能口座・カード 会計ソフトへの柔軟なデータ連携 領収書は撮って入れるだけ、ペーパーレス経費精算クラウド 

事業詳細 / TOKIUM経費精算 「撮って、入れる」2ステップで完了するペーパーレス経費精算クラウド 6 撮って 紙関係の後工程を全て代行し 手間と不正リスクを最小化 10年保管 ファイリングの手間を 削減。ご希望に応じ、 返却/再保管が可能。 データ全数点検 申請に対応する原本 が投函されたか点検。 郵送 入れる 面倒な糊付けや突合も不要に ｢スマホで写真を登録｣ ｢自署や糊付なし投函｣ レターパックにまとめて 原本をTOKIUMに送付*3。 検索要件入力 タイムスタンプの自動付与 登録番号入力・チェック 電子帳簿 保存法対応 インボイス 制度対応 オペレーターが即時に入力*1 を開始。精度は99%超*2。 *1 データ化項目：利用日、支払合計金額(税区分別)、支払先名 、登録番号の入力/照合（インボイス制度に合わせて実施） *2 TOKIUMが規定した条件を満たした書類における、対象項目あたりの精度となります。　 *3 近隣の郵便ポストへ投函。 

インボイス制度とその影響 7 

消費税を正しく処理するための請求書のルール 8 インボイス制度とは 1. 適格請求書発行事業者の氏名または名称・登録番号 2. 取引年月日 3. 取引内容（軽減税率対象品目である旨含む） 4. 税率ごとに区分して合計した対価の額（税込） 5. 税率ごとに区分した消費税額等　←ここが特に重要 6. 書類の交付を受ける事業者の氏名または名称 

9 経費情報に領収書記載の税額データを追加 税率ごとに区分した消費税額を表示 TOKIUM経費精算への影響 

消費税の計算 10 TOKIUM経費精算への影響 Before After 領収書には税額の記載なし 会計処理の際には、消費額と税率から税額を計算 領収書に税額の記載あり 税額の計算は不要になり、領収書記載の税額を参照する （一部例外あり） 

11 一定の期間内に精算された経費について、会計ソフトへとデータを連携するために情報を出力する 会計データ出力について お客様ごとに 出力したい内容は異なる お客様ごとに 出力ロジックをベタ書きした コードを用意 （カスタムフォーマット） 税率 勘定科目 金額 部署 経費科目 利用者 参加者 請求書 発行事業者 利用日 経費 

12 一定の期間内に精算された経費について、会計ソフトへとデータを連携するために情報を出力する 会計データ出力について インボイス制度対応前 税額は保存されていなかった 税額 税額を計算している処理が どこかにある 税率 勘定科目 金額 部署 経費科目 利用者 参加者 請求書 発行事業者 利用日 経費 領収書に記載されている 税額に置き換える必要がある 

13 N＋１を防ぐため、経費の関連情報をバルク取得してまとめた参照用データ構造(キャッシュ)を作成します。 この際に税額をいったん切り捨てで計算して持たせる形になっていました。 カスタムフォーマット内で再計算の場合あり ・切り捨て以外の端数処理で税額計算する場合 ・1つの経費を分割して税額を計算する場合 etc. 会計データ出力システムについて 各カスタムフォーマット内で税額を再計算をしている箇所を網羅的に調べる必要がある 税額計算の端数処理は 事業者の裁量で決められる ・切り捨て ・切り上げ ・四捨五入 切り捨てのケースが一般的 （体感8割以上） 

14 会計データ出力システムについて 1040個のカスタムフォーマット 税額計算の修正が必要な可能性 

15 ①　税額計算が行われているフォーマットの洗い出し 対応方針 ②　計算内容で分類 ③　各分類について、税額出力のロジックを修正方針を検討 

16 ①　税額計算が行われているフォーマットの洗い出し 対応方針 ②　計算内容で分類 ③　各分類について、税額出力のロジックを修正方針を検討 

17 ①　税額計算が行われているフォーマットの洗い出し 前提：1040個のカスタムフォーマットについて ❌サービス開始の初期から作成されており、統一されたコーディング規約がなかった ・税額の計算がどのように行われている可能性があるのかまったく不明 ⭕カスタムフォーマットでよく使用されるメソッドはモジュールにまとめられている（共通メソッドと呼びます） ❌共通メソッドが使用されていることもあれば、使用されていないこともある ❌共通メソッド以外のメソッドを借りてきて使っている可能性も否定できない ⭕インターフェースは統一されていて、受け取っているのは経費の関連情報をまとめたキャッシュのみ 

18 ①　税額計算が行われているフォーマットの洗い出し キャッシュの情報から税額の計算をしているはず 前提：1040個のカスタムフォーマットについて ❌サービス開始の初期から作成されており、統一されたコーディング規約がなかった ・税額の計算がどのように行われている可能性があるのかまったく不明 ⭕カスタムフォーマットでよく使用されるメソッドはモジュールにまとめられている（共通メソッドと呼びます） ❌共通メソッドが使用されていることもあれば、使用されていないこともある ❌共通メソッド以外のメソッドを借りてきて使っている可能性も否定できない ⭕インターフェースは統一されていて、受け取っているのは経費の関連情報をまとめたキャッシュのみ 

19 税額の計算のに必要な情報 ・消費額（税込み金額） ・税率 右記の関連モデルが呼び出されていないことを確認！！ ①　税額計算が行われているフォーマットの洗い出し 経費 ・消費額（税込み金額） 経費科目 税区分 ・税率 キャッシュの情報のみから税額の計算をしている モデル概略 

キャッシュの情報を用いた計算ロジックの洗い出し ・カスタムフォーマットの中 ・共通メソッドの中 ・それ以外のどこか 20 ①　税額計算が行われているフォーマットの洗い出し 

キャッシュの情報を用いた計算ロジックの洗い出し ・カスタムフォーマットの中 キャッシュの税率と同名の属性を参照しているファイル：10個 →税額計算を行なっていたのは2つ（1社）のみ ・共通メソッドの中 →税額計算を行なっているメソッドは1つのみ →これが使用されているカスタムフォーマットが230個 ・それ以外のどこか キャッシュの税率と同名の属性を参照しているファイル：64個 →キャッシュに関連するものはありませんでした🙌🙌 21 ①　税額計算が行われているフォーマットの洗い出し 

キャッシュの情報を用いた計算ロジックの洗い出し ・カスタムフォーマットの中 キャッシュの税率と同名の属性を参照しているファイル：10個 →税額計算を行なっていたのは2つ（1社）のみ ・共通メソッドの中 →税額計算を行なっているメソッドは1つのみ →これが使用されているカスタムフォーマットが230個 ・それ以外のどこか キャッシュの税率と同名の属性を参照しているファイル：64個 →キャッシュに関連するものはありませんでした🙌🙌 22 ①　税額計算が行われているフォーマットの洗い出し 

23 ①　税額計算が行われているフォーマットの洗い出し 対応方針 ②　計算内容で分類 ③　各分類について、税額出力のロジックを修正方針を検討 

24 ②　計算内容で分類 どのような目的で税額の計算が行われているかをできるだけ細かく分類しました ・切り捨て以外の端数処理で税額計算する場合（四捨五入/切り上げ） ・1つの経費を分割して税額を計算する場合 ・×3パターンの端数処理 ・複数の経費の合計額に対して税額を計算 ・×3パターンの端数処理 ・その他、特殊なパターンなど →15パターンほどに分類 

25 ①　税額計算が行われているフォーマットの洗い出し 対応方針 ②　計算内容で分類 ③　各分類について、税額出力のロジックを修正方針を検討 

15個の計算パターンそれぞれについて、修正方針を決定した →修正不要なものや、修正方針が同じになるものが見えてきた 26 ③　各分類について、税額出力のロジックを修正方針を検討 ・最終的に修正方針は大きく3パターンほどに絞られた ・このパターンに含まれない特殊な計算を行なっているものについては 　お客様とのやり取りで修正方針を決定した（8社ほど） 

27 同じパターンで修正を行なうものについては 新しく共通メソッドを用意してこれを利用しました。 今後修正の必要が生じても、共通メソッドの修正のみで対応が完了することが期待されます🙌🙌 修正対応 負債削減！！ 

振り返り 28 

助かったポイント ・カスタムフォーマットのインターフェースが統一されていた ・受け取るデータは経費の関連情報をまとめたキャッシュのみであった ・税額の計算に使用されていたのもキャッシュのデータのみであった ・税額計算のための共通メソッドが用意されていたこと 29 振り返り 

助かったポイント 共通インターフェース ・カスタムフォーマットのインターフェースが統一されていた 依存性の最小化 ・受け取るデータは経費の関連情報をまとめたキャッシュのみであった 依存性の最小化 ・税額の計算に使用されていたのもキャッシュのデータのみであった 再利用可能なドメインロジック ・税額計算のための共通メソッドが用意されていたこと 30 振り返り 設計理論の意義を再確認しました 

31 振り返り 大変だったポイント 再利用可能なドメインロジックの不足 ・税額計算のメソッドが非常に原始的。 ・230個のファイルで使用されていたが、その大半が典型的な3つパターンに落とし込めた ・パターンごとにメソッドが用意されていれば調査や分類の手間が省けたはず。 共通のロジックはメソッドに切り出して再利用 

32 おまけ 共通のロジックはメソッドに切り出して再利用 カスタムフォーマットにおいてはこれが結構難しい ・共通ロジックに気が付くことができない場合がある →1040個のフォーマットを知っている開発者はいない ・共通メソッドがあるのを知らない場合がある →共通メソッドは100個以上ある。存在するすべての共通メソッドを使いこなすのは難しい ・共通メソッドを作成しても、既存コードの置き換えをしづらい →置き換えを行うカスタムフォーマットすべてで動作確認が必要 →フォーマット開発の納期中に動作確認の時間を確保できない場合が多い 

カスタムフォーマット自体がどうしても負債の温床になりやすい 33 おまけ 出力したい内容をお客様自身がシステム上で設定できる仕訳フォーマット機能を開発しました ・複雑な出力ロジックには対応できない場合があります ・対応できるパターンを増やせるよう機能拡充が進められています ・2025年に入ってから作成されたフォーマットのうち約92%をカバー ・仕訳フォーマット　　：1515件 ・カスタムフォーマット：137件 

まとめ 34 

今回うまくいった点 ・うまく設計できている部分まで遡る →インターフェースや参照データが統一されているのを調査の起点に。 ・負債の内容の把握 ・税額計算が230ファイルで行われているが、共通ロジックが散見されることに気がついた →分類して対応方針を絞り込むことができた ・解消するのが難しい負債は、発生源を減らす対策を →仕訳フォーマット機能の開発 35 まとめ 

株式会社TOKIUM 東 京 本 社 ｜ 〒104-0061　東京都中央区銀座 6 丁目18-2 野村不動産銀座ビル12階 西日本営業所 ｜ 〒550-0015　大阪府大阪市西区南堀江 1 丁目 1 番14号 四ツ橋中埜ビル 7 階 36 URL : https://www.keihi.com/company