販売管理システムの開発で最初に詰まる4つ【2026年版】受注から入金消込までの業務要件と、インボイス・電子帳簿保存法への対応

「販売管理システムを作り替えたいが、どこから決めればいいのか分からない」——長く使ってきた基幹システムの更改を控えた方から、こうした相談をよく受けます。受注画面や請求書の様式は想像できる。けれども、見積から入金消込までを一本の線でつなごうとすると、途端に自社の商習慣が顔を出して止まってしまう。カタログに並んだ機能一覧を見ても、自社が引っかかるのはそこではない気がする。そういう感覚は、だいたい正しいのが実情です。

結論から言うと、販売管理システムの開発で最初に詰まるのは、単価体系、与信と掛売、返品・値引き、締め日と請求の締め処理の4つです。いずれも「金額が確定していく端」にあり、自社の商習慣がそのまま設計要件になる場所です。ここを先に固めれば、画面や帳票は後から足せます。逆にここを曖昧にしたまま進めると、稼働後に毎月手作業の訂正が発生し、請求業務が元のExcelに戻っていきます。

もうひとつ、販売管理には在庫管理との境目という固有の難所があります。引当在庫を販売側で持つのか在庫側で持つのか、どちらの数字を正とするのか。この一線を決めずに作ると、棚卸のたびに数字が合わなくなります。制度対応も同じで、インボイス制度や電子帳簿保存法が求めているのは請求書の見た目ではなく、返品・値引きの処理とデータの保存方法です。

本記事では、販売管理の業務フローと在庫管理との境目、要件で最初に詰まる4つ、インボイス制度と電子帳簿保存法が求めること(国税庁の公開資料で確認)、パッケージで足りるかスクラッチかの分岐とExcel運用からの移行、外部チームで作る場合の進め方、よくある質問の順に解説します。費用相場と開発会社の選び方は別の記事に譲り、この記事は販売管理という業務そのものに絞ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。販売管理まわりの相談で必ず出てくるのは「20日締めと月末締めが混在する」「出荷後に値引きが入る」「得意先別の特価が数万行ある」の3つです。珍しい商習慣ではありません。整理されていないだけということも多い。この記事を読み終えるころには、自社の何が標準機能で吸収でき、何を作り込む必要があるのかを切り分けられるはずです。

販売管理システムが扱う業務——見積・受注から出荷、売上計上、請求、入金消込までの一本線

販売管理システムは「受注を入力して請求書を出すシステム」と説明されることが多いのですが、実際に設計してみると、見積から入金消込までの8つの工程が一本の線でつながった業務だと分かります。前の工程で決めた数字が、そのまま次の工程の金額になる。だから途中で一か所でも曖昧なところがあると、最後の請求と入金で必ず食い違いが出ます。まずはこの線の全体像を押さえてください。

業務フローの8工程と、各工程で確定するもの

販売管理の業務は、おおむね次の8工程に分解できます。機能一覧ではなく「各工程で何が確定するか」で見ると、設計で決めるべきことがはっきりします。

この8工程のうち、1〜5は「モノの流れ」、6〜8は「お金の流れ」です。販売管理システムの設計が難しくなるのは、この2つの流れが工程6で合流するからです。工程5までは数量の世界で、工程6以降は金額の世界になる。合流点の定義——どの時点で売上を立てるのか——を最初に決めておかないと、月次の締めが毎回もめます。当社が相談を受けるときも、まずここを確認します。

販売管理と在庫管理の境目——引当在庫・有効在庫・実在庫のどれをどちらが持つか

販売管理システムを作るとき、ほぼ必ず議論になるのが在庫の扱いです。結論から言うと、在庫の数字は3種類あり、それぞれ持ち主を決める必要があります。

• 実在庫: 倉庫に実際にある数。入出庫と棚卸で動く。持ち主は在庫管理(倉庫)側
• 引当在庫: 受注に対して確保済みの数。受注の成立で増え、出荷で消える。持ち主は販売管理側
• 有効在庫: 実在庫から引当在庫を引いた、これから売れる数。計算値であって、どこかに実体として持つものではない

