# 수정세금계산서 안내 (홈택스 화면 우선)

수정 사유 명칭·필수 입력란은 **현재 홈택스 선택지**가 최종 근거다.  
아래는 작업 시 빠지기 쉬운 확인 포인트만 정리한다.

## 공통

1. 원본 전자세금계산서(승인번호)를 먼저 조회한다.
2. 수정 사유를 사용자에게 확인한다. 추측 금지.
3. 변경 전·후 공급가액·세액 표를 만든다.
4. 발급 전 체크리스트 + 사용자 확인 필수.

## 자주 쓰는 사유 체크 포인트

| 사유 계열 | 확인할 것 |
| --- | --- |
| 기재사항 착오정정 | 잘못된 항목(거래처·일자·금액·품목)과 올바른 값 |
| 공급가액 변동 | 증감 금액, 세액 재계산, 계약/정산 근거 |
| 환입 | 환입 일자·수량·금액 |
| 계약의 해제 | 원거래 전부 취소인지 일부인지 |
| 내국신용장 사후개설 등 특수 | 해당 메뉴·증빙 필요 여부 (화면 안내 확인) |

## 보고 시 최소 표

```text
| 구분 | 공급가액 | 세액 | 합계 |
| --- | ---: | ---: | ---: |
| 원본 |  |  |  |
| 수정 후 |  |  |  |
| 차이 |  |  |  |
```

사유가 불명확하면 수정발급을 진행하지 말고 사용자·세무 전문가 확인을 요청한다.

# H06 현금영수증 발급·취소·매입 확인

판매자(가맹점)인지 구매자(지출증빙 수취)인지 먼저 구별한다. 무료는 건별 준비·화면·결과 확인을 제공한다. Pro 일괄 대조는 월마감 엔진의 `sales`와 `evidence(source=cash)`를 이용하며 자동 발급·취소를 수행하지 않는다.

## 판매자 흐름

1. 대상 사업장·거래일·현금 수취일·거래금액·환불 여부·과세구분을 확인한다. 계좌이체도 현금영수증 검토에서 누락하지 않는다. 의무발행 업종·기준은 해당 시점 국세청 안내로 확인한다.
2. 가맹점 가입·발급 가능 상태와 해당 거래의 기존 승인내역부터 확인한다. 조회되지 않았다는 이유만으로 미발급을 확정하지 말고 조회기간·사업장·발급수단을 확인한다.
3. 통합검색 ‘현금영수증 건별 발급’ 또는 현행 가맹점 발급 메뉴에서 거래정보를 준비한다. 소득공제용/지출증빙용과 과세·면세 구분을 확인한다. 발급수단은 사용자가 직접 입력한다.
4. 사용자 최종 발급 후 승인번호·일자·금액·용도·거래상태를 확인한다. 준비표를 승인내역으로 표시하지 않는다.
5. 취소는 원승인 내역·사유·취소금액·실제 환불을 확인한다. 부분 취소와 전체 취소를 구별하고 사용자가 최종 진행한 후 결과를 확인한다. 현금영수증 취소와 은행 환불은 별도 사건이다.

일괄 발급은 현재 홈택스가 제공한 서식을 기준으로 입력자료를 준비하고 행 수·합계·중복·과세구분을 검토한다. 이 스킬의 JSON/CSV를 검증된 홈택스 업로드 서식이라고 소개하지 않는다.

## 구매자 흐름

사업용 지출인지와 거래일·가맹점·금액·증빙 용도를 확인한다. ‘현금영수증 매입내역’ 및 현행 지출증빙·공제 확인 메뉴에서 조회하고 원거래와 대조한다. 소득공제용을 지출증빙용으로 바꿀 수 있는지는 현재 메뉴·요건으로 확인한다. 카드·계산서와 같은 거래인지 확인하여 중복 경비·중복 매입세액 공제를 방지한다.

발급거부·미발급 신고 요청은 거래·지급 사실과 자료를 정리하고 공식 신고 창구로 안내한다. 신고 가능성과 포상금 지급은 구별하며 신고는 본인이 진행한다.

## 대조와 산출물

`거래 가명 / 거래일 / 원금액 / 원승인 참조 / 취소금액 / 취소승인 참조 / 실제 환불 확인 / 조회범위 / 확인사항` 표를 만든다. 실제 원자료에 없는 식별자 연결·환불·승인 결과를 만들지 않는다.

Pro: 종소세 준비 스킬의 월마감 입력에서 원매출은 `sale`, 환불은 양수 금액의 별도 `refund` 사건으로 넣고 주문 연결을 유지한다. 현금영수증은 매출에 더하지 않는 대조 증빙이다. 미연결·분할·날짜 차이·취소 시점 차이는 사용자 확인 대상으로 남긴다. 정산 자료가 없으면 `missing`으로 두며 일괄 대조를 끝냈다고 표시하지 않는다.

