店舗とECの売上を足す前に何をそろえる？同じ注文と返品の確認方法

売上・注文・入金のどれを数えるか、先に決める

経営会議で知りたいことから、使う記録と数える単位を選びます。注文の受付、商品の販売、お金の受領は別の出来事です。店頭のレシートとEC注文が同じ販売に関係していても、二つの出来事を同じ指標として足せるとは限りません。

次の表は、数える対象を決めるための相談表です。「何を知りたいか」の行を選び、その右の条件を販売・EC・経理の担当と埋めてください。各行は選択肢であり、三つを足し合わせる表ではありません。

三つの紙は別の出来事を表します。矢印は足し算ではなく、目的から選ぶ関係です。選んだ日付・状態・金額の条件を、次の表で具体化します。

たとえば、後で読む店頭受取の組は「注文が架空日A、受取が架空日B」です。注文受付を見るなら注文の日が検討対象ですが、販売規模を見る条件は会社の定義を経理と確認します。二つの日を都合よく同じ期間へ寄せる方法は採りません。

この例の用途は「経営用に店舗+EC販売を同期間で把握する試作。実税務・会計確定ではない」。一方、数える基準は「販売行、注文、入金のどれを数えるか未確定」のままです。期間の呼び名は「架空の同期間A」ですが、実在の日付や締め時刻は設定していません。この表から選んだ結果を、すでに決定済みの条件として扱わないでください。

POSは店頭の販売や精算などを記録する仕組み、ECはインターネット上の販売です。どちらも一行が「注文全体」「商品一行」「受渡し」のどれかを確かめます。一注文に複数明細があるとき、行数をそのまま注文数にはできません。

次にすること：経営者へ示す指標を一つ選び、「使う記録・一件の単位・採用する状態・日付」を担当と相談します。資料の所在や一行の単位から不明なら、経営に使うデータの所在・粒度・更新を整理する方法で今回の元記録を特定してください。

レシートとEC注文を、一件ずつ読み合わせる

関連番号・明細・状態を読み、同じ販売を一度扱う候補か、対応不明かを分けます。次の三つは、別々の状況を読み分ける架空例です。改善前後や処理の順番ではありません。番号は元記録を追うための仮の識別子として残し、見出しでは仕事の名前を使います。「未確認」は、0円、取引なし、返品なしを意味しません。

図の「計上条件」は、この経営用の集計で、どの記録をどの日付・金額で売上に含めるかという条件です。会社の経理と確認する内容で、実際に帳簿へ計上したという意味ではありません。

図で見る問い：EC注文に関連番号が書かれた店頭受取と、同じ金額でも関連が不明な記録は、同じ扱いで足せるでしょうか。レシートと注文の番号、受取という状態、日付、線が結ばれている範囲を見てください。

細かい番号と状態は、すぐ下の比較表でも読めます。図の対応線は、二つの記録に同じ注文番号が記載される関係を示します。金銭の移動や、集計・重複除去の完了を表すものではありません。同額という理由だけの組には同一取引の線を引きません。関連番号がある組でも、受取が追加販売かどうかと、数える日を元画面で確かめます。

店頭だけの購入

この例は店頭の販売として置かれています。元記録の値と、分からないことを分けて読みます。

EC情報が未提供であることは、全EC販売を探して対応がないと証明した結果ではありません。金額を一度扱う候補でも、税と締め日が未確認なら、他の売上とそろえた総額にはできません。

EC注文を店頭で受け取る

同じ注文を二度足す危険があるのは、この組です。どちらも3,000円ですが、店頭側の状態は受取記録、EC側は注文です。対応する項目を一行ごとに並べて見ます。

店頭の関連注文番号は E-09。ECの注文番号と対応し、例の関連判定は 「関連あり」、一度数える候補は 「候補あり」 です。

単純に金額欄だけを足すと3,000円＋3,000円＝6,000円になります。ただし、これは二つの欄を機械的に足す危険を示す算数で、この組の正しい売上総額を計算した結果ではありません。店頭で追加の商品販売が含まれるか、分けて記録されるかも、この説明例からは分かりません。

担当へ尋ねることは「POS受取が追加販売か単なる受渡しか」「どちらの日に含めるか」です。受渡しだけなら同じ注文を別販売として追加しないように扱い、追加販売が含まれるなら該当明細を区別します。その後に、どの日を使うか、税や返品をどう合わせるかを確認します。候補のtrueを、最終集計の了承へ進めないでください。

対応がまだ分からない行

