일본 영수증 150장을
확정신고용 Excel로 일괄 변환하는 방법

영수증을 하나씩 처리하면 세금 신고 시기에 무너지는 이유

National Tax Agency에 따르면 2024년 소득에 대한 세금 신고는 2,339만 건이 제출되었으며, 그중 1,329만 건이 집에서 e-Tax로 제출되었습니다. 그중 824만 건은 회계사나 급여 부서가 아닌 납세자 본인이 직접 제출한 것입니다. 일본의 프리랜서 인구는 내각부 추산에 따르면 462만 명에 달하며, 개인사업자, 1인 회사 대표, 부업을 가진 병행 근로자까지 포함합니다. 그들 모두에게 영수증은 kakutei shinkoku 과정에서 가장 지루한 부분입니다. 단일 영수증 하나를 처리하는 것이 어려워서가 아니라, 전체 물량이 선형적인 노력으로는 감당이 안 되기 때문입니다.

일본 영수증 한 장당 데이터 입력 시간은 일정하지 않습니다. 필드가 명확하게 인쇄된 일반 편의점 영수증은 30초면 충분할 수 있습니다. 작은 식당의 손글씨 영수증은 흐릿한 한자, 연호 날짜(令和7年6月15日), 세율 구분이 없어 90초 이상 걸릴 수 있습니다. 일본 Q&A 플랫폼 Qiita의 한 사용자는 freee의 OCR을 손글씨 영수증에 테스트한 결과 금액 필드만 약 20% 정확도를 보고했습니다. 네 자리 숫자가 두 자리로 줄었고, 그중 하나만 정확했습니다. 즉각적인 반응은 OCR을 탓하는 것이지만, 실제 문제는 구조적입니다. 한 번에 하나씩, 영수증별 상호작용을 위해 설계된 처리 모델은 단일 영수증에서는 실패하지 않습니다. 1년치가 쌓였을 때 곱해져서 실패하는 것입니다.

일본 회계 소프트웨어가 잘하는 것 — 그리고 대규모 처리에서 한계에 부딪히는 지점

일본의 3대 클라우드 회계 플랫폼 — freee, Yayoi(‮夥生‬), MoneyForward(‮マネーフォワード‬) — 는 지속적인 부기 워크플로우를 탁월하게 처리합니다. 은행 및 신용카드 거래를 자동으로 가져오고, 기계학습을 적용해 올바른 비용 항목(‮勘定科目‬)을 제안하며, e-Tax 제출에 바로 사용할 수 있는 ‮青色申告決算書‬(청색 신고 재무제표)을 생성합니다. 영수증이 도착할 때마다 스캔하는 프리랜서 — 택시 한 번, Lawson 영수증 한 장, 고객 점심 한 번 — 에게는 모바일 앱 + OCR 파이프라인이 충분히 작동합니다.

한계는 2월에 드러납니다. MoneyForward의 ‮クラウド経費‬(Cloud Expense)는 OCR 처리를 위해 한 번에 최대 영수증 이미지 50장을 일괄 업로드할 수 있으며, 날짜, 공급업체, 금액, 등록번호를 추출합니다. freee의 ‮ファイルボックス‬(File Box)는 각각 10MB 미만의 PDF, JPEG, PNG 업로드를 지원하며, OCR이 주요 필드를 추출하고 검증을 위해 강조 표시합니다. 둘 다 진정한 생산성 도구입니다 — 연중 한 번에 한 장씩 영수증을 처리하는 정상 상태의 워크플로우에는 말이죠. 하지만 신발 상자에 쌓인 연말 잔여 영수증 150장을 마주할 때, "받는 대로 스캔"용으로 설계된 플랫폼은 병목 지점이 됩니다.

차이는 OCR 정확도에 있지 않습니다. 추출 후 어떤 일이 일어나는가에 있습니다. 회계 소프트웨어에서는 각 영수증이 하나의 분개장 항목을 생성합니다. 영수증 150장을 처리한다는 것은 OCR 트리거 150회, 항목 확인 150회, 개별 기록 150건을 의미합니다. 출력물은 스프레드시트가 아닌 총계정원장입니다 — 회계 소프트웨어의 내부 엔진에는 유용하지만, 150개 행을 한눈에 스캔하고 정렬하고 검증하기 위해 설계된 것은 아닙니다.

