「銀行明細のCSVを毎朝ダウンロードして会計システムに取り込む」「経費精算の仕訳を毎月手で転記する」。こうした作業に時間を取られていませんか。
この記事では、会計システムのAPI連携を実務の手順に沿って解説します。連携前の棚卸し・マッピング表・テスト項目・運用ルールまで、経理担当者が準備すべきことをまとめました。
ティーAPI連携は情シスだけの仕事ではありません。仕訳のルールを決めるのは経理です。
- API連携とCSV連携の違いと、自動化できる経理業務
- 連携前の業務の棚卸しと、勘定科目・税区分などのマッピング表の作り方
- 導入の5ステップとテストで確認すべき項目
- エラー対応・締め後の制御・APIキー管理などの運用ルールと月次の確認作業
- 経理と情シスの役割分担、よくある失敗とチェックリスト
会計システムのAPI連携とは？CSV連携との違い
APIは、システム同士がデータをやり取りするための「窓口」です。経費精算システムが会計システムの窓口に「この仕訳を登録して」と依頼すると、人の手を介さずに仕訳が登録されます。
用語は次の3つだけ押さえれば十分です。
- REST API：URLとHTTPの仕組みでデータを送受信する方式。現在の主流です
- JSON：「項目名：値」の形でデータを表す書式。CSVの代わりにやり取りされます
- APIキー・OAuth 2.0：連携先を認証する仕組み。APIキーは合鍵、OAuth 2.0はパスワードを渡さずに利用を許可する方式です
CSV連携との比較
| 比較項目 | CSV連携 | API連携 |
|---|---|---|
| 手作業 | 出力・加工・取込みを人が行う | 設定後は原則として自動 |
| 頻度 | 日次・月次などのまとめ処理 | 随時、または数分〜1日単位 |
| エラー | 列ずれ・文字化け・二重取込み | 通信エラー・認証切れ・項目不一致 |
| リアルタイム性 | 取り込むまで反映されない | 発生後すぐに反映できる |
| 向いている場面 | 件数が少ない、連携先がAPI非対応 | 件数が多い、毎日発生する |
API連携は手作業が減る一方、エラーに気づきにくいという弱点があります。CSVなら取込み画面で目にする異常も、自動化すると誰も見ません。このため、本記事の後半で解説する運用ルールが欠かせません。
ティーCSVの取込みで毎月起きていた列ずれや二重取込みも、API連携ならかなり減らせます。
API連携で自動化できる経理業務
会計システムとAPIでつながる代表的な業務は次のとおりです。対応状況は製品によって異なるため、必ず各社の公式ドキュメントで確認してください。
| 業務 | 連携の内容 | 経理の効果 |
|---|---|---|
| 銀行明細の取得 | 入出金明細を自動取得し、仕訳候補を作成 | 明細の手入力・CSV取込みが不要 |
| クレジットカード明細 | 利用明細を取得し、経費仕訳の候補を作成 | カード利用の計上漏れを防ぐ |
| 経費精算・請求書受領 | 承認済みの経費や請求書から仕訳を登録 | 転記作業と転記ミスがなくなる |
| 販売管理・給与 | 売上・給与の集計結果を仕訳で連携 | 月次の取込み作業を短縮 |
| 債権の消込 | 入金明細と請求データを照合 | 消込の手作業を減らす |
| BI・Excel・スプレッドシート | 試算表や仕訳データを取得 | 予実管理や分析レポートを自動更新 |
| 電子インボイス | Peppolで受け取った請求データを取り込む | 請求書の入力作業を減らす |
銀行APIと電子決済等代行業者
銀行明細の連携は、2017年の銀行法改正で整備された仕組みが土台です。会計サービスなどが預金者の委託を受けて銀行から口座情報を取得する業務は電子決済等代行業と定義され、営むには登録が必要です（銀行法第2条第21項・第52条の61の2）。改正法の附則では、銀行に対し、利用者のIDやパスワードを代行業者に渡さなくても済む体制の整備（いわゆるオープンAPI）が努力義務とされました。
銀行連携は「どの方式でつながるか」を確認する
経理としては、銀行と会計サービスの間で連携契約があるか、自社側でどんな利用申込みや承認が必要かを確認しておきましょう。法人口座は、銀行側の申込みや管理者の承認が必要になることが多い点にも注意が必要です。
Peppolによる電子インボイス
Peppolは電子インボイスの国際的な標準仕様です。デジタル庁がJapan Peppol Authorityとして、日本の標準仕様「JP PINT」を管理しています。請求データをそのまま受け取れるため、会計システムへの取込みと相性のよい仕組みです。
ティー銀行明細とカード明細の連携だけでも、毎朝の作業がかなり減りますよ。
連携前の準備｜業務の棚卸しとマッピング表の作り方
API連携の成否は、連携前の準備でほぼ決まります。まず、現在の手作業を棚卸しします。
- どのシステムから、どのデータを会計システムへ入れているか
- 頻度（日次・月次）と1回あたりの件数・作業時間
- 誰が加工・確認しているか、承認はどこで行っているか
- エラーや修正がよく起きる箇所はどこか
棚卸しで効果の大きい業務を選んだら、連携元と会計システムのコードを対応させる「マッピング表」を作ります。
| 項目 | 連携元（例：経費精算） | 会計システム | 決めておくこと |
|---|---|---|---|
| 勘定科目 | 経費区分「交通費」 | 旅費交通費（コード6110） | 1対1か、条件で分岐するか |
| 補助科目 | 支払先・プロジェクト | 補助科目コード | 未登録時の扱い |
| 部門 | 申請者の所属 | 部門コード | 組織変更時の切替日 |
| 税区分 | 「課税10％」など | 課税仕入10％（適格）など | インボイスの有無で分けるか |
| 摘要 | 申請内容・支払先 | 摘要欄 | 文字数の上限と記載ルール |
科目コードなどは仮の例です。とくに税区分は、連携元と会計システムで分類の細かさが違うことが多く、インボイスの登録番号の有無で区分を分けるかも決めておく必要があります。
仕訳データの項目例
経費精算システムから会計システムへ送る仕訳データ（JSON）の項目は、たとえば次のようになります。
| 項目名（例） | 値の例 | ポイント |
|---|---|---|
| transaction_date | 2026-10-15 | 計上日。締め済み期間なら登録を止める |
| account_code | 6110 | 会計システム側の勘定科目コード |
| amount | 11000 | 税込か税抜かを統一する |
| tax_code | 課税仕入10％ | マッピング表に従って変換 |
| department_code | D100 | 部門コード |
| description | 10/15 東京⇔大阪 新幹線代 | 摘要 |
| external_id | EXP-2026-001234 | 連携元の一意な番号。二重計上の防止に使う |
項目名は製品ごとに異なりますが、連携元の一意な番号（external_id）を持たせるかどうかは重要です。同じ番号のデータが再送されても、二重に計上しない仕組みを作れます。
マッピング表は経理が作って承認する
マッピング表は仕訳のルールそのものです。情シスやベンダー任せにせず、経理が作成し、変更時は経理責任者が承認する運用にしましょう。
ティーマッピング表は、科目の追加や組織変更のたびに更新が必要な「生きた資料」です。
API連携の導入ステップとテスト項目
導入は次の5ステップで進めます。
手作業の流れ・件数・作業時間を整理し、連携する業務と優先順位を決めます。
API仕様書で取得・登録できる項目、認証方式、呼び出し回数の上限を確認し、マッピング表を作ります。
テスト環境や検証用の会社データで、正常系とエラー系の両方を試します。
1〜2か月は従来の手作業と並行して動かし、結果を突き合わせます。
エラー通知・月次の照合・APIキーの管理など、運用ルールに沿って定期的に確認します。
テストで確認すべき項目
| テスト項目 | 確認内容 |
|---|---|
| 正常な仕訳 | 金額・科目・税区分・部門がマッピング表どおりか |
| マスタ未登録 | 新しい部門や科目のデータが来たときにエラーで止まるか |
| 再送 | 同じデータを2回送っても二重計上されないか |
| 締め済み期間 | 締め後の日付のデータが登録されずに通知されるか |
| 修正・取消 | 連携元で取り消したデータが会計側でどう扱われるか |
| 件数と合計額 | 連携元の件数・合計額と会計側の件数・合計額が一致するか |
正常系だけでなく、「失敗したときにどうなるか」を確認するのがテストの本番です。並行稼働中は、手作業の仕訳とAPIの仕訳を件数・金額で突き合わせましょう。
ティー切替の時期は期首がおすすめです。期中に切り替えると、比較や締めの手順が複雑になります。
運用ルールと月次の確認作業｜エラー・締め後・APIキー管理
API連携は、動き始めてからが本番です。最低限、次の運用ルールを文書にしておきます。
| ルール | 内容 |
|---|---|
| エラー対応 | エラー通知の受け手、原因の切り分け、修正後の再送手順を決める |
| 二重計上の防止 | 一意キーで重複を判定し、手作業での再登録を禁止する |
| 締め後の制御 | 締め済み期間への登録を止め、翌月計上か締め解除かの判断者を決める |
| APIキー・権限 | 発行者と用途を台帳化し、退職・異動・委託終了時に無効化する |
| 仕様変更 | ベンダーのAPIバージョン変更の告知を確認し、影響をテストする |
| 呼び出し回数の上限（レート制限） | 上限を確認し、大量データは分割・夜間処理にする |
APIキーは「誰の鍵か」がわからなくなる
担当者個人のアカウントで発行したAPIキーは、退職後も使えてしまうことがあります。連携用のアカウントを分け、委託先に渡したキーも含めて定期的に棚卸ししましょう。
月次の確認作業
| タイミング | 確認すること |
|---|---|
| 毎日 | エラー通知の有無、未処理データの件数 |
| 月次締め前 | 連携元と会計の件数・合計額の照合、仮勘定・未登録マスタの残高 |
| 月次締め後 | 締め後に届いたデータの扱い、手修正した仕訳の記録 |
| 四半期ごと | APIキー・連携アカウントの棚卸し、マッピング表の見直し |
電子帳簿保存法と内部統制への対応
API経由で登録された仕訳も、会計システムの帳簿データです。優良な電子帳簿の要件には訂正・削除の履歴の確保や検索機能の確保などがあり、連携方法によって要件の満たし方が変わることもあります。適用する要件は、国税庁の資料と会計システムの対応状況で確認してください。
上場企業では、IT全般統制（ITGC）のアクセス管理と変更管理も対象になります。誰がAPIキーを発行したか、マッピング表やプログラムを誰がいつ変更したかを、ログと承認記録で示せるようにしておきましょう。
自動連携された仕訳も「承認済み」とは限らない
連携元で承認されたデータでも、会計上の科目や税区分が正しいとは限りません。月次で連携仕訳のサンプルを抽出し、経理が内容を確認する手順を残しておきましょう。
ティー監査で「この仕訳はどこから来たの？」と聞かれても答えられるよう、連携の記録は残しておきましょう。
経理と情シスの役割分担とよくある失敗
API連携は、経理と情シス（またはベンダー）の分担があいまいなまま進むと失敗します。
| 領域 | 経理がやること | 情シス・ベンダーに任せること |
|---|---|---|
| 要件 | 連携する業務・仕訳ルールの決定 | API仕様の調査、実現方法の提案 |
| 設定 | マッピング表の作成・承認 | 接続設定、プログラム・連携ツールの構築 |
| テスト | 仕訳結果の確認、テストケースの作成 | 通信・エラー処理の検証 |
| 運用 | 月次の照合、エラーの業務判断 | 障害対応、APIキーの発行・失効 |
ノーコード連携ツール（iPaaS）という選択肢
プログラムを書かずに、画面上の設定でシステム同士をつなぐサービスをiPaaSと呼びます。小さく始めやすい反面、経理が作った連携が「誰も中身を説明できない」状態になりがちです。設定内容を文書化し、変更は承認を得てから行うルールにしましょう。
よくある失敗と対策
| よくある失敗 | 対策 |
|---|---|
| 税区分の対応が粗く、消費税の集計が合わない | マッピング表で税区分を細かく定義する |
| 通信エラーの再送で二重計上 | 一意キーで重複を判定する |
| 締め後に前月の仕訳が入る | 締め済み期間の登録を止める |
| 担当者の退職で連携が止まる | 連携用アカウントと手順書を用意する |
| API仕様変更に気づかず連携が停止 | ベンダーの告知を確認する担当を決める |
API連携の導入前チェックリスト
- 手作業の流れ・件数・作業時間を棚卸ししたか
- 勘定科目・補助科目・部門・税区分のマッピング表を経理が承認したか
- 一意キーによる二重計上の防止を確認したか
- マスタ未登録・再送・締め後のテストを行ったか
- 並行稼働で件数・金額の一致を確認したか
- エラー通知の受け手と再送手順を決めたか
- APIキーの台帳と失効手順を作ったか
ティーまずは銀行明細や経費精算など、効果が見えやすい業務から小さく始めるのがコツです。
まとめ
- API連携はシステム同士の窓口で、CSV連携より手作業は減るがエラーに気づきにくい
- 連携前に業務を棚卸しし、勘定科目・補助科目・部門・税区分のマッピング表を経理が作る
- テストは正常系だけでなく、マスタ未登録・再送・締め後のケースまで確認する
- エラー対応・二重計上の防止・締め後の制御・APIキー管理を運用ルールとして文書化する
- 月次で件数・合計額を照合し、電子帳簿保存法と内部統制の観点からログを残す
まずは自社の手作業を棚卸しして、連携の候補を書き出すところから始めてみてください。
ティー仕組みは情シスと作り、ルールは経理が持つ。これがAPI連携を長く安定して使うコツです。
