承認データを仕訳にする|会計システム連携の設計
承認システムと会計システムをつなぐとき、実際に決めるのは勘定科目・部門/プロジェクト・税区分・計上タイミングの4つです。勘定科目を誰が決めるかの3方式とそれぞれの崩れ方、インボイス制度で増えた判定、API連携とCSV取り込みの分かれ目、月をまたぐ申請の扱いまでを整理します。
ワークフローシステムの紹介ページには、たいてい「会計システムと連携できます」と書かれています。当サイトの記事でも20本が同じことに触れています。
ところが導入して最初の月次で必ず止まるのは、連携そのものではありません。**「この申請は、どの勘定科目で、どの部門に、どの税区分で、いつ計上するのか」**が決まっていないことです。連携の設定は半日で終わっても、この4つを決めるのに数週間かかる——という順序が実態に近いと思います。
本記事は、その4つをどう決めるかに絞ります。承認フロー側の設計は承認者マスタの設計|組織改編で壊れない承認ルート、経費申請アプリ側の自動化はkintoneで経費申請を自動化する方法|標準機能の限界とはをご覧ください。
この記事の要点
- 会計連携で決めるのは、勘定科目・部門/プロジェクト・税区分・計上タイミングの4つ。連携方式を選ぶのはその後。
- 勘定科目を誰が決めるかで3方式に分かれる。申請者に選ばせる方式は、選択肢が増えた時点で精度が落ちる。
- インボイス制度で税区分の判定が増えた。申請時にどこまで持つかを決めないと、経理側の確認作業が残る。
- API連携とCSV取り込みの分かれ目は件数ではなく、差し戻しが起きるかどうか。
- 締め日と承認日のズレは仕様として決める。放置すると月次のたびに個別判断になる。
会計連携で実際に決める4つのこと
連携作業そのものはコネクタの設定です。難しいのは、申請データに何を持たせれば仕訳になるのかという設計のほうです。
| 決めること | 何を決めるのか | 決めないとどうなるか |
|---|---|---|
| 勘定科目 | 申請内容から科目をどう決めるか | 経理が1件ずつ付け直す |
| 部門・プロジェクト | 費用をどの単位に紐づけるか | 部門別の実績が出せない |
| 税区分 | 税率と適格請求書の区別をどう判定するか | 仕入税額控除の集計が手作業になる |
| 計上タイミング | 承認日・実行日・請求日のどれで計上するか | 月をまたぐ申請のたびに個別判断 |
この4つが決まっていれば、連携方式(API/CSV)は後からでも変えられます。逆に、4つを決めずに連携だけ先に作ると、自動で流れ込んだ仕訳を経理が全部直すという状態になります。
勘定科目を誰が決めるか(3方式)
最も揉めるのがここです。方式は3つあり、組織の規模と科目数で選び方が変わります。
方式1:申請者に選ばせる
申請フォームに勘定科目のプルダウンを置きます。実装は最も簡単ですが、科目数が増えた時点で精度が落ちます。申請者は経理の人間ではないので、「消耗品費」と「事務用品費」の違いを判断できません。結果として、経理が後から直す件数が減りません。
科目を10個程度に絞り込める組織であれば成立します。それ以上になるなら次の方式を検討してください。
方式2:申請カテゴリから自動判定する
申請者には業務の言葉で選ばせ(「PC周辺機器」「出張の宿泊」「書籍」など)、カテゴリと科目の対応表を裏に持ちます。申請者は判断を求められず、経理は対応表だけを管理すればよくなります。
実務ではこの方式が最も安定します。ポイントは対応表を経理が直接編集できる場所に置くことです。システムの設定ファイルに埋め込むと、科目の見直しのたびに情シスが呼ばれます。考え方は承認者マスタの設計と同じで、判断の表をシステム本体から切り離します。
方式3:経理が最後にまとめて直す
申請時には科目を持たせず、経理が仕訳を起こす段階で決めます。件数が少なければ現実的ですが、自動化の効果はほぼ得られません。移行期の暫定策と位置づけるべきで、恒久運用にするなら方式2へ寄せてください。
部門・プロジェクトをどう持つか
勘定科目より見落とされやすいのがこちらです。決めるのは「誰の費用にするか」という帰属のルールです。
- 申請者の所属部門にするのか、利用部門にするのか(他部門のために買った備品はどちらか)
- プロジェクト単位の原価管理をしている場合、申請時にプロジェクトコードを必須にするか
- 期中の組織改編で部門コードが変わったとき、過去の申請をどう扱うか
3つ目は特に決めておいてください。組織改編のたびに過去データの部門が消えると、前年同月比が出せなくなります。申請レコードにはそのときの部門コードを書き込んで残すのが原則です。
税区分はインボイス制度で判定が増えた
税区分は以前なら税率(10%/8%)の区別で済みましたが、インボイス制度以降は判定項目が増えています。
- 取引先が適格請求書発行事業者かどうか
- 適格請求書の記載要件を満たしているか
- 免税事業者からの仕入れに対する経過措置の扱い
経過措置は段階的に縮小される仕組みで、控除できる割合が期間によって変わります。2026年10月以降はその割合がさらに下がる段階に入るため、この時期をまたぐ申請の扱いは事前に経理と確認しておいてください。自社の取引にどう適用されるかは顧問税理士にご確認ください。
実装上の判断は「申請時にどこまで持つか」です。取引先マスタに登録番号を持たせて自動判定できるなら申請時に確定させ、購買サイト経由で都度取引先が変わる領域は請求書の受領後に確定させる、という分け方が現実的です。すべてを申請時に確定させようとすると、申請者の入力項目が増えて定着しません。
計上タイミングは仕様として決める
「いつの費用にするか」の候補は3つあります。
| 基準 | 内容 | 向く場面 |
|---|---|---|
| 承認日 | 承認が下りた日で計上 | 承認と実行がほぼ同時の運用 |
| 実行日 | 発注・購買が実行された日 | 承認後に実行がある購買・出張 |
| 請求日 | 請求書を受け取った日 | 月次でまとめて請求が来る取引 |
購買や出張のように承認のあとに実行がある業務では、実行日基準が実態に合います。承認日で計上すると、承認だけされて実行されなかった申請まで費用になってしまいます。
月をまたぐケース(月末に承認、翌月頭に実行)の扱いも先に決めてください。ここを決めずに運用を始めると、月次のたびに「これはどっち月か」の個別判断が発生します。
API連携とCSV取り込みの分かれ目
「件数が多いからAPI」と考えがちですが、実務での分かれ目は別のところにあります。
判断軸は「差し戻しが起きるか」
CSV取り込みは、取り込む前に人が中身を見られるのが利点です。科目や部門の判定に迷いが残っている段階では、この確認の余地が効きます。一方、判定が安定していて差し戻しがほぼ起きないなら、API連携で都度流すほうが締め作業が平準化します。
導入初期はCSVで運用して判定ルールを固め、安定してからAPIへ移す——という順序が安全です。最初からAPIにすると、間違った仕訳が自動で流れ込み、会計側で取り消す作業が発生します。
どちらでも、突合は残る
見落とされやすい点ですが、連携方式を変えても申請システムと会計システムが別である限り、突合作業はなくなりません。金額が一致しているか、漏れがないかの確認は毎月発生します。
突合そのものをなくすには、申請・承認・実行・経費が同じ記録として残る必要があります。この構造についてはkintoneの経費精算は承認後が詰まる|購買・出張との連携で扱っています。
1Approvalでの実現方法
1Approvalでは、購買や出張が実行された時点で、その内容がそのまま経費データとして生成されます。申請レコードと実行結果が同じデータなので、突合の対象が発生しません。
生成される経費データには、申請時に確定した部門・カテゴリの情報が含まれるため、会計・経費精算システムへの連携でも科目や部門の付け直しが要りません。複数サービス・複数取引先の利用料は月1回の法人一括請求にまとまるため、支払側の処理も件数ではなく契約単位になります。
一般的なBTMや購買サービスでは、請求情報は会計システム、経費情報は経費精算システムと別々に処理されがちですが、1Approvalでは請求情報と経費情報を一括で確認できます。機能の詳細は1Approval for Microsoft 365のページ、購買側の設計はMicrosoft 365で購買申請を自動化する設計の勘所をご覧ください。
よくある質問(FAQ)
勘定科目は申請者に選ばせるべきですか?
科目数が10個程度に収まるなら成立しますが、それ以上なら申請カテゴリからの自動判定に寄せてください。申請者は経理の判断基準を持っていないため、科目が増えるほど誤りが増え、経理の修正件数が減りません。
会計システムとの連携はAPIのほうが良いですか?
判定ルールが安定してからであればAPIが有利です。導入初期は、取り込み前に中身を確認できるCSVのほうが安全です。いきなりAPIにすると、誤った仕訳が自動で流れ込み、会計側で取り消す作業が発生します。
月末に承認して翌月に発注した場合、どちらの月の費用になりますか?
自社で基準を決める必要があります。購買や出張のように承認後に実行がある業務では、実行日基準が実態に合います。重要なのはどちらを選ぶかより、基準を決めて例外を作らないことです。基準がないと月次のたびに個別判断になります。
インボイス対応は承認システム側で持つべきですか?
取引先が固定されている領域(継続取引、購買サイト経由)は取引先マスタで持たせて自動判定できます。都度取引先が変わる領域は、請求書の受領後に確定させるほうが現実的です。すべてを申請時に確定させようとすると入力項目が増え、申請者が使わなくなります。
連携すれば経理の突合作業はなくなりますか?
申請システムと会計システムが別である限り、なくなりません。減るのは転記の手間で、金額の一致や漏れの確認は残ります。突合そのものをなくすには、申請・実行・経費が同じ記録として残る構造が必要です。
まとめ|連携の前に、4つの決めごとを終わらせる
会計連携でつまずく原因は、たいてい技術ではなく決めごとの不足です。勘定科目・部門/プロジェクト・税区分・計上タイミングの4つが決まっていれば、連携方式は後から変えられます。
特に勘定科目は、申請者に判断させない設計にしてください。業務の言葉で選ばせ、科目との対応表は経理が直接編集できる場所に置く。この形にしておくと、科目の見直しのたびに情シスが呼ばれる状態を避けられます。
まずは直近1か月の申請を10件ほど抜き出し、それぞれ4つの項目が申請データだけで決まるかを確認してみてください。決まらない項目が、いま経理が手で埋めている部分です。
監修
伏見 匡矩
株式会社エイチ 代表取締役社長
株式会社エイチ代表取締役社長。出張手配・会場手配の実務を起点に、申請・承認から購買実行までを一体で扱う1Approvalを立ち上げ、事業責任者としてプロダクト設計に携わる。承認されたあとの購買・手配をどう自動化するかという観点から、Microsoft 365を基盤とした申請・承認の設計を扱っている。
経歴・運営者情報を見るこの記事のテーマ
あわせて読みたい
スプレッドシートの経費精算管理が破綻する理由
Googleスプレッドシートで経費精算を管理している組織が、どの規模で何に詰まるのかを整理します。同時編集と行ずれ、承認済みデータの改ざん、証憑と申請の紐付け、電子帳簿保存法への対応という4つの論点と、移行を検討すべきタイミングの見極め方、精算そのものを減らす方向までを解説します。
差し戻しはなぜ減らないのか|手戻りを設計で潰す
申請の差し戻しが減らないのは申請者の不注意ではなく、承認者が指摘しにくい・同じ項目を複数部署が重複チェックしている・何を直すか書かれていないという3つの構造によるものです。差し戻しを4種類に分け、どこで止めるべきかを整理し、チェックの分担と入力時点の制御で手戻りを減らす設計をまとめます。
Power Automateで経費精算を自動化する方法と注意点
Power Automateで経費精算の申請・承認・会計登録を自動化する手順とメリット、ライセンス制限や法令対応の注意点、専用ワークフローとの使い分けを解説します。
出張旅費の統制|手配を個人任せにしない設計
出張旅費規程を管理する部門はあっても、出張旅費の統制を管理する部門がない企業は少なくありません。精算システムだけ導入しても手配が個人任せなら価格の妥当性も安全管理も担保できない理由と、規程・申請時判定・手配導線という3段階で統制をかける設計を整理します。
※記載されている会社名・製品名は各社の商標または登録商標です。