일괄 추출 방식은 이를 뒤집습니다. 영수증을 회계 워크플로우에 한 번에 하나씩 업로드하는 대신, 원하는 열을 정의합니다 — 날짜, 공급업체, 총액, 10% 과세 소계, 8% 과세 소계, ‮但‬し書き 설명, 비용 항목 — 그리고 영수증 150장 전체를 단일 배치로 업로드합니다. 도구는 이를 병렬로 처리하고 각 행이 영수증이고 각 열이 사용자가 이름을 붙인 필드인 단일 스프레드시트를 출력합니다. 이것이 열 이름 추출입니다: AI에게 찾고자 하는 것을 (열 이름을 지정하여) 알려주면, 템플릿 기반 OCR처럼 좌표를 매칭하는 것이 아니라 의미를 이해하여 각 문서에서 해당 값을 찾습니다. 추출 로직은 위치 기반이 아닌 의미 기반이므로 형식에 독립적입니다. 하나의 열 정의가 ‮コンビニ‬ 감열지 영수증, 수입인지가 붙은 손으로 쓴 음식점 ‮領収書‬, Amazon Japan 이메일 PDF에 모두 적용됩니다 — 공급업체별 템플릿도, 형식별 설정도 필요 없습니다.

2024년 전자장부보존법이 영수증 업무에 가져온 변화

2024년 1월부터 일본의 전자장부보존법(電子帳簿保存法)이 영수증 처리에 직접 영향을 미치는 조항과 함께 전면 시행되었습니다. PDF 이메일 첨부 파일, 웹사이트 다운로드, 앱 스크린샷 등 전자적으로 수신된 모든 영수증은 전자 데이터로 보관해야 합니다. 출력해서 종이 사본만 보관할 수 없습니다. 종이 대체를 허용했던 2년 유예 기간은 2024년 1월 1일에 종료되었습니다.

이 법은 전자 보관 문서에 대해 세 가지 검색 요건도 규정합니다: 거래 날짜, 금액, 거래 상대방으로 검색할 수 있어야 합니다. 제대로 구조화된 일괄 추출 스프레드시트는 자동으로 이를 충족합니다: 날짜 열로 정렬하고, 공급업체 열로 필터링하고, 금액을 범위로 스캔합니다. 스프레드시트 자체와 원본 영수증 이미지의 체계적인 디지털 폴더를 결합하면 전용 문서 관리 시스템 없이도 NTA 요건을 충족하는 검색 가능한 아카이브가 만들어집니다. 스캔하여 디지털화한 종이 영수증은 법의 스캐너 보존 규칙에 해당합니다: 영수증 수령 후 2개월 및 영업일 기준 7일 이내에 스캔을 완료하고 사무실에서 요구되는 내부 처리 규칙을 채택했다면 물리적 원본은 폐기할 수 있습니다. 이메일 첨부 파일이나 다운로드로 원래 수신된 영수증의 경우 보관할 종이 원본이 없으므로 전자 보관만이 유일한 적법한 옵션입니다.

독립적으로 신고하는 프리랜서(청색신고 신고자는 7년, 백색신고 신고자는 5년 기록 보관)의 경우 일괄 추출 결과와 체계적인 디지털 파일의 조합은 추출 필요성과 규정 준수 요건을 한 번에 해결합니다. 개별 일본 영수증의 추출 메커니즘, 추출할 정확한 필드와 특정 형식에 맞는 열 설정 방법에 대해 더 자세히 알아보려면 영수증 데이터를 Excel로 추출하는 가이드를 참조하세요.

청색 신고 vs. 백색 신고: 신고 유형별 열 구성 설계

청색 신고(Blue Return)와 백색 신고(White Return) 중 선택하는 것은 세금 계산서에만 영향을 미치는 것이 아닙니다. 추출 스프레드시트에 필요한 열도 결정합니다. 열 설계 단계에서 이를 올바르게 설정하면 출력 결과가 제출하는 양식에 직접 매핑되어 중간 재변환 과정이 필요 없습니다.

