QuickBooksの代替品：APIが必要であり、アプリではない場合

プラットフォームチームがQuickBooksの枠を超えてしまう理由、「APIであってアプリではない」という要件の本質、そしてユースケースに適合する代替品の選び方。

QuickBooks Onlineは、豊富な導入実績、OAuth 2.0 REST API、Webhooks、そして充実した開発者エコシステムを備えた、優れた中小企業向け会計アプリケーションです。代替品を探しているチームのほとんどは、アプリケーションとして不満を感じているわけではありません。彼らが直面している問題は、人間ではなくソフトウェアが記帳を行う必要がある一方で、QuickBooksは人間が操作することを前提に設計されているという点にあります。

この記事では、このミスマッチと、その代わりに何を使用すべきかについて解説します。もしあなたが簿記ソフトを選定している中小企業であれば、QuickBooksが最適な選択肢であり、ここでの内容は当てはまらない可能性が高いでしょう。

ミスマッチが表面化する領域

1つのAPI接続は1つの会社ファイルに対応する。 QuickBooksのAPIのスコープは、レルム（realm）で識別される1つの会社に限定されています。300社のセラー事業者の帳簿を必要とするプラットフォームは、内部に300社を内包する1つのアカウントではなく、300個の接続と300個のサブスクリプションを管理することになります。通常、この単一の事実によって評価は終了します。

APIはアプリケーションの付随物であり、プロダクトそのものではない。 機能はインターフェースに先に追加され、APIには独自のスケジュールで反映されます。統合機能全体が呼び出し可能な機能に依存している場合、「アプリで利用できる」ということと「APIで利用できる」ということは同義ではありません。

スロットリングはトランザクションのフローではなく同期を想定して設計されている。 QuickBooksの制限は、会社ごとに1分あたり500リクエストと言われており、バッチおよびレポートのエンドポイントにはさらに厳しい制限が課されます（正確な数値はIntuitの公式開発者ドキュメントをご確認ください）。これは1社のレコードを同期するには十分ですが、プラットフォームが数千社の事業者のエントリをリアルタイムで投稿する場合には話が変わってきます。

EU域内の国境を越えた税務処理にギャップがある。 Intuitの公式サポート資料によれば、QuickBooksにはIOSS VATを記録するための標準手順が存在しないため、ユーザーに対して簿記担当者や会計士に相談するよう案内しています。EU域内で販売を行うプラットフォームにとって、遠隔地販売（distance-selling）やワンストップショップ（OSS）の処理は決して例外的なケースではないため、構築の前に特定の国における要件を確認する価値があります。

これらはすべて欠陥ではありません。簿記担当者を雇用する企業向けに優れたアプリケーションを構築した結果生じる特性です。

「APIであってアプリではない」が実際に求めるもの

代替品を比較する前に、プラットフォームチームが実際に求めているものを明確にしておくことが役立ちます。「APIを備えている」という条件は、ほとんどすべての製品が満たしているためです。

完全なカバレッジ。 アプリケーションが実行できるすべての操作を呼び出し可能であること。Nordletのこの点における方針は、アプリ専用のエンドポイントは存在しないというものであり、インターフェースは外部の呼び出し元が取得するのと同じエンドポイント上で動作します。
1つのアカウントの下でのマルチカンパニー（複数企業）対応。 多数のサブスクリプションを契約することなく、多数のエンティティの帳簿を管理できること。
冪等性（Idempotency）のある書き込み。 リトライされたリクエストによって、2つ目の請求書や重複した仕訳が作成されないこと。
イベントの配信。 状態の変化をトリガーとしてWebhooksが発火し、システムがポーリングではなくリアクティブに応答できること。
厳格に強制される会計上の不変条件。 貸借不一致の仕訳は拒否され、締め期間はロックされ、転記済みのドキュメントは編集不能であること。
画面ではなくデータとしての税務。 税率、供給地（place-of-supply）の判定、検証結果、および各種レジスタにプログラムからアクセスできること。
本番環境と同等のサンドボックス環境、および統合テストを低コストで行うための無制限のテスト企業。

機能マトリクスに対してではなく、このリストに対して代替品を評価してください。

ユースケース別代替品の比較

あなたの状況	検討すべき製品	理由
プラットフォームが多数のテナントの帳簿を所有する必要がある	Nordletなどの埋め込み型会計API	1つのアカウントでの複数企業対応、従量課金、サーバー側で強制される会計ルール
顧客がQuickBooksで帳簿を管理しており、そこに自社システムを統合したい	QuickBooksのAPIを継続利用するか、アグリゲーターを使用する	帳簿は顧客のものであるため、顧客の環境に合わせるのが正しい
複数の会計アプリの帳簿を同時に処理する必要がある	Codat、Rutter、Mergeなどのアグリゲーター	複数の基幹システムを1つのインターフェースで統合
法定帳簿ではなく、リアルタイムのウォレット残高が必要である	Modern Treasury Ledgersなどの台帳インフラストラクチャ	税務申告ではなく、スループットと不変性に特化している
オペレーションと財務で1つのシステムに統一したい	OdooなどのERP	自社運用するというコストと引き換えに得られる幅広い機能
簿記担当者を置いている中小企業である	Xero、QuickBooks、または各地域の同等製品	アプリケーションそのものが目的であるため

埋め込み型会計API

これは「APIであってアプリではない」という要求に対する直接的な答えです。会計システムはプロダクトが呼び出すバックエンドサービスとなり、ユーザーが総勘定元帳を目にすることは一切ありません。

