買掛管理システム導入の要件定義｜決めること・抜けやすい項目・合意の進め方

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

B2B EC-COLUMN

買掛管理の要件定義で決めることと、機能一覧との違い

買掛管理システムの導入を任されたものの、製品の機能一覧を眺めるほど、何を決めれば要件定義として足りるのかが分からなくなる。
請求書がメール・紙・取引先のサイトなどばらばらに届き、照合や支払の段取りが担当者の頭の中にあると、製品のどこを見ればよいかも決まりません。
買掛の要件定義は、機能を並べる作業ではありません。
請求書の受領から照合・支払・仕訳・締めまでの今の流れを書き出し、困りごとを要件の文に置き換える作業です。
そのうえで、電子取引の保存やインボイスのように制度上外せない要件と、支払データや会計連携のように条件次第で後回しにできる要件を分けます。
例外・承認・移行の抜けを確かめて関係部署と合意すれば、製品比較へ進めます。

業務要件と機能要件を分ける

製品資料に並ぶ機能名を表にしてチェックを付けていくと、要件定義をしたような手応えがあります。
ところが、その表からは「なぜその機能が要るのか」「無いと何が困るのか」が読み取れません。
上司や関係部署に説明するときも、製品ごとに同じ機能を違う言葉で書いている資料を比べるときも、判断の拠り所がなくなります。

独立行政法人情報処理推進機構（IPA）の『ユーザのための要件定義ガイド 第2版』は、要件定義でつまずきやすい問題と解決の勘どころを組にして示す構成で、業務要件とシステム要件を別々の章で扱い、要件の管理や文書の作り方、付録として機能要件の合意形成のガイドを置いています¹。
このガイドは2019年に公開され、冊子は2024年に販売を終えています¹。

ここから借りたいのは、「業務で何を成り立たせたいか」と「システムに何をさせるか」を分けて決めるという考え方です。
以下はガイドの記述ではなく、その構成を手がかりに買掛業務へ当てはめた整理です。
業務要件は、業務の結果として何が成り立っていればよいかを書きます。
たとえば「月次の締めの前に、当月分の請求書をすべて受領・照合済みにする」「支払予定額を支払日の前に経理責任者が確認できる」といった文です。

機能要件は、その業務要件を成り立たせるためにシステムが受け持つことです。
先の例なら「受領した請求書を取引先・日付・金額で一覧できる」「照合済みかどうかが分かる」「支払予定を支払日ごとに集計できる」「承認の状況が分かる」などが下に付きます。
業務要件から機能要件へ下りていくと、一つの機能に複数の理由がつながることも、理由の見当たらない機能が混ざっていたことも見えてきます。
理由のない機能は、比較の場面で優先度を下げてよい候補です。

要件定義で決めずに残すもの

要件定義で決めるのは、満たすべき条件とその優先度です。
製品名、画面の作り、帳票の細かな体裁、操作の手順は、比較・選定や導入時の設定で決まる部分です。
ここで固めてしまうと、特定の製品の作りを前提にした要件になり、他の製品を同じ物差しで比べにくくなります。

一方で、要件とは別に書き留めておくべきこともあります。
予算の上限や稼働させたい時期は、要件というより前提条件です。
要件表とは分けて書いておくと、比較の場面で「要件は満たすが時期に間に合わない」製品を、要件を満たさない製品と混同せずに扱えます。

▼ 図の内容を文字で読む

1. 業務要件：締めの前に当月分の請求書を受領・照合済みにする
   • 受領した請求書を取引先・日付・金額で一覧できる
   • 照合済みかどうかが分かる
2. 業務要件：支払予定額を支払日の前に経理責任者が確認できる
   • 支払予定を支払日ごとに集計できる
   • 承認の状況が分かる

請求書受領から支払・仕訳・締めまでの現状を書き出し、困りごとを要件に変える

受領形態ごとに流れを書く

業務要件を書くには、今の流れを言葉にする必要があります。
書き出す単位は「請求書が1通届いてから、その支払が仕訳され、月次の締めに入るまで」です。
工程は、受領、内容の確認と照合、承認、支払予定への登録、支払データの作成と支払、仕訳、締めの順に並べ、それぞれについて「誰が」「何を見て」「どこに記録するか」を書きます。

