◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 販売管理と在庫の連携が要るかは、入荷・受注・出荷・返品・棚卸のどこで同じ数字を二度入力しているかで見分ける
- 販売管理の在庫機能への一本化、別システムとの連携、手作業の整備は、品目数・件数・販売経路・保管場所・運用人数・止まったときの影響で比べる
- 連携するなら、在庫数を書き換えてよい場所を一つに決め、もう一方は読み取り専用にする
- 品目と販売経路を絞って試し、棚卸で数えた数と照合してから範囲を広げる
- 補助金は、機能要件と小規模事業者の扱いを公募要領で確かめ、方式と製品を絞ってから対象かを確かめる
目次

在庫の数字がずれる場面から、販売管理と在庫の連携が要る状態かを見分ける
受注や出荷のたびに在庫の数字が合わず、販売管理と在庫表の間の転記と確認に時間を取られていませんか。
小規模でも販売管理と在庫の連携が要るかどうかは、入荷・受注・出荷・返品・棚卸のどこで同じ数字を二度入力しているかで見分けられます。
二度の入力が1か所なら、運用の見直しで足りることがあります。
複数の区間や販売経路に及ぶなら、在庫機能のある販売管理への一本化か、API・CSVによる連携を検討します。
どちらを選んでも、在庫数の持ち主を一つに決め、小さく試して棚卸と照合する手順が要ります。
受注・出荷・入荷・返品・棚卸のどこで二重入力が起きるか
在庫の数字は、入荷で増え、出荷で減り、返品で戻り、棚卸で実物に合わせて直されます。
この動きを記録する場所が販売管理と表計算などに分かれていると、同じ数量を人がもう一度入力する場面が生まれます。
ずれが入り込むのは、この転記の時点です。
入力し忘れ、二度入れ、品目の取り違えが、そのまま数字の差として残ります。
たとえば、ネットショップで受けた注文を販売管理に入力して納品書を出し、出荷が終わってから在庫の表で出荷数を差し引いている場合を考えます。
受注の入力と在庫表の更新は、同じ数量を二度扱っています。
しかも在庫表の更新は出荷作業の後に回りやすく、その間に店頭で同じ商品が売れると、表の上では残っているのに棚には無いという状態が起こり得ます。
欠品や過剰在庫の多くは、こうした数量の動きと表の更新との時間差から説明できます。
二重入力は受注と出荷に限りません。
仕入先から届いた商品を販売管理の仕入に入力し、在庫表にも足している場合は入荷で、返品伝票を作ったあと在庫表にも戻している場合は返品で、同じことが起きています。
棚卸では、実際に数えた数で在庫表だけを直し、販売管理の側は直さないまま次の月に進むこともあります。
区間ごとに見ていくと、普段は意識していない転記が見つかります。
見分け方は、表の区間ごとに「人が同じ数字を入力しているのは何か所か」「その入力を誰がいつしているか」を書き出すことです。
日々入力している事務担当と、システムを選ぶ経営者が別の人なら、入力している人の実際の手順から書き出すと漏れが少なくなります。
数えた結果が、連携に進むかどうかの手掛かりになります。
これは判断を整理するための考え方で、何か所以上なら連携すべきという基準ではありません。
運用の見直しで足りるケース
二度の入力が1か所だけで、その入力を一人の担当者が毎日同じ時点で行っているなら、システムを入れ替える前に運用を見直す余地があります。
たとえば、出荷のたびに思い出したときに在庫表を更新するのではなく、その日の出荷作業の最後に更新すると決め、受注の件数と更新した件数を照らし合わせるだけでも、入力漏れには気づきやすくなります。
転記そのものは残りますが、どの時点で数字が動くかが決まるため、ずれたときに原因を追う範囲が狭まります。
一方で、二度の入力が複数の区間にまたがっている場合や、ネットショップと店舗のように販売の入口が複数ある場合は、事情が変わります。
入口ごとに受注が入るため、どちらか一方で売れた数をもう一方の在庫に反映するまでの間、同じ在庫を二重に売ってしまう余地が生まれます。
入力する人が増えるほど、誰がいつ直したかも追いにくくなります。
このような状態では、手順を細かく決めても転記の回数そのものは減らないため、連携を検討する段階に進みます。
ただし、つなげばずれが消えるわけではありません。
在庫管理ソフトと会計ソフトの連携を扱ったfreeeの解説では、担当者が手で在庫数を修正するなど運用ルールが崩れると、データの不整合が起きると説明されています4。
販売管理と在庫の組み合わせでも同じ性質になるかは使う製品によりますが、仕組みをつないでも人が手で直す余地が残れば、数字は合わなくなり得るという点は押さえておく必要があります。
運用の見直しは、連携しない場合の代わりの手段であると同時に、連携した後にも残る前提です。
| 区間 | 在庫の数が動く理由 | 二度の入力が生じる例(仮の例) |
|---|---|---|
| 入荷 | 仕入先から商品が届く | 販売管理に仕入を入力し、在庫表にも入荷数を足す |
| 受注 | 注文を受けて商品を確保する | 販売管理に受注を入力し、在庫表で残りを確かめて引き当てる |
| 出荷 | 商品を発送して手元から減る | 出荷後に在庫表から出荷数を差し引く |
| 返品 | 商品が戻り在庫に戻す | 返品伝票を作り、在庫表にも戻す数を足す |
| 棚卸 | 実物を数えて帳簿を合わせる | 在庫表だけを実数に直し、販売管理の側は直さない |
▼ 図の内容を文字で読む
- 注文を販売管理に入力して納品書を出す
- 出荷が終わる
- 在庫表で出荷数を差し引く前に店頭で同じ商品が売れる
- 表の上では残っているのに棚には無い
販売管理の在庫機能・別システム連携・手作業の整備をどう選ぶか
比較する軸(品目数・件数・販売経路・保管場所・運用人数)
連携を検討する段階に進んだら、販売管理の在庫機能に一本化する、在庫管理の別システムとつなぐ、手作業の整備を続けるという三つの選択肢を、同じ軸で並べます。
軸は、品目数、受注・出荷の件数、販売経路の数、保管場所の数、運用する人数、止まったときの影響です。
軸ごとに一律の線引きがあるわけではないため、自社の数字を書き込み、どの軸で手作業の負担が大きくなっているかを見るための枠として使います。
販売管理の在庫機能に一本化する形について、事業者の解説では、一体型のシステムや販売管理に在庫管理を含める形は、データの整合性を保ちやすい一方で、導入の費用や運用の変更に伴う負担が大きくなる場合があるとされています4。
販売管理と在庫が同じ仕組みの中にあれば、受注の入力がそのまま在庫の引当(注文に対して在庫を確保済みとして扱うこと)になり、別の表へ移す作業がなくなります。
その代わり、今使っている販売管理に在庫機能が無ければ乗り換えが必要になり、伝票の入力方法や帳票も変わります。
別システムとの連携は、今の販売管理を使い続けたまま、在庫を専用の仕組みで持つ方法です。
販売管理の操作に慣れた事務担当の手順を大きく変えずに済む一方、二つの仕組みの間でデータを受け渡す設定と、その受け渡しが止まったときの確認が加わります。
保管場所が複数ある、販売経路ごとに在庫数を更新したいなど、在庫の側に求めることが販売管理の在庫機能では足りない場合に検討する選択肢です。
手作業の整備は、品目が限られ、販売経路が一つで、入力する人も少ない場合に残る選択肢です。
表計算の在庫表を整えて運用すれば費用は抑えられますが、転記は無くならないため、前の節で見た更新の時点と照合の手順を決めておくことが前提になります。
表のうち判断が分かれやすいのは、販売経路と保管場所の行です。
入口が一つで保管場所も一か所なら、販売管理の在庫機能で受注と在庫を一つにまとめるだけで、表で見た転記の多くは消えます。
入口や保管場所が増えると、在庫の側に求める管理が細かくなり、販売管理の在庫機能がそこまで対応するかどうかで、一本化か連携かが分かれます。
軸の中で見落としやすいのが、止まったときの影響です。
連携した仕組みが止まると、受注は入っても在庫数が更新されない時間が生まれます。
受注が少ない日なら手で補えても、繁忙期に止まれば、出荷してよいかの判断に迷う場面が増えます。
手作業の整備は止まる仕組みが少ない反面、担当者が休んだ日に更新が滞るという別の止まり方をします。
どの選択肢にも止まり方があり、そのときに誰が何で代わりを務めるかまで考えておくと、選んだ後に慌てずに済みます。
購入前に提供元の資料で確かめる点
「販売管理」と名の付く製品でも、在庫管理が含まれるとは限りません。
OBCの小規模企業向けの料金ページでは、販売管理の単体(商奉行iクラウド)の機能一覧に在庫管理は見当たらず、在庫管理を含む蔵奉行iクラウドの機能はセット(商蔵奉行iクラウド)に入っています3。
同じ提供元の小規模企業向け商品の中でも、在庫機能の有無が商品の組み合わせで分かれている例です。
在庫機能があると分かっても、その範囲は製品ごとに違います。
購入前に確かめたいのは、次の点です。
- 受注の時点で在庫を引き当てられるか
- 保管場所ごとに在庫数を分けて持てるか
- ロット(同じ条件で仕入れたり作ったりしたまとまり)や期限を管理できるか
- 他の仕組みとデータをやり取りできる範囲と方式
在庫機能がどこまで対応するかは、料金ページの機能一覧だけでは読み切れないことがあります。
先のセットの例でも、在庫管理の機能範囲は提供元の機能説明や仕様の資料で個別に確かめる必要があります。
導入を決める人と日々入力する人が別なら、入力する人に今の作業手順を書き出してもらい、その手順が新しい画面のどこに当たるかを照らし合わせると、機能の有無を具体的に確かめられます。
「引当ができる」と書かれていても、自社の受注の受け方でその機能が使えるかは、手順と突き合わせて初めて分かります。
| 比較する軸 | 販売管理の在庫機能に一本化 | 別システムと連携 | 手作業の整備 | 確認する資料 |
|---|---|---|---|---|
| 品目数 | 在庫機能が自社の品目と管理項目に対応するか | 在庫側の仕組みで品目と属性を管理できるか | 表で扱える範囲に収まるか | 提供元の機能一覧・仕様の資料 |
| 受注・出荷の件数 | 受注の入力が引当に直結し転記は生じない | 受け渡しの頻度が件数に見合うか | 件数が増えるほど転記の回数も増える | 自社の受注・出荷の記録 |
| 販売経路の数 | 各経路の受注を販売管理に集められるか | 経路ごとに在庫数を受け渡せるか | 経路ごとに在庫表を更新する手間が増える | 連携仕様・対応する仕組みの一覧 |
| 保管場所の数 | 保管場所別の在庫を持てるか | 在庫側で保管場所別に管理できるか | 場所ごとに表や列を分けて管理する | 提供元の機能一覧 |
| 運用する人数 | 入力方法の変更を全員で共有する | 二つの仕組みの操作を覚える | 更新の担当と時点を決める | 社内の業務分担 |
| 止まったときの影響 | 一つの仕組みが止まると販売と在庫の両方に及ぶ | 受け渡しが止まると在庫数が古くなる | 担当者の不在で更新が滞る | 提供元のサポート条件と社内の代替手順 |
▼ 図の内容を文字で読む
- 販売管理の在庫機能に一本化
- 入口が一つで保管場所も一か所
- 受注の入力がそのまま引当になる
- 別システムと連携
- 保管場所が複数ある
- 販売経路ごとに在庫数を更新したい
- 手作業の整備
- 品目が限られている
- 販売経路が一つで入力する人も少ない
連携でつなぐ対象と、在庫数の持ち主を決める
自動でつなぐ対象の整理
別システムとの連携を選んだ場合、次に決めるのは何を受け渡すかです。
受け渡すデータは、受注や売上といった取引の記録、品目ごとの在庫数量、棚卸で数えた結果に分けて考えると整理しやすくなります。
事業者の解説によれば、連携で扱えるデータの範囲や、対応するソフトの組み合わせは製品ごとに異なります4。
受注は自動で渡せても棚卸の結果は渡せない、といった組み合わせもあり得るため、データの種類ごとに自動で渡るのか、手で渡すのかを決めておきます。
例として、受注は販売管理に入り、在庫数は在庫管理の仕組みで持つ場合を考えます。
受注データが在庫の側へ自動で渡れば、事務担当が在庫表から出荷数を差し引く作業はなくなります。
ただし、返品の戻しや棚卸の結果がどちらの仕組みから入るのかを決めていなければ、その部分には手での修正が残ります。
自動で渡るデータと手で扱うデータの境目を書き出しておくと、どの数字を誰が確かめるべきかが見えてきます。
在庫数を書き換えてよい場所を一つにする
数字のずれを減らすうえで鍵になるのが、在庫数を書き換えてよい場所を一つに決めることです。
二つの仕組みのどちらでも在庫数を直せる状態だと、片方で直した数字がもう片方からの受け渡しで上書きされたり、両方で直して二重に増減したりする余地が残ります。
前の節で見た、手での修正が不整合を生むという指摘は、直せる場所が複数あるときに起こりやすい問題でもあります。
そこで、在庫数の持ち主を一方に決め、もう一方は持ち主から数字を受け取って表示するだけ、つまり読み取り専用にする運用を提案します。
棚卸で数がずれていると分かったときも、直すのは持ち主の側だけにします。
これで減るのは、どちらの数字が正しいかを照らし合わせる確認と、二か所に同じ修正を入れる作業です。
ずれそのものが起きなくなるわけではありませんが、直す場所が一つなら、いつ誰が直したかを追う先も一つになります。
どちらを持ち主にするかは、製品の連携仕様で決まる面があります。
在庫の側から販売管理へ在庫数を渡せても、その逆ができない製品なら、持ち主は在庫の側になります。
仕様を確かめる前に社内で決めてしまうと、後から運用を組み直すことになるため、先に提供元の資料で受け渡しの向きを確かめてから決めます。
▼ 図の内容を文字で読む
- 提供元の資料で受け渡しの向きを確かめる
- 在庫数の持ち主を一方に決める
- ずれを直すのは持ち主の側だけにする
- もう一方は受け取って表示するだけにする
API・CSVなど連携方式の違いと、費用・手間の見方
API連携
つなぐ方式は、事業者の解説では、API連携、CSVファイルによる連携、一体型のシステムへの内包の3種類に整理されています4。
この解説は在庫管理ソフトと会計ソフトの連携を扱ったもので、販売管理との組み合わせで同じ性質になるかは、使う製品の連携仕様で確かめる必要があります。
そのうえで、方式ごとに日々の作業で何が変わるかを見ていきます。
API(ソフト同士がデータを受け渡すための窓口)による連携は、仕組み同士が自動でデータを受け渡す方式です4。
事務担当がファイルを出し入れする作業は生じず、どの間隔で受け渡すかは製品の仕様によります。
残るのは、受け渡しが止まっていないかを確かめることと、前の節で手で扱うと決めたデータの処理です。
APIで何を受け渡せるかは製品ごとに違うため、受注、在庫数量、棚卸の結果のそれぞれが対象に入っているかを連携仕様で照らし合わせます。
CSVの出力・取り込み
CSV(項目をカンマで区切った表形式のファイル)による連携は、一方の仕組みからファイルを書き出し、必要なら列を整えて、もう一方に取り込む方式です。
事業者の解説では、自動化できず、出力・加工・取り込みの手間と、ファイルの形式の違いによるエラーが生じうると説明されています4。
それでも、数量を一件ずつ打ち直す転記と比べると、減る作業ははっきりしています。
受注を一件ずつ在庫表に入力する代わりに一日分の受注をまとめて取り込めば、品目の取り違えや打ち間違いが入る場面は少なくなります。
代わりに残るのが、取り込みの時点まで在庫数が更新されない時間と、列の並びや品目の書き方が合わずに取り込めなかった行の確認です。
一日に何回取り込むかを決め、取り込めなかった行の件数を毎回見る手順にしておくと、更新漏れに気づきやすくなります。
一体型への内包
一体型は、販売管理と在庫管理を一つの仕組みで扱う形で、つなぐという作業そのものが無くなります。
受け渡しのタイミングや取り込みのエラーを気にしなくてよい点が、APIやCSVとの違いです。
選択肢を比べた節で見たとおり、その代わりに導入や運用変更の負担が大きくなる場合があり、事業者の解説でも、初期設定やデータの移行に工数や費用がかかる場合があるとされています4。
今の販売管理に蓄えた取引先や商品の登録をどう移すかが、一体型を選ぶときの主な作業になります。
小規模向け製品の料金例の読み方
費用は、方式そのものより、選ぶ製品とその組み合わせで決まります。
例として、OBCの小規模企業向け(Jシステム)では、販売管理の単体が月額10,000円~、在庫管理を含むセットが月額18,000円~で、月額とは別に初期費用がかかります3。
料金は法人単位の年間契約で、利用者のライセンス数などの条件が付いています3。
この例から読み取れるのは、同じ提供元の中で在庫機能を加えると月額がどう変わるかという一つの事実です。
他社製品の料金や、小規模向けの一般的な相場を示すものではありません。
また、この料金ページは別の仕組みとつなぐ場合の連携ツールの費用を示すものではないため、つなぐ方式を選ぶなら、連携部分の費用をそれぞれの提供元に見積もってもらう必要があります。
比べるときは、月額だけでなく、初期設定やデータ移行にかかる作業、利用する人数で変わる料金、そしてCSVで運用する場合に残る毎日の作業も並べます。
CSVの取り込みは料金表に出てこない負担ですが、担当者の手間として毎日発生します。
月額が安く見える組み合わせでも、日々の取り込みと確認を誰が担うかまで含めると、比べる結果が変わることがあります。
| 方式 | データの受け渡し | 日々残る作業 | 導入時の負担 |
|---|---|---|---|
| API連携 | 仕組み同士が自動で受け渡す | 受け渡しが止まっていないかの確認と、対象外のデータの処理 | 連携の設定と、受け渡せる範囲の確認 |
| CSVの出力・取り込み | ファイルを書き出して取り込む(自動化できない) | 出力・加工・取り込みと、形式の違いによるエラーの確認 | ファイルの形式と列の対応づけ |
| 一体型への内包 | 一つの仕組みの中で扱う | つなぐ作業は無い | 導入費用・運用の変更・データ移行の負担が大きくなる場合がある |
▼ 図の内容を文字で読む
- 読み取れること
- 販売管理の単体は月額10,000円~
- 在庫管理を含むセットは月額18,000円~
- 月額とは別に初期費用がかかる
- 読み取れないこと
- 他社製品の料金や一般的な相場
- 連携ツールの費用
- 比べるときに並べるもの
- 初期設定やデータ移行にかかる作業
- 利用する人数で変わる料金
- CSVで運用する場合に残る毎日の作業
導入前に整えることと、小さく始めて数字を確かめる手順
マスタ・ルールの統一
方式が決まっても、すぐに全品目をつなぐ前に整えておくことがあります。
事業者の解説では、導入前に、在庫の評価方法や勘定科目といったマスタ(品目や科目などの基本の登録情報)の設計をそろえること、入力と更新のルールを共有すること、使っているソフトとの互換性と連携の範囲を確かめること、将来の拡張性を確かめることが挙げられています4。
業種や製品によっては、これ以外の準備が加わることもあります。
拡張性は、小規模の事業者でも後から効いてきます。
今は店舗だけでも、後でネットショップを始めれば販売の入口が増え、在庫数を受け渡す相手も増えます。
そのときに新しい販売経路とつなげるかどうかを今の段階で提供元の資料から確かめておくと、乗り換えを避けやすくなります。
これは編集上の提案ですが、商品コードと数量の単位をそろえておくことも勧めます。
販売管理では「箱」、在庫表では「個」で数えている、同じ商品に別のコードが付いているといった違いがあると、受け渡した数量がずれたり、取り込みで品目が見つからなかったりする原因になります。
つなぐ前に両方の登録を一覧にして照らし合わせ、コードと単位の対応を一つに決めておくと、試行で出たずれの原因を切り分けやすくなります。
入力と更新のルールは、前に決めた在庫数の持ち主と合わせて書き出します。
誰が、どの画面で、どの時点に入力するかを、導入を決めた人だけでなく、日々入力する人と共有します。
ルールが紙の上にしか無く、入力する人が知らないままでは、手での修正が持ち主以外の場所に入り込みます。
品目や経路を絞った試行と棚卸との照合
最初から全品目・全経路をつなぐと、ずれが出たときにどこが原因かを切り分けにくくなります。
そこで、品目や販売経路を絞って受け渡しを始め、一定の期間、仕組みの上の在庫数と実際に数えた数を照らし合わせる進め方を提案します。
たとえば、よく動く商品をいくつか選び、一つの販売経路だけをつなぎ、週に一度その品目だけを数えて、仕組みの数と合うかを見ます。
照合で数が合わなかったときは、手での修正の記録、受け渡しや取り込みの記録、コードと単位の対応の順にたどると、仕組みの問題か運用の問題かを分けやすくなります。
合う状態が続くことを確かめてから、品目や経路を広げます。
試行の期間は事業の繁閑や品目の動き方で変わるため、一律の目安はありません。
入荷と返品を含む期間を一度は通しておくと、出荷以外の区間の受け渡しも確かめられます。
試行の間に、これまでの在庫表を並行して残すかどうかも決めておきます。
残す場合でも、どちらが正なのかは試行の間から一方に決めておかないと、持ち主を一つにする意味が薄れます。
並行して残した表は照合のための控えと位置づけ、そこで数字を直さないようにします。
▼ 図の内容を文字で読む
- 仕組みの在庫数と数えた数が合わない
- 手での修正の記録を見る
- 受け渡しや取り込みの記録を見る
- コードと単位の対応を見る
費用負担を抑える制度の見方(補助金)
小規模事業者の定義
導入費用の負担を抑える手段として、補助金を調べる方もいるでしょう。
中小機構が示す定義では、小規模企業者は、常時使用する従業員の数が、商業(卸売業・小売業)とサービス業(宿泊業・娯楽業を除く)で5人以下、製造業・建設業・運輸業などその他の業種で20人以下とされています1。
同じ従業員数でも、小売業か製造業かで当てはまるかどうかが変わります。
補助金ごとに対象の要件が別に定められることがあるため、この定義は一般的な目安として扱い、応募する制度の公募要領で確かめます。
補助対象の機能要件
デジタル化・AI導入補助金の案内ページに示された枠では、補助対象のソフトウェアは、インボイス制度に対応し、「会計」「受発注」「決済」のいずれかの機能を持つことが要件とされています2。
このページの要件の中に「在庫管理」「販売管理」という語は見当たりません。
在庫連携のために入れたい製品が受発注の機能の要件を満たすかどうかは、製品の名前からではなく、提供元が補助金向けに登録している情報で確かめる必要があります。
補助率は、ソフトウェア等では中小企業が3/4以内、小規模事業者が4/5以内(補助額50万円以下の部分)とされています2。
同じページにはオプションとしてデータ連携ツールも挙がっていますが、在庫の連携にかかる費用がどこまで対象になるかは、このページだけでは判断できません。
年度や枠、公募回によって要件が変わるため、応募を考える段階で公募要領を確かめ、製品の提供元にも対象かどうかを問い合わせます。
補助金を前提に製品を選ぶと、対象かどうかが選択の軸の先頭に来てしまいがちです。
まず二度の入力の数え方と三つの選択肢の比較で自社に合う方式と製品を絞り、その候補が対象かを確かめる順にすると、補助が受けられなかった場合でも選んだ理由が残ります。
▼ 図の内容を文字で読む
- 小規模事業者の定義
- 商業・サービス業は従業員5人以下
- 製造業・建設業・運輸業などは20人以下
- 補助対象のソフトの要件
- インボイス制度に対応している
- 会計・受発注・決済のいずれかの機能がある
- 補助率
- 小規模事業者は4/5以内(50万円以下の部分)
- 中小企業は3/4以内
二度の入力がどの区間で起きているかは、日々入力している人の手順を書き出してみないと見えにくく、三つの選択肢の比較もその整理が出発点になるためです。
今の入荷・受注・出荷・返品・棚卸の流れを共有いただくことで、どの区間の転記が減らせそうか、運用の見直しで足りるか連携の検討に進むべきかの見立てを一緒に確かめられます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 連携が要るかの見分け | 区間ごとに同じ数字を二度入力している箇所を数え、複数の区間や販売経路にまたがるかを見る |
| 選択肢の比べ方 | 品目数・件数・販売経路・保管場所・運用人数・止まったときの影響を同じ軸で並べる |
| 在庫機能の確認 | 機能一覧に在庫管理があるか、引当・保管場所・ロットに対応するかを提供元の資料で確かめる |
| 在庫数の持ち主 | 書き換えてよい場所を一つに決め、もう一方は受け取って表示するだけにする |
| 方式の違い | APIは自動で受け渡し、CSVは出力・加工・取り込みの手間が残り、一体型は導入と移行の負担が大きくなる場合がある |
| 料金例の読み方 | 特定の提供元・プランの事実として読み、相場や連携ツールの費用には当てはめない |
| 試し方 | 品目と経路を絞って受け渡し、棚卸の数と照合してから広げる |
| 補助金 | 機能要件と小規模事業者の扱いを公募要領で確かめ、方式と製品を絞ってから対象かを確かめる |
在庫数の持ち主や受け渡すデータの範囲は、候補の製品の連携仕様と自社の運用を照らし合わせて決める必要があり、どちらか一方だけでは判断しにくいためです。 候補の製品で受注・在庫数量・棚卸の結果のどれを受け渡せるかの確認点と、試行をどの品目と販売経路から始めるかを整理できます。
よくある質問
表計算で在庫を管理している場合、どの時点で連携を検討すべきですか。
品目数や件数で一律に決まる基準はありません。
手掛かりになるのは、表への転記が複数の区間にまたがっているか、販売の入口が二つ以上になったかです。
ネットショップを加えるなど販売経路を増やす予定があるなら、その前に、今の販売管理に在庫機能があるか、他の仕組みとつなげるかを確かめておくと、増えた後の転記を抑えやすくなります。
販売管理の在庫機能で足りるかは、購入前に提供元の何を確認すればよいですか。
まず機能一覧に在庫管理が含まれるかを見ます。
同じ提供元でも、販売管理の単体には在庫管理が見当たらず、セットで含まれる例があります3。
含まれる場合は、受注時の引当、保管場所ごとの在庫、ロットや期限の管理、他の仕組みとの受け渡しの範囲に対応するかを、機能説明や仕様の資料で確かめます。
CSV連携からAPI連携に切り替えられますか。
使っている製品の双方がAPIでの受け渡しに対応していれば、切り替えを検討できます。
対応の有無や受け渡せるデータの範囲は製品ごとに異なるため4、提供元の連携仕様で確かめます。
CSVで運用している間に商品コードや単位をそろえておけば、切り替えの際に対応づけをやり直す作業を減らせます。
小規模事業者の定義は業種によってどう違いますか。
中小機構が示す定義では、常時使用する従業員の数が、商業(卸売業・小売業)とサービス業(宿泊業・娯楽業を除く)で5人以下、製造業・建設業・運輸業などその他の業種で20人以下です1。
補助金ごとに要件が別に定められることがあるため、応募する制度の公募要領で確かめます。
在庫の数が合わなくなったとき、まず確認する順序は何ですか。
決まった順序があるわけではありませんが、手での修正の記録、受け渡しや取り込みの記録、商品コードと単位の対応、実際に数えた数の順にたどる方法があります。
手での修正は不整合の原因になるとされているため4、最初に持ち主以外の場所で数字を直していないかを見ます。
次に受け渡しが止まっていないか、取り込めなかった行が無いかを確かめ、それでも合わなければ対象の品目を数え直します。
- 1 出典:独立行政法人中小企業基盤整備機構「中小企業・小規模企業者の定義」(2026年)
- 2 出典:独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金(インボイス枠の案内ページ)」(2026年)
- 3 出典:株式会社オービックビジネスコンサルタント「商奉行iクラウド・商蔵奉行iクラウド 小規模企業向け 料金ページ」(2026年)
- 4 出典:フリー株式会社「在庫管理ソフトと会計ソフトは連携すべき?」(2026年)