会計APIとは何か?プラットフォーム開発者のためのプレーン英語ガイド
会計APIの分かりやすい定義、税務APIや決済APIとの違い、そして連携実装前に確認すべきポイントを解説します。
会計APIとは、あるプログラムが別のプログラムの帳簿管理を行えるようにするインターフェースのことです。自社のソフトウェアからHTTP経由で財務イベントを送信すると、APIがそのイベントを勘定科目に基づくバランスの取れた複式簿記の仕訳に変換し、改ざんされないよう保存し、税務処理を適用した上で、同じインターフェースを通じてレポート、帳票、エクスポートデータを提供します。
この定義が仕事の大部分を担っています。この記事の残りの部分はすべて、この定義から導かれる結果にすぎません。
1文での定義
会計APIは、アプリケーションから財務イベントを受け取り、それぞれをバランスの取れた仕訳に変換し、税務処理や裏付け証憑とともに変更不可(イミュータブル)な形で保存し、生成された元帳、帳票、レポートをプログラム可能なエンドポイントとして公開します。
あるプロダクトが自らを会計APIと称していながら仕訳を生成しないのであれば、それは優れたネーミングを持つ別の何かです。それが悪いわけではありません。単に、これからあなたが行おうとする仕事には適していないということです。
会計APIではないもの
よく似た4つのプロダクトカテゴリが、多くの場合プロジェクトの終盤になって会計APIと混同されます。
| カテゴリ | 機能 | 機能しないこと |
|---|---|---|
| 税額計算 API | 取引に対する正確な税率や税額を返す | 帳簿の記帳、または保存期間にわたる判断の根拠となる証憑の保存 |
| 決済 API | 当事者間で資金を移動させ、その移動について報告する | 決済から出金までの間に発生した手数料収入、未払消費税、または出品者に対する債務の記録 |
| 統合(アグリゲーター)API | 顧客が既存で使用している会計ソフト内のデータの読み書きを行う | 記録のシステム(system of record)として機能すること。帳簿は各顧客がすでに使用しているツール上に存在します |
| レポート / BI API | 既存の元帳から数値を読み取り、それを視覚化する | 数値の導出元となる仕訳を作成すること |
これらはいずれも実際のユースケースにおいて重要です。プラットフォームが記録のシステム(system of record)となる必要がある場合、それらの代替としてではなく、その下層基盤として会計APIが必要になります。
会計APIが備えなければならない5つの機能
1. 貸借バランスの取れた仕訳の記録。 すべてのイベントは、借方と貸方の合計が一致する仕訳に変換されます。15%の手数料を取るマーケットプレイスで買い手が100ユーロを支払った場合、仕訳は決済クリアリング口座に100ユーロの借方、出品者未払金に85ユーロの貸方、そして手数料収益に15%の貸方を立てます。これは形式的な記帳の儀式ではありません。レポートに達する前に一連の統合バグを捕捉するための構造的なチェックです。
2. 履歴の保持。 一度確定(ポスト)された仕訳は編集されません。誤りは、修正仕訳とそれ打ち消す逆仕訳のペアによって修正され、両方とも元の仕訳にリンクされます。締めの完了した月はロックされ、その期間に新しい日付の仕訳を計上することはできません。
3. 税務処理の解決。 EU域内取引の場合、これは供給地(place of supply)、リバースチャージ方式、公式の登録簿で検証されたVAT番号、およびその判断を正当化した証憑を意味します。これらは計算後に破棄されるのではなく、すべて取引とともに保存されます。
4. 外部資金との照合。 銀行の明細と一度も突き合わせられない帳簿は、推測にすぎません。APIは、明細やプロバイダーの精算データを取り込み、記録された内容と照合(リコンシエーション)できなければなりません。
5. エクスポート。 人間の会計士や税務当局が受け入れる形式での、レポート、帳票、監査ファイルの出力。
最初の3つを満たしていても最後の2つを満たさないプロダクトでは、担当者が毎月スプレッドシートでの作業を行うことになります。
実際のAPIコールの例
メカニズムは会計処理よりもシンプルです。NordletのAPIでは、すべての操作が予測可能な形状を持つRPCスタイルのPOSTです。
POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>
売上請求書を作成し、その後発行(issue)します。発行こそが会計処理が行われる瞬間です。ドキュメントに連番が付与され、バランスの取れた仕訳が起票され、VAT行がそれとともに記録されます。プラットフォーム側で借方や貸方を手動で組み立てる必要はありません。
このスニペット内の3つの詳細事項は、エンドポイント名よりも重要です。
- キーのスコープ。 キーには
sales:writeなどの権限が付与されているため、連携機能には必要なアクセス権のみが与えられます。 - べき等キー(Idempotency key)。 同じペイロードで同じリクエストを再試行した場合、2つ目の請求書が作成されるのではなく、保存されたレスポンスが返されます。異なるペイロードで同じキーを送信した場合、静かに受け入れられるのではなく、
idempotency_key_reuseエラーで拒否されます。 - 金額の文字列表現。 金額は浮動小数点数ではなく、10進数の文字列として扱われます。浮動小数点数は、期末になって表面化するような丸め誤差を引き起こすためです。
アーキテクチャにおける位置づけ
アプリケーションはフロントエンドおよびビジネスイベントの発生源にとどまります。会計APIは、その背後にある財務上の記録のシステム(system of record)となります。通常、次のようなフローになります。
- プロダクト内でイベント(注文、返金、出金、サブスクリプションの更新など)が発生します。
- バックエンドから、イベントとべき等キーを指定して会計APIを呼び出します。
- APIが仕訳を起票し、VATを適用し、自社のレコードに紐づけて保存するための識別子を返します。
sale_invoice.paidなどのウェブフックが状態の変化をシステムに通知するため、ポーリングで確認するのではなくイベントにリアクトできます。- バンクフィードや明細のインポートを通じて銀行取引データが到着し、記録されたドキュメントと照合されます。
- 期末には同じデータからレポートや税務帳簿が生成され、締められた月がロックされます。
このリストのどの作業においても、人間が会計ソフトを開く必要はありません。それが、このカテゴリの存在意義です。
代替手段との比較
| アプローチ | 導入時の工数 | 監査における立ち位置 | 取引量の増加へのスケーラビリティ |
|---|---|---|---|
| スプレッドシートと手動入力 | 最小 | 弱い。履歴を編集可能 | いいえ |
| 会計ソフトとCSVエクスポート | 低い | 運用規律に完全に依存する | 乏しい。誰かがファイルをインポートする必要がある |
| 顧客ごとの既存帳簿に対するアグリゲーターAPI | 中程度 | 顧客のツール側の仕様に依存する | はい。ただし自社でレコードを所有できない |
| 組み込み会計API | 中程度 | 元帳が変更不可であり期間ロックされていれば強い | はい |
| 自社製元帳の開発 | 最大 | コントロール機構も自作した場合にのみ強い | はい。ただし永久に保守が必要 |
自社で開発することは、一部のチームにとって正当な選択肢です。マーケットプレイス向けの内製と外部調達のガイドで詳しく解説しています。
連携実装前に確認すべきポイント
- 残高は導出されるか、それとも保存されるか。 出品者の残高が仕訳行に対するクエリ結果なのか、それとも誰かが更新するカラムなのかを確認してください。監査に耐えうるのはそのうちの片方だけです。
- 再試行(リトライ)時にはどうなるか。 同じリクエストを2回送信し、生成される仕訳の数を数えてみてください。
- 起票済みの仕訳を編集できるか。 答えは「ノー」であるべきであり、文書化された修正手順が存在するはずです。
- ロックされた期間への起票は実際に拒否されるか。 サンド環境で試してみてください。Nordletでは、ロックされた期間内の日付を持つ起票に対して
409を返します。 - 金額はどのように表現されているか。 10進数の文字列か、最小通貨単位の整数か。浮動小数点数は決して使用しないでください。
- 監査証跡には何が含まれているか。 実行者、アクション、エンティティ、および変更内容そのものが、ログファイルに埋もれることなくクエリ可能であるか。
- レートリミット(利用制限)はどうなっているか。 NordletではAPIキーあたり毎分300リクエストを許可しており、残りの制限数をレスポンスヘッダーで返します。数値が何であれ、同期処理を設計する前に把握しておいてください。
- データをどのように取り出せるか。 会計士に提出できるフォーマットでのレポート、帳票、仕訳データ。
これらの項目はすべて、サンドボックス企業環境に対して午後の時間だけでテスト可能です。ベンダーの機能リストは証拠になりませんが、再現可能なテストは証拠になります。
FAQ
会計APIは会計ソフトと同じものですか?
インターフェースが移行した会計ソフトです。従来の会計ソフトは人間を元帳の前に座らせますが、会計APIはあなたのコードをそこに座らせます。根底にある義務、複式簿記の構造、レポートは同じです。
会計APIを使用する場合でも、会計士は依然として必要ですか?
はい。APIは記録、計算、レポートを自動化します。勘定科目の判断、引当金の計上、特定の契約の処理方法についての判断を下すわけではなく、ほとんどの国において、法的な決算書への署名や提出を肩代わりするものでもありません。
複式簿記を理解していなくても会計 API を使用できますか?
部分的には可能です。優れたAPIは、請求書などのビジネスドキュメントから仕訳を自動的に構築します。ただし、レポートを読み解いたり、監査人に残高を説明したりする際には、勘定科目の意味を理解している必要があります。
会計 API と元帳(レジャー)API の違いは何ですか?
元帳APIは、勘定科目間におけるバランスの取れた資金の移動を記録します。会計APIはそれらに加えて、法的な連番が付与された帳票、VAT処理、税務帳簿、固定資産、期末締め、および管轄官庁が求めるレポートという法定レイヤーを追加します。すべての会計APIには元帳が含まれていますが、すべての元帳が会計システムであるとは限りません。
連携の実装にはどれくらいの時間がかかりますか?
顧客の作成、請求書の発行、入金の受領、仕訳の確認という最初の動作フローであれば、型付きSDKとサンドボックス環境を使用して、数週間ではなく数日で計画できます。返金、修正、多通貨、照合、期末締めを網羅する本番連携はより大規模な作業となり、その正確な見積もりは、プロダクトが実際に生成するそれらのユースケースの数に依存します。