은행 명세서를 엑셀로 변환 — 수동 입력 없이 거래 내역, 날짜, 차변/대변 열 추출

은행 명세서 PDF를 보면 각 거래 행의 날짜는 왼쪽 여백에, 설명은 페이지 중간을 가로지르며, 금액은 오른쪽에 정렬되어 있습니다. 이는 연속된 표가 아닌 세 개의 분리된 시각적 영역이며, 고정된 위치에 있지 않습니다. 페이지 헤더, 중간 합계, 또는 수표 번호를 위한 추가 열이 생기면 금액의 오른쪽 정렬 기준이 문서 중간에 바뀝니다. "왼쪽에서 두 번째 열"에 기준을 두는 템플릿 기반 OCR 도구는 열이 몇 픽셀만 이동해도 잘못된 결과를 냅니다. 수동 데이터 입력은 느리지만 적어도 사람의 눈은 수평 정렬을 추적합니다. 하지만 피로가 쌓이면 차변이 대변 항목으로 입력되기도 합니다.

체이스는 단일 부호 금액이 있는 간결한 3열 레이아웃을 사용합니다. 뱅크오브아메리카는 차변과 대변을 별도 열로 나눕니다. 웰스파고는 참조 번호 열을 추가하고 여러 줄 설명을 들여씁니다. HSBC는 모든 거래 후에 누적 잔액을 표시합니다. 바클레이즈는 소계와 함께 날짜 블록별로 거래를 그룹화합니다. 신용협동조합은 종종 또 다른 레이아웃의 중간 시장 명세서 프로세서를 사용합니다. 템플릿 기반 도구는 각 은행에 대해 별도의 좌표 템플릿이 필요하며, 은행이 PDF 생성기를 업데이트하면 그 템플릿은 작동하지 않게 됩니다. 개인 금융 포럼에서는 자주 언급하듯이 같은 은행의 명세서 레이아웃도 연도별로 변경되어 기존에 구축한 추출 규칙을 무효화합니다.

은행 설명은 악명 높을 정도로 축약되어 있습니다: "DEBIT CARD PURCHASE 04/12 SQ* COFFEE SHOP S" — 문맥을 아는 사람에게는 의미가 있지만, 공백으로 분할하거나 구분된 필드를 가정하는 도구는 쉽게 오해석합니다. 더 나쁜 것은, 여러 줄 설명이 두세 행에 걸쳐 있어 대부분의 추출 도구가 가정하는 '한 행에 하나의 거래' 원칙을 깨뜨린다는 점입니다. AI는 "Transfer to Savings 9876"과 "Interest Payment"가 줄바꿈 경계를 넘는 하나의 설명이 아니라 두 개의 별도 거래임을 이해하기 위해 전체 거래 블록(설명 텍스트, 날짜, 금액)을 함께 읽어야 합니다.

커스텀 열 추출(ImageToTable.ai의 핵심 메커니즘)을 사용하면 "거래일", "적요", "출금액", "입금액", "잔액" 등 원하는 필드를 정의할 수 있습니다. AI는 픽셀 위치를 기준으로 일치시키는 것이 아니라 문서 맥락에서 각 값이 나타내는 의미를 이해하여 읽습니다. 페이지 왼쪽에 MM/DD/YYYY 형식의 날짜가 있으면 PDF 좌표 공간에서 72열에 있든 95열에 있든 관계없이 거래일로 인식됩니다. 페이지마다 열 위치가 달라져도 문제없습니다. AI는 좌표가 아닌 의미론적 의미를 따릅니다.

"거래일", "적요", "출금액", "입금액", "잔액"을 한 번만 입력하세요. 동일한 열 정의로 체이스, 뱅크오브아메리카, 웰스파고, HSBC, 바클레이즈, 그리고 지역 신용협동조합의 데이터를 각 은행의 레이아웃과 관계없이 추출합니다. AI는 각 필드의 위치가 아닌 정체를 이해하여 찾아냅니다. 좌표 템플릿이 필요 없고, 은행별 규칙이 필요 없으며, 은행이 명세서 레이아웃을 업데이트해도 유지보수가 필요 없습니다. 여러 계좌를 조정하는 경우 "계좌(옵션: 입출금/적금/신용카드)"와 같은 추론 열을 사용하면 AI가 문서 헤더에서 읽은 맥락을 기반으로 각 거래가 속한 계좌를 분류합니다.

계산 열(추출 중 AI가 수행하는 계산을 설명하는 이름의 열)을 추가하여 추출된 잔액이 합산되는지 확인하세요. "잔액 확인(이전 잔액 + 입금액 − 출금액 − 추출 잔액)"을 작성하면 AI가 예상 잔액과 명세서에 인쇄된 잔액을 비교하여 모든 행에 대한 차이를 출력합니다. 이를 통해 잘못 읽힌 금액, 숫자 전위, 출금이 입금으로 잘못 추출되는 등의 오류를 데이터가 조정 스프레드시트에 들어가기 전에 잡아냅니다. 더 복잡한 검증 로직이 필요한 경우, 로그인한 사용자는 규칙 형식을 사용하여 JSON 기반 규칙을 정의함으로써 열 이름을 깔끔하게 유지하면서 다단계 검증을 실행할 수 있습니다.