완료는 **승인·취소내역 확인**, **실제 환불 확인**, **대조 검토 완료**를 각각 기록한다.

공식 근거(2026-09-17): [국세청 현금영수증 발급·수취 안내](https://www.nts.go.kr/nts/na/ntt/selectNttInfo.do?mi=&nttSn=1351766). 업종·기준금액·가산세 판단은 거래시점 법령으로 별도 확인한다.

# 전자세금계산서 발급 직전 체크리스트

발급 버튼 전에 모두 확인. fail 또는 확인필요면 발급 권유 금지.

| # | 항목 | pass / fail / 확인필요 | 메모 |
| --- | --- | --- | --- |
| 1 | 로그인 사업·공급자 사업장 일치 |  |  |
| 2 | 공급받는자 사업자번호 정확 |  |  |
| 3 | 조회된 상호 = 사용자 의도 상호 |  |  |
| 4 | 작성일자 확인 |  |  |
| 5 | 공급일자 확인 |  |  |
| 6 | 품목(재화·용역) 명확 |  |  |
| 7 | 공급가액 확인 |  |  |
| 8 | 세액 검산 (과세 시 약 10%) |  |  |
| 9 | 합계금액 = 공급가액 + 세액 |  |  |
| 10 | 과세 / 영세율 / 해당 구분 맞음 |  |  |
| 11 | 동일 거래 중복 발급 아님 (조회) |  |  |
| 12 | 수정발급이면 원본·수정사유 일치 |  |  |
| 13 | 이메일/전송 옵션 필요 시 설정 |  |  |
| 14 | 사용자 확인 문구 준비 |  |  |

확인 문구:

```text
이 내용으로 세금계산서 발급 진행해도 될까요?
- 공급받는자: {상호} ({사업자번호})
- 공급가액: {n}원 / 세액: {n}원 / 합계: {n}원
- 작성일: {yyyy-mm-dd} / 공급일: {yyyy-mm-dd}
- 품목: {내용}
```

# 미수금 점검 모드 (청구 발행 건 입금 대조)

**목적:** `청구`로 발행한 전자세금계산서 중 **입금이 안 된 건을 빠짐없이** 찾아 미수금 리스트로 정리한다.
**아닌 것:** 부가세 신고 금액을 바꾸는 기능이 아니다. 수금 관리 도구다.

---

## ⚠️ 시작 전 필수 고지 (사용자에게 그대로 안내)

점검을 시작하기 전에 아래 3가지를 사용자에게 먼저 보여준다. 생략 금지.

> 1. **부가세는 발생주의입니다.** 입금을 못 받았어도 청구 발행분 매출세액은 해당 과세기간에 **전액 신고 대상**입니다. "입금 안 받았으니 매출에서 빼자"는 처리는 **매출 누락(가산세 대상)**이 되므로 이 도구는 그런 제안을 하지 않습니다.
> 2. **대손세액공제는 별개 제도입니다.** 단순 미입금이 아니라 파산·강제집행 불능·소멸시효 완성 등 **법적으로 대손이 확정**된 경우에만 검토 가능합니다(기한: 공급일부터 10년이 지난 날이 속하는 과세기간에 대한 확정신고 기한까지 대손이 확정된 분 — 부가가치세법 §45). 해당 가능성이 보이면 세무사 상담을 권합니다.
> 3. 이 점검은 **수금 관리용 리스트**를 만드는 것이며, 세무 처리·신고 내용을 변경하지 않습니다.

## 입력 자료

| 자료 | 필수 여부 | 비고 |
| --- | --- | --- |
| 홈택스 매출 전자세금계산서 **발급 목록** (기간 지정, 엑셀) | 필수 | 다운로드 파일(실측 2026-08): 파일명 `매출전자세금계산서목록(1~N).xls`(구형 xls), **상단 5행은 사업자정보·총계 메타이고 6행째가 헤더**, 33컬럼, 구분 컬럼명은 정확히 **`영수/청구 구분`**(22번째, '비고' 다음). 대표 품목 컬럼 포함. 구조가 다르면 화면 목록 기준으로 대조 |
| 통장 **입금내역** (엑셀/CSV) | 선택 | 있으면 자동 대조, 없으면 건별 질문 방식 |

**PII 규칙:** 통장 파일을 받기 **전에** 먼저 안내한다: "계좌번호 등 민감정보는 지우거나 가린 뒤 첨부해 주세요. 대조에는 일자·입금액·의뢰인명만 있으면 됩니다." 받은 파일에 계좌번호·주민번호가 섞여 있으면 마스킹하고, 원본 데이터를 저장하거나 외부로 보내지 않는다.

**Pro 엔진 설치 시:** `assets/receivables-engine.mjs`가 있으면 [`receivables-engine.md`](receivables-engine.md)를 읽고 사용한다. Node.js 18 이상, 외부 패키지 불필요. 판정·합계를 임의로 고치거나 입력 오류를 0원으로 바꾸지 않는다.

**무료 수동 점검:** 엔진이 없으면 아래 같은 절차를 원자료·스프레드시트 합계와 사용자 건별 응답으로 수행한다. 자동 검증을 주장하지 않는다. 원본/수정 순액과 입금 ID를 표에 연결하고 입금 소진·선금·통장 범위·판단불가 유지 및 두 합계 게이트를 동일 적용한다. 엔진 JSON·Node 설치는 무료 점검의 필수 조건이 아니다.

## 절차

### 1. 기간 확정
- 사용자에게 점검 기간을 확인한다. 기본 제안: **직전 과세기간 시작일 ~ 오늘** (예: 1기분이면 1/1~오늘).
- 기간 경계는 **작성일자(발행일) 기준**임을 고지한다. 기간 직전에 발행되고 입금은 기간 안에 된 건이 빠질 수 있으므로, 미수금이 의심되는 오래된 건이 있으면 기간을 넓혀 다시 조회하도록 권한다.
- **약정 결제기일도 함께 확인한다** (예: "월말 마감, 익월 말 지급"). 아래 경과일수 경고 단계는 **결제기일 기준**으로 계산하고, 결제 조건이 없거나 모르면 발행일 기준 **참고치**로 안내한다 — 지급기일이 아직 안 지난 정상 거래처에 독촉을 권하지 않기 위함.

### 2. 발급 목록 다운로드
- 홈택스 **조회/발급 → 전자세금계산서 → 목록조회** (메뉴명은 현재 화면 우선) → 기간 입력 → **매출분**만 → 엑셀 다운로드.
- **조회 기간 상한은 3개월** (실측 2026-08, 화면 안내: "조회기간은 3개월 범위 내로 제한. 단, 공급받는자 등록번호를 입력하면 1년까지 조회가능. [월/분기별 목록조회]에서는 반기별 조회까지 가능"). 점검 기간이 3개월을 넘으면 **기간을 나눠 여러 번 다운로드해 병합**한다 (예: 1기분 1/1~8월 점검이면 3회 분할). 몇 개 구간으로 나눴는지 기록해 둔다. 상한이 바뀌면 현재 화면 우선.
- 조회 기간 기준은 **작성일자**로 선택한다 (화면에서 작성일자/발급일자/전송일자 선택 가능 — §1의 기간 경계 판정과 일치시키기 위함).
- 내려받기 순서(실측): `내려받기` → 품목정보 추가 여부 팝업(기본 미체크로 확인) → 파일 종류 선택(엑셀) → **마지막 "파일을 받으시겠습니까?" 창은 브라우저 시스템 대화상자라 반드시 사용자 본인이 클릭** (AI·확장이 누를 수 없음).
- 다운로드·클릭은 사용자 본인. AI는 화면 순서 안내만.

### 3. 정합성 검증 — 놓침 방지 게이트 ①

대조를 시작하기 **전에** 목록 자체가 온전한지 검증한다. 하나라도 어긋나면 대조를 진행하지 말고 목록을 재확인한다.

- [ ] **총 건수 = 영수 건수 + 청구 건수** — 구분값이 비었거나 제3의 값인 건이 0건인지 (수정 건도 자체 영수/청구 값으로 이 집계에 포함)
- [ ] **수정세금계산서(음수·수정 건)는 원본과 짝지어 순액 처리** — ① 전부 취소(원본+수정 합계 0)는 대조 대상에서 **제외하되 "취소됨"으로 별도 표기**하고, 취소인데 통장에 이미 입금이 있으면 **"환불 필요" 경고**를 붙인다 ② 감액 수정(합계 ≠ 0)은 제외하지 말고 **원본+수정 합산 순액을 그 건의 대조 금액**으로 쓴다 (원본액으로 대조하면 완납 건이 부분입금으로 오분류됨)
- [ ] **분할 조회했다면 구간이 빈틈없이 이어지는지** — 기간 공백·중복이 없는지, 구간별 건수 합 = 병합 후 총 건수인지 (한 구간 파일이 통째로 빠지는 것이 가장 흔한 누락 경로)
- [ ] 같은 거래처·같은 금액·비슷한 일자의 **중복 발행 의심 건**이 있으면 표시하고 사용자에게 확인
- [ ] 조회 기간과 사용자가 말한 기간이 일치하는지

### 4. 청구 건 추출 → 입금 대조

`청구` 건만 추려 대조한다. **모든 매칭은 "후보"이며, 확정은 사용자가 한다. 임의 확정 금지.**

**통장내역이 있는 경우 (Pro 엔진 또는 무료 수동 대조):**
- **합계금액(감액 수정이 있으면 순액) 정확 일치 + 발행일 이후 입금**인 건만 "입금 추정 후보"로 제시
- **입금 소진 규칙 (1:1):** 입금 1건은 세금계산서 1건에만 배정한다. 동일 금액 청구가 여러 건인데 입금 건수가 모자라면(예: 월 110만원 3건 청구에 입금 1건), 어느 것도 입금완료 후보로 만들지 말고 **전부 판단불가**로 내려 "이 입금은 몇 월분 대금인가요?"를 확인한다 — 입금 하나가 여러 건을 동시에 지우면 실미수금이 조용히 사라진다.
- 아래는 자동 확정 금지 → **판단불가**로 분류해 사용자 확인:
  - 부분입금 (금액 일부만 일치)
  - 합산입금 (여러 건을 한 번에 입금)
  - **선금·계약금 (발행일 이전 입금)** — 금액·명의가 일치해도 "이 입금이 이 계산서의 대금인가요?"로 확인 (먼저 받고 나중에 발행하는 흔한 패턴을 미입금으로 오분류하면 이미 지불한 거래처를 독촉하게 됨)
  - 카드·PG·플랫폼 정산 (수수료가 차감되어 계산서 금액과 다르게 입금)
  - 상계·어음 등 통장에 안 잡히는 결제
  - 의뢰인명이 거래처 상호와 다른 입금 (대표자 개인 명의 등)
- **미입금은 최후의 분류다:** 금액·명의·날짜 어느 축으로도 연결 후보가 전혀 없을 때만 미입금으로 분류한다. 하나라도 걸치면 판단불가.

Pro 엔진은 순액 일치, 명의 일치, 작성일 또는 약정 결제기일과 **같은 일자** 중 하나라도 있으면 연결 근거로 남긴다. 날짜가 단순히 작성일 이후라는 이유만으로 무관한 모든 입금을 연결하지는 않는다. 작성일 이전에 같은 금액이 들어왔지만 명의가 다른 경우도 판단불가다. 같은 금액의 다른 청구·영수·취소 건이 있거나 입금 자체가 여러 건이면 자동 배정하지 않는다. 환불·입금취소는 원 입금 ID와 연결해 기록하고, 환불 이력이 있는 입금은 완납 후보에서 제외한다.

통장 범위가 기준일까지 이어지는지, 기간 전 선수금과 현금·상계 등 통장 밖 결제를 점검했는지가 확인되지 않으면, 연결 입금이 없어도 **판단불가**다. 이 확인값을 AI가 임의로 `true`로 만들면 안 된다. 자료가 확인됐고 연결 후보도 전무할 때의 `미입금`은 **확인된 자료 범위의 분류**이며 수령 사실을 법적으로 확정한 것이 아니다.

**통장내역이 없는 경우 (건별 질문):**
- 청구 건 전체를 표(거래처·발행일·합계금액)로 한 번에 제시하고, 건별로 입금 여부(O/X/모름)를 표기받는다.

### 5. 3분류 + 합계 검증 — 놓침 방지 게이트 ②

- 모든 청구 건을 **입금완료 / 미입금 / 판단불가** 셋 중 하나로 분류한다. 네 번째 상태 없음.
- **검증식: 입금완료 + 미입금 + 판단불가 = 청구 건수.** 불일치하면 어딘가에서 건이 새고 있는 것 — 보고하지 말고 재점검한다.
- 사용자가 "모름"이라 답한 건은 미입금으로 넘기지 말고 **판단불가로 유지**해 리스트에 남긴다.
- 판단불가가 남아 있으면 보고서에 "사용자 확인 필요" 섹션으로 반드시 노출한다.

Pro 엔진 사용 시 결과의 `status`는 위 3종만 사용한다. 자동 정확 일치는 `candidate: true`로 추가 표시하되 `status: 판단불가`를 유지한다. 사용자에게 계산서와 연결 입금 ID를 보여 주고 건별 확인을 받은 뒤, 실제 응답만 `confirmations`에 넣어 재실행한다. 은행 완납 확인은 연결 입금의 합계가 계산서 순액과 같아야 하며 이미 소진·환불된 입금은 재사용할 수 없다. 합산 입금 한 건을 여러 계산서에 쪼개 배정하는 기능은 지원하지 않으므로 그 경우 판단불가와 확인 메모를 유지한다. 사용자가 현금·상계로 완납을 확인하면 그 수단과 확인 메모를 기록할 수 있다. 어음 수령만으로 완납을 단정하지 않는다.

무료 수동 표도 정확 일치는 후보·판단불가로 남기고, 사용자의 실제 건별 확인 뒤에만 상태를 바꾼다. 같은 입금 ID 재사용, 미확인 선금·합산입금 임의 배정, 환불된 입금의 완납 사용은 금지다. 검증식은 원자료·스프레드시트의 건수·합계와 대조하며 계산 수단이 없으면 합계를 만들지 말고 확인필요로 남긴다.

### 6. 영수 건 역점검 (권장)

통장내역이 있으면 `영수` 건도 역방향으로 점검한다:

> ⚠️ **영수로 발행됐는데 입금 흔적이 없는 건**이 발견되면 경고한다. '영수' 표시는 "대금을 받았다"는 외관을 만들어, 미수금 분쟁(소송·지급명령) 시 상대방이 지급 증거로 주장할 수 있다. 실제 미입금이 맞다면 ① 통장 미입금 증거 확보, ② 수정세금계산서(기재사항 착오정정 → 청구)를 안내한다 (`amend-types.md` 참조). 정정 여부 판단은 사용자.

### 7. 미수금 리포트 작성

아래 「보고 포맷」대로 작성한다.

## 경과일수별 경고 단계

**약정 결제기일 기준** 경과일수로 단계를 표시한다 (결제 조건이 없거나 모르면 발행일 기준 **참고치**로 안내 — "결제 조건에 따라 아직 정상일 수 있습니다" 단서를 붙인다). 법적 조치·소멸시효는 **단정하지 않고** "검토·전문가 확인" 수준으로만 안내한다.

| 경과일수 | 단계 | 안내 |
| --- | --- | --- |
| 30일 미만 | 정상 | 통상 결제 주기 내. 결제 예정일 확인 |
| 30일 이상 ~ 90일 미만 | ⚠️ 주의 | 독촉 연락, 결제일 재확인 권장 |
| 90일 이상 ~ 1년 미만 | 🔶 경고 | 내용증명 발송 검토, 거래 조건(선금 등) 재협의 권장 |
| 1년 이상 | 🔴 위험 | 지급명령·소송 검토 권고. **소멸시효 주의** — 상품·용역 대금 채권은 3년 단기소멸시효에 해당할 수 있음(채권 성격에 따라 다름 → 변호사·법률 전문가 확인 필수) |

## 보고 포맷

```text
## 미수금 점검 결과 ({기간})

### 정합성 (게이트 통과 확인)
- 통장 자료 유무 / 기준일까지의 범위 / 기간 전 선수금·통장 외 결제 확인 여부 (미확인은 그대로 노출)
- 발급 총 {N}건 = 영수 {a}건 + 청구 {b}건 (수정 건도 자체 구분값으로 포함 집계)
- {c} = 취소 쌍에 속한 청구 건수(원본+수정 모두) → 대조 제외 (환불 필요 여부 확인 결과 병기)
- {d} = 취소되지 않은 원본에 병합한 수정분(감액·증액) 중 **청구 구분인 것만**의 건수 → 원본 행에 병합해 순액으로 대조 (별도 행으로 세지 않음. 영수 구분 수정 건은 {b}에 집계되지 않으므로 여기서도 세지 않는다)
- **대조 대상 청구 {b − c − d}건 = 입금완료 {x} + 미입금 {y} + 판단불가 {z}** ✓ (식이 안 맞으면 보고 금지, 재점검)

### 미수금 리스트 ({y}건, 합계 {금액}원)
| 거래처 | 발행일 | 합계금액 | 경과일수 | 단계 | 다음 액션 |
| --- | --- | ---: | ---: | --- | --- |

### 판단불가 ({z}건) — 사용자 확인 필요
| 거래처 | 발행일 | 합계금액 | 보류 사유 | 연결 입금 ID·자동 후보 여부 |

### 영수 건 경고 (해당 시에만)
| 거래처 | 발행일 | 합계금액 | 권고 |

### ⚠️ 세무 주의
- 위 미입금 건도 해당 과세기간 부가세 신고 매출에 **전액 포함**되어야 합니다 (발생주의). 미수금을 이유로 매출에서 제외하면 매출 누락입니다.
- 대손세액공제는 법적 대손 확정 시에만 검토 가능합니다 — 해당 가능성이 있으면 세무사와 상담하세요.
```

보고 말미에 SKILL.md 「보고 포맷」의 표준 면책 문구를 동일하게 붙인다.

## 금지 사항

- 미입금을 이유로 **신고 매출에서 제외하자는 제안 금지**
- 입금 여부 **임의 확정 금지** — 자동 매칭은 항상 후보, 확정은 사용자
- 판단불가 건을 조용히 누락시키는 것 금지 — 합계 검증식이 깨지면 보고 금지
- 통장 원본 데이터 저장·외부 전송 금지
- 독촉·내용증명·소송 문서의 **발송 대행 금지** — 초안·안내까지만

# 미수금 엔진 실행과 입력

**Pro 실행 파일 `assets/receivables-engine.mjs`가 실제 설치되어 있을 때만 이 문서를 읽고 실행한다.** 무료 수동 점검은 `receivables-check.md`를 따르며 엔진 설치를 요구하지 않는다.

`assets/receivables-engine.mjs`는 스킬에 포함된 실제 계산기다. Node.js 18 이상이면 별도 패키지 설치 없이 실행한다. 파일·네트워크 저장 없이 표준입력 JSON을 받아 표준출력 JSON을 반환한다. 원본 통장 파일을 엔진에 전달하지 않는다. AI가 사용자에게 JSON 작성을 요구하는 대신, 민감정보를 제거한 표를 아래 스키마로 옮기고 누락·확인 사항만 질문한다.

```bash
node assets/receivables-engine.mjs --help
node assets/receivables-engine.mjs < 비식별입력.json
```

위 상대경로는 설치된 `tax-invoice-hometax` 폴더를 기준으로 한다. 실제 사용에서는 준비된 비식별 JSON을 표준입력으로 직접 전달해도 된다. 원본을 새 파일에 복사하거나 외부 서비스에 업로드하지 않는다. 오류 시 종료코드 2와 `stderr` 오류 JSON을 반환하고 `stdout` 보고 결과는 내보내지 않는다. 자동 복구라는 명목으로 누락값·오류를 0·빈 배열·확인 완료로 채우지 않는다.

## 입력 스키마

표에 있는 필수값은 생략할 수 없다. 알 수 없는 필드, 금액 문자열·소수, 잘못된 날짜, 중복 ID, 잘못된 수정·환불 연결은 오류다. 금액은 원 단위 JSON 정수로 넣는다(`"1,000,000"`이 아니라 `1000000`). 날짜는 `YYYY-MM-DD`다. 명의는 원문이 같을 때만 일치로 취급하며 법인표기 제거·유사어·대표자명 추정을 하지 않는다.

| 필드 | 내용 |
| --- | --- |
| `asOf` | 사용자와 확인한 점검 기준일 |
| `period` | `{from, to}`: 계산서 작성일 기준 조회 기간. 종료일은 기준일 이하 |
| `segments` | 다운로드 구간별 `{from, to, count}` 배열. 단일 조회도 1개 구간을 넣고 실제 원본의 건수를 기재. 구간은 전체 기간을 공백·중복 없이 덮어야 함 |
| `reportedCounts` | 홈택스 목록 총계의 `{total, 청구, 영수}`. 원본·수정분을 모두 원래 구분으로 세고, 입력 행과 대조. 이 값을 입력 행 수에서 임의로 만들어 내면 목록 누락을 검출할 수 없음 |
| `bankCoverage` | 통장이 없으면 `null`. 있으면 아래 범위·확인값 객체 |
| `invoices` | 계산서 원본·수정분 배열. 목록이 실제 0건인 경우에만 빈 배열 |
| `deposits` | 통장이 없으면 `null`. 자료를 확인했고 입금이 실제 없을 때만 빈 배열. 입금·연결 환불 배열 |
| `confirmations` | 사용자의 건별 응답 배열. 아직 응답을 받지 않았으면 빈 배열 |

`bankCoverage`는 `{from, to, complete, priorPaymentsReviewed, nonBankPaymentsReviewed}`다. `complete`는 해당 구간의 대상 계좌 입금·관련 취소가 빠짐없이 제공됐는지, `priorPaymentsReviewed`는 기간 전 선수금·이월 수령액을 확인했는지, `nonBankPaymentsReviewed`는 현금·상계·어음 등 통장 밖 결제를 확인했는지다. 세 확인값은 `true`/`false`만 허용하며 사용자가 확인하지 않았으면 `false`다. 통장 시작일이 계산서 조회 시작일 이후이거나, 통장 종료일이 기준일과 다르거나, 확인값 하나라도 `false`면 연결 흔적이 없어도 미입금으로 분류하지 않는다. 정확 일치 흔적은 후보로 보여 줄 수 있다.

계산서 행:

| 필드 | 내용 |
| --- | --- |
| `no`, `partner`, `date`, `amount`, `kind` | 필수: 계산서 고유 ID·거래처명·작성일·부가세 포함 합계·`청구` 또는 `영수` |
| `amendOf` | 수정분에만 원본 ID. 음수는 필수이며, 양수 증액 수정에도 사용 가능. 수정분끼리 연쇄 연결하지 말고 같은 거래처의 선행 원본에 직접 연결 |
| `dueDate` | 선택: 사용자와 확인한 약정 결제기일. 없으면 작성일 경과일수를 참고치로 표시 |
| `settlement` | 선택: `bank`/`cash`/`offset`/`note`/`pg`/`unknown`. 통장 밖 결제·어음·PG 정산 또는 미확인은 자동 완납 후보 제외 |

원본은 양수, 수정 후 순액은 0 이상이어야 한다. 순액 0은 `cancellations`로 별도 보고하고, 그 외에는 원본 구분을 기준으로 순액 1건을 만든다. 기재사항 착오 등으로 거래처가 바뀌거나 원본이 조회 범위 밖이면 임의로 이어 붙이지 말고 원본 관계를 먼저 확인하고 조회 범위를 넓힌다.

입금 행은 `{id, date, amount, name}`이다. 환불·입금취소를 확인한 경우 음수 금액과 `reverses: 원입금ID`를 함께 넣는다. 음수 거래는 같은 명의의 선행 양수 입금과 연결되어야 하며 누적 환불액이 입금액을 넘으면 오류다. 일반 출금을 마구 포함하지 않는다. 다른 명의로 환불한 건처럼 연결이 확인되지 않은 사례는 금액을 바꾸거나 가짜 연결을 만들지 말고 미확인 사유로 남긴다. 원입금에 환불 이력이 있으면 자동 완납 후보·은행 완납 확인에 사용하지 않는다.

사용자 확인 행은 `{no, status, note}`가 기본이다. `status`는 `입금완료`/`미입금`/`판단불가` 중 하나이며, `note`에 실제 응답의 요지를 적는다. `입금완료`는 `method`도 필요하다.

- `method: bank`: `depositIds` 배열 필수. 연결 입금 합계가 순액과 정확히 같아야 하며, 같은 입금은 다른 확인에 재사용할 수 없다. 명의 차이·선금·분할입금은 사용자가 귀속·완납을 확인한 경우에만 이 방식으로 확정한다.
- `method: cash` 또는 `offset`: 사용자가 현금·상계로 완납을 확인한 메모가 필요하며 `depositIds`는 넣지 않는다.
- 부분입금, 합산 입금 1건의 다건 분배, 수수료 차감·어음·환불 관계가 남아 있는 건은 `판단불가`와 확인 메모로 유지한다. 정확한 배정이 이 스키마로 표현되지 않으면 금액을 조작하지 않는다.

## 합성 예제

아래는 실행 확인용 가상자료다. 실제 확인값을 대신하는 기본값으로 사용하지 않는다.

```json
{
  "asOf": "2026-09-12",
  "period": {"from": "2026-07-01", "to": "2026-09-12"},
  "segments": [{"from": "2026-07-01", "to": "2026-09-12", "count": 1}],
  "reportedCounts": {"total": 1, "청구": 1, "영수": 0},
  "bankCoverage": {
    "from": "2026-07-01", "to": "2026-09-12", "complete": true,
    "priorPaymentsReviewed": true, "nonBankPaymentsReviewed": true
  },
  "invoices": [{
    "no": "가상-I1", "partner": "가상거래처", "date": "2026-07-10",
    "amount": 1100000, "kind": "청구", "dueDate": "2026-08-10"
  }],
  "deposits": [{
    "id": "가상-D1", "name": "가상거래처", "date": "2026-07-20", "amount": 1100000
  }],
  "confirmations": []
}
```

예상 결과는 `status: 판단불가`, `candidate: true`, 연결 후보 `가상-D1`이다. 자동으로 입금완료가 되지 않는다. 사용자가 해당 건 완납을 확인한 뒤에만 `confirmations`를 다음으로 바꾸어 재실행한다.

```json
[{"no": "가상-I1", "status": "입금완료", "method": "bank",
  "depositIds": ["가상-D1"], "note": "사용자가 이 입금이 해당 계산서의 완납 대금임을 확인"}]
```

## 결과를 보고서에 옮기는 순서

1. 종료코드 0, `gate.status: 통과`와 실제 구간·목록 총계를 확인한다. `dataCompleteness`에 통장·결제 확인이 미완료로 나오면 보고서에도 노출한다. 게이트 통과는 원본 자체의 진실성이나 세무 처리를 보증하지 않는다.
2. `rows`를 `status` 3종으로 빠짐없이 나누고, `candidate`는 판단불가 표의 추가 정보로만 표시한다. `confirmation`이 없으면 사용자가 수령 여부를 확정했다는 문구를 쓰지 않는다.
3. `gate.classification`과 `summary`를 그대로 사용한다. 수정·취소 집계는 `cancelledClaimRows`, `mergedClaimRows`, `targetCount`로 대조한다.
4. `cancellations`의 환불 필요 여부와 `receiptChecks`를 별도 노출한다. 환불 경고는 관련 흔적을 찾았다는 의미이며 환불채무를 확정한 것이 아니다.
5. 결제기일 기준 경과일수 또는 발행일 참고치와 그 단서를 유지한다. 실제 입금일·지급기일·독촉 여부를 추측하지 않는다.
6. `receivables-check.md`의 세무 고지·표준 면책을 붙인다. 미수금 결과로 신고 매출을 바꾸지 않는다.

이 엔진은 제공된 명의·금액·동일 일자 근거를 대조한다. 거래처 별칭 추정, 모든 합산·분할 조합 탐색, 통장 밖 결제의 자동 입증, 원본이 누락된 수정 관계의 복원은 하지 않는다. 그 경우 결과를 판단불가로 남기고 필요한 확인을 제시한다.

# 매출·정산 자료 대조

세금계산서·카드·현금영수증·플랫폼 정산·은행 입금은 같은 거래를 다른 시점·형태로 보여 줄 수 있다. 전부 더하면 중복 매출이 된다. 다음 역할을 먼저 지정한다.

| 역할 | 자료 | 사용법 |
| --- | --- | --- |
| 매출 원장 | 판매/주문·공급 기록 | 해당 사업·채널·기간의 주된 매출 자료로 선택 |
| 대체 증빙 | 세금계산서·카드·현금영수증 | 원거래와 연결해 중복 여부·증빙 누락 대조 |
| 정산명세 | 플랫폼·PG·카드사 | 총 결제·환불·수수료·보류·지급예정 확인 |
| 실제 입금 | 은행 입금 | 정산 지급과 연결. 입금 자체를 새 매출로 합산하지 않음 |

## 무료 수동 흐름

1. 실제 판매채널 목록부터 받고 자료별 사업 가명·조회기간·기준일·수집 범위·매출 기준(공급가액/공급대가)을 기록한다. 자료 없음/부분 수집/실제 0건을 구분한다.
2. 홈택스 계산서·영수증·카드의 **신용카드·판매(결제)대행 매출자료 조회**, 전자계산서·현금영수증과 채널 원장을 대조한다. 이 명칭의 공개 메뉴는 2026-09-12 확인했지만 실제 로그인 자료의 범위·최신성은 작업 시 확인한다.
3. 거래/주문 ID로 같은 거래를 연결하고 수수료·환불·정산 보류·전월 이월을 나란히 표시한다. 같은 금액·비슷한 일자만으로 연결을 확정하지 않는다. 임의로 원장 중복을 삭제하지 않는다.
4. 확인된 원자료·스프레드시트 합계로 총매출, 환불, 순매출, 정산지급액, 실제입금, 설명되지 않는 차이를 보여 준다. 정산입금은 수수료 차감·시차가 있으므로 그대로 신고매출로 쓰지 않는다. 수수료 필요경비/매입공제도 별도 증빙 검토다.
5. 미수금은 기존 receivables-check.md의 입금 소진·선금·판단불가·사용자 확인 규칙을 적용한다. 이 대조만으로 부가세 공급시기나 세무 처리를 확정하지 않는다.

출력 열: 채널 / 원장 기간·범위 / 매출 출처 / 대체 증빙 연결 / 정산 연결 / 입금 연결 / 차이 사유 / 누락·중복 후보 / 사용자 확인. 실제 채널 자료가 빠졌으면 다른 자료 합계가 같아도 전체 매출 누락 없음이라고 하지 않는다.

Pro jongsose-prep-kr 설치 시 references/monthly-review.md와 scripts/monthly_review.py --help에 맞춰 CSV/JSON 대량 대조로 연결한다. 기존 미수금 엔진과 다른 도구다. 지원하지 않는 연결은 자료·금액을 조작하지 말고 확인필요로 둔다. 이 공개판에서는 없는 실행 파일을 요구하거나 실행했다고 표시하지 않는다.

공식 근거: [국세청 2025년 귀속 사업장현황신고 안내](https://b.nts.go.kr/dongnae/na/ntt/selectNttInfo.do?mi=5157&nttSn=1348061)는 매출·매입 종류별 제공자료의 기준기간이 다름을 안내한다(확인일 2026-09-12). 특정 안내의 제공기간을 모든 신고·연도에 그대로 적용하지 않는다. 위 대조 절차는 누락 방지를 위한 제품의 검토 방식이다.