BtoB EC分割納品（分納）対応｜支払期日と帳票

◆監修・編集責任者　小園 将隆　2026年8月20日

B2B EC-COLUMN

BtoB ECの分割納品（分納）とは

BtoB ECの分割納品（分納）対応とは、1件の受注を複数回に分けて出荷・納品し、そのつど発生する納品書・在庫引当・請求・支払期日の処理を、システムと運用の両面で破綻なく回せる状態に整えることです^*1。

取引のEC化そのものは広がっており、2024年のBtoB-EC市場規模は514.4兆円（前年比10.6%増）、EC化率は43.1%（前年比3.1ポイント増）でした^*3。ただしこの数値は国内のBtoB取引全体を母集団としたもので、分納取引に限った統計ではありません。受発注をシステムに載せる企業が増えるほど、分納のような例外処理をどこまで仕組みで持つかという設計判断が表に出てきます。

分納が問題になる理由は、代金の支払期日が一括納品とは違う数え方になる点にあります。取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）は、委託事業者が給付の内容について検査をするかどうかを問いません^*1。受領日から起算して60日以内（受領日を算入）のできる限り短い期間内で、支払期日を定める義務を課しています^*1。分納では出荷（受領）のたびにこの起算日が発生するため、月まとめの請求慣行と条文上の建付けがずれやすくなります。

分納が起きる4つの場面（在庫不足・発注ロットと出荷単位の不一致・配送/車建ての制約・取引先からの指定）

分納は担当者の判断で発生するものと、取引先や物流の制約で発生するものに分かれます。在庫不足による後送り、発注ロットと出荷単位の不一致、車建てや配送便の容量制約、取引先からの分納指定という4つの場面が典型です。

いずれの場面でも、出荷が複数回に分かれること自体は珍しくありません。問題になるのは、出荷回数が増えるほど納品書・請求書・支払期日の管理点数が増え、Excelや電話による手作業では追いきれなくなることです。

分納・一括納品・同梱の違いは出荷単位の分け方にある

一括納品は受注1件に対して出荷1回で完結する形です。同梱は複数の受注を1回の出荷にまとめる形であり、分納とは逆方向の集約です。分納は受注1件を複数回の出荷に分ける形であり、受注明細と出荷明細の対応関係を管理する必要が生じます。

この3つを混同すると、システム要件の設計を誤りやすくなります。同梱は受注側の集約、分納は出荷側の分割という違いを、要件定義の最初に共有しておくことが大切です。

分納で崩れるのは在庫・帳票・請求の3か所

分納の運用が属人化すると、影響は在庫・帳票・請求の3か所に集中します。在庫では残数の把握がずれ、帳票では納品書の発行漏れが起き、請求では納品書と請求書の突合に時間がかかるようになります。次章では、このうち帳票・請求に関わる法令・税務の扱いを一次情報にもとづいて整理します。

分納で変わる支払期日・帳票・会計の扱い

支払期日は「受領日から起算して60日以内」（受領日を算入・検査の有無を問わない）

取適法第3条は、委託事業者が給付の内容について検査をするかどうかを問わない旨を定めています^*1。受領日から起算して60日以内（受領日を算入する）のできる限り短い期間内で、代金の支払期日を定める義務があります^*1。支払期日を定めなかったときは、受領日が支払期日とみなされます^*1。

分納では出荷（受領）のたびにこの起算日が発生します。1回の受注でも出荷が3回に分かれれば、支払期日の起算日も3つ生じるため、契約や運用ルールがこの前提とずれていないかを確認する必要があります。

「締切対象期間」による月まとめは役務提供委託・特定運送委託の枠で記述されている

取適法テキストは、役務提供委託または特定運送委託において、月単位で設定した締切対象期間の末日に役務が提供されたものとして扱える条件を示しています^*1。前提として、個々の役務が連続して提供される役務であることが必要です^*1。そのうえで条件は3つあります。代金の支払が締切対象期間の末日までに提供した役務に対して行われることを中小受託事業者と協議のうえ合意し、その旨を4条明示していること、対象期間の代金の額（または算定方法）を4条明示していること、提供される役務が同種であることです^*1。これらを満たす場合に、締切後60日（2か月）以内の支払いが認められます^*1。

この記述はテキスト上、役務提供委託・特定運送委託を対象にした説明です。物品の製造委託・修理委託にあたる分納取引にそのまま当てはめられるかどうかは、委託の類型と契約内容によって変わります。自社の取引が委託事業者側に当たるかどうかの判断は、取引ごとに確認することが望ましいでしょう。

