売上の集計が合わない原因と対策。条件に事務作業を混ぜない
こんにちは、時短ギア管理人の清光です。
コードは書けない現役の営業ですが、AIと一緒に、現場が毎日使う業務システムを1年以上つくり続けてきました。
「入力したはずの金額が、合計に出てこない」——そんな指摘を受けたことはありませんか。
この記事では、数字が合わない原因を入力ミスではなく「数える条件」から疑う方法を、私の失敗そのままの形で紹介します。
売上の集計が合わない原因は、たいてい「条件」にある
数字が食い違うと聞くと、まず入力ミスを疑いますよね。私も最初はそうでした。
でも自作の業務ツールで実際に調べたら、犯人は入力ではなく、集計が「何を売上として数えるか」という条件のほうでした。
正直、ここは自分で決めた条件なので、疑うのが一番遅くなる場所なんですよね。
私の失敗＝「請求書を出した案件だけ」を売上にしていた
自作ツールの収支画面で、入力したはずの金額が合計に出てこない、という指摘を受けました。
調べると、収入に載せる条件が「請求書の送付記録がある案件」になっていたんです。
これで何が起きるか。請求書を出さずにその都度精算する取引先の分は、構造的に永久に合計へ出てきません。
しかも同じ条件は他の取引先にも効いていました。つまり請求書を出し忘れた月は、数字が丸ごと消えるという弱点でもあったわけです。
なぜ静かに消えるのか＝「事務の作業」を条件に混ぜたから
請求書の送付は、お金が動いた事実そのものではありません。人がやる事務作業の記録です。
そこを条件にすると、集計は「取引があったか」ではなく「事務をやったか」を数えることになります。
最初にハマったのが、この壊れ方はエラーを一切出さないという点でした。
合計が少し小さく出るだけなので、誰かが実物と突き合わせるまで誰にも気づけません。
数字が静かに欠ける話は、以前ダッシュボードの指標の決め方でも書きました。集計はだいたいこの型で壊れます。
直し方は3ステップ。条件を「事実」に置き換える
- いまの集計が何を条件に数えているかを、一文で書き出す（例：請求書の送付記録がある案件）
- その条件が「事実」か「人の作業」かを判定する。作業なら必ず欠測すると考える
- 条件を、作業に依存しない事実へ置き換える（私の場合は「入金予定がある案件」にしました）
ここで捨てなくていいのが、請求書を出したかどうかの情報そのものです。
私は集計の条件からだけ外して、画面上のラベルとして残しました。見えるけれど数字は左右しない位置まで降格させた形です。
これがかなり効きます。実際にやってみたら、消えていた分が合計に戻ってきました。
条件に混ぜてよいもの、いけないもの
| 条件にしてよい（事実） | 条件にしてはいけない（作業） |
|---|---|
| 入金予定・入金日 | 請求書を送ったか |
| 契約が成立したか | 台帳に転記したか |
| 発生した金額そのもの | ステータスを更新したか |
見分け方はひとつだけです。
「その入力をサボっても、仕事は回るか」と自分に聞いてみてください。
回るなら、それは必ず抜けます。数える条件には使えません。
次に出てくる疑問に、先回りで答えます
Q. 条件を変えたら、過去の数字はどうなりますか？
今まで消えていた分が戻るので、合計は上がります。
ただし前後の数字は比べられなくなります。定義を変えた日をメモに残しておくと安全です。
Q. スプレッドシートでも同じことは起きますか？
起きます。条件付きの合計に、チェック欄や進捗の列を入れているなら、まったく同じ型です。
Q. 請求書の管理をやめろ、ということですか？
いいえ、逆です。管理は今までどおり続けたうえで、集計の条件からだけ外します。
まとめ：今日やるのは、条件を一文で書くことだけ
- 売上の集計が合わないときは、入力ではなく「数える条件」を先に疑う
- 条件に「人の作業をやったか」を混ぜると、サボった月の数字が丸ごと消える
- 置き換え先は、作業に依存しない事実（入金予定・契約の成立など）
- 作業の記録は捨てず、集計に効かないラベルへ降格させる
今日の一歩は5分で終わります。自分の集計が何を条件に数えているかを、一文で書き出してみてください。
それだけで、消えている数字があるかどうかの見当がつきます。私の場合も、気づいたきっかけはこの一文でした。
今日はここまで。この記事が、あなたの時間を少しでも価値に変えるお手伝いになれば嬉しいです。
それでは、また次の時短ハックでお会いしましょう。
自作している業務システムのことや、お仕事のご依頼はお問い合わせからどうぞ。
