2026-09-19 · WekeyLab AI

AI CSV sales totals: all three got KRW 80,000, but the reports differed

A canceled order still has an older paid row. Another order changes quantity. Add a missing price and a partial refund, and the hard part is choosing which rows to count. ChatGPT, Gemini and Claude all returned KRW 80,000. WekeyLab AI would use Claude’s report as the starting point because it makes the unresolved order hard to overlook.

Our pick: Claude for the report handoff

Claude places the missing-price warning directly after the headline figures. K104 is not included; resolving it can change revenue, the order count and the item count together. It recommends labeling the report provisional. That matters when someone receives the total without reading every row.

ChatGPT and Gemini also correctly hold K104 aside. Claude did not uniquely discover the missing value. Its useful addition is a reconciliation: eight unique orders equal four included, three excluded and one on hold. We would keep that line in the final report.

What the same ten-row input asked them to do

The fictional Korean store data uses September 19, 2026 timestamps in Korea Standard Time and amounts in Korean won. K102 changes from paid at09:15 to canceled at10:10. K103 changes from two units at09:20 to three at10:00. We required the latest row per order before filtering for paid status.

K104 has no unit price and must be held, not assigned zero. Fully refunded K105 and pending-payment K108 are excluded. K107 has a KRW4,000 partial refund, which reduces revenue but not its item count. No shipping or tax amounts are supplied. We fixed eight checks before submitting the same unrestricted Korean question once to each service.

An independent Python CSV calculation retained K101 at24,000, K103 at24,000, K106 at20,000 and K107 at12,000. Gross item amounts of84,000 minus4,000 in partial refunds produce80,000. Four included orders contain ten units. These remain KRW values in this English edition so the source arithmetic is reproducible.

ChatGPT: easy to follow, with some repetition

ChatGPT presents headline totals, a table of every order, individual calculations, exclusion explanations and a workflow for next time. It clearly explains why the latest canceled K102 row wins and why K103 has three units. It separately confirms that K107 keeps one unit despite its partial refund.

Its saved answer was the longest of the three in this run. The table, formulas and explanation repeat information, but that helps when checking source rows one by one. For a report recipient, we would put the short summary and unresolved item first, with the detailed audit trail afterward. Length did not make its arithmetic more correct than the other two.

Gemini: compact tables, with one price-source correction

Gemini gets the same totals and classifications. Its saved answer is the shortest, and its future-work suggestions focus on sorting latest-first, highlighting missing values and flagging unexpected statuses. Those are practical input checks.

Its advice for K104 is to obtain the normal unit price from the product database and add the order afterward. That is useful only if the database preserves the actual price for this transaction. A current catalog or list price could differ from what the customer paid. The input does not tell us what that database contains. WekeyLab AI would instead ask for the transaction’s applied unit price from the order or payment record.

This is a correction to the proposed follow-up, not an arithmetic failure. Gemini correctly excludes K104 from its current KRW80,000 total.

Claude: reconcile where the orders went

Claude shows that ten source rows become eight unique orders after two older versions are removed. Four are included, three excluded and one held. That catches a different kind of problem from merely matching a money total: an order might otherwise disappear without an explanation.

It also suggests holding an order if two rows share its latest timestamp rather than arbitrarily choosing one. Our sample has no tied timestamps, so we did not test that behavior. It is a useful rule to decide before the next file arrives.

Our final version combines Claude’s reconciliation, ChatGPT’s explicit order calculations and Gemini’s input-status checks. Since all three got the supplied calculation right, there is no numerical winner to invent.

Change the order of operations and80,000 becomes110,000

If you filter for paid rows first, K102’s newer cancellation disappears. Selecting the latest remaining row then resurrects the older KRW30,000 paid order. The total becomes110,000. Latest-row selection must happen before status filtering.

Treating the missing price as zero is harder to spot. The revenue total stays80,000, but including K104 produces five orders and eleven units instead of four and ten. Using K103’s old two-unit row instead produces72,000. We calculated these as counterexamples from the same input; they are not mistakes the three services actually made.

WekeyLab AI’s reusable report

This is our own report text for the supplied Korean-won dataset, not a real store’s closed accounts.

September19,2026 CSV report — provisional; K104 price unresolved Net sales: KRW80,000 / included orders:4 / units:10 Included: K10124,000; K10324,000; K10620,000; K10712,000 (KRW) Calculation: gross item amounts84,000 − partial refund4,000 Excluded: K102 canceled; K105 fully refunded; K108 awaiting payment On hold: K104, missing unit price; not treated as zero Reconciliation:10source rows →8unique orders =4included +3excluded +1held No shipping or tax added Next: verify K104’s actual transaction price and latest status, then rerun.