行は受領形態ごとに分けて書きます。
紙で郵送されるもの、メールにPDFが添付されるもの、取引先のサイトからダウンロードするもの。
同じ取引先でも月によって受け取り方が変わるなら、それも書いておきます。
形態で分けておくと、次に扱う電子取引の保存要件がどの請求書にかかるのかが、そのまま表から読み取れます。

受け取る書類の種類も洗い出します。
インボイス（適格請求書）は、売手の名称と登録番号、取引年月日、取引内容、税率ごとの対価の額と税額、買手の名称を記載した書類で、「請求書」という名前でなくても要件を満たせばインボイスになります³。
納品書、利用明細、請求書と、取引先ごとに何が届き何を保存しているかを並べると、照合の基準にしている書類と、税務上保存している書類が同じなのか違うのかも見えてきます。

書き出しを経理担当者だけで進めると、購買や現場の部署で止まっている請求書が見えません。
請求書が最初に届く場所が経理でない場合は、そこで受け取っている人に流れを聞き、経理に回ってくるまでの時間や経路も書き込みます。

困りごとを要件の文に置き換える

書き出した流れのうち、手で転記している所、承認待ちなどで止まる所、人によってやり方が違う所に印を付けます。
困りごとは、その印の場所で「何が起きて、その結果どう困るか」の形で書き、業務要件、機能要件の順に置き換えます。
次の三つは、置き換えの形を示すための仮の例です。

• メールで届いた請求書を担当者が自分のフォルダに保存しており、担当者が休むと誰も探せない → 業務要件「受領した請求書を担当者以外も同じ場所から探せる」 → 機能要件「請求書を取引先・日付・金額で検索できる」
• 支払予定を表計算ソフトに手で写し、振込データを作る前に金額を突き合わせ直している → 業務要件「支払予定と振込データが同じ元データから作られる」 → 機能要件「承認済みの請求書から支払予定と振込データを作れる」
• 承認者が不在だと承認が止まり、支払日に間に合うか経理が分からない → 業務要件「経理が承認の状況を把握し、不在時の代理を決められる」 → 機能要件「承認の状況を一覧でき、代理承認者を設定できる」

置き換えるときの要点は、解決の手段を要件の文に書き込まないことです。
「請求書を自動で読み取る」と書いた時点で手段が一つに決まり、困りごとが「手入力が多い」のか「入力ミスに気付けない」のかが要件表から消えます。
仮に読み取りの仕組みを入れても、手で打ち込む作業は減る一方で、読み取った金額が請求書と合っているかを確かめる作業は残ります。
困りごとの文を残しておけば、どの確認が減り、どの確認が残るのかを、製品を比べるときにも関係部署に説明するときにも示せます。

▼ 図の内容を文字で読む

1. 受領
   • 紙の郵送：紙の保管と照合へ
   • メール添付のPDF：電子取引のデータ保存の要件がかかる
   • 取引先サイトからのダウンロード：電子取引のデータ保存の要件がかかる
2. 内容の確認と照合
3. 承認
4. 支払予定への登録
5. 支払データの作成と支払
6. 仕訳
7. 締め

電子取引・インボイスへの対応：受領側で必須になる要件

電子で受け取る請求書の保存要件

書き出した表にメール添付やダウンロードの行があれば、そこは電子取引に当たり、受け取ったデータの保存に制度上の要件がかかります。
財務省の広報誌によると、電子取引データは紙に出力して保存するだけでは認められず、データ自体の保存が必要です²。
保存にあたっては、真実性を確保するための4つの措置のいずれかを取ること、可視性を確保すること、日付・金額・取引先で検索でき、範囲指定や項目の組み合わせでも検索できることが求められます²。

買掛の要件に直すと、「電子で受け取った請求書を元のデータのまま保存できる」「保存した請求書を日付・金額・取引先で、範囲指定や組み合わせで探せる」という二つの文になります。
この要件がかかるのは会社に対してであり、買掛管理システムそのものに対してではありません。
システムに保存の役割を持たせるのか、すでに使っている保存先で満たし、システムとは請求書を紐付けるだけにするのかは、選択の余地があります。
どちらにするかは、保存先が二か所に分かれたときに、照合や問い合わせ対応で請求書を探す手間が増えないかで考えます。

