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