은행 거래 내역을 Excel로 추출하는 방법
— 기존 OCR이 실패하는 이유와 AI가 해결하는 방법

은행 거래명세서가 인보이스보다 구조적으로 까다로운 이유

은행 거래명세서는 필드의 집합이 아닙니다. — 시간 순서대로 정렬된 원장으로, 모든 행의 위치가 중요하며 산술이 맞아떨어져야 합니다. 이를 인보이스처럼 취급하는 것이 대부분의 추출 실패의 근본 원인입니다.

인보이스는 한 페이지에 레이블이 지정된 영역에 흩어져 있는 약 15~20개의 데이터 포인트로 구성됩니다. 여기에는 인보이스 번호, 마감일, 하단의 합계 등이 포함됩니다. 이들은 개별 필드입니다. 추출은 찾아서 가져오는 작업입니다. 도구가 하나의 필드를 놓치면, 하나의 정보를 놓치는 것뿐입니다. 나머지 출력은 여전히 사용할 수 있습니다.

은행 거래명세서는 완전히 다른 데이터 구조입니다. 여기에는 거래 테이블이 포함됩니다. 보통 월별로 30~300개의 행이 있으며, 각 행에는 날짜, 설명, 차변 또는 대변 금액, 그리고 누적 잔액이 있습니다. 47번째 행의 잔액 열은 46번째 행의 잔액에 따라 달라지며, 이는 45번째 행에 따라 달라지고, 결국 초기 잔액까지 거슬러 올라갑니다. 이는 인쇄된 테이블로 렌더링된 연결 리스트 데이터 구조입니다. 도구가 하나의 행을 놓치거나 열을 한 위치만큼 이동시키면, 산술 체인이 끊어지고 전체 조정이 실패합니다 — 단순히 하나의 필드가 아니라 전체가 실패합니다.

게다가 은행 거래명세서는 일반적으로 여러 페이지에 걸쳐 있으며, 거래 테이블이 페이지 중간에서 끊기고 이월 소계가 표시될 수 있다는 점을 고려하면, 은행 거래명세서 추출이 근본적으로 다른 문제임을 알 수 있습니다. 이는 "더 어려운 OCR"이 아닙니다. 이는 다른 종류의 추출입니다: 필드 추출이 아닌 연속적인 원장 재구성입니다.

이를 더욱 복잡하게 만드는 것은 은행 거래명세서 형식의 엄청난 다양성입니다. 전 세계적으로 수천 가지의 고유한 은행 거래명세서 레이아웃이 존재하는 것으로 추정됩니다. 미국의 Chase와 Bank of America부터 영국의 HSBC와 Barclays, 독일의 Deutsche Bank, 브라질의 Caixa까지. 각 은행은 거래 열을 다르게 배열하고, 차변과 대변에 다른 용어를 사용하며, 다른 페이지 수준의 서식을 적용합니다. 한 은행의 PDF에서 작동하는 템플릿 기반 도구는 다른 은행의 거래명세서에 대해 완전히 새로운 템플릿이 필요합니다. 여러 은행의 고객을 처리하는 회계 법인의 경우, 일반적인 형식을 모두 다루기 위해 수십 개의 템플릿을 유지 관리해야 하며, 은행이 거래명세서 디자인을 업데이트할 때마다 다른 템플릿이 깨집니다.

처음 이 문제를 접하는 대부분의 사람들은 더 나은 OCR, 즉 더 높은 문자 수준의 정확도가 해결책이라고 가정합니다. 하지만 실제 문제는 문자를 읽는 것이 아닙니다. 문제는 어떤 문자가 거래 행을 구성하고, 어떤 문자가 헤더를 구성하며, 어떤 문자가 잔액을 구성하고, 이 모든 것이 페이지 간에 어떻게 연결되는지 이해하는 것입니다. 이는 광학 인식이 아닙니다. 이는 문서 이해입니다.

일반 OCR이 은행 거래 명세서에서 잘못 읽는 부분