この3つを混ぜて1つの「在庫数」にすると、受注を取った瞬間に倉庫の在庫が減ったように見えたり、逆に出荷済みなのに引当が残ったりします。棚卸のたびに差異が出て、原因を追いかける担当者の時間が毎月削られる。これは要注意です。在庫管理システムを別に立てるかどうかは規模次第ですが、自作の限界と破綻の境界線については「在庫管理システム 自作」の記事で整理していますので、在庫側の設計を詰める段階で参照してください。

購買(仕入)管理との関係と、受注の粒度——明細単位・分納・直送

販売管理は、その裏側で購買(仕入)管理とつながっています。在庫を持たずに受注のたびに仕入れる商流(受注生産や直送)では、受注伝票と発注伝票を紐づけておかないと、粗利が出せません。ここで効いてくるのが「受注の粒度」です。

受注を伝票単位で扱うか、明細単位で扱うかで、設計は大きく変わります。伝票単位だと実装は軽くなりますが、10明細のうち3明細だけ先に出荷する分納ができません。明細単位にすると分納・一部キャンセル・明細ごとの納期に対応できる代わりに、受注残の管理と画面が複雑になります。私が見てきた範囲では、卸売と製造の販売管理はほぼ例外なく明細単位が必要でした。小売や単品のサービス販売であれば伝票単位で足ります。

では、この一本線のどこで実際に手が止まるのか。次に、要件定義の場で最初に詰まる4つを見ていきます。

販売管理の要件で最初に詰まる4つ——単価体系、与信と掛売、返品・値引き、締め処理

要件定義の場で議論が止まるのは、決まって同じ4か所です。単価体系、与信と掛売、返品・値引き、締め日と請求の締め処理。どれも「金額が確定していく端」にあり、長年の商習慣が現場の記憶と口頭運用に散らばっています。仕様書に書かれていないルールが、稼働直前に出てくる。この4つを先に紙に落とすことが、販売管理システム開発の実質的なスタートです。

詰まる4つの一覧表——何が起きるか、設計で決めること

この4つは、どれも「業務システム一般」の話ではなく、販売管理に固有のものです。業務システム開発全体の費用感や規模別のレンジを知りたい場合は「業務システム 開発 外注 費用」の記事に譲りますが、見積金額が会社によって大きく違う理由の大半は、この4つをどこまで作り込む前提で積算しているかの差だと考えてください。

単価体系——得意先別単価、数量単価、キャンペーン、特価伝票の優先順位を1本に決める

私が相談を受ける販売管理の案件で、最も頻度が高いのが「得意先別の特価が数万行ある」という状態です。先日も、得意先1,200社・商品8,000点に対して特価が約4万行という会社の相談がありました。これ自体は珍しくありません。問題は、その4万行と、数量単価表と、期間限定キャンペーンと、営業が伝票上で直接書き換える特価が、同時に存在していることです。

設計で決めるのは、どれが勝つかという優先順位です。一般的には次の順になります。

1. 伝票入力時に手入力された特価(理由コードと承認者を必ず残す)
2. 期間限定キャンペーン単価(適用期間と対象得意先グループで判定)
3. 数量単価(数量帯ごとの単価。受注数量の変更で再判定が要る)
4. 得意先別単価(得意先×商品のマスタ。改定履歴を日付で持つ)
5. 標準売価(商品マスタ)

大事なのは、単価マスタに「適用開始日」を必ず持たせることです。改定前の単価で受注した分が、改定後に請求されてしまう事故は、履歴を持たない設計で必ず起きます。また、手入力の特価には理由コードを付けておくと、後から「なぜこの価格だったのか」を追えます。パッケージを評価するときも、この5段階が標準機能でどこまで表現できるかを確かめてください。

与信管理と掛売——与信限度のチェックをどの工程に置くか

