두 표의 숫자가 안 맞을 때 대조하는 프롬프트

다음 순서로 확인하세요. 현재 설명만으로는 원인을 확정할 수 없습니다.

1. 범위(Scope)

두 보고서의 9월 범위를 동일하게 맞춰 비교합니다.

확인할 항목:

• 기간: 9월 1일 00:00부터 9월 30일 23:59:59까지인지
• 기준 일자: 주문일, 계약일, 결제일, 매출 인식일 중 무엇인지
• 법인·사업부·국가·통화 등 대상 엔터티
• 취소·환불·보류·삭제·테스트 거래의 포함 여부
• 세금과 할인 포함 여부
• CRM의 거래 금액이 ERP 매출 금액과 같은 정의인지

실행할 체크:

두 시스템에서 거래별로
거래 ID, 기준 일자, 상태, 사업부, 금액, 세금, 할인, 통화
를 추출한 뒤 동일한 필터 조건으로 집계한다.

판정:

• 같은 조건으로 다시 집계했을 때 합계와 건수가 일치하면 범위 차이가 원인입니다.
• 여전히 ERP 128,450,000원·342건, CRM 131,200,000원·338건이면 범위 차이만으로는 설명되지 않습니다.
• 특히 CRM이 4건 적은데도 2,750,000원 더 큰 구조가 그대로인지 확인합니다.

2. 차이의 형태(Difference shape)

현재 차이는 다음과 같습니다.

• 금액: CRM이 2,750,000원 더 큼
• 건수: ERP가 4건 더 많음
• 평균 거래액:
  • ERP: 약 375,877원
  • CRM: 약 388,166원

먼저 각 금액이 거래 한 건 또는 묶음의 금액과 일치하는지 확인합니다.

실행할 체크:

ERP와 CRM 각각에서 다음 금액을 찾는다.
1. 2,750,000원과 정확히 같은 거래 금액
2. 2,750,000원의 배수 또는 분할 조합
3. 여러 거래 금액의 합이 2,750,000원이 되는 조합
4. 수량 × 단가가 2,750,000원이 되는 거래 또는 품목
5. 세금, 할인, 수수료, 배송비 합계가 2,750,000원인지

판정:

• 한 거래가 정확히 2,750,000원이면 즉시 해당 거래의 포함 여부·상태·금액 필드를 대조합니다. 이것이 가장 우선적인 설명 후보입니다.
• 여러 거래의 합이 2,750,000원이면 CRM에만 포함된 거래 묶음 또는 ERP에서 제외된 거래 묶음일 가능성을 확인합니다.
• 수량 × 단가, 세금, 할인, 수수료 합계가 일치하면 금액 산식 또는 매출 정의 차이를 확인합니다.
• 일치하는 금액이 없으면 다음 단계로 진행합니다.

3. 중복(Duplication)

CRM은 건수가 4건 적으므로 단순히 거래 행이 중복됐다고 단정할 수 없습니다. 다만 한 CRM 거래가 여러 품목·기회·계정 행과 조인되면서 금액만 중복 합산됐는지 확인해야 합니다.

실행할 체크:

-- 시스템별 거래 ID 중복
SELECT 거래ID, COUNT(*) AS 행수, SUM(금액) AS 합계
FROM CRM_9월
GROUP BY 거래ID
HAVING COUNT(*) > 1;

품목·고객·기회 조인을 사용했다면:

조인 전 거래 수와 조인 후 행 수를 비교한다.
조인 후 동일 거래ID의 금액이 몇 번 반복되는지 확인한다.

판정:

• 동일 거래ID가 여러 행에 반복되고 금액도 반복 합산됐다면 중복이 확인됩니다.
• 복수 행이더라도 각 행이 실제 품목별 금액이고 합계가 정확하다면 정상 분해일 수 있으므로 중복 원인은 아닙니다.
• 중복 금액의 합이 2,750,000원이면 금액 차이를 직접 설명합니다.
• 중복은 있으나 차이 금액과 맞지 않으면 주원인으로 확정하지 않습니다.

4. 누락(Omission)

두 시스템의 거래 ID를 대조해 어느 쪽에만 존재하는 거래가 있는지 확인합니다.

실행할 체크:

ERP에만 있는 거래 ID 목록
CRM에만 있는 거래 ID 목록
양쪽에 모두 있으나 상태·금액이 다른 거래 목록

각 목록에 대해 건수와 금액을 집계합니다.

판정:

• CRM에만 있는 거래들의 금액 합계가 2,750,000원이면 누락 또는 범위 필터 차이가 확인됩니다.
• ERP에만 있는 거래가 4건이고, 그 금액 합계가 CRM의 초과분과 별개라면 건수 차이와 금액 차이가 서로 다른 원인일 수 있습니다.
• 빈 거래 ID, 공백, 대소문자·하이픈 차이, 숫자형과 문자형 차이로 매칭이 실패했는지도 확인합니다.
• CRM에만 있는 거래가 없으면 단순 누락으로는 설명되지 않습니다.

5. 반올림 및 데이터 형식

실행할 체크:

거래별로 다음 값을 비교한다.
- 원 단위 원본 금액
- 소수점 포함 금액
- 화면 표시 금액
- 반올림 후 금액
- 세전·세후 금액

또한 다음을 검사합니다.

금액 컬럼의 자료형
문자열로 저장된 금액
쉼표·원화 기호·공백 포함 값
NULL 또는 변환 실패 값
합계 전에 반올림했는지, 합계 후 반올림했는지

판정:

• 거래별 반올림 차이의 총합이 2,750,000원이면 반올림 처리 차이가 확인됩니다.
• 문자형 금액 일부가 합계에서 제외되었다면 해당 제외 금액이 차이를 설명해야 합니다.
• 형식 문제는 발견됐지만 차이 금액과 맞지 않으면 원인으로 확정하지 않습니다.

6. 마지막으로 행 단위 비교

앞선 검사에서 설명되지 않은 경우, 공통 거래 ID 기준으로 모든 필드를 비교합니다.

거래ID
거래일
상태
고객·법인·사업부
상품
수량
단가
할인
세금
매출 금액
통화
최종 수정일

비교 결과를 다음 네 그룹으로 나눕니다.

• 양쪽에 있고 금액이 동일
• 양쪽에 있지만 금액이 다름
• ERP에만 존재
• CRM에만 존재

최종적으로 다음 합계가 맞아야 합니다.

CRM 금액 - ERP 금액 = 2,750,000원
ERP 건수 - CRM 건수 = 4건

특히 2,750,000원과 정확히 일치하는 단일 거래, 거래 묶음, 세금·할인·수수료 합계가 있는지 먼저 확인하세요. 해당 값이 한쪽에만 존재한다면 그 거래의 상태와 포함 조건을 대조하는 것이 가장 빠른 종료 지점입니다.