일반 OCR은 페이지의 모든 문자를 동등하게 읽습니다. 거래 금액과 잔액, 페이지 헤더를 구분하지 못합니다. 은행 거래 명세서의 경우, 첫 번째 행부터 구조적 노이즈가 섞여 엑셀 출력이 오염됩니다.

은행 거래 명세서 PDF를 표준 OCR이나 Adobe 내보내기 같은 PDF-to-Excel 변환기에 넣으면, 대략적으로 올바른 문자가 대략적으로 올바른 위치에 배열된 결과를 얻습니다. 하지만 '대략적으로 올바른 위치'라는 점이 은행 거래 명세서에서 다섯 가지 방식으로 문제를 일으킵니다.

1. 잔액 열 혼동. OCR에게 잔액 열은 그저 또 다른 숫자 열처럼 보입니다. OCR 엔진은 N행의 잔액이 파생 값임을 이해하지 못합니다. 즉, 이전 잔액에 N행의 거래 금액을 더하거나 뺀 결과여야 하며, 독립적으로 추출된 숫자가 아닙니다. 명세서가 4열 레이아웃을 가질 때, OCR은 잔액 값을 차변/대변 열에 합치거나 그 반대의 경우가 자주 발생합니다. 결과 스프레드시트는 모든 데이터가 있는 것처럼 보이지만 숫자가 맞지 않습니다. 한 회계 담당자가 r/Bookkeeping에서 설명했듯이, "은행 거래 명세서 PDF를 엑셀로 깔끔하게 변환되나요? 제 건 안 되는데…" — 결국 사용자는 직접 입력하는 것보다 더 많은 시간을 추출 데이터 수정에 씁니다.

2. 여러 페이지에 걸친 표 분할. 6페이지 분량의 은행 거래 명세서는 페이지에 걸쳐 나뉜 하나의 연속 거래 표입니다. 페이지 나눔으로 인해 반복되는 열 헤더, 페이지 번호, 그리고 종종 이월 소계 행이 발생합니다. OCR은 각 페이지를 독립적인 표로 처리합니다. 결과적으로 헤더 행과 소계 행이 거래 행 사이에 섞여 출력되어 행 순서가 깨지고 데이터가 오염됩니다. 실제 거래가 147개인 명세서가 엑셀에서 160개 이상의 행으로 끝날 수 있습니다. 이 중 13개는 거래 데이터로 위장한 페이지 헤더와 소계입니다.

3. 페이지 간 열 위치 이동. 같은 은행 내에서도 거래 열의 위치가 페이지마다 바뀔 수 있습니다. 1페이지는 '잔액' 열이 없어 설명 열이 페이지 너비의 60%를 차지할 수 있습니다. 2페이지에서는 다섯 번째 열로 잔액 열이 추가되어 설명 너비가 40%로 줄어듭니다. 고정 열 좌표를 사용하는 OCR은 열 이동 이후 모든 행을 잘못 읽습니다. 설명이 있어야 할 자리에 계좌 번호를 추출하거나, 거래 금액이 있어야 할 자리에 잔액을 추출합니다.

4. 차변/대변 부호 모호성. 일부 은행은 각각 양수 값이 있는 별도의 차변 및 대변 열을 사용합니다. 다른 은행은 차변에 음수 값을 사용하는 단일 금액 열을 사용합니다. 또 다른 은행은 차변에 'Dr' 접미사, 대변에 'Cr' 접미사를 붙인 단일 금액 열을 사용합니다. OCR은 이를 회계 항목이 아닌 텍스트 문자열로 읽습니다. 출력은 수동 정리가 필요합니다. '500.00Dr'을 -500.00으로 변환하거나, 두 열을 하나의 부호 있는 열로 통합하는 작업이 있어야 조정을 시작할 수 있습니다. AICPA의 2025년 업무 효율성 벤치마크에 따르면, 평균 회계 법인은 고객당 월 11.3시간을 은행 조정에 소비하며, 그 시간의 78%가 예측 가능하고 자동화 가능한 패턴을 따르는 거래 매칭에 소모됩니다.

