은행 명세서를 스캔하고 OCR 도구로 처리한 후 결과가 잘못되었습니다. 거래 금액이 열을 바꾸고, 상인 이름이 줄 중간에서 끊기고, 출금이 입금으로 읽혀집니다. 은행 명세서에 일반 OCR을 시도해본 적이 있다면, 이 답답함을 알 것입니다. 70% 오류율은 과장이 아닙니다.
문제는 OCR 자체가 아닙니다. 은행 명세서가 기계가 읽을 수 있도록 설계되지 않았다는 것입니다. 은행마다 다른 레이아웃을 사용하고, 스캔한 이미지는 품질 문제를 야기하며, 여러 줄의 거래는 일반 텍스트 페이지용으로 구축된 패턴 매칭 엔진을 혼동시킵니다. 여기서는 표준 OCR이 명세서에서 실패하는 이유, 사람들이 시도하는 해결책, 그리고 실제로 조정할 수 있는 신뢰할 수 있는 데이터를 얻는 방법을 설명합니다.
일반 OCR 도구가 대부분의 은행 명세서를 놓치는 이유
Tesseract 같은 일반 OCR 엔진이나 Adobe Acrobat의 내장 리더는 페이지를 스캔하고, 텍스트 블록을 식별하고, 문자열을 출력합니다. 이들은 타이핑된 편지나 고정 필드를 가진 양식에서는 잘 작동합니다. 은행 명세서는 이 모델을 세 가지 특정한 방식으로 깨뜨립니다.
첫째, 거래 테이블에는 고정된 열 너비가 없습니다. 한 상인 이름은 40자일 수 있고, 다음은 8자입니다. OCR은 텍스트 덩어리를 보고 한 필드가 끝나고 다음이 시작하는 지점을 추측합니다. 설명이 두 번째 줄로 이어질 때, 엔진은 종종 두 번째 줄을 별도의 거래로 취급하거나 잘못된 열에 추가합니다. 결국 날짜가 금액 필드에 있고 금액이 설명에 있게 됩니다.
둘째, 스캔하고 복사한 명세서는 노이즈를 야기합니다. 인쇄본의 복사본은 명암이 감소하고, 책상 위 명세서의 휴대폰 사진은 그림자와 원근 왜곡이 있습니다. OCR 신뢰도가 떨어지고, 엔진은 숫자 8을 3으로 읽기 시작하거나 희미한 텍스트를 완전히 건너뜁니다. 온라인 뱅킹의 디지털 PDF는 이를 피하지만, 명세서가 스캐너나 팩스를 거치는 순간 정확도는 급락합니다.
셋째, 모든 은행은 명세서 형식을 다르게 합니다. Chase는 날짜를 첫 번째 열에 배치하고, Bank of America는 거래 유형으로 시작할 수 있습니다. 하나는 DD/MM/YYYY를 사용하고, 다른 하나는 MM-DD-YY를 사용합니다. 일반 OCR은 은행 명세서가 무엇인지 전혀 모르므로 구조를 적용할 수 없습니다. 그저 읽기 순서대로 텍스트를 출력하고, 출력을 직접 파싱해야 합니다.
사람들이 시도하는 해결책 (그리고 왜 부족한가)
일반 OCR이 실패할 때, 본능은 프로세스를 수정하는 것입니다. 세 가지 해결책이 포럼과 지원 스레드에서 반복적으로 나타나며, 각각의 한계가 있습니다.
OCR 후 수동 재입력
일부 사람들은 OCR을 실행하고 70% 정확도를 얻은 다음 모든 오류를 수동으로 수정합니다. 이는 자동화의 목적을 무효화합니다. 금액 전치와 상인 이름 재입력에 30분을 보내면, 차라리 처음부터 데이터를 입력하는 것이 낫습니다. 시간 절약은 증발하고, 오류 기반선에 대해 교정하고 있으므로 새로운 오타를 도입할 위험이 증가합니다.
온라인 뱅킹에서 거래 데이터를 텍스트로 다운로드
가능할 때 온라인 뱅킹에 로그인하고 거래를 CSV 또는 OFX로 다운로드하면 OCR을 완전히 우회합니다. 이는 은행이 제공할 때 그리고 내보내기가 필요한 기간을 포함할 때 완벽하게 작동합니다. 문제는 많은 은행이 다운로드를 90일로 제한하고, 일부는 과거 데이터에 요금을 부과하며, 고객 명세서를 조정하거나 폐쇄된 계정을 다루는 경우 종종 PDF만 있다는 것입니다. 텍스트 다운로드에 의존하는 것은 이상적인 경로이지만 항상 가능한 것은 아닙니다.
여러 OCR 도구를 시도하고 최적의 결과 선택
같은 명세서를 세 가지 OCR 엔진으로 실행하고 출력을 비교하는 것이 철저해 보입니다. 실제로는 세 도구 모두 다른 방식으로 실패할 수 있습니다. 하나는 입출금을 바꾸고, 다른 하나는 날짜를 훼손하고, 세 번째는 절반의 거래를 놓칩니다. 여전히 줄 단위 검증이 필요하고, 이제 처리 시간이 3배가 되었습니다. 이 접근법도 근본적인 문제, 즉 이 도구 중 어느 것도 명세서 구조를 이해하지 못한다는 점을 해결하지 못합니다.
실제로 작동하는 것: 구조 인식 추출
신뢰할 수 있는 추출에는 은행 명세서가 무엇인지 아는 엔진이 필요합니다. 거래 테이블을 인식하고, 열 경계를 적용하고, 여러 줄의 설명을 처리하며, 추출된 데이터가 인쇄된 개시 잔액과 종료 잔액에 대해 조정되는지 검증해야 합니다. 일반 OCR은 모든 문서를 일반 텍스트로 취급하기 때문에 이를 수행할 수 없습니다. 금융 문서용으로 설계된 도구는 할 수 있습니다.
구조 인식 시스템은 다양한 기관의 실제 은행 명세서 수천 개에 대해 학습된 머신 러닝 모델을 사용합니다. 그들은 맨 왼쪽 열이 거의 항상 날짜이고, 금액이 오른쪽에 정렬되며, 날짜가 없는 줄은 아마 이전 거래의 연속이라는 것을 배웁니다. 스캔하거나 복사한 명세서를 만날 때, 그들은 이미지 전처리(기울어짐 제거, 명암 향상, 노이즈 감소)를 OCR 전에 적용하여 문자 인식 정확도를 크게 향상시킵니다.
더 중요하게는, 이들 도구는 출력을 검증합니다. 거래를 추출한 후, 시스템은 개시 잔액에서 실행 잔액을 계산하고 인쇄된 종료 잔액과 일치하는지 확인합니다. 일치하지 않으면 추출이 어딘가에서 실패한 것이고, 도구는 불일치를 표시합니다. 이 단일 검증 단계는 일반 OCR을 통과하는 바뀐 입출금, 놓친 거래, 오독된 금액을 포착합니다.
옵션 비교
PDF 은행 명세서에서 데이터가 필요할 때 일반적인 접근법이 어떻게 비교되는지 보겠습니다.
| 방법 | 스캔한 명세서의 정확도 | 여러 줄 거래 처리 | 잔액 검증 | 배치 처리 |
|---|---|---|---|---|
| 일반 OCR (Tesseract, Adobe) | 낮음 (수동 수정 없이 30-50%) | 아니오 | 아니오 | 파일당 수동 |
| 은행 CSV 다운로드 | 완벽함 (가능할 때) | 예 | 해당 없음 (소스 데이터) | 한 번에 하나의 명세서 |
| 수동 입력 | 높음 (하지만 시간 소모) | 예 | 직접 확인할 경우에만 | 아니오 |
| BankStmtConverter | 높음 (AI는 스캔한 것과 깔끔한 PDF 처리) | 예 | 예 (인쇄된 합계에 대해 자동 확인) | 예 (다중 파일 업로드) |
명세서가 깔끔한 디지털 PDF이고 선택 가능한 텍스트를 가지고 있으며 페이지가 몇 장뿐이면, Tabula 같은 무료 도구나 Adobe의 내보내기 기능으로 충분할 수 있습니다. 스캔한 이미지, 복사본 또는 수십 페이지보다 긴 명세서를 도입하는 순간, 문서 구조를 이해하는 것이 필요합니다.
전문 변환기를 사용해야 할 때
세 가지 시나리오는 일반 OCR이나 수동 방법보다 전문 도구를 실용적인 선택으로 만듭니다.
스캔하거나 사진으로 찍은 명세서가 있습니다. 고객이 복사본 명세서 묶음을 줄 때, 또는 감사 중 종이 명세서의 휴대폰 사진을 찍었을 때가 그렇습니다. 일반 OCR은 페이지의 암호화된 텍스트를 생성합니다. 이미지 전처리를 적용하고 명세서 레이아웃을 아는 변환기는 깔끔한 데이터를 추출합니다.
여러 명세서를 한 번에 배치 처리해야 합니다. 월말 5개 은행 계좌 조정은 10~15개의 명세서 파일을 의미합니다. 모두 한 번의 배치에 업로드하고 단일 통합 CSV 또는 명세서당 별도 파일을 다시 받으면 각각을 개별적으로 처리하는 것보다 몇 시간을 절약합니다.
추출된 데이터를 인쇄된 합계에 대해 조정해야 합니다. 개시 잔액이 $4,832.15이고 종료 잔액이 $6,201.48이면, 추출된 거래가 실행 합계를 계산할 때 정확히 그 종료 수치를 생산해야 합니다. 수동 현장 점검은 명백한 오류를 포착하고, 자동 잔액 검증은 모든 것을 포착합니다. 명세서에서 시도해보십시오 그리고 도구가 데이터가 조정되는지 미리 알려줄 때 차이를 보세요.
개인정보 보호 및 로컬 처리
웹 서비스에 은행 명세서를 업로드하는 것은 명백한 질문을 제기합니다. 파일은 어디로 가는가? 고객을 위해 명세서를 변환하거나 민감한 계좌를 다루는 경우, 데이터가 다른 사람의 서버에 무기한 앉아 있거나 다음 버전의 도구 학습에 사용되지 않는다는 확신이 필요합니다.
BankStmtConverter는 처리 후 업로드된 파일을 삭제합니다. 추출이 일어나고, 출력을 다운로드하고, PDF는 서버에서 제거됩니다. 더 높은 민감도의 워크플로우를 위해, 데스크톱 버전은 명세서를 전적으로 로컬 머신에서 처리합니다. 파일은 컴퓨터를 떠나지 않으므로 업로드 위험을 제거하고 반복되는 구독 없이 일회성 구매를 제공합니다. 이 옵션은 클라이언트 데이터를 클라우드에서 위험에 빠뜨릴 수 없는 회계사와 부기 담당자에게 맞습니다.
회계 준비 완료된 출력 형식
거래 추출은 첫 번째 단계입니다. 두 번째 단계는 그 데이터를 재입력 없이 회계 소프트웨어로 얻는 것입니다. CSV는 Excel에서 작동하지만, QuickBooks와 Xero는 그들의 가져오기 워크플로우에 직접 매핑되는 QBO 또는 OFX 파일을 선호합니다. 좋은 변환기는 모두 세 가지를 출력하므로, Excel에서 조정한 후 같은 데이터를 한 번의 클릭으로 회계 시스템에 가져올 수 있습니다.
CSV에는 표준 열이 포함되어야 합니다. 날짜, 설명, 출금, 입금, 잔액. 일부 도구는 거래 유형 열 또는 계정 차트 코드에 매핑할 수 있는 범주 필드를 추가합니다. 출력이 구조화될수록, 가져온 후 정리할 작업이 줄어듭니다. 도구가 기관별 템플릿을 요구하지 않고 모든 은행과 레이아웃을 처리하는지 확인하십시오. 지원되는 은행을 여기서 보십시오 - 추출 엔진은 고정 템플릿이 아닌 구조를 배우기 때문에 목록에는 수백 개의 기관이 포함됩니다.
단계별: 스캔한 명세서 변환
스캔하거나 복사한 명세서가 있고 신뢰할 수 있는 데이터가 필요할 때의 워크플로우는 다음과 같습니다.
- 스캔한 명세서를 PDF로 저장하십시오. 종이 명세서 묶음이 있으면 모두 하나의 다중 페이지 PDF로 스캔하거나 명세서당 별도 PDF로 스캔하십시오.
- 파일을 구조 인식 변환기에 업로드하십시오. 여러 명세서를 처리하는 경우, 시간을 절약하기 위해 모두 한 번에 업로드하십시오.
- 추출을 기다리십시오. 도구는 전처리를 통해 OCR을 실행하고, 거래 테이블을 식별하고, 각 행을 날짜, 설명, 출금, 입금, 잔액 열로 파싱합니다.
- 출력을 다운로드하십시오. Excel은 CSV를 선택하고, QuickBooks는 QBO를 선택하고, 다른 회계 소프트웨어는 OFX를 선택하십시오. 파일은 모든 거래가 올바른 열에 있는 깨끗하게 열려야 합니다.
- 종료 잔액을 확인하십시오. CSV를 Excel에서 열고 개시 잔액에서 출금과 입금의 합계를 계산하십시오. 계산된 종료 잔액이 인쇄된 명세서와 일치하면, 추출이 성공했습니다. 그렇지 않으면 누락되거나 중복된 거래를 확인하십시오.
회계 소프트웨어에서 데이터를 조정하는 경우, QBO 또는 OFX 파일을 가져오고 거래를 은행 피드 또는 수동 항목과 일치시키십시오. 변환기의 잔액 검증 단계는 가져온 후가 아니라 이미 거래를 원장에 게시한 후에 오류를 포착하지 않습니다.
대부분의 도구를 무너뜨리는 엣지 케이스
전문 변환기도 한계에 도달합니다. 세 가지 엣지 케이스가 가장 많은 문제를 일으킵니다.
필기 메모나 스탬프가 있는 명세서. 스캔한 명세서에