Ask for an audit trail, not just a total

Specify how versions, statuses, missing values and partial refunds should work. Request the included, excluded and held lists, then check that they account for every unique order. Remove customer names and contact details that are unnecessary for the calculation before sharing data.

The prompt below is our reusable template, not another tested run. The related meeting-notes and refund-email comparisons examine the same broader issue: a plausible result is useful only when its conditions stay intact.

Use the latest modified row per order before filtering by status. Show included, excluded and held orders, with per-order calculations. Reconcile their counts against all unique orders. Do not fill a blank unit price with zero or a current catalog price. Flag tied latest timestamps and undecidable values for review. Apply the supplied refund and quantity rules.

Sources and actual records

Actual web replies collected September19,2026,12:02–12:04 KST. Same fictional Korean input, once per service, no length cap. ChatGPT Free/Think off/model not displayed; Gemini Flash/plan unverified; Claude Free/Sonnet5 Medium. Original text fingerprints matched. Eight predetermined checks plus independent Python CSV computation; no file-upload workflow, large dataset, Excel-formula execution or real accounting close tested. EN/ZH editions localize the same run and retain explicitly labeled KRW amounts. Search volume unknown.

Related: meeting action items / 회의록 비교

ChatGPT · 2026-09-19 12:02–12:04 KST

온라인 쇼핑몰 주문 CSV를 보고 오늘 매출을 정리하려고 해. 아래는 연습용 가상 자료이고 금액은 원이야. 보고서에 넣을 순매출, 집계 주문 수, 상품 수량과 주문별 계산 근거를 정리해 줘. 제외하거나 확인해야 하는 주문도 알려주고, 다음에 비슷한 파일을 받았을 때 실수를 줄이는 방법도 설명해 줘.

집계 규칙은 이래. 같은 주문번호가 여러 번 나오면 수정시각이 가장 최근인 행 하나만 사용해. 최신 행의 상태가 결제완료인 주문만 집계하고 취소·전액환불·결제대기는 제외해. 단가가 비어 있으면 0원으로 보지 말고 그 주문은 확인 대기로 따로 빼 줘. 순매출은 수량×단가에서 부분환불액을 뺀 값이야. 상품 수량은 집계에 포함한 주문의 수량 합계이고, 부분환불액이 있다고 수량을 임의로 줄이지 않아. 배송비와 세금은 이번 자료에 없으니 추가하지 마. 수정시각은 모두 한국시간이야.

주문번호,수정시각,상태,수량,단가,부분환불액
K101,2026-09-19 09:10,결제완료,2,12000,0
K102,2026-09-19 09:15,결제완료,1,30000,0
K103,2026-09-19 09:20,결제완료,2,8000,0
K104,2026-09-19 09:25,결제완료,1,,0
K105,2026-09-19 09:30,전액환불,1,18000,0
K106,2026-09-19 09:35,결제완료,4,5000,0
K107,2026-09-19 09:40,결제완료,1,16000,4000
K108,2026-09-19 09:45,결제대기,1,25000,0
K103,2026-09-19 10:00,결제완료,3,8000,0
K102,2026-09-19 10:10,취소,1,30000,0

주어진 규칙을 **주문번호 중복 제거 → 최신 행 확인 → 상태 판정 → 단가 확인 → 순매출 계산** 순서로 적용하면 다음과 같습니다.

### 오늘 집계 결과

* **순매출: 80,000원**
* **집계 주문 수: 4건**
* **상품 수량: 10개**
* **확인 대기: K104 1건**
* 배송비·세금은 자료에 없으므로 계산에 포함하지 않았습니다.

## 2026년 9월 19일 매출 집계