検索要件が不要になる条件

保存の要件のうち、検索については会社の条件で必須度が変わります。
基準期間（2課税年度前）の売上高が5,000万円以下の保存義務者、または電子取引データを紙に出力し、日付・取引先ごとに整理して提示できる場合は、検索要件は不要とされています²。
どちらも、税務調査でデータのダウンロードを求められたときに応じられることが前提です²。

ここで取り違えやすいのは、検索要件が外れても、データの保存そのものは外れないことです。
紙に出力して整理するやり方は検索の代わりになるもので、データを保存しなくてよくなるものではありません。

さらに、相当の理由があると税務署長が認め、ダウンロードの求めなどに応じられる場合は、データを保存するだけでよいとする猶予措置もあります²。
ただし、理由なく選べるものではありません²。
要件定義の前提にするかどうかは、顧問税理士などに自社が当てはまるかを確かめてから決めるほうが、後で要件を組み直さずに済みます。

売上高5,000万円以下で検索要件が外れる会社でも、要件表から検索を消してよいとは限りません。
取引先が多く、請求書を探す手間そのものが困りごとになっているなら、制度上の必須ではなく業務上の必要として残す判断もあります。
また、基準期間の売上高は年度ごとに変わります。
数年のうちに上限を超える見込みがあるなら、「今は制度上不要、将来は必須」と理由欄に書いておくと、比較の場面で後から検索を加えられるかを確かめる観点になります。

インボイスの保存と登録番号の確認

仕入税額控除を受けるには、インボイスの保存が必要です³。
受け取る側の要件は、「受け取った書類が記載事項を満たしているかを確かめる」と「インボイスを保存する」の二つに分かれます。
前者の中心は、売手の登録番号が記載されているか、取引先として登録している番号と食い違っていないかです。
どの工程で誰がこれを確かめるのかを、書き出した流れの照合の段に書き加えます。

簡易課税、2割特例、3割特例を適用している場合は、仕入税額控除のためのインボイスの取得・保存は不要ですが、所得税などの観点から書類の保存は必要です³。
つまり課税方式によって、登録番号の確認を必須にするかは変わっても、請求書を保存する仕組みは残ります。
また、インボイスについては2031年9月末まで一定割合を控除できる経過措置があります³。
インボイスの要件を満たさない書類が届いたときの処理は、この経過措置を含めて税理士と確かめ、例外処理の要件として書いておきます。

ここまでの条件を重ねると、電子で受け取る請求書の要件は「保存」「検索」「控除のための確認」の三つの観点に分かれ、売上高や課税方式によってどれが必須になるかが変わります。
この整理は財務省と国税庁の資料をもとにした編集上の分析で、特定の製品がどの要件に対応しているかを示すものではありません。

▼ 図の内容を文字で読む

1. メール添付・ダウンロードで請求書を受け取る
   • データのまま保存する（紙出力のみは不可）
   • 真実性・可視性を確保する
2. 基準期間の売上高が5,000万円以下
   • 検索要件は不要（ダウンロードの求めに応じることが前提）
   • データの保存は残る
3. 紙出力を日付・取引先ごとに整理して提示できる
   • 検索要件は不要（ダウンロードの求めに応じることが前提）
   • データの保存は残る
4. インボイスで仕入税額控除を受ける
   • インボイスを保存する
   • 記載事項と登録番号を確かめる
5. 簡易課税・2割特例・3割特例を適用する
   • インボイスの取得・保存は不要
   • 所得税等の観点の書類保存は必要

出典：財務省「ファイナンス」令和6年8月号（電子取引データの保存義務者が対象、2024年）、国税庁「インボイス制度の概要」

支払データと会計連携：条件別に必須と後回しを分ける

支払データ作成とZEDI

承認が済んだ請求書は支払予定になり、支払日に合わせて銀行へ振込を依頼します。
複数の取引先へまとめて振り込む総合振込を使っている会社では、支払予定から振込データを作る工程があります。
書き出しの段階で、この振込データの金額をどこから写しているかを見ておくと、どの転記を減らしたいのかが要件の文になります。

