材料を手配した。出荷も済ませた。
そのあとで、経理から「まだ入金がありません」と連絡が来る。
NetSuiteの前受金管理とは、前受金を顧客デポジットという標準の記録に載せ、受注にひも付けて、請求のときに充当する仕組みです。
受け取った時点では売上ではなく負債として持ち、売掛金の残高は動きません。
会計の処理は、この標準の形で回ります。
冒頭の事故は、会計の処理では防げません。
入金を確かめないまま次の工程が進む。これは業務の順番の問題です。
では、「入金がなければ次へ進めない」は、標準でどこまで作れるのか。どこから作り込むのか。
受注生産やプロジェクト型の事業を支援してきた、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが答えます。
この記事で分かること
- 前受金の運用が「人の記憶」に頼ってしまう理由
- NetSuiteで前受金を載せる標準の器と、似た器との使い分け
- 「入金がなければ進めない」を、標準・拡張・連携の3段階で作る方法と、手を付ける順番
- 日本固有の論点（消費税の課税時期、インボイス、前受金残高の説明）
- 前受金の統制でよくある3つの失敗と、避け方
言葉の整理
- 前受金：商品やサービスを提供する前に、顧客から受け取る代金
- 充当：受け取った前受金を、あとで発行した請求書の支払いに当てること
前受金の運用が「人の記憶」に乗ってしまう理由
前受金のある取引は、工程が増えます。
通常の取引は「受注 → 出荷 → 請求 → 入金」です。
前受金の取引は「受注 → 前受金の請求 → 入金 → 出荷 → 残額の請求 → 入金」になります。
増えたのは2つ。
前受金の請求と、入金を見てから先に進む判断です。
多くの会社で、この2つがシステムの外に置かれています。
- 前受金の請求書は、受注管理とは別のExcelやテンプレートで作る
- 入金は経理が通帳で見て、営業に口頭かチャットで伝える
- 出荷や着手は、「たしか入金があったはず」という記憶で決める
担当者が優秀なうちは、これで回ります。
崩れるのは、取引が増えたときと、担当が代わったときです。
事故は、いつもどおりの流れから起きる
前受金の事故は、特殊な取引で起きるわけではありません。
急ぎの案件で、先に手配した。
分割入金の2回目を見落とした。
金額が少し違ったが、誤差だと思って進めた。
どれにも悪意はありません。
判断を人に任せている限り、一定の割合で必ず起きます。
だから、止める場所をシステムの側に持たせます。
NetSuiteで前受金を載せる標準の器｜顧客デポジット
NetSuiteには、前受金のための標準の器があります。
顧客デポジット（Customer Deposit）です。
Oracleの公式ドキュメントでは、顧客デポジットを次のように位置づけています。
- 商品やサービスの提供前に受け取った前払い金として記録する
- 総勘定元帳では負債（その他流動負債）として持つ
- 売掛金の残高には影響しない
- 提供を済ませて請求書を発行すると、デポジットが請求書に充当され、負債が消える
受け取った時点では売上ではなく負債。
前受金の会計上の扱いが、標準の記録方法としてそのまま用意されています。
販売注文にひも付けられる
顧客デポジットは、顧客に対して単独で記録できます。
販売注文にひも付けて記録することもできます。
公式ドキュメントによると、販売注文からデポジットを作ると、次のように動きます。
- デポジットのレコードに、元の販売注文が読み取り専用で表示される
- その販売注文を請求したとき、デポジットが自動で充当される
- ひも付いたデポジットは、ほかの請求書には充当できない
- ひも付けられるのは、まだ請求していない販売注文だけ
1件の注文に、複数のデポジットを充当することもできます。
注文金額を超えた分は、ほかの請求書に回せます。
顧客レコードには顧客デポジット残高の欄があり、まだ充当していない前受金の合計が分かります。
似た器との使い分け
前受金に見える取引でも、器を間違えると、あとで残高を説明できなくなります。
| 器 | 使う取引 | 会計上の位置 | 売掛金への影響 |
|---|---|---|---|
| 顧客デポジット | 提供前に受け取る前受金。受注にひも付く手付金・着手金 | 負債（その他流動負債） | 影響しない |
| 請求書＋入金 | 提供済みのものに対する、通常の売上債権 | 売掛金 → 入金で消す | 立てて、消す |
| 未充当の入金（仮受金に近い扱い） | 何の代金か分からないまま着金したもの | 中身が決まるまで保留 | 決まるまで当てない |
分け方の基準は1つです。
何に対するお金かが、受注の単位で分かっているか。
分かっていれば顧客デポジット。分からなければ、先に中身を決めます。
🌏 日本での提供状況：顧客デポジットはNetSuiteの標準機能で、日本のアカウントでも使えます。ただし、日本の消費税・インボイスへの対応は、Japan Localization SuiteAppや税の設定に左右されます。自社環境での動きは、導入時に実機で確かめてください（第5章）。
日本対応の全体像は、NetSuite Japan Localization SuiteAppとはで紹介しています。
「入金がなければ次工程に進めない」をどう作るか
顧客デポジットは、前受金を正しく記録するための器です。
「入金がなければ出荷させない」という順番の統制は、器を用意しただけでは生まれません。
ゲートを別に作る必要があります。
図の③が、この記事の中心です。
受注と前受金の請求のあとに、入金を確かめるゲートを置きます。
入金がなければ差し戻し、あれば出荷や着手に進む。
請求のときにデポジットが充当され、負債が消えて売上が立ちます。
3段階の作り方
| 段階 | やること | 向いている場面 |
|---|---|---|
| 標準（設定で作る） | 顧客デポジットを有効にし、販売注文にひも付ける運用にそろえる。未充当の残高をリストやダッシュボードでいつでも見られるようにする | 取引が少なく、担当者が画面を見て判断すれば回る規模 |
| 拡張（ワークフローで止める） | 販売注文のステータスの移り方や、出荷・請求の実行に条件を付ける。入金を確かめていない注文は次へ進めない。承認者への通知や差し戻しも自動にする | 例外の運用が多い。担当が複数いる。監査で順番を説明する必要がある |
| 連携（外部とつなぐ） | 銀行明細の自動取込や入金消込のサービスとつなぎ、入金の事実そのものを自動で入れる。人が「入金あり」と入力する工程をなくす | 入金が多い。振込名義が合わない。部分入金・分割入金が多い |
⚠️ 機能名や設定名は、環境やバージョンで違います。この表は「標準／拡張／連携」の粒度で書いています。自社でどこまで標準で作れるかは、実際のアカウントで確かめてください。
ワークフローで止める考え方は、NetSuiteの承認ワークフロー実装ガイドで扱っています。
この記事の統制は、その考え方を「承認」ではなく「入金の事実」に当てはめたものです。
どこから手を付けるか｜標準 → 連携 → 拡張
迷ったら、標準 → 連携 → 拡張の順に進めます。
- 標準の器に載せないと、何を止めるかの基準が決まらない
- 入金の事実が自動で入らないと、止めた注文をいつ再開してよいか分からない
- ワークフローは、業務のルールが固まってから作るほど手戻りが少ない
作り込みから入ると、運用が変わるたびに作り直すことになります。
作り込みと連携の量は、導入費用にも響きます。
ベンチャーネットが支援したNetSuite導入の費用では、3名程度・開発なしの事例が150万円程度・1.5か月でした。
100名程度で外部システムとの連携開発を含めた事例は、2億円程度（うち開発約7割）・1.5年です。
費用と期間を左右するのは、機能範囲・開発（特に外部連携）・社内の体制・ユーザー数の4つです。
4事例の条件は、NetSuiteの料金・費用・価格に載せています。
ゲートで業務を止めない｜銀行連携と消込につなぐ
第3章のゲートは、入金の事実がシステムに入ってこないと働きません。
経理が通帳を見て手で入力していると、どうなるか。
ゲートは「経理の入力待ち」という渋滞に変わります。
止めたかったのは工程であって、業務ではありません。
入金の事実を入れる経路は、現実には3つです。
- 銀行明細の自動取込：明細を定期的に取り込み、消込の候補を自動で当てる
- 金融EDI（ZEDI）：振込に付いた情報を使い、請求と入金の一致の精度を上げる
- 入金消込サービスとの連携：名義の違い・分割入金・まとめ入金を、外部のサービスの側で解く
詳しくは、次の記事で扱っています。
- NetSuiteの銀行連携・自動消込ガイド
- ZEDI（全銀EDI）×NetSuiteで売掛金消込を自動化する
- NetSuiteで日本の銀行明細を自動取込（Japan Bank Feeds）
- NetSuiteの入金消込はどこまで自動化できるか
前受金の消込は、売掛金の消込より難しい
売掛金の消込には、請求書という照合の相手があります。
前受金は、請求書をまだ立てていない段階の入金です。
何の注文に対する入金か。
それを見分ける情報が振込データに載っているかどうかで、難しさが大きく変わります。
打つ手は地味ですが、効きます。
- 前受金の請求時に、注文番号を振込依頼人名や摘要に入れてもらうよう案内する
- 顧客ごとに未充当の前受金残高を見えるようにし、着金したら当てる先をすぐ絞り込めるようにする
- 分割入金の取引は、回数と金額を最初から注文の側に持たせる
日本固有の論点｜消費税・インボイス・残高の説明
前受金は、日本の税務・会計の実務と深く関わります。
ここは断定を避け、確かめるべき論点として並べます。
消費税の課税時期
国税庁のタックスアンサー No.6165「前受金や前払金などがあるとき」は、売上げの時期を次のように示しています。
前受金を受け取っていても、受取の時期に関係なく、実際に引渡しやサービスの提供があった時が売上げの時期になる。
つまり、前受金を受け取った時点では、原則として売上も課税売上も立ちません。
売上と消費税は、引渡しやサービスの提供の時点で認識します。
システムの動きも、これに合っている必要があります。
顧客デポジットを負債で記録し、請求時に充当して売上にする流れは、この考え方に沿っています。
🌏 確認事項：前受金にかかる消費税の具体的な処理（税区分の設定、受領時の証憑の扱い、インボイス制度上の対応）は、取引の形と自社の税務方針で判断が分かれます。税務上の扱いは、顧問税理士に確かめてください。システム側の税設定は、NetSuite SuiteTaxとは？Japan Localizationとの非互換問題も参考になります。
前受金残高を説明できるか
実務で効いてくるのは、残高の説明です。
決算や監査で、前受金残高について次の質問が来ます。
- この残高は、どの注文に対するものか
- いつ売上になる見込みか
- 長く動いていないものは、なぜ動いていないのか
顧客デポジットを販売注文にひも付けていれば、3つともデータで答えられます。
注文とひも付かない入金として処理していると、決算のたびに調べ直しです。
前受金の統制は、事故を防ぐためだけのものではありません。
決算を早く終わらせるための投資でもあります。
売上として認識するタイミングの設計は、NetSuiteの収益認識（ARM）完全ガイドで扱っています。
よくある3つの失敗
3つの失敗と避け方を、先に図にまとめます。
失敗1：器をそろえず、前受金が複数の場所に散る
起きること：ある案件は顧客デポジット、ある案件は先に請求書、ある案件は「入金だけ先に受けて後で処理」。決算で前受金残高が合わない。
原因：前受金の定義が「お金を先にもらう取引」としか決まっていない。どの器に載せるかのルールがなく、担当者がその場で決めている。
避け方：受注の時点で「前受金あり／なし」を注文データに持たせる。ありなら顧客デポジットに載せる、と一本にする。例外に見える取引は、まず注文の切り方を見直す。
失敗2：ゲートを作ったら、業務が止まった
起きること：入金を確かめるまで出荷させないルールを入れた。経理の入金入力が追いつかず、出荷が毎日たまる。現場から解除の依頼が相次ぎ、結局ゲートを外した。
原因：止める仕組みだけを先に作り、入金の事実が入る速さを上げていなかった。統制の設計と、入金データの取り込みの設計が分かれていた。
避け方：ゲートを入れる前に、入金が1営業日以内に反映される状態を作る。銀行明細の自動取込や消込の自動化が先です。そのうえで、ゲートには例外を解除する正規のルート（誰が、何を根拠に解除できるか）を必ず用意する。
失敗3：分割入金で、残高が迷子になる
起きること：契約金額の30％を着手金、40％を中間金、30％を検収後に受け取る取引。2回目の入金が漏れたまま、最後の工程まで進んだ。請求の段階で初めて気づいた。
原因：ゲートが「1回目の入金があるか」しか見ていない。何回目まで受け取っているべきかを判定する基準がなかった。
避け方：入金の予定を回数と金額で注文に持たせる。工程ごとに「進むには何回目までの入金が要るか」を対応づけ、その表で判定する。分割入金が多い事業では、ここが統制の中心になります。
ベンチャーネットならこう見る
前受金の相談で、ベンチャーネットが最初に聞くのは3つです。
- いまの前受金の取引はどの器に載っているか：顧客デポジット・請求書・入金だけ、が混ざっていないか
- 入金の事実は何日でシステムに入るか：1営業日以内でなければ、ゲートより先に経路を整える
- 分割入金の取引はどれくらいあるか：工程ごとの判定表が要るかどうかが決まる
見える化してから「標準に合わせる／開発する／残す」を決める
最初にやるのは、いまの前受金の流れの見える化です。
どの取引を、誰が、どの器で処理し、何を見て出荷や着手を決めているか。
次に、やめる・まとめる・そろえる作業を決めます。
受注の切り方を見直すのも、この段階です。
そのうえで、NetSuiteの標準機能と照らし合わせます。
照らし合わせたあと、取引ごとに3つから選びます。
| 選択 | 前受金での例 |
|---|---|
| 標準に合わせる | 前受金は顧客デポジットに一本化し、販売注文にひも付ける。未充当の残高をリストとダッシュボードで見る |
| 開発する | 入金がなければ次へ進ませないワークフロー。分割入金の工程別の判定、例外解除のルート、承認者への通知まで含める |
| 残す | 件数が少なく、担当者の確認で回る取引は、無理にゲートを作らず運用で回す |
入金の事実を入れる経路も、同じ順で選びます。
銀行明細の自動取込、金融EDI、国内の入金消込サービスのどれを使うか。
入金の件数、名義の違いの実態、いまの運用から決め、連携の開発とその後の運用まで担います。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。特定の製品に誘導しない立場を取っています。
前受金の統制でも、標準の運用で足りるなら作りません。
作るか、つなぐか、運用で回すかを、取引の実態に照らして示します。
今日できること
最初にやることを、1つだけ挙げます。
直近3か月の前受金取引を10件抜き出してください。
それぞれ「入金の確認から次の工程に進むまで、誰が何を見て判断したか」を書き出します。
10件のうち、判断の根拠がシステムのデータだったのは何件か。
口頭・メール・記憶だったのは何件か。
この比率が、いま作るべき統制の優先度をそのまま示します。
システムのデータが半分を切っているなら、ゲートより先に、入金の事実を入れる経路から手を付けてください。
よくある質問
Q1. 顧客デポジットを使わず、先に請求書を出して入金してもらう方法ではだめですか
運用としては成り立ちますが会計上の意味が変わります。
請求書を出すと売掛金が立ち、提供前でも売上として扱う設計になり得ます。
前受金として負債で持ちたいなら、顧客デポジットを使うのが素直です。
どちらにするかは、収益認識の方針と合わせて決めてください。
Q2. 販売注文にひも付けたデポジットは、あとから別の請求書に充当できますか
Oracleの公式ドキュメントでは充当できないとされています。
ひも付けられるのは、まだ請求していない販売注文だけです。
運用では、注文を分けるか、ひも付けずに記録するかを決める必要があります。
Q3. 「入金がなければ出荷できない」は、NetSuiteの標準機能だけで作れますか
器は標準ですが止める判定はワークフローで作ることが多いです。
前受金を記録する器は、標準で用意されています。
工程を止める判定の部分は、ワークフローでの実装が現実的な選択肢になることが多いと考えてください。
自社の要件が標準の範囲に収まるかは、実際のアカウントで確かめることをおすすめします。
Q4. 前受金を受け取った時点で消費税はかかりますか
原則として受け取った時点では課税売上を認識しません。
国税庁のタックスアンサーでは、受取や支払の時期に関係なく、実際に引渡しやサービスの提供があった時が売上げや仕入れの時期とされています。
個別の取引の税務判断は、顧問税理士に確かめてください。
Q5. 分割入金が多い事業でも、この統制は作れますか
作れます。
分割入金が多い事業ほど、効果は大きくなります。
入金の予定を回数と金額で注文に持たせ、工程ごとに必要な入金の回数を対応づけます。
第6章の失敗3の事故は、この設計でほぼ防げます。
Q6. 前払金（自社が先に払う側）にも同じ考え方は使えますか
仕組みは同じで追うものが逆になります。
受け取る側の論点は、「受け取ったお金を、いつ売上にしてよいか」です。
払う側の論点は、「払ったお金が、いつ物やサービスに変わるか」です。
NetSuiteには対になる標準機能として仕入先前払金があり、発注にひも付けて残高の滞留を防ぐ設計が中心になります。
詳しくは、NetSuiteの前払金はどう管理するかをご覧ください。
まとめ
前受金の管理は、会計処理の問題に見えます。
実際には、業務の順番を誰が守らせるかの問題です。
- 顧客デポジットは、前受金を負債として記録するNetSuiteの標準の器
- 販売注文にひも付ければ、請求時に自動で充当され、残高の説明もデータでできる
- 「入金がなければ次工程に進めない」は、標準・拡張・連携の3段階で組み立てる
- 手を付ける順は「標準 → 連携 → 拡張」。止める仕組みより先に、入金が入る経路を整える
- 消費税の課税時期は引渡しの時。前受金を受け取った時点では、原則として課税売上を認識しない
材料を手配したあとで「まだ入金がありません」と知る。
その順番の崩れを止めるのは、器とゲートと入金の経路の3つです。
まずは10件の棚卸しから始めてください。データになっていない判断の数が、そのまま改善の余地です。
もう少し詳しく知りたい方へ
前受金の器はそろえたが、ゲートをどこまで作るか決めきれない。
入金の反映が遅く、止める仕組みを入れる前に経路から見直したい。
そうした段階から、ご相談をお受けしています。
- 顧客デポジットの構成や統制の作り方を相談したい方：お問い合わせ
- 導入から運用までの支援の範囲を知りたい方：NetSuite導入支援サービス