Nordletはこの形態に合わせて構築されています。コミット時にデータベーストリガーによって残高が強制される不変の複式簿記台帳、ギャップのないドキュメント番号の採番、締め月内の日付を持つ仕訳を 409 エラーで拒否する期間ロック、すべての変更に対する監査証跡、リトライ時に保存されたレスポンスを再送する Idempotency-Key のサポート、そして変更と同一のデータベーストランザクション内でトランザクションアウトボックスに書き込まれる署名付きWebhooksを備えています。価格設定は企業ごとではなく従量課金制となっており、月額10ユーロから（3,000リクエストを含む）利用でき、すべてのプランで企業数、ユーザー数、サンドボックス企業数が無制限です。

率直な制限事項：Nordletは現在アーリーアクセス段階であり、設計パートナーのオンボーディングを行っています。EU VATについては国別の税率、VIES検証、OSS/IOSS申告書の計算をカバーしていますが、国内向けの申告書パッケージは現時点では3カ国（リトアニアの FR0600、ドイツの UStVA、ポーランドの JPK_V7M）のみであり、給与計算はリトアニアのみに対応しています。

アグリゲーター

Codat、Rutter、Mergeは、顧客がすでに使用している任意の会計システムへの単一のインターフェースを提供します。もしあなたのプロダクトの目的が顧客の帳簿の読み取りや書き込み（融資、支出管理、分析など）であれば、このカテゴリが適切であり、埋め込み型台帳は不適切です。プラットフォーム自体が情報源（System of Record）となる必要がある場合、アグリゲーターをその代替とすることはできません。

台帳インフラストラクチャ

このカテゴリの製品は、法定会計を行わずに、高いスループットで不変の残高を追跡します。ウォレットや決済プロダクトの基盤としては適していますが、VAT、請求書発行、年次報告などは他のシステムに委ねる形になります。

ERP

Odooおよび類似のスイートは、会計にとどまらずビジネスの広範な領域をカバーしています。プラットフォーム構築者にとってのトレードオフは統合の複雑さにあります。Odooの外部APIはRPCを介したデータモデルレベルで動作し、公式ドキュメントではAPIアクセスがCustom価格プランに限定されていることが示されています。また、現在のRPCエンドポイントは新しいJSON APIへの置き換えが予定されています。これについてはプラットフォーム構築者のためのNordlet対Odooの比較で解説しています。

QuickBooksからの移行を進める場合

予想以上に時間がかかる傾向にあるいくつかの注意点：

勘定科目マッピング。 計画的に実行し、新しい勘定科目の参照フィールドとして古い勘定科目コードを保持してください。比較数値が変動した理由を尋ねられた際に必要になります。
期首残高。 履歴を再投稿するのではなく、カットオフ日時点の残高として移行してください。何年分もの仕訳を再生しようとするよりも、保持期間中は古いシステムを閲覧可能な状態で維持する方が現実的です。
ドキュメント番号。 新しいシリーズが古い番号を引き継ぐか、新しくリセットして開始するかを決定し、選択する前に管轄地域の要件を確認してください。
未決済項目。 未払請求書、未適用クレジット、部分的に消込が行われた支払いは、純残高としてではなく、未決済項目として移行する必要があります。そうしないと、その後の消込処理が機能しなくなります。
税務期間。 2つのシステムから1つの申告書を作成する準備ができていない限り、期間の途中で移行を行わないでください。
1サイクル分は両方のシステムを並行稼働させる。 同じ月の仕訳を両方のシステムに投稿し、古いシステムを停止する前に試算表（Trial Balance）を比較してください。

FAQ

QuickBooksに無料の代替品はありますか？

無料およびオープンソースの会計システムが存在し、Odooは1つのアプリに限定された無料プランを提供しています。プラットフォームにとって、コストはホスティング、アップグレード、コンプライアンス対応、そして統合を維持するためのエンジニアリング工数へと移行するため、無料のシステムが「無料」のままでいることは稀です。ライセンス費用ではなく総コストで評価してください。

マーケットプレイスにとってQuickBooksより優れたものは何ですか？

マーケットプレイスの会計に特化する場合、埋め込み型会計APIの方が構造的に適しています。1つのアカウントの下で多数のエンティティの帳簿を管理でき、サーバー側で会計ルールを強制し、ソフトウェアから完全に制御できるためです。一方、簿記担当者を置く単一の企業にとっては、依然としてQuickBooksの方が優れたプロダクトです。

QuickBooksには開発者向けAPIがありますか？

はい。QuickBooks Onlineは、Webhooksと開発者ポータルを備えたOAuth 2.0 REST APIを提供しています。プラットフォーム用途での制約はそのAPIの品質ではなくスコープにあります。つまり、それは企業の帳簿と統合するために設計されたものであり、別のプロダクト内部の台帳として機能するように設計されているわけではありません。

QuickBooksを維持したまま会計APIを追加することはできますか？

可能ですし、そうしているチームもあります。プラットフォーム自身の帳簿は埋め込み型台帳で管理しつつ、統合機能を通じて各事業者の顧客が使用する任意の会計システムへ集計仕訳をプッシュするという方法です。ここで留意すべきルールは、いかなる帳簿セットに対しても、信頼できる情報源（System of Record）となるシステムは厳密に1つでなければならないという点です。2つのシステムが共に権威ある情報源であると主張すると、消込の問題が発生する原因になります。

Xeroはどうですか？

Xeroはアプリケーションとして非常に強力であり、よく整備されたAPIを持っていますが、構造上の特性は同じです。サブスクリプションとAPIの制限は組織（organisation）単位であり、非認証アプリは連携可能な組織数が25に制限されています。この比較については埋め込み会計のためのNordlet対Xeroの比較で解説しています。