모든 은행과 형식에 관계없이 은행 거래내역서를 Excel로 변환

은행 명세서 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는 좌표가 아닌 의미론적 의미를 따르므로 페이지 간에 이동하는 열은 문제가 되지 않습니다.

"거래일자," "내역," "출금액," "입금액," "잔액"을 한 번 입력하세요. 동일한 열 정의가 각 은행의 레이아웃과 관계없이 Chase, Bank of America, Wells Fargo, HSBC, Barclays 및 지역 신용협동조합에서 데이터를 추출합니다. AI는 각 필드가 어디에 있는지가 아니라 무엇인지 이해하여 찾습니다. 좌표 템플릿이 없습니다. 은행별 규칙이 없습니다. 은행이 명세서 레이아웃을 업데이트해도 유지 관리가 필요 없습니다. 여러 계좌를 조정하는 경우 "계좌"와 같은 추론 열을 사용할 수 있으며, AI는 문서 헤더에서 읽은 맥락을 기반으로 각 거래가 어떤 계좌에 속하는지 분류합니다.

추출된 잔액이 합산되는지 확인하려면 추출 중에 AI가 수행하는 계산을 설명하는 이름의 열인 계산 열을 추가하세요. "잔액 확인"을 작성하면 AI가 명세서에 인쇄된 값과 예상 잔액을 비교하여 모든 행의 차이를 출력합니다. 이렇게 하면 데이터가 조정 스프레드시트에 들어가기 전에 잘못 읽은 금액, 전치된 숫자 또는 출금액이 실수로 입금액으로 추출된 것을 찾아냅니다. 더 복잡한 검증 논리의 경우 로그인한 사용자는 규칙 형식을 사용하여 열 이름을 깔끔하게 유지하면서 다단계 검증을 실행하는 JSON 기반 규칙을 정의할 수 있습니다.