ZEDI（全銀EDIシステム）は、総合振込の際に支払通知番号や請求書番号などの情報を添付できる仕組みです⁴。
支払う側は請求データ付きの総合振込の作成を自動化でき、受け取る側は入金の消込の自動化に使えるとされています⁴。
買掛の担当者から見ると、効果は自社の振込データ作成と、支払を受け取る取引先の消込作業の二か所に分かれます。

そのため、ZEDIへの対応を最初から必須にするかは、自社の事情だけでは決まりません。
取引先から「どの請求書への支払か分からない」という問い合わせを受けているか、取引先が請求書番号などの添付を求めているか、利用している銀行で使えるかで判断が分かれます。
利用にあたって金融機関側での申込みや契約が必要になる場合もあるため、取引銀行に条件を確かめたうえで優先度を決めます。

ZEDIを後回しにする場合でも、前に挙げた「支払予定と振込データが同じ元データから作られる」という要件は残せます。
金額を手で打ち直さないことと、振込に請求書の情報を添えることは別の要件です。
前者だけを必須にし、後者を後回しにするという分け方もできます。

照合と会計連携の確認観点

照合の要件は、請求書を何と突き合わせているかで変わります。
発注書と比べる会社、納品や検収の記録と比べる会社、契約書の単価と比べる会社があり、取引先によって基準が違うこともあります。
突き合わせる相手が別のシステムにあるなら、そのデータを買掛管理の側に取り込むのか、人が二つの画面を見比べるのかで、システムに持たせる要件が変わります。

金額が合わないときの扱いも、照合の要件に含めます。
差額が小さいから端数処理の違い、大きいから誤請求、と金額の大小で原因を決めつけると、値引きや返品、送料の計上漏れを見落とします。
差異が出たら、明細と取引条件を照合して原因を判断し、その結果をどこに記録するかまでを要件の文にしておきます。

会計システムとの連携は、方式が製品と会計システムの組み合わせで変わるため、要件定義では方式より先に次の点を決めておきます。

• 今使っている会計システムと、仕訳を取り込む方法
• 勘定科目・部門・取引先のマスタを、どちらのシステムで正とするか
• 費用を計上する時点を、請求書の受領時とするか検収時とするか
• 支払の仕訳を、誰がいつ会計システムへ渡すか

会計連携を必須にするか後回しにするかは、今の二重入力がどれだけ締めを遅らせているかで考えます。
取引件数が少なく、仕訳を月末にまとめて入力しても締めに支障がないなら、まず受領と照合、支払の要件を固め、連携は次の段階に回す選択もあります。
反対に、買掛管理と会計の両方に同じ請求書を入力し、その突き合わせで締めが延びているなら、連携は最初から必須の側に置く理由があります。

抜けやすい要件：例外処理・承認・権限・データ移行

例外処理

現状の書き出しは、いつもの流れを書いた時点で終わったように見え、例外が抜けやすい作業です。
例外は件数が少なくても、締めの遅れや支払の誤りにつながりやすい場面です。
書き出した流れの各工程に、次のような場面が起きたら誰がどう扱っているかを書き加えます。

• 請求額が発注額や検収の記録と合わない
• 締めの後に前月分の請求書が届く
• 同じ請求書が紙とメールの両方で届く
• 登録番号の記載がない、または取引先として登録している番号と食い違う
• 取引先から請求書の訂正や再発行の連絡が来る
• 支払日の前に取引先から振込先口座の変更連絡が来る

登録番号の不備は、インボイスの記載事項と保存が仕入税額控除にかかわるため³、経理の判断だけで済ませにくい例外です。
誰が気付き、取引先に何を依頼し、正しい書類が届くまでの間その請求書をどう扱うかを決めておきます。

例外をすべてシステムで処理する必要はありません。
システムの外で扱う例外も、「どこで扱い、結果をシステムのどこに記録するか」を要件表に書いておけば、導入後に担当者ごとの判断へ戻ることを防げます。
同じ請求書が二つの経路で届く場面は、どちらか一方だけを支払予定に載せる確認が必要になるため、取り込みの段階で重複に気付ける仕組みを要件にするかを検討する材料になります。

承認・権限

