「大口の取引先に指定されたのだから、NetSuiteともつながないといけない」
取引先から「今後の請求書はBtoBプラットフォームで」と言われると、そう考えがちです。
ただ、つなぐかどうかを決めるのは、指定されたことではありません。
その取引先との請求書の件数です。
BtoBプラットフォーム 請求書は、株式会社インフォマートが提供する、請求書の発行と受取をオンラインで行うサービスです。
以下、「BtoBプラットフォーム」と書きます。
自社で選んだサービスではなく、取引先が使っているから合わせることになった。
そういう会社が多いサービスです。
月に数件なら、手で入れる運用で足ります。
では、何件を超えたら、どこまで自動にすればよいのか。
📌 この記事で分かること
- 請求書サービスの3つの型と、BtoBプラットフォームの位置づけ
- 取引先に指定される2つの立場（受け取る側・発行する側）
- 件数で決める3つのつなぎ方と、切り替える目安
- 公式情報で確かめたAPIの条件
請求書サービスの3つの型
請求書のクラウドサービスは、大きく3つの型に分かれます。
| 型 | 主な役割 | 代表例（このシリーズの記事） | 価値の源泉 |
|---|---|---|---|
| 発行代行型 | 自社の請求書を、相手に合わせて届ける | 楽楽明細 | 郵送代行や送り分け |
| 受取型 | 届いた請求書を読み取り、データにする | バクラク | 読み取りの仕組み |
| ネットワーク型 | 発行する側と受け取る側が、同じ場所でやりとりする | BtoBプラットフォーム | 取引先が同じ場所にいること |
発行代行型はNetSuite×楽楽明細連携、受取型はNetSuite×バクラク連携で扱っています。
ネットワーク型の性質
ネットワーク型は、両方が同じサービスを使えば、紙もPDFの読み取りも要らなくなります。
請求書が、最初からデータとして相手に届きます。
BtoBプラットフォームの公式サイトでは、次のことが案内されています。
- 請求書の発行も受取も、同じシステムで扱える
- 取引先は、無料で利用できる
- 請求書のほか、支払通知書や納品書も発行できる
- 紙やPDFで届いた請求書は、AI-OCRでデータにできる
- 電子帳簿保存法とインボイス制度に対応している
（出典：BtoBプラットフォーム 請求書「特徴」、2026年9月23日確認）
AI-OCRは、画像やPDFの文字を自動で読み取り、データにする技術です。
裏を返せば、ネットワーク型の価値は取引先がそこにいるかどうかで決まります。
取引先が使っていなければ、受取型や発行代行型と変わりません。
取引先から指定される場面が多いのも、この性質のためです。
取引先が使っているかどうかで分けると、次のとおりです。
取引先に指定される、2つの立場
指定される場面は、2つあります。
受け取る側として指定される
仕入先から「請求書はBtoBプラットフォームで送ります」と言われる場面です。
自社は、受け取る側になります。
請求書はデータで届きます。
NetSuiteでは、仕入先からの請求（仕入請求書）として記録します。
何の形で渡すか（仕訳・仕入請求書・支払済み）は、NetSuite×バクラク連携の第2章と同じ考え方です。
発行する側として指定される
得意先から「請求書はBtoBプラットフォームで送ってほしい」と言われる場面です。
自社は、発行する側になります。
このとき、請求書の正本はNetSuiteに置きます。
正本（せいほん）は、元になる記録のことです。
NetSuiteで請求書を作り、その内容をBtoBプラットフォームに登録して送ります。
BtoBプラットフォームの側で金額や明細を直すと、NetSuiteの売掛金と食い違います。
この考え方は、NetSuite×楽楽明細連携の第5章と同じです。
2つの立場の比較
| 立場 | 自社がすること | NetSuiteでの記録 | 気をつけること |
|---|---|---|---|
| 受け取る側 | 届いた請求書を確認し、承認する | 仕入請求書（または仕訳） | 仕入先の番号の対応 |
| 発行する側 | NetSuiteの請求書を登録して送る | 請求書（売掛金） | 正本はNetSuite。BtoB側で直さない |
両方の立場に、同時になる会社
卸売や商社では、同じサービスで両方の立場になることがあります。
仕入先からは受け取り、得意先には発行する形です。
この場合も、記録は立場ごとに分けます。
受け取る請求書は仕入請求書、発行する請求書は売上の請求書です。
ただし、取引先の番号の対応は1つの表にまとめます。
同じ会社が、仕入先であり得意先でもあることがあるからです。
NetSuiteの顧客と仕入先の番号を、BtoBプラットフォームの取引先と1対1で結びつけます。
件数で決める、3つのつなぎ方
つなぎ方は、その取引先との請求書の件数で決めます。
| つなぎ方 | 向いている件数の目安 | やること | 手間がかかるところ |
|---|---|---|---|
| A. 手で入力する | その取引先との請求書が、月に数件 | BtoBプラットフォームの画面で確認・入力し、NetSuiteにも手で入れる | 二重入力。ただし件数が少なければ軽い |
| B. CSVで受け渡す | 月に数十件、または取引先が複数 | 一方から出したファイルを、もう一方に取り込む | 項目の対応を決めて保守する |
| C. APIでつなぐ | 件数が多く、取引先も多い | プログラムで自動的に登録・取得する | プログラムの開発と保守 |
月に数件ならつながない選択が現実的です。
つなぐ仕組みの開発と保守の手間が、手で入れる手間を上回るからです。
取引先の数が増えてきたら、BかCに進みます。
NetSuiteのCSV取り込みは、NetSuiteのCSVインポートで解説しています。
データで届く請求書は、発注と突き合わせやすい
受け取る側としてつなぐ場合、ネットワーク型ならではの利点があります。
請求書が最初からデータで届くので、NetSuiteの発注や入荷と突き合わせやすいのです。
紙やPDFの請求書は、読み取りの誤りを確かめてから突き合わせます。
データで届けば、この確認の手間は小さくなります。
AIに突き合わせを手伝わせるときも、最初からデータであることが効いてきます。
発注をNetSuiteで管理している会社ほど、つなぐ価値は大きくなります。
発注から支払までの流れは、NetSuiteの購買管理の流れにあります。
どこから「つなぐ」に切り替えるか
目安は、二重入力にかかる時間が月に何時間あるかです。
担当者が1か月に使っている時間を、実際に測ってください。
その時間と、つなぐ仕組みの開発・保守の費用を比べます。
件数だけでなく、明細の行数も見ます。
月に数件でも、1件に数百行の明細がある取引先はあります。
明細が多いほど、手で入れる手間は重くなります。
指定されたときに、取引先へ聞く3つ
つなぐかどうかを決める前に、取引先へ次の3つを聞いておくと判断が速くなります。
- いつから切り替えるか：紙やPDFと並行する期間があるか
- 請求書の単位：取引ごとの請求か、月ごとにまとめた締め請求か
- 対象の範囲：すべての取引か、一部の部門や拠点だけか
並行する期間が長いと、その間は2つの窓口を同時に扱います。
締め請求なら、件数は月に1件でも、明細の行数が多くなりがちです。
一部の拠点だけなら、つなぐ範囲も小さく始められます。
APIについて、公式情報で確かめたこと
BtoBプラットフォームは、外部のシステムとつなぐためのAPIの仕様を公開しています。
APIリファレンスで案内されていること
- 請求書・受発注・契約書・社員マスタの領域ごとに、APIの仕様がある
- 認証の方法など、共通の仕様がまとめられている
- 利用は、申込みからテスト環境を経て、本番に進む流れ
（出典：BtoBプラットフォーム APIリファレンス、2026年9月23日確認）
請求書のAPI仕様書に書かれていること
請求書の外部連携API仕様書（バージョン2、2023年12月13日発行）では、次の内容が定義されています。
- 対象は、請求書を発行する側と受け取る側の両方
- 請求書の登録・取得・一覧の取得、状態の管理、PDFや添付の扱い
- 発行元や取引先の登録、振込先の情報など、マスタのAPI
- データの形式はJSONまたはXML
（出典：BtoBプラットフォーム 外部連携API仕様書 バージョン2）
JSONやXMLは、システム同士がデータを受け渡すときの書き方の決まりです。
Peppolへの対応
公式サイトでは、Peppol経由での請求書のやりとりにも対応すると案内されています。
APIリファレンスの更新履歴にも、Peppolに関するAPIの追加が記載されています。
（出典：BtoBプラットフォーム 請求書「特徴」／APIリファレンス、2026年9月23日確認）
Peppolは、請求書などの電子文書を、異なるサービスの間でやりとりするための国際的な標準の仕組みです。
取引先が別のサービスを使っていても、Peppolに対応していれば、データでやりとりできる可能性があります。
取引先がPeppolで送ってくる場合の受け取り方は、利用しているサービスの提供元に確認してください。
NetSuiteとの連携の案内はない
2026年9月23日時点で、公式サイトにNetSuiteとの連携の記載は確認できませんでした。
協業のためのAPIの案内ページでも、連携している製品にNetSuiteの名前はありません。
一方で、API仕様書は一般に公開されています。
問い合わせないと仕様を読めないサービスもある中で、事前に読める例です。
仕様が事前に読めるのでつなぐ開発の見積もりが立てやすくなります。
日系SaaS全体の事情は、NetSuite×日系SaaS連携マップにまとめています。
つなぐ前に決める3つのこと
BかCでつなぐと決めたら、次の3つを先に決めます。
1．取引先の番号をどちらに合わせるか
BtoBプラットフォームの取引先と、NetSuiteの顧客・仕入先を結びつける番号を決めます。
基本は、NetSuiteの番号を正とし、BtoBプラットフォームの側に持たせる形です。
新しい取引先は、NetSuiteで先に登録してから、BtoBプラットフォームの側に番号を入れます。
この順番を守れば、取り込みのたびに「取引先が見つからない」で止まることを防げます。
2．明細の細かさをどこまで合わせるか
BtoBプラットフォームは、明細の単位で仕訳できると案内しています。
NetSuiteの品目や勘定科目と、明細をどこまで対応させるかを決めます。
全部を合わせる必要はありません。
NetSuiteで見たい単位までで十分です。
3．直すときの向きをどちらにするか
発行する側なら、NetSuiteで直してから送り直します。
受け取る側なら、差し戻しはBtoBプラットフォームで行い、確定したものだけをNetSuiteに入れます。
NetSuiteに入れた後で誤りが見つかったら、NetSuite側で取り消し、差し戻してから入れ直します。
連携手段の全体像は、NetSuiteの連携方法ガイドで扱っています。
つまずく3つのパターン
パターン1：取引先ごとに、請求書サービスが増えていく
起きること：A社はBtoBプラットフォーム、B社は別のサービス、C社はメールのPDF。指定に合わせているうちに、請求書の窓口が5つになった。
原因：指定されるたびに、個別に対応してきた。
どのサービスをどこまで使うかを、全体として決めていません。
避け方：取引先ごとに「どのサービスで、何件か」を1枚の表にします。
件数の多いサービスだけNetSuiteとつなぎ、少ないものは手で入れる、と線を引きます。
パターン2：発行した請求書を、BtoBプラットフォームの側で直してしまう
起きること：得意先から金額の誤りを指摘され、BtoBプラットフォームで直して再送した。月末に、NetSuiteの売掛金と送った請求書が合わない。
原因：正本がNetSuiteにあることを、担当者が意識していなかった。
避け方：第5章の3つめのとおり、発行した請求書の訂正はNetSuiteから行います。
手順書に「BtoBプラットフォームの側では金額を直さない」と書いておきます。
パターン3：取引先の番号を合わせずに、CSVをつなぐ
起きること：CSVの取り込みで、毎回数件が「取引先が見つからない」で止まる。社名の表記が、両方で少しずつ違う。
原因：社名で突き合わせていた。
「株式会社」の位置や、全角と半角の違いで、同じ会社が別の会社になります。
避け方：第5章の1つめのとおり、NetSuiteの番号を正として両方に持たせます。
社名での突き合わせは、やめます。
ベンチャーネットならこう見る｜取引先ごとに3つから選ぶ
取引先に指定されたサービスは、断りにくいものです。
だからといって、指定されるたびにつないでいけば、つなぐ仕組みの数だけ保守が増えます。
型1：標準に合わせる／開発する／残す
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、取引先ごとに扱いを3つから選びます。
- 標準に合わせる：両方の標準のCSVの出し入れを使い、項目の対応だけを決める（B）
- 開発する：件数も取引先も多いなら、公開されている仕様にもとづいてAPIでつなぐ（C）
- 残す：件数の少ない取引先は、つながずに手で入れる運用を続ける（A）
選ぶ順番は、件数の多い取引先からです。
件数の少ない取引先には、つながない運用をおすすめします。
型2：誰が何を受け持つかを、先に分ける
BtoBプラットフォームの契約と設定は、インフォマートが窓口です。
ベンチャーネットが受け持つのは、NetSuite側と、2つの製品の間のつなぎです。
- 取引先ごとの件数と手間を数え、A・B・Cのどれにするかを一緒に決める
- NetSuite側の受け皿として、取引先の番号と明細の対応を整える
- CSVの組み替えや、APIの連携を設計・開発する
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
特定の製品に誘導しない立場なので、つながないという答えもそのままお伝えします。
今日できること｜取引先ごとの請求書の窓口を書き出す
次の表を、経理の担当者と一緒に埋めてみてください。
| 取引先 | 受け取る／発行する | 使っているサービス | 月の件数 |
|---|---|---|---|
| （例）A社 | 受け取る | BtoBプラットフォーム | 20件 |
書き出すと、つなぐ価値のある取引先と、手で入れれば足りる取引先が分かれます。
件数の多いサービスが1つに集まっていれば、そこだけつなげば効果が出ます。
あわせて、「明細の行数の目安」も書き添えてみてください。
件数が少なくても、明細が多い取引先は、つなぐ価値が出ることがあります。
よくある質問
Q1. BtoBプラットフォームは、NetSuiteと連携できますか
公式サイトにNetSuiteとの連携の記載はありません（2026年9月23日時点）。
ただし、外部連携のAPI仕様書が公開されています。
APIやCSVでつなぐことを前提に設計します（第4章）。
Q2. 取引先から指定されたら、必ずNetSuiteとつなぐべきですか
件数が少なければ手で入力する運用で足ります。
つなぐかどうかは、二重入力にかかる時間と、開発・保守の費用で比べます（第3章）。
Q3. 受け取る側として使うのに、費用はかかりますか
公式サイトでは取引先は無料で利用できると案内されています。
ただし、自社から発行する側として使う場合や、会計との連携の機能を使う場合の条件は、インフォマートに確認してください。
Q4. 楽楽明細やバクラクとは、何が違いますか
取引先が同じサービスを使っているかどうかで価値が変わる点です。
楽楽明細は発行代行型、バクラクは受取型です。
BtoBプラットフォームはネットワーク型で、双方が使うと最初からデータでやりとりできます（第1章）。
Q5. 発行した請求書に誤りがあったら、どこで直しますか
NetSuiteで直してから送り直してください。
請求書の正本はNetSuiteです。
BtoBプラットフォームの側だけで直すと、売掛金と食い違います（第2章2-2）。
Q6. 自社は得意先にも仕入先にもなります。つなぎ方は分けるべきですか
記録は立場ごとに分け番号の対応は1つにまとめます。
受け取る請求書は仕入請求書、発行する請求書は売上の請求書として記録します。
同じ会社が両方の立場になることがあるため、番号の対応表は共通にします（第2章2-4）。
まとめ：指定されたら、まず件数を数える
- 請求書サービスは、発行代行型・受取型・ネットワーク型の3つ
- BtoBプラットフォームはネットワーク型。取引先がそこにいるかで価値が決まる
- 取引先に指定される立場は2つ。受け取る側と発行する側
- つなぎ方は件数で決める。月に数件なら、つながない選択が現実的
- NetSuiteとの連携の案内はないが、API仕様書が公開されている
- 取引先の番号はNetSuiteを正にし、発行した請求書はNetSuiteで直す
指定されたからといって、つなぐ理由にはなりません。
まずは先月の実績で、その取引先の請求書が何件、明細が何行あったかを数えてください。
もう少し詳しく知りたい方へ
「取引先に指定された請求書サービスを、NetSuiteとつなぐべきか」の判断から、ご相談をお受けしています。