| 주문번호 | 최종 수정시각 | 최종 상태 | 수량 |      단가 |  부분환불액 |     순매출 | 처리    |
| ---- | ------- | ----- | -: | ------: | -----: | ------: | ----- |
| K101 | 09:10   | 결제완료  |  2 | 12,000원 |     0원 | 24,000원 | 집계    |
| K102 | 10:10   | 취소    |  1 | 30,000원 |     0원 |       - | 제외    |
| K103 | 10:00   | 결제완료  |  3 |  8,000원 |     0원 | 24,000원 | 집계    |
| K104 | 09:25   | 결제완료  |  1 |   단가 없음 |     0원 |       - | 확인 대기 |
| K105 | 09:30   | 전액환불  |  1 | 18,000원 |     0원 |       - | 제외    |
| K106 | 09:35   | 결제완료  |  4 |  5,000원 |     0원 | 20,000원 | 집계    |
| K107 | 09:40   | 결제완료  |  1 | 16,000원 | 4,000원 | 12,000원 | 집계    |
| K108 | 09:45   | 결제대기  |  1 | 25,000원 |     0원 |       - | 제외    |

### 집계 계산

* K101: 2 × 12,000 - 0 = **24,000원**
* K103: 3 × 8,000 - 0 = **24,000원**
* K106: 4 × 5,000 - 0 = **20,000원**
* K107: 1 × 16,000 - 4,000 = **12,000원**

**순매출 합계: 24,000 + 24,000 + 20,000 + 12,000 = 80,000원**

**상품 수량: 2 + 3 + 4 + 1 = 10개**

**집계 주문 수: 4건**

### 제외·확인 대기 주문

* **K102:** 처음에는 결제완료였지만 10:10에 수정된 최신 행의 상태가 **취소**이므로 전체 주문을 제외합니다.
* **K103:** 09:20의 2개가 아니라 10:00의 최신 행인 **3개**를 사용합니다.
* **K104:** 결제완료이지만 **단가가 비어 있으므로 0원으로 계산하지 않고 확인 대기**로 분리합니다.
* **K105:** 최신 상태가 **전액환불**이므로 제외합니다.
* **K108:** **결제대기**이므로 제외합니다.
* **K107:** 부분환불 4,000원이 있어도 수량은 1개 그대로 유지하고, 매출에서 4,000원만 차감합니다.

### 다음에 같은 CSV를 받을 때 실수를 줄이는 방법

가장 안전한 방법은 **금액부터 계산하지 말고 먼저 행을 정리하는 것**입니다.

1. **주문번호별로 묶는다.**
2. 각 주문에서 **수정시각이 가장 늦은 행만 남긴다.**
3. 남은 행의 상태가 `결제완료`인지 확인한다.
4. `결제완료` 중 **단가 공란을 별도로 분리**한다.
5. 나머지만 `수량 × 단가 - 부분환불액`으로 계산한다.
6. 마지막에 **주문 수와 상품 수량을 각각 합산**한다.
7. 특히 중복 주문은 **행 수가 아니라 주문번호 기준**으로 세는지 확인한다.

이번 자료에서 가장 쉽게 생길 수 있는 오류는 **K102의 이전 결제완료 행을 그대로 집계하거나, K103의 이전 수량 2개를 사용하는 것**입니다. 따라서 CSV를 받으면 먼저 `주문번호 → 최신 수정시각 → 최종 상태`를 확인하는 습관을 들이는 것이 좋습니다.

Gemini · 2026-09-19 12:02–12:04 KST

온라인 쇼핑몰 주문 CSV를 보고 오늘 매출을 정리하려고 해. 아래는 연습용 가상 자료이고 금액은 원이야. 보고서에 넣을 순매출, 집계 주문 수, 상품 수량과 주문별 계산 근거를 정리해 줘. 제외하거나 확인해야 하는 주문도 알려주고, 다음에 비슷한 파일을 받았을 때 실수를 줄이는 방법도 설명해 줘.

집계 규칙은 이래. 같은 주문번호가 여러 번 나오면 수정시각이 가장 최근인 행 하나만 사용해. 최신 행의 상태가 결제완료인 주문만 집계하고 취소·전액환불·결제대기는 제외해. 단가가 비어 있으면 0원으로 보지 말고 그 주문은 확인 대기로 따로 빼 줘. 순매출은 수량×단가에서 부분환불액을 뺀 값이야. 상품 수량은 집계에 포함한 주문의 수량 합계이고, 부분환불액이 있다고 수량을 임의로 줄이지 않아. 배송비와 세금은 이번 자료에 없으니 추가하지 마. 수정시각은 모두 한국시간이야.

주문번호,수정시각,상태,수량,단가,부분환불액
K101,2026-09-19 09:10,결제완료,2,12000,0
K102,2026-09-19 09:15,결제완료,1,30000,0
K103,2026-09-19 09:20,결제완료,2,8000,0
K104,2026-09-19 09:25,결제완료,1,,0
K105,2026-09-19 09:30,전액환불,1,18000,0
K106,2026-09-19 09:35,결제완료,4,5000,0
K107,2026-09-19 09:40,결제완료,1,16000,4000
K108,2026-09-19 09:45,결제대기,1,25000,0
K103,2026-09-19 10:00,결제완료,3,8000,0
K102,2026-09-19 10:10,취소,1,30000,0