청색 신고는 e-Tax를 통해 전자 제출하고 복식부기(複式簿記)를 유지하는 신고자에게 최대 65만 엔의 특별 공제를 제공합니다. 2027년부터는 e-Tax와 "우수한 전자 기록"을 결합한 경우 최대 공제액이 75만 엔으로 증가하며, 서면 제출자만 이용하는 경우 10만 엔으로 제한됩니다. 사업 소득 400만 엔인 개인 사업자의 경우, 한계 세율 20%(소득 330만 엔~695만 엔 구간)에서 65만 엔 공제는 대략 13만 엔의 소득세 절감에 해당하며, 여기에 주민세 감면 약 6.5만 엔(공제액의 약 10%)이 추가됩니다. 개인 사업자에게는 실질적인 금액이지만, 깔끔하고 세분화된 기록이 필요합니다.

일괄 추출에 대한 실질적 의미: 청색 신고자는 NTA(국세청)가 더 세분화된 보고를 요구하므로 더 많은 열이 필요합니다. 백색 신고자는 수지내역서(收支內譯書, Statement of Earnings and Expenses)가 청색신고결산서(青色申告決算書, Blue Return Financial Statement)만큼 상세한 수준을 요구하지 않으므로 더 간단한 열 집합을 사용할 수 있습니다.

비용 분류 열은 추론 열로 설정할 수 있습니다. 150개의 영수증 각각에 수동으로 분류를 입력하는 대신 "분류(옵션: 旅費交通費/接待交際費/消耗品費/通信費/地代家賃/その他)"와 같은 열 이름을 정의하면 AI가 비고(但し書き) 설명을 읽고 해당하는 표준 비용 분류를 판단하여 자동으로 채웁니다. 택시 영수증은 旅費交通費로, 고객 미팅 식사 영수증은 接待交際費로 분류됩니다. 추출과 분류가 별도의 단계가 아닌 한 번에 이루어집니다.

두 단계 워크플로우: 한 번 업로드하면 스프레드시트 완성

일년치 일본 영수증을 일괄 처리하는 워크플로우는 두 가지 핵심 단계로 나뉩니다. 나머지는 모두 준비와 검증 과정입니다.

1단계: 영수증 디지털화

종이 영수증의 경우 휴대폰 카메라를 사용하세요. 각 영수증을 어두운 표면에 평평하게 놓고, ‮発行者‬(발행자) 이름부터 합계 금액까지 전체 영수증이 보이도록 하며, 손 그림자가 생기지 않게 하세요. 대부분의 일본 편의점과 레스토랑에서 발행하는 감열지 영수증의 경우, 가능하면 받는 즉시 이미지를 촬영하세요. 감열지는 6~12개월 내에 변질되기 시작하며, 1년이 지난 ‮コンビニ‬ 영수증의 글자는 발행 당시보다 눈에 띄게 흐려져 있을 수 있습니다. 일본 경제산업성(METI)은 감열지 영수증을 발행 후 3개월 이내에 스캔할 것을 권장합니다.

전자적으로 받은 영수증 — Amazon Japan 주문 확인서, 공과금 PDF, 서비스 제공업체의 이메일 청구서 — 은 업로드 전에 한 폴더에 저장하세요. YYYY-MM-DD_Vendor와 같은 일관된 파일 명명 규칙(예: 2025-08-15_Yoshinoya.pdf)을 사용하면 각 파일을 개별적으로 찾을 수 있습니다. 수동으로 이름을 바꾸기에는 너무 많은 경우, 추출 도구가 출력 스프레드시트에 원본 파일 이름을 보존하므로 각 데이터 행을 원본 파일로 추적할 수 있는 링크가 제공됩니다.

2단계: 열 정의 및 일괄 업로드

신고 유형(청색 또는 백색 신고)과 위에서 논의한 필드에 따라 필요한 열 이름을 지정하세요. 열이 정의되면 모든 영수증 형식에서 동일하게 작동합니다: 7-Eleven의 열전사 영수증, 작은 식당의 손으로 쓴 ‮領収書‬, Amazon Japan의 이메일 PDF. 150장의 영수증을 한 번에 업로드하세요. AI가 각 영수증을 처리하고, 정의된 열과 일치하는 값을 찾아 단일 스프레드시트에 채웁니다.

3단계: 신고 전 출력 결과 검증

어떤 추출 도구도 모든 영수증에서 100% 정확도를 달성하지 못합니다. 일괄 추출의 목표는 인간의 노력을 "모든 필드 입력"에서 "이상치 점검"으로 옮기는 것입니다. 150장 영수증 배치의 경우, 집중적인 검증 절차는 약 30분이 소요됩니다:

1. 금액 기준 정렬(내림차순) 후 상위 10개 행을 육안으로 검토하세요. 이들은 가장 큰 지출 항목이며 감사 위험이 가장 높습니다. 각 항목을 원본 영수증과 대조하세요. ¥45,000 지출이 설비 구매 대신 사무용품으로 잘못 분류되면 NTA 규정에 따라 다른 감가상각 처리가 적용될 수 있습니다.
2. 카테고리 열 검토 — AI가 카테고리를 확신할 수 없을 때 사용하는 포괄 분류인 "‮その他‬"(기타) 분류가 있는지 확인하고 수동으로 재분류하세요.
3. 날짜 기준 정렬 후 현재 과세 연도(1월 1일~12월 31일)를 벗어난 항목이 없는지 확인하세요. 2025년 신고에 2026년 1월 영수증이 포함되면 곧 시정 조치가 필요해집니다.
4. 청색 신고 신고자의 경우: 세액 소계 합계를 점검하세요. 10% 소계와 8% 소계를 더하면 총액과 대략 일치해야 합니다(약간의 반올림 차이는 정상). 수백 엔 이상의 차이는 해당 영수증의 추출 오류 가능성을 나타냅니다.

출력 스프레드시트에는 각 행에 대한 원본 파일 참조가 포함되어 있어 원본 영수증 이미지로 돌아갈 수 있습니다. 이러한 추적 가능성은 ‮電子帳簿保存法‬ 검색 가능성 요구 사항을 충족합니다 — 모든 데이터 포인트는 원본 문서에 연결할 수 있습니다.

일본 특유의 과제: 대규모 처리에서 더 커지는 문제

일본 영수증의 여러 특징은 건별 처리에서 마찰을 일으킵니다. 100장 이상을 처리하는 대규모 작업에서는 이러한 마찰점이 사소한 불편에서 수 시간의 수작업으로 증폭됩니다. 일괄 워크플로우에서 각각의 특징이 어떻게 작용하는지 이해하면, 추출 결과물에 많은 후처리가 필요한지 아니면 세무 신고에 바로 사용할 수 있는 상태로 나오는지가 결정됩니다.

연호 날짜: ‮令和‬/‮平成‬/‮昭和‬를 서양력으로 변환

일본 영수증은 연호를 사용합니다: ‮令和‬(레이와, 2019년 5월 시작), ‮平成‬(헤이세이, 1989-2019), 그리고 오래된 보관 영수증의 경우 ‮昭和‬(쇼와, 1926-1989)도 가끔 볼 수 있습니다. 표준 추출 열은 문서에 적힌 그대로 날짜를 출력합니다 — "‮令和7年8月15日‬" — 대부분의 회계 소프트웨어는 이를 직접 해석할 수 없습니다. 영수증 1장당 30초씩, 150장의 날짜를 수동으로 변환하면 단일 필드 하나에 75분이 소요됩니다. 계산 열 — 추출 중에 계산을 수행하여 후처리가 필요 없는 기능 — 이 문제를 해결합니다: 변환 규칙(레이와 연도는 2018을 더하고, 헤이세이는 1988, 쇼와는 1925를 더함)이 있는 열을 정의하면 AI가 "2025-08-15"를 자동으로 출력합니다. Excel에서 별도의 변환 단계가 필요 없습니다.

이중 세율: 영수증이 필요한 정보를 구분해 주지 않을 때

2019년 10월부터 일본은 대부분의 상품과 서비스에 표준 10% 세율을, 식품(주류 및 외식 제외)과 신문 구독에는 8% 경감 세율을 적용합니다. 편의점 ‮領収書‬ 한 장에 10%‮対象‬, 8%‮対象‬, 0%‮対象‬(우표 등 비과세 품목)의 세 가지 소계가 표시될 수 있습니다. 2023년 이후의 현대적인 체인점 영수증 — Qualified Invoice System(‮インボイス制度‬)에 따라 요구됨 — 은 이러한 내역을 명확히 표시합니다. 오래된 영수증이나 소규모 상점의 수기 ‮領収書‬는 총액만 표시하는 경우가 많습니다.