5. 스캔 PDF와 디지털 PDF 혼동. 디지털 PDF는 선택 및 기계 판독이 가능한 텍스트를 포함합니다. 스캔 PDF는 텍스트 이미지로, 사진과 다를 바 없습니다. 많은 PDF-to-Excel 튜토리얼은 디지털 PDF를 가정하고 스캔 명세서에서는 조용히 실패합니다. 깨끗한 디지털 텍스트용으로 설계된 OCR 엔진은 접힌 종이 명세서의 150dpi 스캔에서 엉터리 결과를 냅니다. 그럼에도 스캔 명세서는 여전히 흔합니다: 최근 r/Accounting 게시글은 "모든 것을 스캔 PDF로 보내는" 고객의 현실을 논의합니다.

AI 추출이 은행 명세서를 읽는 방식의 차이

OCR에서 AI 추출로의 근본적 전환은 문자 읽기에서 문서 구조 이해로의 이동입니다. 즉, 잔액 열이 단순한 숫자 열이 아니고 거래 행이 단순한 텍스트 줄이 아님을 인식하는 것입니다.

전통적 OCR은 "이 좌표에 어떤 문자가 있는가?"라는 질문에 답합니다. AI 추출은 "이 문서에 무엇이 포함되어 있고 어떻게 구성되어 있는가?"라는 다른 질문에 답합니다.

이것이 위치 기반 추출과 의미 기반 추출의 차이입니다. 위치 기반 도구는 각 필드가 페이지의 어디에 있는지 알려줘야 합니다. "거래 금액은 항상 네 번째 열, 왼쪽 가장자리에서 73mm 지점에 있습니다." 체이스가 다음 분기에 명세서 레이아웃을 변경하거나 완전히 다른 열 배열의 웰스파고 명세서를 받으면 그 템플릿은 깨집니다. 새로 만들어야 합니다.

사용자 정의 열 추출 — ImageToTable.ai의 핵심 메커니즘 — 은 반대 접근법을 취합니다. 시스템에 데이터가 페이지의 어디에 있는지 알려주는 대신, 원하는 데이터가 무엇인지 알려줍니다: "거래일자", "내역", "출금액", "입금액", "잔액" 같은 열 이름. AI는 전체 페이지를 읽고, 헤더, 거래 행, 잔액 행, 바닥글을 이해한 다음, 정의한 열로 모든 거래 행을 추출하며 행 순서를 처음부터 끝까지 유지합니다. 각 은행이 어떤 열 위치를 사용하는지는 중요하지 않습니다. AI는 좌표가 아닌 의미를 읽습니다.

이것은 특히 누적 잔액에서 중요합니다. "잔액" 열을 정의하면 AI는 이 열이 파생 필드임을 인식합니다. 값을 그대로 추출하지만 실제 검증은 계산 열을 통해 이루어집니다. AI가 인쇄된 잔액을 무시하고 거래 금액에서 다시 계산하도록 지시할 수도 있습니다. 그러면 내장 검증이 작동합니다: 계산된 잔액과 명세서의 인쇄된 잔액 간 불일치가 있으면 검토가 필요한 행이 표시됩니다.

이를 가능하게 하는 메커니즘은 비전-언어 모델을 OCR 엔진과 근본적으로 다르게 만드는 것과 동일합니다: 페이지를 문자 경계 상자의 격자가 아닌 전체 시각적 장면으로 처리합니다. "테이블에 5개의 열이 있고, 다섯 번째는 누적 잔액이며, 데이터는 페이지 나누기를 넘어 계속되고, 중간 부분에 거래가 아닌 소계 행이 있다"는 것을 봅니다. 전통적 OCR은 이 중 어떤 것도 보지 못합니다. 픽셀이 격자로 배열된 것만 볼 뿐입니다.

단계별 가이드: 은행 거래 내역서 데이터를 Excel로 추출하기

PDF 은행 거래 내역서에서 정리되고 대사 가능한 스프레드시트까지의 경로는 4단계입니다. 템플릿도, 은행별 설정도, 열 위치 학습 데이터도 필요 없습니다.