제시된 집계 규칙에 따라 최신 수정시각을 기준으로 중복을 제거하고 상태를 판별하여 정산한 오늘 매출 보고서입니다.

오늘의 매출 집계 요약

항목 집계 결과
순매출 80,000원
집계 주문 수 4건
총 상품 수량 10개

주문별 상세 처리 및 계산 근거

주문번호 최신 수정시각 최종 상태 수량 단가 부분환불액 순매출 계산식 최종 분류
K101 09:10 결제완료 2 12,000원 0원 (2×12,000)−0=24,000원 집계 포함
K102 10:10 취소 1 30,000원 0원 - 제외
K103 10:00 결제완료 3 8,000원 0원 (3×8,000)−0=24,000원 집계 포함
K104 09:25 결제완료 1 누락 0원 - 확인 대기
K105 09:30 전액환불 1 18,000원 0원 - 제외
K106 09:35 결제완료 4 5,000원 0원 (4×5,000)−0=20,000원 집계 포함
K107 09:40 결제완료 1 16,000원 4,000원 (1×16,000)−4,000=12,000원 집계 포함
K108 09:45 결제대기 1 25,000원 0원 - 제외

확인 대기 및 제외 주문 내역

확인 대기 주문 (1건)

K104: 상태는 '결제완료'이나 단가가 비어 있습니다. 임의로 0원 처리하지 않고 상품 DB에서 정상 단가를 확인한 후 매출에 합산해야 합니다.

제외 주문 (3건)

K102: 09:15에는 결제완료였으나, 10:10 최신 수정시각 기준 '취소'로 변경되어 집계에서 제외되었습니다.

K105: 최신 상태가 '전액환불'로 제외되었습니다.

K108: 최신 상태가 '결제대기'로 미결제 상태이므로 제외되었습니다.

향후 유사 CSV 파일 작업 시 실수 방지 가이드

중복 제거 전 정렬 수행: 주문번호로 중복을 제거하기 전에 반드시 수정시각 기준 내림차순(최신순) 정렬을 먼저 실행하세요. 단순 중복 제거만 하면 과거 기록이 남고 최신 상태(예: 취소)가 누락될 수 있습니다.

누락 데이터(NULL) 식별자동화: 단가나 수량 셀이 비어 있는 경우 자동 계산식에서 0으로 넘어가기 쉽습니다. 조건부 서식이나 데이터 검증을 통해 빈 값을 하이라이트 표시하도록 설정하세요.

상태값(Status) 파이프라인 표준화: '결제완료', '취소', '전액환불', '결제대기' 등 상태값을 유효성 검사 목록으로 관리하고, 미인식 상태값이 들어올 경우 경고가 뜨도록 전처리 규칙을 세워두는 것이 좋습니다.

Claude · 2026-09-19 12:02–12:04 KST

온라인 쇼핑몰 주문 CSV를 보고 오늘 매출을 정리하려고 해. 아래는 연습용 가상 자료이고 금액은 원이야. 보고서에 넣을 순매출, 집계 주문 수, 상품 수량과 주문별 계산 근거를 정리해 줘. 제외하거나 확인해야 하는 주문도 알려주고, 다음에 비슷한 파일을 받았을 때 실수를 줄이는 방법도 설명해 줘.

집계 규칙은 이래. 같은 주문번호가 여러 번 나오면 수정시각이 가장 최근인 행 하나만 사용해. 최신 행의 상태가 결제완료인 주문만 집계하고 취소·전액환불·결제대기는 제외해. 단가가 비어 있으면 0원으로 보지 말고 그 주문은 확인 대기로 따로 빼 줘. 순매출은 수량×단가에서 부분환불액을 뺀 값이야. 상품 수량은 집계에 포함한 주문의 수량 합계이고, 부분환불액이 있다고 수량을 임의로 줄이지 않아. 배송비와 세금은 이번 자료에 없으니 추가하지 마. 수정시각은 모두 한국시간이야.