掛売(締め請求)を行う会社では、与信管理がシステム要件に入ってきます。決めることは3つです。

与信限度の持ち方。 得意先単位か、企業グループ単位か。グループ単位なら親子関係をマスタで持つ必要があります。チェックを置く工程。 受注時にチェックすると営業の入力が止まり、出荷指示時にチェックすると倉庫作業が止まります。実務では「受注時に警告、出荷指示時に停止」という二段構えが扱いやすいことが多いです。超過時の挙動。 誰の承認で通すのか、承認履歴を残すのか。

与信残枠の計算式も定義が要ります。受注残を含めるか、出荷済み未請求を含めるか、手形の未決済分をどう扱うか。ここを曖昧にしたまま「与信機能あり」と書かれた見積もりを比べても、意味がありません。

返品・値引きと締め日——赤伝の起こし方、複数締めの持ち方、締め後訂正の扱い

出荷後に値引きが入る。これも相談で必ず出てくる話です。計上済みの売上を戻す処理は、一般に赤伝(マイナス伝票)で行いますが、設計では次を決めます。元の売上伝票と紐づけるか単独で起こすか、計上日を元伝票の日付にするか処理日にするか、税率は元取引の税率に従うか。税率については、売上げに係る対価の返還等の適用税率は、その基となった課税資産の譲渡等の適用税率に従うと国税庁が示しています(2026年9月19日確認)。つまり元取引が8%なら返還も8%です。これはシステム側で自動的に引き継ぐ設計にしておくのが安全です。

締め処理は、締めパターンをマスタで持つところから始まります。20日締め・月末締め・5日締めが混在するのは普通のことなので、得意先マスタに締日コードを持たせ、請求の締め処理を締日コード単位で走らせます。次に決めるのが締め後訂正です。方式は2つあります。

どちらか一方に決めきるのではなく、「送付前は締め解除、送付後は次回繰越」と運用ルールで切り分けている会社が多い印象です。

この4つを最初から例外まで全部作ろうとするのが、失敗のもとです。件数の多い8割を標準機能で通し、残りは運用で回して次の版で載せる。この割り切りができるかどうかで、稼働までの期間が半分違ってきます。

制度対応——インボイス制度と電子帳簿保存法が販売管理システムに求めること【2026年9月19日時点】

制度対応というと請求書の様式変更を思い浮かべがちですが、販売管理システムにとって本当に効いてくるのは、記載事項そのものよりも返品・値引きの処理とデータの保存方法です。ここでは国税庁の公開資料を直接確認したうえで、システム設計に落ちる部分だけを整理します。なお、以下は制度をシステム要件に翻訳するための整理であり、法的・税務的な助言ではありません。自社の取引への当てはめは、顧問税理士または所轄の税務署にご確認ください。

適格請求書の記載事項6つと簡易インボイス——国税庁の記載に基づく

国税庁は、インボイス(適格請求書)を「以下の事項が記載された書類やデータ」とし、請求書に限らず領収書や納品書など名称を問わないとしています(2026年9月19日確認)。

設計で効くのは⑤と⑥です。税率ごとの合計と消費税額を請求書単位で求める必要があるため、伝票ごとに税額を丸めて積み上げる従来の作りだと差異が出ます。税率別の集計を先にしてから端数処理する順序に直してください。

簡易インボイス(適格簡易請求書)については、国税庁は「不特定多数の者に対して販売等を行う小売業、飲食店業、タクシー業では、インボイスの記載事項の一部を省略した簡易インボイスを交付することができる」とし、①宛先は省略してよい、②税率又は税額のどちらか一方の記載でよい、としています。店舗レシートと法人向け請求書を同じシステムで出す小売チェーンでは、帳票テンプレートを分けておくと運用が楽になります。

なお売手側の義務として、国税庁は「買手側(取引相手である課税事業者)から求められたときは、インボイスを交付しなければならない」「交付したインボイスの写しは、保存しておく必要があります」と明記しています。交付だけでなく控えの保存までがシステムの要件だという点は、見落とされやすいところです。