위의 4단계 워크플로우 — 업로드, 열 정의, 추출, 내보내기 — 는 바로 저희 은행 거래 내역서 Excel 변환기가 한 번에 수행하는 작업입니다. 템플릿도, 은행별 설정도 필요 없습니다. 직접 거래 내역서로 무료로 사용해 보세요: PDF를 업로드하고 열 이름을 지정하면 추출된 행이 몇 초 안에 반환되어 대사 확인에 바로 사용할 수 있습니다.

이 워크플로우가 템플릿 기반 파서와 다른 점은 시스템에 데이터가 어디에 있는지 알려주지 않고 무엇을 원하는지만 알려준다는 것입니다. 이것이 템플릿 불필요의 핵심입니다. AI가 문서의 레이아웃과 무관하게 구조를 이해합니다. 새 은행에서 명세서를 받거나 기존 은행이 양식을 개편해도 다시 설정할 필요가 없습니다. 같은 열 이름이 페이지의 어느 위치에 있든 동일한 데이터를 찾아냅니다.

다중 페이지 명세서 및 일괄 처리

월말 조정 한 건에 3개 은행의 PDF 12개가 포함될 수 있습니다. 일괄 처리는 이를 한 번에 모두 처리하여 각 명세서의 행 순서를 유지한 채 모든 거래를 단일 출력 스프레드시트로 병합합니다.

은행 명세서 추출은 파일 하나씩 처리하는 문제가 아닌 경우가 대부분입니다. 1분기 장부를 마감하는 회계 담당자는 3개월 × 3개 은행 계좌 = 9개의 PDF를 처리해야 할 수 있습니다. 50개 고객사를 관리하는 회계 법인은 월 200건 이상의 명세서를 처리할 수 있습니다. 수동 방식은 거래 수에 비례하여 시간이 늘어나며, AICPA 데이터가 결과를 확인해 줍니다. 고객사당 월 11.3시간, 50개 고객사 법인 기준 전담 인력 3.5명이 은행 조정에만 필요합니다.

일괄 우선 처리는 여러 파일을 한 번에 받아 단일 출력 테이블로 병합하도록 설계된 방식입니다. 체이스 1월, 체이스 2월, 체이스 3월, 웰스파고 1월, 웰스파고 2월, 웰스파고 3월 — 여섯 개 파일을 한 번에 업로드하면 여섯 개 명세서의 모든 거래가 담긴 단일 Excel 스프레드시트를 받을 수 있으며, 각 거래에는 추적 가능하도록 출처 파일명이 태그로 표시됩니다. 각 명세서 내 행 순서는 유지되며, 출력 시 선택적으로 출처 파일 열을 추가하여 어떤 거래가 어떤 명세서에서 왔는지 항상 확인할 수 있습니다.

다중 페이지 명세서의 경우 AI는 단일 PDF의 1~6페이지가 여섯 개의 개별 테이블이 아니라 하나의 연속된 거래 테이블임을 이해합니다. 3페이지 28행에 표시된 누적 잔액은 2페이지의 거래 시퀀스가 이어진 것으로 인식됩니다. 매 페이지마다 반복되는 헤더, 페이지 번호, 이월 소계, 은행 표준 문구는 Excel 출력에 도달하기 전에 필터링됩니다.

이것이 일괄 처리와 다중 페이지의 결합이 수동 입력보다 훨씬 큰 이점을 만드는 지점입니다. 200건의 거래가 있는 12페이지 분량의 기업 당좌 명세서는 수동 입력 시 약 1시간이 걸리지만, 이 도구는 페이지당 5~10초면 처리합니다. Sage 2025 회계 기술 보고서에 따르면 은행 조정을 자동화한 법인은 처리 시간을 75% 단축하고 첫 번째 통과 매칭 정확도를 94.2%에서 99.6%로 개선했습니다. 핵심 통찰은 단순한 시간 절약이 아니라 인간 입력에서 AI 추출로 전환하면 가장 흔한 오류 유형인 전위 실수를 제거한다는 점입니다. 예를 들어 "2,847.31"을 "2,487.31"로 잘못 읽거나 금액을 잘못된 행에 입력하는 실수입니다.