영수증에 세율 구분이 명확히 표시된 경우, AI 추출은 안정적으로 처리합니다 — 두 개의 열이 두 소계를 각각 포착합니다. 영수증에 세금 내역 없이 총액만 표시된 경우, AI는 인쇄되지 않은 것을 나눌 수 없습니다. 이 경우 내용을 기준으로 수동으로 구분을 계산해야 합니다: 식품은 8%, 기타 품목은 10%. 핵심 작업량 차이: 일괄 워크플로우에서 수동 처리가 필요한 것은 내역이 누락된 영수증뿐입니다 — 150장 전체가 아닙니다. 명확히 인쇄된 영수증은 자동으로 처리됩니다.

‮但‬し書き (설명): 현장 감사가 기반하는 필드

‮但‬し書き는 지불 목적에 대한 법적 요구 설명이며, NTA 감사 중 가장 질문을 받기 쉬운 필드입니다. "‮品代‬"(상품 대금)이라고 적힌 영수증은 너무 모호한 것으로 간주됩니다. 허용되는 설명에는 "‮お食事代‬"(식비), "‮セミナー参加費‬"(세미나 참가비), 또는 "‮消耗品費‬"(소모품비)이 포함됩니다. 영어 영수증으로 학습된 범용 OCR은 이 필드를 종종 완전히 건너뛰지만, 문서를 전체적으로 읽는 비전-언어 모델은 의미로 필드를 찾기 때문에 이를 추출할 수 있습니다. ‮但‬し書き는 또한 비용을 올바른 ‮勘定科目‬로 자동 분류하는 추론 열에 입력되어, 영수증 처리에서 가장 수동적인 단계를 제거하는 일석이조의 워크플로우를 제공합니다.

손으로 쓴 영수증과 바랜 감열지: 한계를 알아야 합니다

일본에서는 수리, 컨설팅, 프리랜서 작업과 같은 서비스에 대해 손으로 쓴 ‮領収書‬가 여전히 흔합니다. 최신 비전-언어 모델은 인쇄된 일본어를 높은 정확도로 읽을 수 있지만, 손으로 쓴 한자 — 특히 필기체나 양식화된 붓글씨 — 는 모든 OCR 시스템에 가장 어려운 테스트 사례입니다. 명확하고 블록 스타일의 손글씨 필드는 일반적으로 추출 가능하지만, 매우 양식화된 글씨는 수동 검증이 필요할 것으로 예상해야 합니다.

편의점과 식당의 감열지 영수증은 6-12개월 내에 바래기 시작합니다. 육안으로 텍스트를 읽을 수 없을 정도로 바랜 경우, AI도 이를 복구할 수 없습니다. 실용적인 규칙: 받는 즉시 디지털화하거나, 최소한 연말 이전에 하십시오. 6월에 읽을 수 있었던 영수증도 다음 해 2월에는 희미한 회색 직사각형이 될 수 있습니다.

자주 묻는 질문

한 번에 영수증 150장을 정말 업로드할 수 있나요?

네. 일부 회계 소프트웨어 플랫폼은 세션당 일괄 OCR 업로드를 50개 파일로 제한하지만, 이 워크플로우를 위해 설계된 일괄 추출 도구는 영수증 이미지를 한 번에 모두 업로드할 수 있습니다 — JPG, PNG 또는 PDF — 그리고 각 영수증당 한 행씩 하나의 출력 스프레드시트로 처리합니다. 처리 시간은 볼륨에 비례합니다: 150장 영수증 배치는 몇 분이 아니라 몇 분 안에 완료됩니다.

8%와 10% 소비세 분리를 얼마나 정확하게 처리하나요?

영수증에 10%와 8% 소계가 별도로 명확히 표시된 경우 — 2023년 이후 대부분의 체인점 영수증이 Qualified Invoice System에 따라 그렇게 합니다 — AI 추출이 분리를 안정적으로 처리합니다. 영수증에 세금 내역 없이 단일 합계만 표시된 경우(오래된 영수증이나 소규모 판매자의 손글씨 ‮領収書‬에서 흔함), AI는 인쇄되지 않은 분리를 추출할 수 없습니다. 이러한 경우에는 품목이 경감 세율에 해당하는지 여부에 따라 분리를 수동으로 계산해야 합니다 — 하지만 이는 인쇄된 내역이 없는 소수의 영수증에만 적용됩니다.

손글씨 ‮領収書‬도 처리할 수 있나요?