返品・値引きと適格返還請求書、税込1万円未満の交付義務免除

前の章で触れた赤伝の処理は、そのまま制度対応につながります。国税庁は、インボイス発行事業者が返品や値引き、割戻しなどの売上げに係る対価の返還等を行った場合には返還インボイス(適格返還請求書)の交付義務があるとしたうえで、その金額が税込1万円未満である場合には交付義務が免除されるとしています(新消法57の4③、新消令70の9③二)。例として、売手が負担する振込手数料相当額を売上値引きとして処理している場合は、通常1万円未満となるため交付義務が免除される、と示されています。

システム設計に落とすと、次の3点になります。

• 返還の金額が税込1万円未満かどうかを判定し、1万円以上のときだけ返還インボイスの交付対象としてフラグを立てる
• 返還の適用税率は、その基となった課税資産の譲渡等の適用税率に従う。元伝票の税率を自動で引き継ぐ
• 振込手数料相当額を「支払手数料」として経理処理しつつ消費税法上は売上げに係る対価の返還等とする場合、国税庁は通常の支払手数料と判別できるようにコードを分けるなどの対応が考えられるとしている。勘定科目コードの設計に反映する

請求書と返還請求書を1つの書類にまとめて交付することも認められています。当月の請求書に「前月値引き」の行を載せている会社は、必要事項がそろっているかを一度確認しておくと安心です。

電子帳簿保存法——電子取引データ保存の真実性4措置と検索要件3つ

請求書をPDFでメール送信したり、Web上でダウンロードさせたりする販売管理システムを作るなら、電子帳簿保存法の電子取引の区分が関係します。国税庁の一問一答【電子取引関係】によれば、電磁的記録の保存等には真実性と可視性を確保するための要件を満たす必要があり、真実性については次の4つのいずれかの措置を行うこととされています。

1. タイムスタンプが付された後の授受
2. 授受後遅滞なくタイムスタンプを付す
3. データの訂正削除を行った場合にその記録が残るシステム、又は訂正削除ができないシステムを利用
4. 訂正削除の防止に関する事務処理規程の備付け

自社開発の販売管理システムなら、3番目を設計で満たすのが素直です。伝票と帳票データを論理削除にし、更新履歴を別テーブルに残す作りにしておけば、追加のタイムスタンプサービスを使わずに済みます。当社が担当した決済アプリの開発でも、PDF帳票の発行履歴を残す作りにしました。

可視性については、見読可能装置(ディスプレイ・プリンタ等)の備付け、自社開発のプログラムを使用する場合に限りシステムの概要を記載した書類の備付け、そして検索機能の確保が挙げられています。スクラッチ開発を選ぶ場合、システム概要書は法令要件として必要になるという点は覚えておいてください。検索機能の要件は次の3つです。

• 取引年月日その他の日付、取引金額その他の国税関係書類の種類に応じた主要な記録項目を検索の条件として設定することができること
• 日付又は金額に係る記録項目については、その範囲を指定して条件を設定することができること
• 二以上の任意の記録項目を組み合わせて条件を設定することができること

国税庁は、3つ目について「A又はB」の組合せは必要なく、一の記録項目で検索してから別の記録項目で絞り込む段階的な検索でも要件を満たすとしています。また、保存されている電磁的記録は原則として一課税期間を通じて検索できる必要があるとしたうえで、データ量が膨大で複数媒体に保存せざるを得ないなど合理的な理由がある場合は、その合理的な期間ごとの検索でも差し支えないとしています。ディスプレイやプリンタの性能・設置台数は要件とされていない点、画面印刷(ハードコピー)でも整然とした形式で速やかに出力できれば認められる点も明記されています。

ここまでが、国税庁の公開資料から読み取れるシステム要件です。繰り返しになりますが、自社の取引に制度がどう当てはまるかの判断は税務の領域です。開発側は「要件を満たせる作りにしておく」ところまでを担い、適用の可否は税理士に確認するという線引きをしておくと、後で揉めません。