受領日から起算した支払期日の管理を後回しにすると、締め処理の直前に不整合が見つかり、支払遅延という取適法上のリスクにつながります。分納の可視化コストを自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

納品書＋請求書で「一の適格請求書」にする（端数処理は納品書につき税率ごとに1回）

国税庁のインボイスQ&A問67は、1枚の書類だけで記載事項を満たす必要はないと示しています^*2。相互の関連が明確な複数の書類を合わせて、一の適格請求書とできる方法です^*2。具体例として、納品書に税率ごとの消費税額等を記載し、請求書に登録番号と納品書番号を記載する形が挙げられています^*2。

この方式を使う場合、端数処理は納品書につき税率ごとに1回行います^*2。出荷のたびに納品書を発行し、月締めの請求書側で納品書番号をまとめて紐づける運用が、分納と月次請求を両立させる代表的な形です。

分納と収益認識の考え方（一時点で充足される履行義務）

企業会計基準委員会は、企業会計基準第29号「収益認識に関する会計基準」を公表しています^*5。この基準は、履行義務を一時点で充足する取引について、資産の支配が顧客に移転した時点で収益を認識する考え方を示しています^*5。

分割納品はこの移転時点が出荷ごとに区切られる取引であるため、出荷実績と請求データを対応させる仕組みが会計処理の前提になります。個別の項番を適用する場合は、自社の会計方針にもとづいて別途確認することをおすすめします。

分納に対応するためのシステム要件

受注明細と出荷明細を1:Nで持つ（データモデル図）

分納に対応するデータモデルの起点は、受注明細1件に対して出荷明細を複数件持てる1:N構造です。出荷明細ごとに数量・納品書番号・出荷日を持たせることで、分納の回数が増えても1件の受注として一元管理できます。

残数と分納ステータスの持ち方（受注残・出荷済・キャンセル）

受注明細には受注残・出荷済・キャンセルの3状態を持たせ、出荷明細が作成されるたびに受注残を減算する形が基本になります。この状態管理を出荷明細側だけに持たせると、受注全体の進捗が分かりにくくなるため、受注明細側にも集計値を反映させる設計が実務では有効です。

出荷単位の在庫引当と出荷可能数の判定

分納では、出荷明細ごとに在庫を引き当て、その時点で出荷可能な数量を判定する仕組みが欠かせません。在庫引当の粒度を受注単位のままにすると、一部入荷した分だけを先行出荷する判断ができず、結果的にすべての出荷が最終入荷まで止まってしまいます。

在庫引当の判定を誤ると、出荷可能な数量が実際の在庫と食い違い、欠品案内の遅れや過剰出荷につながります。出荷単位で引当と判定する設計に切り替えることが、この失敗を避ける前提になります。

基幹システム・EDIとの連携（流通BMSの出荷/受領/請求メッセージ）

消費財流通のEDI標準である流通BMS（流通ビジネスメッセージ標準）は、発注・出荷・受領・返品・請求といった電子取引文書と通信プロトコルを標準化しています^*4。取引先が流通BMSに対応していれば、分納にともなう出荷・受領のメッセージを標準の形式でやり取りすることが可能です。

基幹システムとBtoB ECを連携させる場合、分納の出荷実績を双方向で反映できるかどうかが要件の分かれ目になります。この点は次章のよくある失敗でも取り上げます。

分納の運用設計5ステップ

①取引先ごとの合意事項：分納可否と最小出荷単位を先に決める

最初に決めるのは、取引先ごとに分納を許容するかどうかと、分納する場合の最小出荷単位です。ここが未確定だと、後続のシステム設定と運用ルールのすべてが手戻りの対象になるでしょう。

②受注時の見える化：納期回答とマイページ表示で分納予定を示す

受注を受けた時点で、分納になる可能性と各回の納期見込みを取引先に提示します。マイページやEC画面上で分納予定を表示できると、問い合わせ対応の件数を抑えられます。

③出荷単位の帳票：出荷のつど納品書を発行し送料を按分する

出荷のたびに納品書を発行し、送料が発生する場合は出荷回数に応じて按分します。按分方法は契約時に明文化しておくことで、請求段階での認識差を防げます。

④請求突合：納品書番号で紐づけて締める

請求を締める際は、納品書番号をキーにして出荷明細と請求明細を突合します。国税庁のインボイスQ&Aが示す一の適格請求書の方式^*2を、運用に落とし込む工程がここです。

⑤例外処理の事前設計：欠品・キャンセル・返品・値引の扱いを決める

欠品によるキャンセル、出荷後の返品、値引が発生した場合の分納ステータスの更新方法を、あらかじめ決めておきます。例外処理を後回しにすると、担当者の個別判断に依存する範囲が広がります。

