受注残と売掛金は同じですか？

同じではありません。受注残は受注後に提供や売上計上が残っている範囲を指すことがあり、売掛金は売上計上後にまだ回収していない債権です。自社の台帳では、未提供、未検収、未請求、請求済み未入金を別の状態にします。

受注残が多ければ、業績は好調ですか？

受注が積み上がっている点は確認できますが、それだけで好調とは判断できません。提供可能な体制、延期や中止の有無、粗利、売上になる時期、入金時期を分けて確認します。根拠のない予定額を確定売上へ足しません。

分割提供する契約は、どの単位で管理しますか？

人が完了を確認でき、予定日や金額を更新できる提供明細に分けます。月次支援なら対象月、制作なら成果物、研修なら実施回などが候補です。契約1件を1行のままにすると、一部だけ終わった状態を表せません。

AIで受注残を自動更新できますか？

メールや議事録から日付変更や完了候補を抽出する補助はできます。ただし、顧客との合意変更、検収、確定残額、売上計上をAIだけで決めないようにします。根拠箇所と更新案を人へ返すところから試します。

受注残とは？受託サービスの未提供・未検収・未請求を分ける管理方法

受注は増えているのに、今月どこまで提供でき、何を請求できるかは担当者へ聞かないと分からない。こうした状態では、受注残の合計があっても、次の行動は決まりません。特に月額支援、制作、開発、研修などは、1件の契約を複数回に分けて提供するため、契約単位の一行だけでは途中の状態が消えてしまいます。

営業の着地予測で受注残をどう足すかは営業パイプライン管理、販売管理と会計の役割分担は販売管理ソフトと会計ソフトの境目、請求後の滞留は売掛金エイジングで扱っています。この記事では、受注後から請求前までに残る提供明細の管理へ絞ります。

受注残とは、受注したうち未完了の範囲です

物販では、受注した数量のうち未出荷や未納品の数量を受注残と呼ぶことが一般的です。一方、サービスでは、提供、売上計上、請求の時期が一致しないことがあります。そのため「受注したが請求していない額」と「受注したが売上として扱っていない額」が同じとは限りません。

ディータイドの請求管理システムBsupの公式説明でも、サービス提供では請求と売上計上のタイミングや提供回数が異なるため、未請求と未売上を分けて扱っています。これは同製品の管理方法ですが、サービスの受注残を一つの残高だけで表すと意味が曖昧になる具体例です。出典：ディータイド「受注残一覧表」

未提供・未検収・未請求・未入金を分けます

最初に、自社で「残っている」と呼んでいる状態を分解します。合計だけを見る前に、各行がどの状態にあるかを一つ選びます。

受注後に分ける4つの状態
状態	意味	次に確認する項目
受注済み・未提供	契約は成立したが、約束した作業や成果物をまだ提供していない	提供予定日、担当者、提供単位
提供済み・未検収	提供は終わったが、顧客の確認や合格の記録がそろっていない	提出物、版、確認期限、差戻し
検収済み・未請求	確認は終わったが、請求書の発行や送付が終わっていない	検収日、請求予定日、請求担当
請求済み・未入金	請求済みで、支払期限または入金確認を待っている	請求番号、支払期限、入金状態

未検収と未請求を受注残に含めるかは、社内の目的によって変わります。営業会議、提供管理、会計処理で必要な数字は同じではありません。共通の明細を使いながら、画面や集計では状態別に分けます。会計上の売上認識は契約内容と履行義務に基づくため、管理表の状態名だけで決めません。

企業会計基準委員会の収益認識基準は、顧客との契約を識別し、契約に含まれる履行義務を識別し、その履行義務を充足した時または充足するにつれて収益を認識する手順を示しています。この記事の管理表は会計判断の代わりではありません。自社の契約に対する売上計上は、経理責任者や税理士・会計士と確認してください。出典：企業会計基準委員会「収益認識に関する会計基準」

契約1件ではなく、提供明細を1行にします

契約総額を一行で持つと、一部が完了した後も全額が残るか、反対に最初の請求で全額が消えるかのどちらかになります。月次支援なら対象月、研修なら実施回、制作なら成果物、開発なら受入単位など、人が完了を確認できる提供明細へ分けます。