パッケージで足りるか、作るか——分岐の判断軸と、Excel運用からの移行で詰まるところ

「うちは特殊だからパッケージでは無理だ」という言葉を、販売管理の相談ではほぼ毎回聞きます。けれども実際に業務を分解してみると、特殊なのは全工程のうち2つか3つで、残りは標準機能で通ることのほうが多いのが実情です。作るか買うかは、機能の有無ではなく「標準から外れる例外が、年に何件、いくらの手作業を生んでいるか」で決めてください。なお、スクラッチとパッケージ、ノーコードの一般的な比較は「スクラッチ開発とは」と「ノーコードとは」の記事に譲り、ここでは販売管理に固有の分かれ目だけを扱います。

分岐の判断軸4つ——標準機能で吸収できるか、例外の件数、連携の数、10年後の保守

4つのうち2つ以上がスクラッチ側に寄るなら作る、そうでなければパッケージかカスタマイズを先に検討する。これが実務的な目安です。費用の桁で判断したくなりますが、規模別・機能別の費用レンジは「業務システム 開発 外注 費用」の記事にまとめてありますので、そちらで当たりを付けてから戻ってきてください。パッケージ製品の料金はプランや同時接続数で変わるため、必ず各社の公式ページで最新の条件を確認することをお勧めします。

ひとつ補足すると、販売管理のパッケージには「標準機能で足りるのに、現行システムの画面と同じにしたい」という理由でカスタマイズが積み上がる傾向があります。画面の見た目を揃えるための作り込みは、10年後の保守を最も重くする支出です。ここは割り切ったほうが賢明です。

会計・在庫・ECとの連携設計——マスタの正はどちらか、仕訳の粒度、連携の頻度

販売管理システムは単体では完結しません。連携設計で決めるのは3つです。

マスタの正をどちらに置くか。 得意先マスタは販売管理と会計の双方にありますが、両方で新規登録できる作りにすると、必ず二重登録が起きます。どちらかを正として片方向に流す。商品マスタも同様で、EC側と販売管理側の双方で登録できる状態は事故のもとです。

仕訳の粒度。 売上仕訳を伝票単位で送るか、締め後に得意先別・税率別の合計で送るか。伝票単位は会計側で明細が追えますが、件数が多い会社では会計システムが重くなります。実務では「売上は締め後の合計、入金は個別」という分け方が多く見られます。

連携の頻度と方向。 日次バッチか、リアルタイムAPIか。在庫は出荷のたびに動くのでリアルタイムに寄せたくなりますが、夜間の締め処理との整合を考えると、在庫引当はリアルタイム、実在庫の同期は日次という組み合わせが扱いやすい構成です。

ECサイトを持っている場合は、受注取り込みの重複対策も要件になります。同じ注文が二重に取り込まれないよう、EC側の注文番号を一意キーとして販売管理側に持たせてください。

Excel・Accessからの移行で最初に詰まる3つ——得意先の表記ゆれ、単価の履歴、過去伝票の範囲

Excelや Access で長年回してきた運用から移行するとき、最初に止まるのは機能ではなくデータです。私が見てきた範囲では、決まって次の3つでした。

1. 得意先の表記ゆれ。 「株式会社○○」「(株)○○」「○○」が別行として存在し、支店違いも混ざっている。名寄せをしないと与信も売掛残も合いません。移行作業のうち最も時間がかかるのがここで、1,000社規模なら数週間は見ておく必要があります
2. 単価の履歴がない。 Excelの単価表は「今の単価」しか持っていないことがほとんどです。過去伝票を移行しようとすると、当時の単価が再現できず、金額が合わない。過去伝票は単価を再計算せず、金額をそのまま取り込む設計にしてください
3. 過去伝票をどこまで移すか。 全期間を移そうとすると、データ品質の悪い古い伝票の補正に工数が吸われます。売掛の未消込残と、直近1〜2年の実績だけを移し、それ以前は参照用に別途保管する。この割り切りができると移行は一気に軽くなります