부분적으로 가능합니다. AI 비전 모델은 문서를 전체적으로 처리하기 때문에 전통적인 템플릿 OCR보다 영수증의 명확한 블록체 손글씨를 더 잘 처리합니다 — 픽셀 대비뿐만 아니라 문맥에서 텍스트를 추론합니다. 특히 붓펜으로 쓴 ‮領収書‬의 필기체나 장식된 한자는 추출 정확도가 낮아집니다. 손글씨 영수증이 연간 볼륨의 20-30% 이상을 차지한다면, 워크플로우를 확정하기 전에 샘플 배치를 테스트하고 해당 영수증에 대한 수동 검증 시간을 추가로 확보하세요.

출력물을 freee, Yayoi 또는 MoneyForward로 가져올 수 있나요?

네. 일본의 주요 회계 플랫폼 3곳 모두 거래 데이터에 대한 CSV 가져오기를 지원합니다. 일괄 추출 스프레드시트를 CSV로 내보내고, 소프트웨어에서 요구하는 가져오기 형식에 맞게 열 순서를 조정한 다음, 영수증 150장을 개별 입력하는 대신 파일 하나를 가져오세요. freee의 가져오기 템플릿은 날짜, 금액, 계정 항목(‮勘定科目‬), 설명(‮摘要‬), 거래처(‮取引先‬) 열을 기대합니다. MoneyForward와 Yayoi도 유사한 열 규칙을 따릅니다. 일괄 추출 출력은 이러한 필드에 직접 매핑됩니다.

추출된 스프레드시트가 NTA 감사 요건을 충족하나요?

NTA는 전자적으로 수신된 영수증에 대해 종이 원본을 요구하지 않습니다 — ‮電子帳簿保存法‬은 전자 보관을 의무화합니다. 스캔하여 디지털화한 종이 영수증의 경우, 스캔본이 증빙 자료 역할을 하며, 감사 중에 NTA가 원본을 요청할 수 있습니다. 소스 파일 참조가 포함된 일괄 추출 스프레드시트 — 각 행이 원본 영수증 이미지로 연결됨 — 와 체계적으로 정리된 디지털 폴더를 결합하면 날짜, 금액, 거래처별로 검색 가능해야 한다는 기록 요건을 충족합니다. 핵심은 추적 가능성입니다: 세금 신고서의 모든 비용 청구는 요청 시 검색할 수 있는 원본 문서에 연결될 수 있어야 합니다. NTA는 기록을 7년(청색 신고) 또는 5년(백색 신고) 동안 보관할 것을 요구합니다 — 잘 정리된 스프레드시트와 디지털 아카이브는 검색을 사냥이 아닌 조회로 만듭니다.

2월의 주말 대신 2월의 오후

일본 프리랜서들이 1월에 서로에게 가장 자주 묻는 질문은 공제 전략이나 신고 마감일에 관한 것이 아닙니다 — "영수증을 아직 몇 장이나 입력해야 하느냐"입니다. 그 대답은 거의 항상 찡그린 표정을 만들어냅니다. 개별 ‮領収書‬ 하나를 처리하는 것이 어렵기 때문이 아니라, 하나씩 처리하면 적당한 양의 문제가 작업의 실제 복잡성에 비해 과도한 시간 낭비로 변하기 때문입니다.

일괄 추출이 데이터 검증의 필요성을 없애지는 않습니다 — 그것은 워크플로우와 관계없이 모든 책임 있는 신고자가 수행하는 단계입니다. 일괄 추출은 데이터를 처음부터 생성하는 부분을 없앱니다. "2025-08-15"를 143번째로 입력하고, 흐릿한 ‮但‬し書き 필드를 들여다보며 "‮お食事代‬"인지 "‮お菓子代‬"인지 확인하고, 7월의 감열지 영수증이 이제 거의 알아볼 수 없어 10% 대 8% 비율을 다시 계산하는 부분을 말입니다. 영수증 150장 기준으로 계산은 간단합니다: 열 설정 3-5분, 처리 몇 분, 목표 검증 약 30분. 총 1시간 미만 대 대부분의 하루 업무 시간입니다.

자신의 영수증으로 워크플로우를 테스트해 보세요. 오후 내내 걸릴 묶음이 커피를 마시며 검증할 수 있는 스프레드시트가 되는지 확인해 보세요 — 그리고 검증 시간이 빈 셀에서 만드는 작업이 아닌 확인 작업처럼 느껴지는지 확인해 보세요.