ただし、細かく分けるほどよいわけではありません。担当者が予定と実績を更新でき、責任者が完了を確認できる単位を下限にします。一つの作業を数十分ごとのタスクへ分けても、契約上の提供状態や請求予定を判断できなければ、管理項目だけが増えます。

受注残台帳に持つ最小項目
項目	役割
案件ID・明細ID	契約全体と、分割した提供単位を結びます
提供内容	何を渡せば完了かを短い言葉で固定します
合意金額	契約総額ではなく、その明細へ割り当てた金額を持ちます
予定日・実績日	提供、検収、請求の予定と実績を別々に持ちます
現在の状態	未提供、確認待ち、差戻し、検収済みなど、今の状態を1つ選びます
根拠	契約、注文、議事録、提出物、検収記録の場所を残します
次回行動・責任者	誰が、何を、いつまでに更新するかを決めます

部分完了・延期・中止を同じルールで更新します

たとえば、3か月の業務整理支援を90万円で受注し、各月30万円の提供明細に分けたとします。1か月目が検収済み、2か月目が確認待ち、3か月目が翌月へ延期なら、残り60万円を一つの受注残にしません。2か月目は確認待ち、3か月目は未提供として、次の行動と予定日を別々に持ちます。

延期では予定日だけを書き換えず、変更前の日付、変更理由、合意した相手、根拠となるメールや議事録を残します。中止の場合も、担当者の判断で明細を削除しません。合意内容、取消額、既に提供した範囲、請求の扱いを確認し、状態を「中止」へ変えます。履歴を残すと、前週から受注残が減った理由を説明できます。

前受金がある場合も、入金したから提供済みになるわけではありません。入金状態と提供状態を別の列に置きます。反対に、提供が終わっていても請求や入金が済んでいるとは限りません。工程を一つの「完了」へ押し込まないことが、二重計上と確認漏れを防ぎます。

週次確認では、金額ではなく変化と期限を見ます

週次会議で全行を読み上げる必要はありません。前回から予定日が変わった明細、期限を過ぎた明細、根拠なしで完了になった明細、次回行動や責任者が空欄の明細だけを出します。

提供・検収・請求の実績日を更新します。
予定日を過ぎた明細を、提供待ちと顧客確認待ちに分けます。
前週から金額が増減した明細の根拠を確認します。
担当者だけで解消できない変更を、責任者へ戻します。
次回行動、期限、更新者がある状態で会議を終えます。

受注残の総額は結果です。会議で判断したいのは、何が止まり、どの条件を誰が解消すれば提供や請求へ進むかです。総額が同じでも、来週提供できる明細と、合意の見直しが必要な明細では扱いが異なります。

AIは更新候補と根拠箇所の抽出から試します

メールや議事録が多い場合、AIに「予定日が変わった可能性のある明細」「中止や範囲変更に触れた箇所」「顧客の確認待ちを示す記述」を抽出させる使い方があります。出力には案件ID、変更候補、根拠文、元資料、確認者を含めます。

AIの抽出結果をそのまま確定データへ書き込ませません。同じ言葉でも、希望、社内予定、顧客との合意は意味が違います。根拠を人が読み、合意済みかを確認してから台帳を更新します。売上計上、確定残額、顧客への連絡、請求書発行も人の承認を残します。

試すときは、架空または匿名化した数件で、変更の拾い漏れ、誤抽出、根拠へ戻れたか、人の確認時間を記録します。この記事ではSalesDockによる削減率や精度実績を示していません。自社の資料と判断条件で比較してください。

来週は、進行中の3案件だけを明細へ分けます

最初から過去の全案件を移行せず、進行中の3案件を選びます。契約を提供明細へ分け、未提供、確認待ち、検収済み、請求済みを付けます。状態を選べない行が出たら、列を増やす前に「何の証拠があれば次へ進めるか」を担当者と確認します。

3案件を一週間更新すると、営業、実行担当、経理のどこで同じ情報を再入力しているかが見えます。既存のCRM、案件表、請求ソフトを捨てる前に、案件IDと明細IDで受け渡せる場所を決めます。自社の受注から提供・請求までを一枚に整理したい場合は、下の相談窓口で現状の表と確認手順を一緒に確認できます。