この記事で分かること（読了時間：約11分）
- 前払金が「残ったまま」になるのは、担当者の確認漏れではなく仕組みの問題であること
- NetSuiteの仕入先前払金が、会計上どう振る舞うか
- 発注（PO）にひも付ける方式と、ひも付けない方式の違い
- 自動充当が働く条件と、働かない条件（ここが最大の落とし穴）
- 月末の「この前払金、まだ残っていて大丈夫か」を仕組みで解消する方法
月末が近づくと、経理から購買にこの質問が飛びます。
「この前払金、まだ残っていますが大丈夫ですか」
聞かれた側も即答できません。発注の進捗を追い、担当者に確認し、折り返す。これが毎月繰り返されます。
この記事は、すでにNetSuiteを使っている会社が、この往復をなくすための運用設計をまとめたものです。
前払金が「残ったまま」になるのは、確認漏れではなく仕組みの問題
前払金とは、商品やサービスを受け取る前に支払う代金のことです。
払った時点では、まだ何も受け取っていません。だから費用にも仕入にもならず、資産として残ります。受け取ったときに初めて、買掛金や仕入と相殺されて消えます。
問題は、払ってから受け取るまでが長い取引です。
- 海外ベンダーへの先払い。船積みまで数か月かかる
- 長納期の設備。着手金を払い、納入は半年後
- 開発委託。着手金を払い、検収は工程の終わり
海外仕入が中心の会社では、これに為替の評価も重なります。多通貨や三国間貿易まわりの論点は商社・専門商社のNetSuite活用で、外貨建て取引の評価替えはNetSuiteで為替差損益はどう処理する？で扱っています。
この間、前払金は帳簿に残り続けます。残っていること自体は正しい状態です。
では何が問題なのか。その前払金が「まだ残っていて正しいのか」「もう消えているべきなのか」を判断する材料が、別々の場所にあることです。
前払金の残高は会計側にあります。対応する発注がどこまで進んだか（入荷したか、検収したか、請求が届いたか）は購買側にあります。この2つを突き合わせる作業が人手で残っている限り、月末の往復はなくなりません。
つまり必要なのは、確認を強化することではありません。前払金と発注の進捗を、同じ線の上に乗せる設計です。
NetSuiteの仕入先前払金は、会計上どう振る舞うか
NetSuiteには、仕入先への前払金を記録・追跡する標準機能があります。仕入先前払金（Vendor Prepayment）です。
Oracleの公式ドキュメントでは、この機能をこう説明しています。
The Vendor Prepayments feature records and tracks payments to vendors before they accept a purchase order for a good or service.
つまり、ベンダーが発注を受ける前の支払いを記録し、追跡する機能です。
買掛金に影響しない、という設計
会計上の振る舞いで最も重要なのは、次の点です。
a posting transaction that impacts the general ledger without offsetting the Accounts Payable account. When the vendor prepayment is applied, the Accounts Payable account is offset.
前払金を計上した時点では、買掛金（AP）には影響しません。総勘定元帳には記録されますが、買掛金残高は動かないということです。
買掛金が動くのは、前払金を請求書に充当したときです。そのとき初めて買掛金がオフセットされます。
この設計には理由があります。前払金はまだ債務ではないからです。まだ受け取っていないものに対する支払いなので、買掛金として並べると債務残高が二重になります。
買掛金・未払金・未払費用の区分そのものについては、買掛金と未払金の違い：NetSuiteで実現する効率的な財務管理で整理しています。前払金は、そのどれでもない資産側の科目です。
売る側の前受金と対になっている
NetSuiteには、売る側の仕組みとして顧客デポジット（前受金）もあります。こちらは売掛金（AR）残高に影響せず、請求時に充当されます。
買う側の前払金と、売る側の前受金は、同じ構造の裏表です。どちらも「まだ債権債務になっていないお金」を、本体の残高から切り離して持つという考え方です。
ただし、統制の論点は逆向きになります。前払金は「払ったものがいつ物に変わるか」を追う話です。前受金は「受け取ったものをいつ売上にしてよいか」を決める話です。同じ仕組みでも、見るべき指標と関わる部署が変わります。
利用可否の確認について
仕入先前払金の利用可否や有効化の要否は、アカウントの構成によって異なる場合があります。公式ドキュメントには対象地域の制限に関する記載は見当たりませんでした。実際の利用条件は、docs.oracle.com の該当ページとOracleの担当者にご確認ください。本記事の内容は2026年9月15日時点の公式ドキュメントにもとづいています。
発注にひも付けるか、ひも付けないか
仕入先前払金の使い方には2つの方式があります。ここが運用設計の最初の分岐点です。
| PO紐づけ型 | スタンドアロン型 | |
|---|---|---|
| 発注（PO）との関係 | 特定の発注にひも付ける | どの発注にもひも付けない |
| 自動充当（Auto-Apply） | 使える | 使えない（公式Docに明記） |
| 充当先 | ひも付けた発注に関連する請求書 | 同じ仕入先のどの請求書にも充当可 |
| 向いている取引 | 発注が先にある取引（設備・海外仕入・開発委託） | 発注を立てない継続取引、前払いを積んでおく運用 |
| 月末の追跡しやすさ | 高い。発注の進捗と並べて見られる | 低い。消し込む意思決定が人に依存する |
| AIとの親和性 | 高：発注と前払金が構造で結ばれているため、滞留の検知や照会の自動化に乗せやすい | 低：ひも付けの根拠がデータ上に存在せず、判断材料を人が持っている |
公式ドキュメントはスタンドアロン型についてこう書いています。
A stand-alone vendor prepayment can’t use the Auto-Apply accounting preference to automatically apply vendor prepayments to your bills.
推奨する考え方
発注があるなら、必ず発注にひも付けてください。
スタンドアロン型が悪いわけではありません。前払いを積んでおいて後から使う運用には合っています。ただし、その場合は「誰がいつ充当するか」を運用ルールとして決める必要があります。決めていないと、まさに「残ったまま」になります。
なお、同じ発注に複数の前払金をひも付けることもできます。分割して着手金を払う取引に対応できます。
自動充当が働く条件と、働かない条件
PO紐づけ型を選んでも、自動充当は常に働くわけではありません。ここが実務で最もつまずく箇所です。
働く条件
公式ドキュメントによると、自動充当（Auto-Apply）には次の条件があります。
| 対象 | 必要な状態 |
|---|---|
| 発注（PO） | Pending Receipt / Pending Bill / Partially Received / Pending Billing・Partially Received のいずれか |
| 仕入先前払金 | Paid または Partially Applied |
| 請求書（Bill） | Open |
さらに、請求書についてこう注記されています。
Bills that have a Payment Hold or Pending Approval status are not available for application
支払保留中や承認待ちの請求書は、自動充当の対象になりません。承認フローを回している会社では、承認が下りるまで前払金は充当されないということです。
働かない条件（最大の落とし穴）
もう一つ、見落とされやすい条件があります。請求書をどこから起票したかで挙動が変わります。
公式ドキュメントは、自動充当が働くのは発注画面の請求ボタン、または発注からの請求作成の画面を経由した場合だとしています。理由はこう説明されています。
Auto-Apply requires an association to the purchase order
一方、請求書を単独で起票する経路（Enter Bills）からは、自動充当は働きません。発注との関連が作られないためです。
これは操作の巧拙ではなく、機能の前提条件です。経理が普段どおり請求書を起票しているだけで、前払金が充当されない状態が起こり得ます。
対策は運用手順の固定です。「発注がある取引の請求書は、必ず発注から起票する」を業務手順として明文化し、例外を作らないことです。
充当の順序と金額
複数の前払金が同じ発注にひも付いている場合、公式ドキュメントでは古いものから順に充当されるとしています。金額は各回で可能な最大額が充当されます。
充当の配分を自分で決めたい場合は、自動充当ではなく手動で充当する必要があります。
なお、仕入先割引はこの機能では考慮されません。割引を扱う取引では、別途の処理を設計してください。
「まだ残っていて大丈夫か」を仕組みで解消する
ここまでの設定ができていれば、前払金と発注は構造的に結ばれています。あとは見る仕組みです。
見るべきは残高ではなく、滞留
前払金の残高一覧だけを見ても、判断はできません。残高があること自体は正常だからです。
判断に必要なのは、次の3つを並べた状態です。
- 前払金の金額と支払日
- ひも付いた発注の進捗（入荷済みか、検収済みか、請求が届いたか）
- 支払日からの経過日数
この3つが同じ画面にあれば、「払って90日経っているのに入荷の予定が動いていない」といった異常が、質問しなくても見えます。
線の引き方を先に決める
可視化しただけでは運用は回りません。どこから異常とみなすかの線を先に決めてください。
- 取引の性質ごとに標準的な納期を決める（海外仕入は120日、設備は180日など）
- 標準納期を超えた前払金を「要確認」として区別する
- 要確認になったものを、誰がいつ見るかを決める
線が決まっていれば、月末の確認は「要確認の件数がゼロか」を見るだけになります。経理から購買への個別の質問は不要になります。
買う側の検収と、売る側の検収は別物
前払金の精算には検収が関わります。ここで用語の混同が起きやすいので、区別しておきます。
自社が売る側の検収は、売上をいつ計上するかの基準の話です。詳しくは検収書とは何か？納品書との違いとNetSuiteによる効率的な管理方法で扱っています。
この記事で扱っているのは、自社が買う側の検収です。前払金を精算してよいかどうかの根拠になります。同じ「検収」という言葉ですが、立場も使う目的も逆です。
よくある失敗パターンと回避策
失敗1：請求書を入れたのに、前払金が充当されない
現象：発注にひも付けて前払金を登録したのに、請求書を入れても充当されない。手で充当し直している。
構造的な原因：請求書を単独で起票する経路から入力しているためです。自動充当は発注との関連を前提としており、発注を経由しない起票では関連が作られません。
回避策：請求書の起票経路を業務手順として固定してください。「発注がある取引の請求書は、必ず発注から起票する」を手順書に明記し、経理の担当者全員に共有します。設定の問題ではなく手順の問題なので、教育と手順書で解決します。
失敗2：承認待ちの請求書が滞留し、前払金も消えない
現象：請求書は登録されているのに、前払金がいつまでも残っている。調べると請求書が承認待ちだった。
構造的な原因：承認待ちや支払保留の請求書は、自動充当の対象外です。承認フローが滞ると、前払金の滞留として現れます。
回避策：前払金の滞留を見るときは、請求書の承認状況も同じビューに入れてください。「前払金が残っている」と「請求書が承認待ち」が同時に見えれば、原因の切り分けが一度で済みます。承認の滞留そのものはNetSuiteの承認ワークフロー実装ガイドの設計で対処します。
失敗3：前払金の残高は合っているのに、誰も判断できない
現象：残高一覧は正確に出ている。しかし「この前払金は大丈夫か」に誰も答えられない。結局、担当者に電話で確認している。
構造的な原因：残高しか見ていないためです。判断には発注の進捗と経過日数が要りますが、それらが別の場所にあります。
回避策：第5章のとおり、前払金・発注の進捗・経過日数を同じビューに並べ、標準納期を超えたものを区別する線を先に引いてください。線がないと、可視化しても判断は人に戻ります。
ベンチャーネットの対応
ベンチャーネットは、NetSuiteの前払金まわりの運用設計と実装に対応しています。
- 前払金と発注をひも付ける運用ルールの設計。どの取引をPO紐づけ型にするか、スタンドアロン型をどこまで許容するかを、実際の取引の性質から決めます
- 請求書の起票経路の標準化。自動充当が働く手順を業務手順書に落とし込み、教育まで行います
- 滞留前払金の可視化。前払金・発注の進捗・経過日数を並べたダッシュボードとカスタム保存検索を実装します。輸入商社・製造業で必要になる「標準納期を超えた前払金だけを出す」仕組みも含みます
- 前払金の承認フローの設計。仕入先前払金には承認プロセスを設定できます。金額や取引先に応じた承認の分岐を組み立てます
国内向けの支払実行そのもの（振込データの作成）はNetSuiteで全銀フォーマット（FBデータ）の支払を自動化する方法で扱っています。前払金の管理と支払の実行は、分けて設計します。
海外仕入や長納期設備を扱う会社では、前払金の管理そのものが資金繰りの精度に直結します。単なる経理の作業ではなく、支払った資金がいつ物に変わるかを追う仕組みとして設計します。
やらない選択肢も提示します。前払いがほとんど発生しない会社に、この仕組みを整えることはおすすめしません。取引の実態を確認したうえで判断します。
よくある質問（FAQ）
Q1. 前払金と前払費用は何が違いますか
対価の性質が違います。
前払金は、商品やサービスそのものの代金を先に払ったものです。受け取った時点で仕入や費用に振り替わります。前払費用は、まだ提供を受けていない期間分のサービス料を先に払ったものです。保険料や賃借料のように、時の経過にしたがって費用になります。
仕入先前払金の機能が対象にするのは、前者です。発注に対する先払いを扱います。
Q2. 前払金を払った時点で、消費税はどう扱いますか
支払った時点ではなく、実際に引き渡しやサービスの提供があった時点で認識します。
国税庁のタックスアンサーNo.6165は、売上げや仕入れの時期をこう説明しています。「受取や支払の時期に関係なく、実際に引渡しやサービスの提供があった時」。前払いをしても、その時点で仕入税額控除の対象になるわけではありません。
前払金が資産として残る期間は、消費税の処理も保留されている状態だと理解してください。
Q3. 発注にひも付けない前払金は使わないほうがいいですか
使ってはいけないわけではありません。発注を立てない継続的な取引や、前払いを積んでおいて後から使う運用には合っています。
ただし自動充当は働きません。誰がいつ充当するかを運用ルールとして決めてから使ってください。決めずに使うと、残高だけが残って判断できない状態になります。
発注がある取引については、ひも付けることを推奨します。
Q4. 前払金の支払いに承認を回せますか
回せます。公式ドキュメントには、仕入先前払金の処理に承認プロセスを設定できる旨の記載があります。
ただし第6章の失敗2のとおり、承認待ちの請求書は自動充当の対象外です。承認フローを設計するときは、承認の滞留が前払金の滞留として現れることを前提に、滞留の監視もセットで設計してください。
まとめ：前払金は「残高」ではなく「発注との距離」で見る
NetSuiteの前払金管理でつまずくのは、機能を知らないからではありません。前払金と発注が別々に管理され、突き合わせが人手に残っているからです。
- 仕入先前払金は、買掛金に影響せず、充当したときに初めて買掛金をオフセットする
- 発注にひも付ければ自動充当が使える。ひも付けなければ使えない
- 自動充当は、請求書を発注から起票した場合にのみ働く。承認待ちの請求書も対象外
- 月末の確認をなくすには、前払金・発注の進捗・経過日数を並べ、異常とみなす線を先に引く
今日できること：残っている前払金を1件選び、「ひも付いた発注がどこまで進んでいるか」を調べてみてください。調べるのに何分かかったか、どこを何回見に行ったかを記録します。その回数が、設計で減らせる工数です。
前払金の運用設計から可視化の実装まで、ベンチャーネットが伴走します。「毎月同じ質問をしている」という段階でも構いません。まずはご相談ください。
もう少し詳しく知りたい方へ
関連記事