다운로드한 Excel 파일 대신 Google Sheets에서 직접 데이터가 필요한 실무자를 위해 Google Sheets 애드온은 사이드바 인터페이스를 제공하여 명세서를 업로드하고 추출된 거래 행을 활성 시트에 직접 추가합니다. 파일 다운로드나 가져오기 단계가 필요 없습니다. 다양한 명세서 규모에서 수동 입력과 어떻게 비교되는지 자세히 알아보려면 수동 vs AI 은행 명세서 입력 비교를 참조하세요.

추출된 데이터를 조정 가능한 형태로 만들기

거래 내역을 Excel로 옮기는 것은 첫 단계에 불과합니다. 이를 자동으로 조정 — 기초 잔액 + 입금 − 출금 = 기말 잔액이 맞는지 검증하는 것 — 계산 열이 추출된 데이터를 검증된 데이터로 바꾸는 지점입니다.

거래 행이 완벽하게 추출되었더라도 조정에는 산술 검증이 필요합니다. 은행 거래 명세서는 기초 잔액과 기말 잔액을 명시하며, 그 사이의 모든 거래 합계는 두 잔액을 연결해야 합니다. 수동 작업 방식은 가져온 후 별도의 Excel 열에서 계산을 수행하여 이를 처리합니다. AI 추출 작업 방식은 계산 열을 사용하여 추출 중에 처리할 수 있습니다.

계산 열은 AI가 각 명세서를 처리할 때 실행되는 계산을 정의할 수 있게 해줍니다. 은행 거래 명세서 조정에는 두 가지 계산 열이 특히 유용합니다:

누적 잔액 검증: 각 거래 후 예상 잔액을 계산하고 명세서에 인쇄된 잔액과 비교하는 계산 열을 정의할 수 있습니다. 불일치가 발생하면 플래그가 생성됩니다 — 산술이 맞지 않는 행이 사람의 검토가 필요한 행입니다.

입금/출금 상계: 입금과 출금 열이 분리된 명세서의 경우, 계산 열이 각 행의 순액과 전체 행의 누적 순액을 계산할 수 있습니다. 최종 누적 순액을 기초 잔액에 더하면 기말 잔액과 일치해야 합니다. 일치하지 않으면 불일치 금액이 추출이 얼마나 벗어났는지 정확히 알려주며, 일반적으로 잘못 읽힌 특정 행 하나 또는 두 개를 가리킵니다.

이러한 계산 검증은 조정 작업을 수행하는 모든 사람에게 선택 사항이 아닙니다 — "데이터가 맞아 보인다"와 "데이터가 맞음이 입증되었다"의 차이입니다. 공인부정감사인협회(ACFE)는 보고에 따르면 재무제표 사기 사건의 약 22%가 은행 조정을 통해 발견되며, 이는 산술 검증 단계를 건너뛸 수 없는 이유를 강조합니다.

추출 및 검증 후, 구조화된 Excel 출력은 회계 소프트웨어 — QuickBooks Online, Xero, Sage, NetSuite 또는 CSV/XLSX 가져오기를 지원하는 모든 플랫폼 — 로 유입될 수 있으며, 거래 데이터는 이미 정리되고 표준화되고 검증된 상태입니다. 전체 재무 문서 워크플로우에 사용할 도구를 평가 중이라면, 당사의 은행 거래 명세서 추출 도구 비교에서 정확성, 가격, 회계 통합 측면의 현황을 확인할 수 있습니다.

다른 은행 및 국가의 은행 거래 내역서

형식 독립적 추출 시스템은 Chase 거래 내역서, Deutsche Bank 거래 내역서, Caixa 거래 내역서를 동일한 문제로 취급합니다. 각각은 날짜, 설명, 금액이 있는 거래 테이블입니다. 시각적 레이아웃 차이는 추출 로직을 변경하지 않습니다.

