신용카드 명세서 추출:
대부분의 도구가 틀리는 부분

신용카드 명세서가 기존 OCR에서 깨지는 이유

신용카드 명세서는 평면적인 표가 아닙니다. Chase, Amex, Capital One 명세서를 열어보면 같은 페이지에 최소 세 개의 서로 다른 데이터 영역이 보입니다. 날짜, 가맹점, 금액 열로 구성된 Purchases 섹션, 자체적인 열 구조를 가진 Payments & Credits 섹션, 그리고 종종 또 다른 레이아웃을 가진 Fees & Interest 섹션입니다. 일부 발급사는 Debit과 Credit을 나란히 배치된 열로 분리합니다. 다른 발급사는 모든 항목을 하나의 Amount 열에 쌓고 부호를 사용합니다. 어떤 곳은 가맹점명 뒤에 참조 번호를 넣고, 또 다른 곳은 별도 열을 사용합니다.

기존 OCR은 영역을 보지 못합니다. 전체 페이지를 하나의 연속된 텍스트 흐름으로 취급하며 왼쪽에서 오른쪽으로, 위에서 아래로 읽습니다. 결제 행에는 세 개의 열이 있는데 구매 행에는 네 개가 있으면, OCR은 이를 하나의 깨진 줄로 이어 붙입니다. 15건의 거래마다 표시되는 누적 소계는 굵은 글씨에 다르게 정렬되어 있어, 설명도 없고 금액도 엉터리인 거래로 읽힙니다. 명세서 헤더(카드 번호, 청구 기간, 결제 예정일)가 첫 거래 행에 섞여 들어갑니다.

신용카드 PDF를 Excel로 변환하는 방법에 관한 r/Bookkeeping 스레드에서 한 부기 담당자는 전형적인 결과를 이렇게 설명했습니다. "OCR 출력은 가맹점명의 절반을 날짜 열에 넣고, Credit과 Debit을 뒤섞으며, '다음 페이지에 계속' 헤더를 모두 거래로 포함합니다. 이걸 정리할 시간이면 그냥 직접 입력했을 겁니다." 이것이 실제 OCR 문제입니다. 읽지 못하는 것이 아니라, 정리하지 못하는 것입니다.

문제에는 두 번째 층도 있습니다. 바로 다중 페이지 연속성입니다. 80건의 거래가 네 페이지에 걸쳐 있는 월간 명세서는 OCR이 네 개의 개별 텍스트 블록을 생성한다는 뜻입니다. 누적 잔액은 페이지마다 끊깁니다. 두 번째 페이지의 "이전 페이지에서 계속" 헤더는 데이터 행으로 파싱됩니다. 첫 페이지의 페이지 하단 소계와 두 번째 페이지의 페이지 상단 이월 금액이 모두 추출되어 중복 항목이 생깁니다.

그리고 세 번째 층은 스캔된 명세서입니다. StatementDesk가 추적하는 업계 벤치마크에 따르면, 2026년에도 여전히 약 15~20%의 소규모 금융 기관이 텍스트 선택이 가능한 디지털 PDF가 아닌 이미지 기반 PDF를 생성합니다. 신용협동조합이 스캔된 PDF를 보내거나 종이 명세서 사진으로 작업하는 경우, 기존 OCR 정확도는 즉시 30~50% 떨어지며 위의 세 가지 문제 모두 악화됩니다.

시맨틱 추출이 OCR이 읽지 못하는 것을 읽는 방법

근본적인 문제는 문자 인식이 아닙니다. OCR이 문자 수준에서 멈춘다는 점입니다. OCR은 페이지의 (x,y) 위치에 텍스트가 있다는 것은 알지만, 그 (x,y) 위치가 "Purchases" 영역에 속한다는 것, 이 영역이 헤더 행으로 정의된 네 개의 열을 가지고 있다는 것, 그리고 7번째 행의 네 번째 열에 있는 금액이 Credit이 아닌 Debit을 나타낸다는 것을 알지 못합니다. 사람이 명세서를 한눈에 보고 즉시 파악할 수 있게 해주는 그 조직적 지식이 바로 빠져 있는 것입니다.

Vision Large Model(VLM)이 그 간극을 메웁니다. 좌표를 매칭하는 템플릿 기반 OCR과 달리, VLM은 사람이 읽는 방식으로 신용카드 명세서를 읽습니다. 레이아웃을 보고, "Payments and Credits"가 "Purchases"와 다른 섹션임을 이해하며, Purchases 영역의 가장 오른쪽 열이 거래 금액임을 인식하고, 페이지가 넘어가도 행 구조를 유지합니다. 이 모델은 Chase와 Amex에 대해 템플릿이 필요하지 않습니다. 좌표를 찾는 것이 아니라 의미를 찾기 때문입니다.

좌표 매칭에서 시맨틱 이해로의 이러한 전환은 가능한 것들을 바꿉니다. "금액 열이 Chase 명세서에서는 412픽셀에서 시작하고 Amex 명세서에서는 387픽셀에서 시작한다"고 도구에 알려주는 대신, 원하는 데이터를 알려주면 됩니다. AI가 각각의 특정 페이지에서 그 데이터가 어디에 있는지 파악합니다.