移行は、マスタ(得意先・商品・単価)、残高(売掛・在庫)、伝票履歴の3つの塊に分けて進めてください。この順に固め、それぞれ本番同等のデータで2回ずつリハーサルをする。並行稼働の期間は、締めを1回丸ごと通せるよう最低1か月取ります。

販売管理システムを外部チームで作る場合の進め方——当社の体制と、パッケージで十分なケース

販売管理は止められない業務です。だからこそ、外部チームに渡すときは「全部を一度に作ってもらう」発注ではなく、一本線の骨格から段階的に載せていく進め方が向いています。ここでは社内で先に決めておくこと、最初の3か月の置き方、当社に依頼する場合の体制、そして作らないほうがよいケースを順に書きます。

外部チームに渡す前に社内で決めておく5つと、最初の3か月の置き方

開発会社を探す前に、次の5つを社内で紙に落としてください。これがないまま相見積もりを取ると、各社の前提がばらばらになり、金額を比べる意味がなくなります。

1. 単価決定の優先順位(前述の5段階のうち、自社で実際に使っているもの)
2. 締めパターンの一覧(締日コードと、該当する得意先の件数)
3. 与信チェックを置く工程と、超過時の承認者
4. 返品・値引きの年間件数と、赤伝の起こし方
5. 連携する外部システムの名前と、マスタの正をどちらに置くか

要件定義そのものの進め方は「要件定義 進め方」の記事に整理していますので、社内の合意形成を含めた手順はそちらを参照してください。開発会社の比較軸は「システム開発会社 選び方」の記事にあります。

最初の3か月は、見積・受注・出荷・売上計上という一本線の骨格だけを作ります。請求と入金消込は現行のまま残し、売上データだけを新システムから出す。この順にすると、万一遅れても請求は止まりません。逆に請求から作り始めると、締め日に間に合わなかった時点で業務が止まります。順番の設計が、販売管理では品質そのものです。

当社の体制——日本人PMフロント、1名から、1か月単位の増減

当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする形を取っており、協力会社や紹介を経由しないため仲介マージンが乗りません。体制は、日本人PM/ブリッジSEをフロントに置いてベトナム人エンジニアが実装するパターンA(推奨)と、エンジニアのみのパターンBの2つです。販売管理のように業務知識のすり合わせが多い案件は、パターンAをお勧めしています。

単価は公開しており、実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で2,000USD、10年・ブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で月額約80万円からになります。1名から契約でき、開始は最短2週間、増員は約1週間、縮小・交代は1か月単位です。流れは、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質は3点で担保しています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。販売管理では金額計算のテストが命綱になるため、単価決定・税額計算・締め処理はテストケースを先に書いてから実装する進め方を取ります。介護記録SaaS「CareViewer」では日本語ブリッジSE1名とフルスタック2名の体制で、要件が動く前提の開発を週次の優先順位判断で回しています。ベトナムとの時差は2時間で、午前中から同じ時間帯で動けます。

パッケージで十分なケース——この3つに当てはまるなら作らないほうがよい

正直に書きます。次の3つに当てはまる会社には、当社は開発ではなくパッケージ導入をお勧めしています。

• 締めパターンが1種類で、得意先別特価がほとんどない。 標準機能の範囲に業務が収まっており、作る理由が見当たりません
• 返品・値引きが月に数件で、手作業でも回せている。 自動化の投資が回収できません
• 社内に要件を決め切れる人がいない。 スクラッチは決める人がいないと止まります。パッケージなら「製品の作法に合わせる」という決め方ができます

作らない判断の考え方そのものは「社内システム 開発」の記事にも整理しています。当社に相談いただいた場合も、この3つに当てはまれば率直にその旨をお伝えします。合わない案件を無理に受けても、続かないからです。

販売管理システムの開発でよくある質問