템플릿 기반 추출의 숨은 비용 중 하나는 은행별 유지보수 오버헤드입니다. 파싱 도구가 각 은행 형식에 대해 학습이나 템플릿 생성이 필요하고, 회사가 고객 기반 전반에 걸쳐 15개 다른 은행의 거래 내역서를 처리한다면, 15개의 파싱 구성을 유지해야 합니다. 그중 어떤 은행이 거래 내역서 레이아웃을 업데이트하면 — 글꼴 변경, 열 순서 변경, 새 로고 배치 — 템플릿 하나가 작동을 멈춥니다. 이는 보통 시간이 가장 빠듯한 월말에 고객의 거래 내역서를 처리하려 할 때 출력이 깨져서 발견하게 됩니다.

형식 독립적 AI 추출은 이를 완전히 우회합니다. 은행이 2열 레이아웃, 5열 레이아웃, 또는 현지 용어를 사용하는 지역 변형 — 프랑스어 거래 내역서의 "Debits" 대신 "Retraits", "Credits" 대신 "Versements" — 을 사용하든, AI는 구조적 패턴으로 거래 테이블을 식별합니다: 날짜, 텍스트 설명, 숫자 금액의 반복 시퀀스. 해당 패턴 내의 특정 배열은 중요하지 않습니다.

이 형식 독립성은 기본 데이터 표준이 다른 국제 거래 내역서도 처리합니다. 유럽 은행들은 점점 camt.053 — 은행-고객 거래 내역서용 ISO 20022 XML 형식 — 으로 거래 내역서를 발행하며, 이는 명시적 거래 수준 메타데이터가 있는 구조화된 기계 판독 가능 형식입니다. 그러나 많은 은행이 여전히 camt.053 파일과 함께 또는 대신 PDF 거래 내역서를 발행하며, 일부 국가는 ISO 20022 채택까지 수년이 걸립니다. 대부분의 회계 팀이 직면한 현실은 혼합 수신입니다: 일부 고객은 CSV 내보내기를 제공하고, 일부는 PDF를 제공하며, 소수는 파싱할 수 없는 XML 거래 내역서를 전달합니다. 세 형식을 모두 처리하는 단일 도구는 형식별 별도 처리 경로의 필요성을 제거합니다.

단일 국가 내에서도 레이아웃 다양성은 상당합니다. Wells Fargo 비즈니스 당좌 거래 내역서는 Chase 비즈니스 당좌 거래 내역서와 다른 테이블 구조를 가지며, 이는 지역 신용협동조합 거래 내역서와도 다릅니다. 형식 독립적 접근 방식은 부기 담당자가 열을 한 번만 정의하고 — "거래 날짜, 설명, 금액, 잔액" — 발행 은행에 관계없이 모든 고객의 거래 내역서에 동일한 열 정의를 사용한다는 의미입니다. 연간 전체에 걸친 일괄 조정에 이 방식이 어떻게 적용되는지 자세히 알아보려면 12개월 은행 거래 내역서를 하나의 스프레드시트로 일괄 처리에 대한 가이드를 참조하세요.

자주 묻는 질문

여러 페이지로 된 은행 거래 명세서도 처리되나요?

네. AI는 페이지 수와 관계없이 명세서를 하나의 연속된 거래 테이블로 읽습니다. 250건의 거래가 있는 12페이지 분량의 명세서도 단일 단위로 처리되며, 페이지 헤더, 반복되는 열 레이블, 이월 소계, 바닥글 텍스트는 자동으로 식별 및 필터링되어 Excel 출력을 오염시키지 않습니다. 행 순서는 원본 명세서에 표시된 그대로 페이지 간에 유지됩니다.

스캔하거나 촬영한 은행 명세서에서도 데이터를 추출할 수 있나요?

네. 시각-언어 모델은 디지털 PDF뿐만 아니라 이미지에서도 텍스트를 읽습니다. 평판 스캐너, 휴대폰 사진 또는 은행이 자체 스캔한 종이 명세서 등 스캔된 종이 명세서도 기본 PDF와 동일한 방식으로 처리됩니다. 이미지 품질이 중요하지만, 디지털 생성 및 텍스트 선택 가능한 PDF일 필요는 없습니다.

잔액 합계 열은 어떻게 처리되나요?