주문번호,수정시각,상태,수량,단가,부분환불액
K101,2026-09-19 09:10,결제완료,2,12000,0
K102,2026-09-19 09:15,결제완료,1,30000,0
K103,2026-09-19 09:20,결제완료,2,8000,0
K104,2026-09-19 09:25,결제완료,1,,0
K105,2026-09-19 09:30,전액환불,1,18000,0
K106,2026-09-19 09:35,결제완료,4,5000,0
K107,2026-09-19 09:40,결제완료,1,16000,4000
K108,2026-09-19 09:45,결제대기,1,25000,0
K103,2026-09-19 10:00,결제완료,3,8000,0
K102,2026-09-19 10:10,취소,1,30000,0

# 2026-09-19 매출 집계 (연습용 가상 자료)

## 1. 보고서 반영 수치

| 항목 | 값 |
|---|---|
| 순매출 | **80,000원** |
| 집계 주문 수 | **4건** (K101, K103, K106, K107) |
| 상품 수량 | **10개** |
| 확인 대기 | 1건 (K104) |

K104는 단가가 비어 있어 위 수치에 넣지 않았습니다. 단가가 확인되면 순매출, 주문 수, 수량이 함께 바뀌므로 보고서에 "잠정, K104 제외"라고 표기하는 것이 안전합니다.

## 2. 주문별 계산 근거

**집계 포함 (최신 행 기준 결제완료)**

| 주문번호 | 사용한 행 | 수량 | 단가 | 수량×단가 | 부분환불 | 순매출 |
|---|---|---|---|---|---|---|
| K101 | 09:10 | 2 | 12,000 | 24,000 | 0 | 24,000 |
| K103 | 10:00 (최신) | 3 | 8,000 | 24,000 | 0 | 24,000 |
| K106 | 09:35 | 4 | 5,000 | 20,000 | 0 | 20,000 |
| K107 | 09:40 | 1 | 16,000 | 16,000 | 4,000 | 12,000 |
| **합계** | | **10** | | 84,000 | 4,000 | **80,000** |

K103은 09:20 행(2개)이 아니라 10:00 행(3개)을 사용했습니다. K107은 부분환불이 있어도 수량은 1개 그대로입니다.

**제외 또는 확인 대기**

| 주문번호 | 최신 행 상태 | 처리 | 사유 |
|---|---|---|---|
| K102 | 취소 (10:10) | 제외 | 09:15에는 결제완료였지만 최신 행이 취소 |
| K105 | 전액환불 | 제외 | 집계 대상 상태가 아님 |
| K108 | 결제대기 | 제외 | 집계 대상 상태가 아님 |
| K104 | 결제완료 | **확인 대기** | 단가 공란 (0원 처리 금지) |

**검산:** 고유 주문번호 8개 = 집계 4 + 제외 3 + 확인 대기 1. 전체 행은 10개이고, 중복 행 2개(K102, K103)를 빼면 8개가 남습니다.

## 3. 다음에 실수를 줄이는 방법

1. **순서를 지키기:** 중복 제거(주문번호별 최신 행)를 먼저 하고 상태 필터를 그다음에 적용합니다. 상태 필터를 먼저 걸면 K102의 옛 행(결제완료)이 살아남아 30,000원이 잘못 들어갑니다.
2. **최신 행 판단은 시각 기준으로:** 행 순서가 아니라 수정시각을 날짜·시간 값으로 변환해 비교합니다. 같은 주문에 같은 수정시각 행이 둘 이상이면 임의로 고르지 말고 확인 대기로 뺍니다.
3. **빈 값과 0을 구분하기:** 단가 공란은 0으로 채우지 않고 별도 목록으로 뺍니다. 수량이나 환불액의 공란, 숫자가 아닌 값도 같은 방식으로 처리합니다.
4. **부분환불은 금액에서만 차감하기:** 수량은 원본 그대로 두고, 순매출에서만 환불액을 뺍니다.
5. **건수 대사하기:** 항상 "고유 주문 수 = 집계 + 제외 + 확인 대기"가 맞는지 확인합니다. 맞지 않으면 누락이나 중복이 있는 것입니다.
6. **값 정리하기:** 상태값의 앞뒤 공백, 단가의 쉼표나 문자열 형태(예: "12,000")를 먼저 정리합니다.
7. **보고서에 기준 명시하기:** "최신 수정시각 행 기준, 결제완료만, 배송비·세금 제외, 확인 대기 N건 제외" 한 줄을 붙입니다.

원하시면 이 절차를 그대로 검증하는 스크립트(주석 포함)도 정리해 드리겠습니다.

All articles