こちらは両側が2,000円で日付も同じですが、注文との対応や状態が分かりません。同額・同日だけでは、同じ販売か、別の販売かを決められません。

店頭の関連注文番号は 未確認、同じ取引かの判定は 未確認、一度数える候補も 未確認 です。別取引として二つを採用したり、重複だとして片方を消したりせず、対応確認を保留します。

調べる対象は「同じ販売か別販売か」「取消/返品/未処理」「元画面担当」です。注文や受渡しの元画面を管理する担当へ、どの状態の記録で、関連する注文・返品・返金記録があるかを尋ねます。元の行は残し、確認先と総額へ含めていない理由が追えるようにします。

例2の関連IDは架空の入力。例3の同額は同一取引の証明ではない。3例は修正前後/実成果/実欠損原因ではない。

次にすること：自社の一組について、元の番号・関連番号・金額・状態・日付を並べます。関連が不明なら削除せず、分からない問いを保留の記入例と同じ形で残してください。

日付・税・返品と、取り込んだ時点をそろえる

対応が分かった組も、日付・金額・返品・取得時点がそろうまで確定値にしません。同じ対象期間という表記でも、注文日で選んだ表と受取日で選んだ表では、含まれる記録が変わります。

表の「残すもの」が、集計担当から経理やIT担当へ渡す条件になります。一度に総額を直す前に、店頭受取の一組で日付と金額の意味を説明できるか確かめてください。

同じ注文に関係していても、二つの日は違います。点線は採用日を相談する関係で、計上済みを示しません。税・返品・取得時点も次の表でそろえます。

たとえば、注文と受取のどちらの日を選ぶか決まっていない間に、二つの表を月別に合計しても、差が二重計上なのか日付の違いなのか区別できません。先に採用する出来事を決め、対象に含めた理由を一件から説明できるようにします。金額の内訳がなければ、税や送料を推測してそろえないでください。

返品受付、商品の戻り、注文取消、お金の返金は、見る出来事を分けます。Shopify公式の販売データ不一致の説明も、同製品の販売レポートの返品と財務レポートの返金、注文エクスポートの違いを説明しています。これは自社レポートの意味を調べる手掛かりです。同製品の分類を、全POSや日本の会計・税務の一律の基準にはしません。

返品番号が未確認でも、返品なし・返金0円ではありません。この架空例には実際の返品や後着行は与えていません。締め後の訂正は、会計連携の締め・訂正・照合の確認方法も参照し、経理の確認範囲と分けて進めます。

次にすること：表の四条件を自社の採用項目と担当へ置き換え、未決の欄を埋める依頼を出します。未決のまま試す場合は「何が未決で、どの範囲を除いた試算か」を明示してください。

元の画面へ戻り、確認担当へ具体的に尋ねる

総額の差を説明する前に、一組の元記録へ戻り、担当・根拠・回答を結びます。合計済みの日報だけでは、受渡しと追加販売を見分けられない場合があるためです。画面名は製品によって違うので、以下を自社のレシート明細、注文詳細、受取・返品履歴に読み替えます。

上から順に進める手順です。右欄の成果物がなければ、次の工程で推測を埋めず、元の担当へ確認を戻します。

矢印は、元記録の意味を確かめてから条件を渡す順です。回答や実装の完了を示しません。各工程の担当・根拠・成果物は次の表で読めます。

回答が「受渡しだけ」と確認できた場合は、同じ注文を追加販売として二度足さない条件を相談します。「追加販売あり」なら元注文と区別できる明細が必要です。答えが不明、または候補が複数なら、勝手に一つ選ばず保留へ戻します。どの場合も日付や税・返品の確認は別に残ります。

次にすること：一組を選んで上の依頼文の番号と問いを自社のものに置き換えます。IT担当には「自動で重複を消す」だけでなく、同じものと認める根拠、曖昧なら止める条件、元記録への戻り方を一緒に渡してください。

表をつなぐ処理と、同じ販売の照合を分ける

行を追加すること、同じ販売の関係を調べること、金額を集計することは、別の仕事です。表が一つになっても、同じ注文が二行残ることはあります。次の架空例では、同じ二つの記録を工程ごとにどう読むかを示します。

一表になっても受取と注文の二行が残ります。関連があるかを読む仕事と、どの条件で数えるかを決める仕事は別です。受渡しか追加販売か、採用する日・金額・返品の条件を確認してから集計します。