여기서 맞춤 열 추출이 등장합니다. 대부분의 추출 도구가 제공하는 것과는 다르게 작동하는 메커니즘입니다. 각 카드 발급사별로 템플릿을 미리 구성하거나 데이터 필드 주위에 수동으로 상자를 그리는 대신, 최종 스프레드시트에 원하는 열 이름을 입력하기만 하면 됩니다. "Transaction Date", "Merchant Name", "Amount"처럼요. AI가 문서를 읽고, 각 열 이름에 해당하는 데이터를 픽셀 위치가 아닌 시맨틱 의미로 파악하여 행을 채웁니다. 입력한 열 이름이 출력 테이블의 헤더가 됩니다. 템플릿 학습도, 좌표 매핑도, 은행별 설정도 필요 없습니다.

단계별: 맞춤 열 추출로 거래 내역 추출하기

다음은 맞춤 열 추출을 사용해 원하는 데이터만 정확히 정의하여 PDF 명세서에서 깔끔한 Excel 스프레드시트로 변환하는 워크플로입니다.

1단계: 명세서를 업로드하세요. 이 도구는 PDF(디지털 또는 스캔), JPG, PNG, WebP를 지원합니다. 여러 페이지로 된 명세서(예: Chase의 4페이지 월간 명세서)가 있다면 파일 전체를 한 번에 업로드할 수 있습니다. 다중 페이지 문서는 하나의 연속된 데이터셋으로 처리되며, 1, 2, 3, 4페이지의 거래 내역이 모두 순서대로 동일한 출력 테이블에 들어갑니다. 여러 카드의 명세서(예: 업무용 Amex와 개인용 Visa)가 있다면 배치로 함께 업로드하여 하나의 병합된 스프레드시트를 받을 수 있습니다.

2단계: 열을 정의하세요. 추출 영역을 구성하거나 모델을 학습시키는 대신, 추출할 열 이름을 입력하기만 하면 됩니다. 완전한 거래 원장의 경우 일반적인 열은 다음과 같습니다:

명세서 수준 필드도 포함할 수 있습니다 — Statement Period Start, Statement Period End, Payment Due Date, Minimum Payment Due — AI가 명세서 헤더에서 한 번 추출하여 모든 거래 행에 참조용으로 반복 입력합니다. 여러 달을 한 번에 처리할 때 각 행에 청구 기간을 태그해야 하는 경우 유용합니다.

Step 3: Excel로 내보내기. AI가 추출을 완료하면 — 보통 페이지당 5–10초 — 구조화된 Excel(XLSX) 파일을 다운로드합니다. 정의한 모든 열이 스프레드시트의 열이 됩니다. 모든 거래가 행이 됩니다. 데이터는 이미 표준화되어 있습니다: 일관된 형식의 날짜, 깔끔한 숫자로 된 금액(셀에 통화 기호가 포함되지 않음), 은행 내부 코드가 제거된 가맹점 이름. 회계 소프트웨어에 가져올 때 선호하는 형식이라면 CSV 및 JSON 내보내기도 가능합니다. 외화 처리, 다양한 발급사 형식에 걸친 다중 영역 파싱, 배치 다중 월 처리 등 전체 추출 기능에 대한 자세한 내용은 신용카드 명세서를 Excel로 변환 페이지를 참조하세요. 다운로드 및 가져오기 단계 없이 행을 Google Sheets에 직접 넣고 싶다면, 신용카드 명세서를 Google Sheets로 추출하는 방법을 다룬 저희 글에서 동일한 명세서에 대한 사이드바 애드온 워크플로를 확인하세요.

추론 열로 거래 자동 분류하기

PDF에서 거래 데이터를 추출하면 추출 문제는 해결됩니다. 하지만 조정과 세무 준비를 위해서는 추출이 첫 단계에 불과합니다. 모든 거래에는 여전히 분류가 필요합니다. Amazon 결제가 사무용품인지, 장비인지, 개인 비용인지 말이죠. 실제 수동 조정 시간의 대부분은 바로 이 분류 단계에서 소요됩니다.

이때 필요한 것이 바로 추론 열입니다. 문서에 명시적으로 인쇄된 데이터를 추출하는 일반 열과 달리, 추론 열은 AI가 문서에 직접 명시되지 않은 사항을 문서 내용 분석을 통해 판단하도록 요청합니다. Category (options: Office Supplies/Equipment/Travel/Meals/Software/Utilities/Other)라는 열을 정의하면, AI는 각 거래 행에 대해 가맹점 이름과 거래 맥락을 읽고 가장 적절한 분류를 선택합니다.

"Staples"의 $42 결제는 "Office Supplies"로 분류됩니다. "Delta Airlines"의 $389는 "Travel"이 됩니다. "Adobe Creative Cloud"의 $59.99는 "Software"가 됩니다. AI는 키워드 매칭을 하는 것이 아닙니다. 명세서 레이아웃을 분석할 때 사용하는 것과 동일한 의미론적 이해를 활용합니다. "Staples"가 사무용품 소매업체이고, "Delta"가 항공사이며, "Blue Bottle Coffee"의 $3.50 결제가 장비가 아닌 식사 비용임을 알고 있습니다.