属人化・送料・支払後ろ倒し——分納で起きやすい失敗と回避策

分納の設計が不十分な場合に起きやすい失敗には共通の型があります。ここでは4つの失敗パターンと、それぞれの回避の打ち手を整理します。

属人化が進むと、担当者が不在の際に出荷判断や請求突合が止まり、受領日から60日以内という支払期日の規定^*1を守れなくなる可能性があります。属人化のリスクは、在庫・帳票・請求のいずれか1か所ではなく、3か所同時に表れる点に注意が必要です。

分納要件を要件定義・RFPに落とす

ベンダーに確認する7項目（順位根拠：着手順序の依存関係）

この7項目はRFPの評価軸に転記できる形にしてあります。着手順序に依存関係があるため、上位の項目が未確定のまま下位の確認を進めると、要件の手戻りが生じやすくなります。

「システムで持つ」「運用で持つ」の線引き

受注明細と出荷明細の1:N管理、在庫引当、帳票番号の発番は、システムで持つべき範囲です。取引先ごとの分納可否の交渉や、例外発生時の最終判断は、運用側で持つ範囲として残ります。

受発注データモデルの設計とEDI連携の要件定義には、業務要件を整理する担当者とシステム側の設計者の両方が必要です。どちらか一方だけで進めると、システムで持つ範囲と運用で持つ範囲の線引きが曖昧になり、要件定義の後戻りにつながりやすいでしょう。

スモールスタートの起点は分納フラグと出荷単位の在庫引当

すべての機能を一度に実装するのではなく、取引先ごとの分納可否フラグと、出荷単位の在庫引当から着手する進め方が現実的です。この2点が整えば、納品書の分割発行や請求突合は既存の帳票機能を拡張する形で対応しやすくなります。

まとめ：分割納品対応を支える3つの判断軸

本稿では、BtoB ECの分割納品（分納）対応を、法令・税務、システム要件、運用設計の3面から整理しました。要点は3つに集約できます。第一に、支払期日は受領日ごとに起算される点です。

第二に、受注明細と出荷明細の1:N管理がシステム要件の土台になる点です。第三に、分納可否と最小出荷単位を取引先ごとに決めることが、運用設計の起点です。この3つの判断軸を押さえておけば、要件定義やRFPの場でも社内外に説明しやすくなります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

分納した場合、支払期日はいつを起点に数えますか。

起点は各回の受領日です。取適法は、検査の有無を問わず受領日から起算して60日以内（受領日を算入）に支払期日を定める義務を委託事業者に課しています^*1。分納では出荷（受領）ごとに起算日が生じるため、まとめて数える運用は前提が異なります。

分納のたびに請求書を発行する必要がありますか。

必須ではありません。国税庁のQ&Aは、納品書と請求書を組み合わせて一の適格請求書とする方法を示しています^*2。出荷のたびに納品書を発行し、請求書側で納品書番号を紐づければ、請求書自体は月単位でまとめる運用も可能です。

納品書だけでインボイスの要件を満たせますか。

納品書のみでは記載事項が不足する場合があります。登録番号は請求書に記載し、税率ごとの区分と消費税額等は納品書に記載する形で、両者を合わせて記載事項を満たす方法が示されています^*2。端数処理は納品書につき税率ごとに1回行います。

分納したときの送料はどう扱えばよいですか。

送料の按分方法そのものを直接定める一次情報は確認できていません［要追加：送料按分に関する契約条項・社内基準の確認］。出荷回数分をそのまま請求すると取引先との認識差につながりやすいため、契約時に按分方法を明文化しておくことが実務上の対応と言えるでしょう。

基幹システムで分納処理をしている場合、BtoB EC側は何を持つべきですか。

出荷実績をEC側に返す仕組みが要点です。受注明細と出荷明細を1:Nで管理し、出荷単位の残数と分納ステータスをEC側でも保持することで、基幹システムの処理結果が反映されないという失敗を避けられます。

1. *1　出典：公正取引委員会・中小企業庁「中小受託取引適正化法テキスト」（令和7年11月）
2. *2　出典：国税庁「インボイス制度に関するQ&A 問67」（平成30年11月追加・令和5年10月改訂）
3. *3　出典：経済産業省「令和6年度電子商取引に関する市場調査」（2025年8月26日公表）
4. *4　出典：一般財団法人流通システム開発センター「流通BMS標準仕様」
5. *5　出典：企業会計基準委員会「企業会計基準第29号「収益認識に関する会計基準」等の公表」（平成30年3月30日）