承認の要件では、金額や取引先、費用の種類によって承認者が変わるか、承認者が不在のときの代理、承認後に請求書が訂正された場合にもう一度承認を通すかを決めます。
今の承認が紙への押印なら、その押印で何を確かめているのかを言葉にしておきます。
取引があった事実なのか、金額の妥当性なのか、予算内かどうかなのかによって、システム上で承認者に見せるべき情報が変わります。

権限の要件は、誰が何をできるかの分け方です。
請求書を登録する人、承認する人、振込データを作る人、銀行へ送る人を同じ人にしてよいか。
取引先の振込先口座を変更できる人を限るか。
口座の情報は支払先そのものを変えられるため、変更の登録と確認を別の人に分けるかどうかは、少人数の経理でも要件として一度決めておく価値があります。

IPAのガイドは、非機能要件の文書化や要件の管理も扱っています¹。
権限や操作の記録のように、機能の一覧には現れにくい要件を別に書き出しておくという考え方の手がかりになります。

データ移行

移行の対象は、取引先の情報（名称、振込先、登録番号）、切り替え時点で未払いの請求書、過去に受け取った請求書のデータに分かれます。
このうち取引先の情報は、移す前に重複や古い口座が残っていないかを整理しないと、新しいシステムにそのまま持ち込まれます。

過去の請求書のうち電子で受け取ったものは、データのまま保存しておく必要があります²。
古い保存先を使わなくなる場合は、過去分を新しいシステムへ移すのか、古い保存先に残して探せる状態を保つのかを決めておきます。
どちらを選んでも、日付・金額・取引先で探せるか、税務調査でダウンロードを求められたときに応じられるかという観点は変わりません。

切り替えの時期も要件の一部です。
月の途中で切り替えると、同じ月の請求書が古い仕組みと新しい仕組みに分かれ、締めのときに両方を見なければなりません。
締めの区切りで切り替えるか、しばらく並行して動かすかを決めておくと、未払いの請求書をどちらで支払うかの迷いが減ります。

関係部署と合意し、比較・選定へ渡す

合意に使う要件表

ここまでの書き出しを、一つの要件表にまとめます。
列は次のように置くと、合意にも比較にもそのまま使えます。

• 業務要件
• 機能要件
• 区分（必須・後回し・対象外）
• 理由（制度によるものか、業務上の困りごとか）
• 確認を頼む部署
• 確認の状況

理由の欄で制度と業務を分けておくのは、話し合いの余地が違うからです。
電子取引のデータ保存のように制度から来る必須は、費用や時期を理由に外せません。
一方、業務上の困りごとから来る要件は、費用や導入時期と比べて後回しにする判断ができます。
この区別が表にないと、会議で「全部必須」か「全部削る」かの議論になりがちです。

確認を頼む部署は会社によって違いますが、請求書が最初に届く現場や検収の担当、発注と取引先を管理する購買、会計連携やアカウント管理を受け持つ情報システムの担当は、書き出しの段階から関係します。
保存要件や課税方式の前提は顧問税理士に、予算と時期は決裁者に確かめます。
全員を一度に集めるより、部署ごとに関係する行を先に見てもらい、異論の出た行だけを全体で話し合うほうが、確認の範囲がはっきりします。

IPAのガイドが付録で機能要件の合意形成を扱っているように¹、合意は要件を書き終えた後のおまけではなく、要件定義の作業の一部として日程に入れておくものです。

比較時の確認観点

製品の比較では、要件表の必須の行をそのまま比較の行にし、各製品が満たすかを提供者の公式資料や問い合わせへの回答で確かめます。
資料に「対応」とあっても、標準の機能なのか、設定や追加の契約が要るのか、別の製品との組み合わせが前提なのかで意味が変わります。
どの条件で満たすのかを書いてもらうと、製品ごとの表現の違いに引きずられずに比べられます。

比較を進めると、製品の説明を読んで初めて思い当たる例外や、必須にしていた要件が実は業務上の好みだったと気付くことがあります。
そのときは比較表だけを書き換えず、要件表に戻って区分と理由を直し、関係する部署にもう一度確かめます。
要件表と比較表が食い違ったまま選定に進むと、導入後に「なぜこの要件を外したのか」を説明できなくなります。