販売管理システムの開発について、検討段階でよく受ける質問を5つ挙げます。本文で扱った論点と重ならない範囲で、短く答えます。

Q1. 開発期間はどのくらいかかりますか

一本線の骨格(見積・受注・出荷・売上計上)までなら3〜4か月、請求と入金消込を含めて6〜9か月、移行とリハーサルを含めると9〜12か月が一つの目安です。ただし期間を決めるのは機能の数ではなく、単価・締め・返品の例外をいくつ実装するかです。社内で5つの前提が固まっていれば、この目安に収まります。

Q2. 見積もりを比べるとき、どこを見ればよいですか

金額の総額ではなく、単価決定ルールを何段階実装する前提か、締めパターンをいくつ持つ前提か、連携先が何本か、データ移行の対象期間がいつからか、の4点を各社に同じ条件で示して出し直してもらってください。ここが揃っていない見積もりは、比べても意味がありません。

Q3. パッケージのカスタマイズとスクラッチは、どう違いますか

カスタマイズは製品のバージョンアップに追随する義務が発生し、作り込み部分は更新のたびに検証が要ります。スクラッチは追随義務がない代わりに、セキュリティ更新やライブラリの更新を自分たちで計画しなければなりません。どちらが楽かではなく、10年間どちらの負担を引き受けられるかで選んでください。

Q4. 在庫管理は販売管理システムに含めるべきですか

拠点が1か所で、ロットや使用期限の管理が不要なら、販売管理システムに在庫を含めて問題ありません。複数拠点、ロット・期限管理、入出庫のハンディ端末運用のいずれかが必要になった時点で、在庫側を分けることを検討してください。境目の設計は本文のh2-1で触れたとおりです。

Q5. インボイスや電子帳簿保存法への対応は、自社開発のシステムでもできますか

可能です。国税庁の一問一答では、電子取引データの真実性を確保する措置として「訂正削除の記録が残るシステム、又は訂正削除ができないシステムを利用」する方法が挙げられており、自社開発でも設計で満たせます。ただし自社開発のプログラムを使用する場合はシステムの概要を記載した書類の備付けが要件とされている点に注意が必要です。制度の当てはめ自体は税務の判断であり、確認先は顧問税理士または所轄の税務署。

まとめ: 販売管理は「お金の端」で決まる——4つを先に固め、足りない分だけ作る

販売管理システムの開発で最初に詰まるのは、単価体系、与信と掛売、返品・値引き、締め日と請求の締め処理の4つです。見積から入金消込までの8工程は一本の線でつながっており、前工程の数字がそのまま後工程の金額になります。だから金額が確定していく端に自社の商習慣が集中し、そこが設計要件になる。あわせて、引当在庫を販売側で持つか在庫側で持つかという境目も、最初に決めておく必要があります。

制度対応は、請求書の様式よりも処理の中身に効きます。適格請求書の記載事項6つは税率ごとの集計と端数処理の順序を変えますし、返品・値引きは適格返還請求書の交付義務(税込1万円未満は免除)と適用税率の引き継ぎに直結します。電子帳簿保存法の電子取引データ保存では、訂正削除の記録が残るシステムを利用する方法で真実性を満たせる一方、自社開発のプログラムを使う場合はシステム概要書の備付けが要件になります。いずれも2026年9月19日時点の国税庁の公開資料に基づく整理で、自社の取引への当てはめは顧問税理士または所轄の税務署にご確認ください。

作るか買うかは、標準から外れる例外が年に何件・いくらの手作業を生んでいるかで決めてください。締めパターンが1種類で特価がほとんどなく、返品も月数件で回せているなら、パッケージで十分です。作る場合も、最初の3か月は見積・受注・出荷・売上計上という骨格だけを載せ、請求は現行のまま残す。この順番なら業務は止まりません。規模別の費用レンジは業務システム開発を外注する費用、在庫側の設計は在庫管理システムの自作もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、パッケージで足りるかどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。