この図で読めるのは「二行を一つの一覧に置く」と「一つの販売として扱える」は違う、ということです。二つの金額欄を機械的に足すと3,000円＋3,000円＝6,000円ですが、これは誤った足し方の危険を示す算数で、正しい売上総額ではありません。関連があるという入力だけで、片方の3,000円を削ってよいとも確定しません。

Microsoft公式のPower Query「Append queries」では、行追加は列名で項目を合わせ、相手の表にない列はnull（その列に値がない状態）になります。列の位置が同じだから同じ意味と決める操作でも、取引を自動判定する機能でもありません。

同製品の「Merge queries overview」は、選択した列の値を使って表を結び合わせる操作を説明します。対応列のデータ型を合わせ、複数列なら選ぶ順もそろえる必要があります。ただし、列が一致したことは業務上の同一販売の証明ではありません。注文一件に複数の受取・明細が結び付けば、注文総額が複数行に繰り返されることもあるため、そのまま総額列を足さないでください。

次にすること：IT担当へ「元の二行がどこに残るか」「関連の根拠はどの列か」「複数候補をどう保留するか」「どの条件で数えるか」を別々に確認します。本稿は考え方の説明で、Power Query・Excel・APIの処理を実行した記録ではありません。

対応不明・欠けた期間・後から来た訂正を残す

保留は削除でも0円への置き換えでもありません。元の行と未解決の問いを残し、誰のどの回答で扱いを変えるかを明示します。曖昧な組を片方だけ消すと、別の販売を落とす危険があります。

以下は、対応不明のS-99とE-11を記入した静的な文例です。自社で使うときは、同じ欄へ自社の参照と回答を記録します。確認の送信・回答・処理を実施済みと見せるものではありません。

二つの記録の間に、同じ販売と示す線はありません。点線は両方の参照をメモへ残す関係です。次の記入例で、誰へ何を尋ねるかまで具体化します。

金額と日付が同じことから、関連未確認を「別取引」や「重複あり」へ変えません。相手が見つからない理由も、未取込・未処理などと推測しないでください。保留を解く根拠が得られたときに、元参照・理由・採用条件を一緒に更新します。

対応不明以外にも、対象範囲が欠ける場合と、後から訂正が来る場合は扱いを分けます。次は将来起きた場合の手順であり、この架空例で取込失敗や返品を観測した結果ではありません。

次にすること：保留中の一組について「元参照／不明点／調べた場所／確認先／暫定の扱い／再確認のきっかけ」を書きます。根拠が増えていない間は、都合のよい採用判定へ進めません。

試算後は、採用した記録と保留した理由を確かめる

試算は、元の一組から採用・保留の理由をたどれるかで確かめます。合計がたまたま同じでも、重複と欠落が打ち消し合っているかもしれません。元記録、集計条件、処理後の扱いを同じ組で照らし合わせます。

次は実務で記録を残すための確認表です。「満たせば次へ進む」は期待条件で、実際の合格結果ではありません。確認した根拠・担当・時点を記入し、満たさない項目は保留理由と再確認の条件を残します。

虫眼鏡の対象は合計金額だけではなく、元番号と判断理由の対応です。実際の確認結果は未実施です。次の表の期待条件に照らして根拠と担当を残します。

記録は「判定＝未確認／進める／保留」「見た根拠」「確認担当」「確認時点」「保留理由」「再確認のきっかけ」を一組にします。返答が「処理成功」だけなら、元の販売がどう扱われたかを再確認してください。試算の技術的成功を、販売や経理の了承へ読み替えません。

本稿の三例は税や締めなどが未確認なので、正しい経営用総額は出していません。照合率・導入効果・作業時間の実測もありません。担当者が根拠を見て判断するための確認手順として使ってください。

次にすること：進められる範囲と保留範囲を分けて利用者へ説明します。保留分は担当の回答や元記録が得られたときに戻し、対象条件と変更理由を残して再試算します。

まとめ：一組の記録を確認し、足せる条件を決める

店頭とECの合計を足す前に、数える対象を決め、元の一組を照合し、日付・金額・返品・取得時点をそろえます。関連番号は候補の根拠であり、集計確定の印ではありません。同額同日の対応不明は保留します。

図の順に進め、未確認は飛ばさず残します。最初から全件を自動処理する前に、自社の店頭受取を一組選んでください。

1. 何を数えるか選ぶ
2. 一組を担当と読む
3. 不明点を残す
4. 採用・保留を確かめる

最初の一歩：自社の店頭受取を一組選び、レシート番号・関連注文番号・状態・日付を並べて、販売・ECの担当と読み合わせてください。経理と数える条件を確認できるまでは、総額を確定しません。