後回しにした要件は、捨てたものとして扱わず、導入後に見直す時期を書いておきます。
ZEDIへの対応や会計連携のように、取引先や銀行の状況が変われば必須に上がる要件もあります。

▼ 図の内容を文字で読む

1. 要件表を作る（必須・後回し・対象外と理由を付ける）
2. 関係部署が担当する行を確かめて合意する
3. 製品ごとに必須要件を満たすかを公式資料や回答で確かめる
4. 不足や新たな例外に気付いたら要件表の区分と理由を見直す

受領形態、売上高や課税方式、取引銀行や会計システムの条件が重なると、どの要件を必須にするかを導入担当者だけで決めるのは難しくなります。

書き出した現状の流れをもとに、必須・後回し・対象外の切り分けと、関係部署や税理士に確かめる事項を一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
要件の書き方	業務で成り立たせたいことから、システムが受け持つことへ下りて書く
現状の書き出し	受領形態ごとに、誰が何を見てどこに記録するかを書く
電子取引	データ保存は外せない。検索要件は売上高5,000万円以下などの条件で不要
インボイス	保存と記載事項の確認。簡易課税等では取得・保存は不要だが書類保存は必要
支払・会計連携	取引先の消込の負担、銀行の条件、二重入力の影響で必須か後回しかを決める
合意と比較	区分と理由を付けた要件表で合意し、同じ表で製品を確かめ、気付きは表へ戻す

要件表ができても、製品ごとに「対応」の意味が違い、比較表の読み方で迷うことがあります。 要件表の必須の行ごとに、提供者へ何を質問すれば満たす条件を確かめられるかを一緒に整理できます。

よくある質問

電子で受け取った請求書を印刷して保存するだけでは足りないのか

足りません。
電子取引データは紙に出力して保存するだけでは認められず、データ自体の保存が必要です²。
紙に出力して日付・取引先ごとに整理する方法は、検索要件を不要にするための条件の一つであり、データの保存を不要にするものではありません²。

売上高5,000万円以下なら検索機能は要件から外してよいのか

基準期間（2課税年度前）の売上高が5,000万円以下の保存義務者は、制度上の検索要件は不要とされています²。
ただし、税務調査でデータのダウンロードを求められたときに応じられることが前提です²。
また、請求書を探す手間が業務上の困りごとになっているなら、制度とは別の理由で検索を残す判断もあります。
基準期間の売上高は年度ごとに変わるため、上限を超える見込みがあるなら、後から検索を加えられるかを比較の観点に入れておきます。

簡易課税や2割特例の会社でもインボイスの保存要件は必要か

簡易課税、2割特例、3割特例を適用している場合は、仕入税額控除のためのインボイスの取得・保存は不要です³。
ただし、所得税などの観点から書類の保存は必要です³。
登録番号の確認を必須にするかは課税方式で変わりますが、請求書を保存する仕組みは要件として残ります。

ZEDIへの対応は要件定義の段階で必須にすべきか

条件によります。
ZEDIは総合振込に請求書番号などの情報を添付でき、支払側の振込データ作成と、受け取る側の消込の自動化に使える仕組みです⁴。
取引先から支払内容の問い合わせを受けている、取引先が情報の添付を求めているといった事情があれば必須に近づきます。
利用している銀行での条件も確かめたうえで決め、後回しにする場合も見直す時期を要件表に書いておきます。

要件定義の段階で、経理担当者以外にどの部署を巻き込むべきか

請求書が最初に届く現場や検収の担当、発注と取引先を管理する購買、会計連携やアカウント管理を受け持つ情報システムの担当は、現状の書き出しの段階から関係します。
保存要件や課税方式の前提は顧問税理士に、予算と導入時期は決裁者に確かめます。
会社によって部署の分け方は違うため、書き出した流れで請求書が通る場所を基準に選ぶと漏れが減ります。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」（2019年）
2. 2　出典：財務省「広報誌「ファイナンス」令和6年8月号 電子帳簿等保存制度の内容と中小企業の対応策」（2024年）
3. 3　出典：国税庁「インボイス制度の概要（適格請求書等保存方式）」（2026年）
4. 4　出典：一般社団法人全国銀行協会「全銀EDIシステム（ZEDI）」（2025年）