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