従業員数がちょうど50人を超えたところで、会社の購買のやり方が従業員30人あたりでどこかで破綻した。エンジニアは個人カードでソフトウェアを経費精算し、何ヶ月も後に払い戻しを受ける。オフィスマネージャーは一番早く返信してきた相手からノートPCを発注する。法務が新しいベンダーの存在を初めて知るのは、自動更新の請求書が買掛金に届いたときだ。正確に言って不正があるわけではない——しかし今四半期に会社が何にいくら支出する約束をしたのか、誰も答えられず、月末決算は受信箱を発掘する考古学のような作業になっている。「誰かが購入ボタンを押した」瞬間と「財務がそれを知る」瞬間の間のこのギャップを埋めるために、調達ソフトウェアは存在する。
成長企業の候補リストを支配する3つのプラットフォームがある：Ramp、Airbase、Zipだ。いずれもインテーク、承認、発注書、そして会計システムへのクリーンな同期を約束する。しかし出発点が異なる——Rampは法人カードから、Airbaseは買掛金から、Zipは購買リクエストそのものから——そしてその起源が、それぞれの適合の仕方をあらゆる面で形作っている。本記事では、最も重要な4つの観点でこれらを比較する：インテークと承認、発注書、ループを閉じるERP同期、そしてそれぞれの実際のコストだ。
各プラットフォームの実態
Rampは調達を上に載せた支出管理プラットフォームだ。法人カードとして始まり、その後経費管理、請求書支払、出張を追加し、調達はそのオールインワンの物語の中のモジュールとして登場した。売り文句は統合だ：1つのベンダー、1つのログイン、カード・経費精算・請求書・購買リクエストをカバーする1つのデータセット。調達機能には、貼り付けた見積書からリクエストフォームを事前入力するAI支援インテーク、ルールベースの承認ルーティング、発注書、ベンダーレコード、契約・更新の追跡、請求書を発注書・受領記録と照合する自動3-wayマッチングが含まれる。基本プラットフォームは無料——Rampはカード支出のインターチェンジで稼ぐ——一方、調達はPlusプランの有料アドオンだ。
Airbaseも支出管理プラットフォームだが、重心は買掛金と決算にある。ガイド付き調達とAP自動化、経費管理、法人カードを、最初のリクエストから支払い・照合までの1つのワークフローに組み合わせている。同社は「ガイド付き調達」をフロントエンドとして位置づける：従業員はリクエスト時点で優先ベンダーやポリシー内の選択肢へと誘導され、下流のすべて——承認、支払い、GLコーディング——がその構造を引き継ぐ。Airbaseは会社規模別にプランを階層化する：従業員200人まで向けのStandard、500人まで向けのPremium、5,000人まで向けのEnterpriseで、価格は見積もりベースだ。
Zipは意図的に異端だ。intake-to-procureの統制として始まった：任意の従業員があらゆる購買やベンダーのリクエストを始める単一の玄関口であり、Zipがそれを財務、IT、法務、セキュリティ、調達のレビューへノーコードのワークフローでルーティングする。決定的なアーキテクチャ上の違いは、Zipが既存のERPやprocure-to-payシステムを置き換えるのではなく、その上位に位置することだ。適切なタイミングでERP内に購買依頼や発注書を作成するので、リクエスターはNetSuiteやSAPに一切触れずにオープンPO残高を追跡できる。ローンチ以来、ソーシング、サプライヤー管理、契約統制、支出インサイト、グローバル決済を追加して完全なintake-to-payへと成長してきたが、レビューチーム間の統制こそがそのアイデンティティであり続けている。
インテークと承認：3者が最も分かれるところ
主な痛みが「何がリクエストされ、誰が承認したか誰も知らない」ことなら、まずインテーク体験を比較すべきだ。ここでは3製品が本当に異なるからだ。
Zipはインテークをすべてと捉える。フォームは以前の回答に基づいて追加質問を適応させ、リクエスターが入力するそばからポリシーガイダンスを文脈内に表示し、ステークホルダーチーム間で並行にルーティングするので、法務・セキュリティ・財務のレビューが順次ではなく同時に進む。承認者は新しいシステムを学ばずにSlackやメールで承認する。この設計は、資金が動く前に購買が5つのチームにまたがる企業——20,000ドルのツール購入に6週間のメール転送が必要という、典型的なシリーズB以降の不満——を狙っている。
RampのインテークはAIに依存する：見積書をアップロードするかスクリーンショットを貼り付ければフォームが自動入力され、ルールがベンダー種別、支出カテゴリ、金額別にリクエストをルーティングし、有料プランでは財務・IT・法務・セキュリティ間の並行承認が可能だ。無料プランでもAIインテーク、カスタムフォーム、基本承認をカバーし、承認チェーンが「マネージャー、次に財務」という小企業には十分だ。Rampが抜きん出るのは承認後だ：カードが同じプラットフォームにあるため、承認されたリクエストは発注書から直接バーチャルカードを発行でき、従業員が立て替える必要がない。
Airbaseのアプローチは、多様なステークホルダーの監督を強制する承認ワークフローを備えたガイド付き調達だ。柔軟なインテークフォームと設定可能な承認チェーンは標準的なケースをよくカバーし、その強みはポリシーレイヤーにある：支出管理、ベンダールール、GLコーディングを一度設定すれば、リクエストから支払いまで一貫して適用される。独立系の比較では、Airbaseは深い構造化された調達ワークフロー——複雑な購買依頼や多段階のPO管理——においてAPや照合側ほど強くないと一貫して指摘されている。購買プロセスが本当に複雑で、セキュリティレビューや法務の修正が第一級のステップなら、Zipの統制はまさにそのために作られている。Airbaseは主流の中間をカバーする。
実用的なテスト：最近の最も厄介な購買3件を洗い出そう。痛みがルーティング——誤った承認者、停滞したスレッド、法務の関与が遅すぎる——なら、インテークを探しておりZipがリードする。痛みが支払い——経費精算が遅い、請求書が山積み、どのカードが何を支払ったか誰も知らない——なら、調達を付属させた支出管理を探しており、RampかAirbaseがより適合する。
発注書と3-wayマッチング
3つのプラットフォームすべてが発注書を発行するが、POの意味は各アーキテクチャで異なる。
Rampでは、POは統合された支出記録の中の1つの成果物だ：リクエスト、承認、PO、カードまたは請求書での支払い、照合が一体となって存在する。自動3-wayマッチングは請求書をPOと受領記録に照合し、支払い前に過請求をフラグ立てする。受領ドックを持たない成長企業——ほとんどのソフトウェアやサービスの購買——では「受領」は多くの場合リクエスターが納品を確認するだけであり、Rampのフローはその軽量なケースを優雅に処理する。
Airbaseでは、POはAPエンジンに供給する。このプラットフォームの最大の強みはバックエンドで起きることだ：請求書が届き、照合され、正しいGL勘定に転記され、最小限の手間で元帳に同期される。Airbaseを選んだ企業は通常、決算を称賛する——手作業の仕訳が減り、コーディングがクリーンになり、照合が速くなる。前述のとおり、トレードオフは高度な調達側ワークフロー（購買依頼の階層、包括発注、部分出荷に対する受領）が専用調達ツールより薄いことだ。
Zipでは、POは記録システムへの受け渡しだ。ZipはPOの前のすべて——インテーク、部門横断レビュー、ベンダー設定——を統制し、その後ERP内に購買依頼や発注を作成し、リクエスターにERPのシートなしでステータスを知らせ続ける。これは財務がすでにNetSuiteで堅実なprocure-to-payプロセスを運用しており、問題がその上流のすべてにある場合に正しい形だ。受け渡す下流プロセスが存在しない場合には間違った形だ：PO規律のないQuickBooksで帳簿をつけている企業は、統制レイヤーよりもプロセスそのものであるプラットフォームからより多くを得る。
ループを閉じるERP同期
元帳にきれいに転記されない調達ソフトウェアは、月末の掘削作業を受信箱からCSVエクスポートへ移すだけだ。3つとも主要システム——NetSuite、QuickBooks、Sage Intacct、Xero——に同期するが、同期はロゴの壁ではなく3つの問いで評価しよう。
第一に、ソースでのコーディング。最良の同期は触れる必要のないものだ：インテークと承認の間に割り当てられたGL勘定、部門、プロジェクト、クラスが仕訳へと流れ込む。Airbaseはここで評判上最も強い——そのNetSuite照合同期とリクエストから支払いまでの一貫したコーディングが、財務チームがこれを選ぶ理由だ。Rampは統合プラットフォーム内でその仕組みを同等に備え、ZipはPOがそこで生まれるためERPのコーディング規律を引き継ぐ。
第二に、誰がシートを必要とするか。ZipのモデルはERPコスト管理で輝く：リクエスターと承認者はZipで作業し、財務だけがERPに触れるので、人員増加が高価なNetSuiteシートを倍増させない。RampとAirbaseはこれを反転させる——全員が働く場所になることを望み、ERPはクリーンでコード化されたエントリを受け取る記録システムになる。
第三に、監査証跡。誰がリクエストし、誰が承認し、どのポリシーに照らし、どの請求書と照合されたか——そのチェーンが監査人が求めるものであり、更新時にソフトウェアを正当化するものだ。3つともこれを保持するが、違いはどこで読むかだ。RampとAirbaseでは支出プラットフォーム内に存在する。Zipでは2つのシステムにまたがり、PO前の物語はZipに、財務記録はERPにあり、PO番号でリンクされる。購入前に、監査人と未来の自分がどちらを好むかを決めよう。
それぞれの実際のコスト
このカテゴリの価格は無料から6桁に及び、その幅は本当に異なる買い手を反映している。
Rampは最も明確な価格を公表している。コアプラットフォーム——カード、経費、請求書支払、基本承認——は無料で、カードのインターチェンジで補助される。調達機能にはPlusのユーザーあたり月額15ドルとプラットフォーム料金が必要で、調達アドオン自体は公開ページでは価格未掲載、またはカスタム見積もりのEnterpriseプランとなる。すでにRampカードを発行しているスタートアップにとって、調達を追加する限界コストは3つの中で断然最も低い——ただしモデル化する際は調達シートを必要とするユーザーだけを数え、予測前にプラットフォーム料金を書面で確認しよう。
Airbaseは定価を公表していない；3つの階層（Standard、Premium、Enterprise）はすべて見積もりベースで従業員数に応じて設定される。第三者トラッカーは無料のエントリ階層やユーザーあたりの数字を様々に記述するが、それらは古いか部分的なものとして扱おう——2026年の情報源を通じて一貫する事実は、従業員数とモジュールに応じた見積もりを交渉することになるということだ。中堅市場の支出プラットフォーム取引として予算を組もう：無視できないが、エンタープライズ調達スイートよりははるかに低く、更新時の値上げは後ではなく今交渉するのが定石だ。
Zipは見積もり専用で、確実に3つの中で最も高い。より大きく複雑な購買組織に売っているからだ。Vendrが収集した買い手報告データによると、Zip契約の中央値は年間約88,000ドルで、エントリ配備は約27,000〜40,000ドルから始まり、大企業の取引は200,000ドルを超える。AWS Marketplaceでアクティブユーザー100人・ワークフロー1つのパイロットが75,000ドルで掲載されているのは、「Zipを試す」コストの具体的な目安になる。導入は数週間から数ヶ月——CoupaやSAP Aribaの展開より速く、それが売り文句の一部でもあるが、他の2社が低価格帯で提供するセルフサービス登録ではない。
あらゆる階層で買い手が忘れるコストが1つある：サブスクリプション自体に適切な帳簿が必要だということだ。前払いした年間プラットフォーム料金は12ヶ月にわたって償却される前払資産であり、ある月の損益計算書を破壊する1月の費用ではない。発注書PO-1042に対する年額5,400ドルのサブスクリプションのプレーンテキスト元帳でのパターンはこうだ：
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Software USD
2026-01-01 open Expenses:Software:Procurement USD
2026-01-05 * "Ramp" "Annual subscription, PO-1042"
Assets:Prepaid:Software 5400.00 USD
Assets:Cash:Operating -5400.00 USD
2026-01-31 * "Month-end" "Amortize January procurement software"
Expenses:Software:Procurement 450.00 USD
Assets:Prepaid:Software -450.00 USDすべてのプラットフォームのサブスクリプションがこの形——支払時に前払い、毎月費用化——に従えば、月あたりのソフトウェア支出は12枚の請求書を探すのではなく1つの勘定の照会になる。Favaで元帳を開けば、償却スケジュールはきれいな月次行として読め、キャンセルし忘れた更新を最も早く見つける方法でもある。
あなたのステージに合うのはどれか
機能マトリックスを会社の形で切り抜けよう：
- 100人未満、購買の混乱は新しい。 Rampから始めよう。無料のコアがカードと経費精算を即座に修正し、基本承認が受信箱プロセスを飼いならし、リクエスト量が正当化するときにだけ有料の調達を追加する。リスクは後でワークフローの深さを超えて成長すること——しかしそれは良い問題であり、移行は過剰購入に勝る。
- 100〜500人、決算に2週間かかる。 Airbaseを候補に。ガイド付き調達に強力なAPエンジンとGL同期を加えたものが照合の滞りを直接攻撃し、従業員数ベースの階層は中堅市場の財務チームの買い方に合う。最も厄介な承認チェーンを——ハッピーパスではなく——デモして、ワークフローの深さがそれをカバーするか確認しよう。
- 200人超、あらゆる購買が5つのチームにまたがる。 Zipをデモしよう。法務、セキュリティ、IT、財務、調達すべてが本当に発言権を必要とし——すでにNetSuiteやSAPを記録システムとして運用しているなら——統制レイヤーはカードプラットフォームにレビューワークフローをボルト留めするより優れている。デモには実際のインテークフォームと実際の承認マトリックスを持参しよう；一般的なウォークスルーはどのベンダーもよく見せる。
- すでにERPのprocure-to-payモジュールに深く入り込んでいる。 Zipはその上に重なる；RampとAirbaseはますますそれと競合する。各ベンダーに、PO、ベンダーマスター、支払いを正確にどのシステムが所有するかをホワイトボードで描かせよう——「双方向に同期します」には頷きではなく図が必要だ。
どれを選んでも、同じパイロットを実施しよう：実際のベンダー3社、更新1件、承認閾値を超える新規購買1件、システムが捕捉すべきと期待するポリシー外のリクエスト1件。インテーク時間、承認者の負担、元帳でのコーディング精度、そしてリクエスターにトレーニングが必要だったかどうかを採点する。そのパイロットに勝つプラットフォームが、従業員が実際に使うものだ——そして使われない調達ソフトウェアは、どんな価格であれ最も高くつく種類のものだ。