AI는 명세서에 표시된 대로 잔액 합계를 추출합니다. 그러나 인쇄된 잔액에 오류가 있거나 추출 과정에서 숫자를 잘못 읽을 수 있으므로, 추출된 출금 및 입금 금액에서 잔액 합계를 다시 계산하는 계산 열을 정의하는 것이 좋습니다. 계산된 잔액이 인쇄된 잔액과 일치하면 교차 검증이 완료됩니다. 차이가 발생하면 검토해야 할 행을 정확히 알 수 있습니다. 이를 통해 잔액 합계는 수동 추출 필드에서 능동적인 검증 메커니즘으로 전환됩니다.

레이아웃이 다른 여러 은행의 명세서에서도 작동하나요?

네. 이것이 형식 독립적 추출의 핵심 장점입니다. 체이스, 웰스파고, 바클레이즈, 지역 신용협동조합의 명세서는 모두 동일한 기본 구조를 공유합니다. AI는 열 순서, 글꼴, 간격 또는 페이지 레이아웃에 관계없이 해당 구조를 식별합니다. 모든 은행에서 동일한 열 이름을 사용합니다. 은행별 템플릿을 만들거나 유지 관리할 필요가 없습니다.

은행마다 차변과 대변을 다르게 표기하는 경우 어떻게 처리하나요?

일부 은행은 차변과 대변을 별도의 열로 구분하고 두 열 모두 양수로 표기합니다. 다른 은행은 단일 금액 열에 차변을 음수로 표기하기도 합니다. 또 다른 은행은 금액에 "Dr" 또는 "Cr" 접미사를 붙이기도 합니다. AI는 명세서에 존재하는 어떤 열 구조든 추출할 수 있으며, 필요에 따라 계산 열을 정의하여 값을 단일 부호 금액 열로 정규화할 수 있습니다. 이를 통해 각 은행의 명세서 형식과 관계없이 일관된 출력을 생성할 수 있습니다.

은행 명세서 거래 추출의 정확도는 어느 정도인가요?

인쇄된 은행 명세서 PDF로 글자가 선명한 경우 필드 수준 정확도는 최대 99%에 달합니다. 스캔하거나 촬영한 명세서의 경우 이미지 품질에 따라 정확도가 달라집니다. 깨끗한 300dpi 스캔은 유사한 결과에 근접하지만, 구겨진 종이 명세서를 저해상도 폰으로 촬영한 경우 정확도는 낮아집니다. 핵심 안전장치는 대사 확인입니다. 모든 은행 명세서에는 검증 가능한 기말 잔액이 있어 추출된 거래를 검증할 수 있으므로, 대사에 영향을 미칠 만한 추출 오류는 데이터가 회계 시스템에 입력되기 전에 잔액 검증 단계에서 발견됩니다.

결론

은행 명세서 추출은 대부분의 데이터 도구가 별도로 해결하는 두 가지 문제, 즉 정확한 문자 인식과 문서 구조 이해가 교차하는 지점에 있습니다. OCR만으로는 문자를 얻을 수 있지만 구조는 얻을 수 없습니다. 거래 행과 헤더 행을 구분할 수 없고, 누적 잔액과 거래 금액을 구분할 수 없으며, 1페이지의 표와 2페이지의 동일한 표의 연속을 구분할 수 없습니다. 템플릿 기반 파싱은 구조를 추가하지만 은행별 설정이 필요하고 레이아웃이 변경되면 취약해집니다.

비전-언어 모델을 통한 AI 추출은 이를 하나의 단계로 통합합니다. AI는 문서를 전체적으로 읽고 구조를 이해하며 요청한 내용을 추출합니다. 행 순서를 보존하고 구조적 노이즈를 필터링하며 데이터가 회계 시스템에 도달하기 전에 산술 검증을 가능하게 합니다. 출력은 "대략적으로 올바른 데이터가 대략적인 순서로" 있는 것이 아닙니다. 명세서의 기말 잔액과 일치하는 거래 원장입니다. 이것이 대사에 있어 유일하게 중요한 기준입니다. 직접 은행 명세서로 시도해 보세요.

지금 은행 명세서 추출하기 →

무료로 시작 — 신용카드 불필요