신용카드 조정에서 이것이 강력한 이유는 추출과 분류가 동시에 이루어지기 때문입니다. 거래를 Excel로 추출한 다음 Category 열을 수동으로 추가하는 데 한 시간을 더 쓰지 않아도 됩니다. AI가 두 열을 동시에 채웁니다. 그리고 추론 열은 일괄 업로드에서도 작동하므로 — 여러 카드 또는 여러 달의 명세서를 함께 처리 — 모든 출처의 모든 거래가 이미 분류된 단일 스프레드시트를 얻을 수 있습니다.

신용카드 명세서와 은행 명세서: 추출 방식의 차이

신용카드 명세서와 은행 명세서가 동일한 추출 문제라고 생각하기 쉽습니다. 둘 다 날짜, 설명, 금액이 포함된 거래 테이블이 있으니까요. 하지만 실제로는 서로 다른 과제를 제시하며, 한쪽에 최적화된 도구는 다른 쪽에서 어려움을 겪는 경우가 많습니다.

특히 은행 명세서 추출은 누적 잔액 검증과 수표 번호 파싱이라는 고유한 과제를 안고 있습니다. 소기업을 위한 은행 명세서 추출에서 해당 작업 흐름을 자세히 다룹니다. 신용카드 명세서의 핵심은 영역 인식이 필수라는 점입니다. 전체 페이지를 하나의 평면 테이블로 처리하는 도구는 구매, 결제, 수수료를 섞어 사용할 수 없는 단일 목록으로 만들어 버립니다. 의미론적 추출은 "Purchases", "Payments and Credits", "Interest Charged" 같은 헤더 텍스트를 인식하고 영역별로 다른 파싱 규칙을 적용하여, 명세서를 읽을 때 눈이 하는 것과 같은 방식으로 문제를 해결합니다.

월간 조정에서 연말 세무 준비까지

신용카드 명세서 추출을 자동화하는 이유는 단지 이번 달 한 시간을 아끼기 위한 것이 아닙니다. 그 한 시간을 여러 달, 여러 카드, 연말 요구 사항에 걸쳐 곱했을 때 어떤 일이 일어나는지에 대한 문제입니다.

일반적인 소기업 부기 워크플로우에는 세 가지 조정 주기가 있습니다: 월간(신용카드 명세서 거래를 영수증 및 General Ledger(GL) 항목과 대조), 분기별(예상 세금 납부를 위한 분류된 지출 집계), 연간(CPA 검토 및 세금 신고를 위한 연간 거래 데이터 통합). 각 단계에서 기본 거래 데이터의 품질이 다음 단계에서 발생하는 작업량을 결정합니다. 월간 단계에서 데이터가 지저분하면 연말에 이를 정리하기 위해 시간당 $200 이상을 청구하는 CPA가 필요하게 됩니다.

월간 조정은 자동화된 추출이 가장 즉각적인 영향을 미치는 부분입니다. 명세서 PDF를 Excel과 나란히 열고 각 행을 입력하는 대신, 명세서를 업로드하고 열을 한 번 정의하면 몇 초 안에 깔끔한 스프레드시트를 얻을 수 있습니다. 매월 세 개의 카드를 처리한다면, 이는 복리 효과가 있는 반복적인 시간 절약입니다.

분기별 예상 세금 계산에는 분류된 거래 데이터가 필수적입니다. IRS는 Publication 535(사업 비용)에 따라 비용 공제에 합리적인 근거를 요구합니다. 즉, 얼마를 지출했는지뿐만 아니라 각 비용이 어떤 범주에 속하는지도 알아야 합니다. 추출 시점에 분류를 처리하는 추론 열을 사용하면 분기별 지출 요약이 이미 정리되어 있습니다: 총 여행비, 총 사무용품비, 총 소프트웨어 구독비가 각각 피벗 준비가 된 스프레드시트의 한 줄로 표시됩니다.

연말에는 그 차이가 더 두드러집니다. 대부분의 소기업은 아웃소싱 부기에 월 $500~$1,000을 지불하며, 정리되지 않은 기록에 대한 소급 또는 정리 부기는 6~12개월 분량의 백로그에 대해 $800~$2,500이 소요될 수 있습니다. 매월 깨끗하고 분류된 거래 데이터가 이미 내보내지고 정리되어 있다면, 부기 담당자의 업무는 데이터 입력에서 검토 및 분석으로 전환되어 더 빠르고 저렴한 업무가 됩니다. 특히 세금 시즌에는 수동 세금 데이터 입력이 자동화 문제를 만드는 이유 및 세금 시즌 데이터 정리에 대한 관련 기사가 W-2 및 1099 양식에 동일한 논리를 적용합니다. 사전 구조화된 추출이 후속 재작업을 줄인다는 동일한 원칙이 문서 유형 전반에 걸쳐 적용됩니다.

FAQ