은행 거래 내역서 형식 이해하기: 기술 가이드

은행 거래 내역서 PDF는 간단해 보입니다. 날짜, 설명, 금액, 잔액이 깔끔한 열로 정렬되어 있습니다. 하지만 그 외관 뒤에는 구조화된 데이터를 저장하도록 설계되지 않은 문서 형식(PDF)과 입력 형식 및 사용 가능한 다양한 출력 형식을 모두 이해해야 하는 변환 프로세스가 있습니다.

이 가이드에서는 모든 은행 거래 내역서에 나타나는 12가지 섹션(은행에 관계없이), 은행 거래 내역서 PDF의 기술적 현실, 은행별 레이아웃 변형, 접하게 될 모든 출력 형식(Excel, CSV, QBO, OFX, QFX, QIF, JSON), 국제 형식 차이점 및 금융 데이터 교환을 관리하는 산업 표준에 대해 다룹니다.

은행 거래 내역서의 구조

Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank 등 어떤 은행이든 모든 은행 거래 내역서는 동일한 12가지 섹션으로 구성됩니다. 레이블은 변경될 수 있습니다("Subtractions" 대 "Withdrawals"). 열 배열은 다양하지만 기본 구조는 일관됩니다. 이러한 섹션을 식별할 수 있게 되면 모든 거래 내역서가 익숙하게 보일 것입니다.

이 인포그래픽을 블로그에 사용하고 싶으신가요? 다음 임베드 코드를 복사하세요:

주요 은행별로 이러한 12가지 섹션을 정확히 어떻게 배열하는지 다루는 은행별 심층 분석은 다음을 참조하세요:

• Chase 은행 거래 내역서 설명
• Bank of America 은행 거래 내역서 설명
• Wells Fargo 은행 거래 내역서 설명
• Citi 은행 거래 내역서 설명
• Capital One 은행 거래 내역서 설명

PDF가 데이터 형식이 아닌 이유

PDF는 Portable Document Format의 약자로, ISO 32000(버전 2.0은 ISO 32000-2:2020)으로 표준화되었습니다. 이 형식은 모든 화면과 프린터에서 문서가 동일하게 보이도록 하는 단 하나의 목적을 위해 설계되었습니다. 이는 시각적 충실도에는 훌륭하지만 데이터 추출에는 끔찍합니다.

은행 거래 내역서 PDF 내부에 실제로 있는 것

모든 PDF 페이지 내부에는 콘텐츠 스트림이 있습니다. 이는 PostScript와 유사한 언어로 작성된 그리기 연산자 시퀀스입니다. 텍스트는 특정 연산자를 사용하여 렌더링됩니다:

• BT / ET - 텍스트 시작 / 텍스트 끝: 텍스트 객체의 경계
• Tf - 글꼴 및 크기 설정
• Td / Tm - 텍스트 위치 이동 또는 전체 텍스트 변환 행렬 설정
• Tj - 텍스트 문자열 표시
• TJ - 개별 글리프 위치 지정(커닝 조정)으로 텍스트 표시

핵심 통찰: PDF 사양에는 "테이블", "행" 또는 "열"이라는 개념이 없습니다. 깔끔하게 형식화된 거래 테이블처럼 보이는 것은 실제로 페이지의 특정 x,y 좌표에 배치된 수십 개의 텍스트 조각입니다. 추출 도구는 다음을 수행해야 합니다:

1. 콘텐츠 스트림 연산자 구문 분석
2. 글리프 인덱스를 유니코드 문자에 매핑하기 위해 글꼴 인코딩 확인
3. 텍스트 행렬(Tm/Td)을 사용하여 모든 문자의 x,y 위치 결정
4. 해당 좌표에서 단어, 줄, 열 재구성

완벽하게 정렬된 것처럼 보이는 열은 한 줄에서는 x=72.0이고 다음 줄에서는 x=72.5일 수 있습니다. 추출 알고리즘은 이러한 서브픽셀 변형에 대한 허용 오차를 사용하여 열 경계를 정의해야 합니다.

태그가 지정된 PDF 대 태그가 없는 PDF

태그가 지정된 PDF에는 콘텐츠를 제목, 단락, 테이블, 테이블 행 및 테이블 셀로 표시하는 숨겨진 논리 구조 트리가 포함됩니다(HTML 태그와 유사). 이렇게 하면 추출이 훨씬 쉬워집니다.

태그가 없는 PDF에는 구조 메타데이터가 없습니다. 추출 도구는 원시 위치 데이터만 받으며 모든 것을 추론해야 합니다.

대부분의 은행 생성 거래 내역서 PDF는 태그가 없습니다. 은행은 배치 처리 시스템(Oracle BI Publisher, SAP Crystal Reports 또는 사용자 지정 인쇄-PDF 파이프라인)을 사용하여 거래 내역서를 생성합니다. 접근성 규정(ADA/WCAG)은 은행이 태그가 지정된 PDF를 사용하도록 추진하고 있지만 채택은 느립니다. 대부분의 주요 은행에서 표준 다운로드는 태그가 없는 상태로 유지됩니다.

은행 거래 내역서 레이아웃 변형

은행이 PDF 거래 내역서를 형식화하는 방법에 대한 산업 표준은 없습니다. 날짜, 설명, 차변, 대변, 잔액이라는 동일한 5가지 정보가 은행마다 다르게 배열됩니다.

단일 금액 열(부호 포함)

날짜 설명 금액 잔액
01/15/26 직접 입금 급여 +3,500.00 5,200.00
01/16/26 POS 구매 식료품 -87.50 5,112.50

차변은 음수, 대변은 양수입니다(또는 그 반대). 소규모 은행, 신용 조합 및 디지털 은행에서 흔히 사용됩니다. 추출할 금액 열이 하나뿐이므로 구문 분석이 더 간단합니다.

별도의 차변/대변 열

날짜 설명 인출 입금 잔액
01/15/26 직접 입금 급여 3,500.00 5,200.00
01/16/26 POS 구매 식료품 87.50 5,112.50

Chase, Bank of America 및 많은 전통적인 은행에서 사용됩니다. 추출 도구는 금액이 포함된 열을 식별하고 그에 따라 부호를 결정해야 합니다.

거래 유형별 그룹화

비즈니스 및 기업 계좌는 종종 거래를 그룹화합니다:

입금 및 기타 대변 01/15  와이어 송금 입금 REF#12345 10,000.00 01/18  수표 입금 #4567 2,500.00 총 입금 12,500.00
 
지급된 수표 01/16  수표 #1234 850.00 01/17  수표 #1235 1,200.00 총 지급 수표 2,050.00
 
전자 거래 01/19  ACH 결제 - 공급업체 법인 3,200.00 01/20  저축 계좌 온라인 이체 1,000.00 총 전자 거래 4,200.00

섹션 헤더는 거래가 차변인지 대변인지 결정합니다. 요약 줄("총 입금")은 식별하여 거래 데이터에서 제외해야 합니다.

은행별 특성

• Chase - 별도의 차변/대변 열; "입금 및 추가", "전자 결제", "수수료"별 그룹화; 판매자 세부 정보에 대한 여러 줄 설명 일반적
• Bank of America - 별도의 인출/입금 열; "일별 잔액" 섹션 포함; 계좌 번호, 거래 내역서 기간, 라우팅 번호가 포함된 광범위한 헤더
• Wells Fargo - 별도의 열; "일별 잔액 요약" 섹션 포함; CSV 다운로드를 "쉼표로 구분된"이라고 함
• Capital One - 소비자 카드에 대한 깔끔한 단일 금액 레이아웃; 최소한의 헤더 정보
• Citi - 종종 별도 줄에 원화 금액 및 환율이 포함된 국제 거래 세부 정보 포함

열 배열 변형

차변/대변 문제 외에도 열 순서는 표준화되지 않았습니다:

• 열 순서: 날짜-설명-금액-잔액 대 날짜-금액-설명-잔액
• 수표 번호: 기업 계좌에 존재, 개인 계좌에 없음
• 참조 번호: 기업 거래 내역서에 일반적, 개인 거래 내역서에 드묾
• 실행 잔액: 거래별(가장 일반적) 대 일별 소계 대 없음

디지털 PDF 대 스캔 PDF

변환 정확도에 가장 중요한 요인은 PDF가 디지털인지 스캔인지 여부입니다.

디지털(네이티브) PDF

거래 내역서를 다운로드할 때 은행 시스템에서 프로그래밍 방식으로 생성됩니다. 텍스트는 글꼴 인코딩이 있는 콘텐츠 스트림 연산자로 저장됩니다.

• 정확도: 텍스트 추출 시 99% 이상 - 인식 오류 없음
• 속도: 페이지당 밀리초
• 개인 정보 보호: 브라우저에서 완전히 처리 가능 - 파일이 장치를 떠나지 않음
• 파일 크기: 페이지당 일반적으로 50KB–500KB
• 식별 방법: 개별 단어를 선택하고 강조 표시할 수 있음

스캔된 PDF

종이 거래 내역서의 이미지 - 물리적 문서를 스캔하거나 사진 촬영하여 생성됩니다. 콘텐츠는 래스터화된 이미지(JPEG, JPEG2000, CCITT 또는 Flate 압축)로 저장됩니다.

• 정확도: 전문 OCR으로 95–99%, 일반 OCR로 65–70%
• 속도: 페이지당 초(이미지 처리 필요)
• 개인 정보 보호: 일반적으로 서버 측 처리 필요(OCR을 위해 파일을 업로드해야 함)
• 파일 크기: 페이지당 200KB–2MB 이상
• 식별 방법: 텍스트를 선택할 수 없음; 400%로 확대하면 픽셀화 보임

스캔 정확도가 금융 데이터에 더 중요한 이유

97%의 문자 정확도율은 훌륭해 보이지만 금융 데이터에 적용하면 그렇지 않습니다. 1,000자의 금액이 있는 거래 내역서에서 30자의 문자가 잘못 읽힙니다. 단 하나의 잘못 읽힌 숫자는 거래 금액을 변경합니다. "$1,234.56"이 "$1,234.86" 또는 "$7,234.56"이 됩니다. 고급 OCR은 거의 99%의 정확도를 달성하지만 남은 오류는 0/O, 1/l/I, 5/S, 8/B, 6/G와 같이 유사하게 보이는 문자와 결정적으로 쉼표/마침표에 불균형적으로 발생합니다.

항상 디지털 다운로드를 선호하십시오. 종이를 스캔하는 대신 은행 웹사이트에서 거래 내역서를 다운로드하십시오. 이렇게 하면 OCR 오류가 완전히 제거됩니다.

출력 형식: 심층 분석

은행 거래 내역서를 변환할 때 출력 형식을 선택합니다. 각 형식에는 다른 강점, 제한 사항 및 이상적인 사용 사례가 있습니다.

Excel (.xlsx)

표준: Office Open XML(OOXML), ECMA-376 및 ISO/IEC 29500으로 표준화됨.

무엇인가: .xlsx 파일은 실제로 워크북 구조, 셀 데이터, 스타일 및 공유 문자열을 포함하는 ZIP 아카이브입니다. 이것이 데이터 유형(날짜를 날짜로, 숫자를 숫자로), 서식, 수식 및 여러 시트를 저장할 수 있는 이유입니다.

은행 거래 내역서에서 인기 있는 이유:

• 날짜는 날짜로 유지됨(정렬 가능, 필터링 가능)
• 숫자는 숫자로 유지됨(합산 가능, 서식 지정 가능)
• 조정용 수식(SUM, VLOOKUP)
• 지출 분류를 위한 피벗 테이블
• 불일치를 강조 표시하기 위한 조건부 서식
• 읽기 쉬운 스프레드시트가 필요한 클라이언트와 공유

제한 사항:

• 최대 1,048,576개 행(은행 거래 내역서에는 거의 관련 없음)
• 대부분의 회계 소프트웨어에 직접 가져올 수 없음(대신 QBO/OFX 사용)
• 열려면 Excel, Google Sheets 또는 LibreOffice Calc 필요

최적: 수동 검토, 사용자 지정 분석, 조정, 보관, 클라이언트 보고.

CSV (쉼표로 구분된 값)

표준: RFC 4180(2005) - "쉼표로 구분된 값에 대한 일반 형식 및 MIME 유형."

핵심 규칙:

• 레코드는 CRLF(캐리지 리턴 + 줄 바꿈)로 구분됨
• 필드는 쉼표로 구분됨
• 쉼표, 따옴표 또는 줄 바꿈이 포함된 필드는 큰따옴표로 묶어야 함
• 필드 내의 큰따옴표는 두 번 묶어 이스케이프 처리

실제 구분 기호 변형:

• 쉼표 (,) - 표준, 미국/영국에서 사용
• 세미콜론 (;) - 쉼표가 소수 구분 기호인 국가(프랑스, 독일, 이탈리아, 스페인, 브라질)에서 사용
• 탭 (\t) - TSV 형식, 구분 기호 충돌 방지

인코딩 문제:

• 상호 운용성을 위해 UTF-8 권장
• UTF-8 BOM (바이트 순서 표시): 표준에서 요구하지 않지만 Windows의 Excel은 ASCII가 아닌 문자(악센트 기호, 통화 기호)를 올바르게 표시하려면 필요합니다. BOM이 없으면 Excel은 UTF-8을 Windows-1252로 해석하여 문자를 손상시킬 수 있습니다.
• Excel은 유럽 로케일에서 필드 구분 기호로 쉼표 대신 세미콜론을 사용합니다.

제한 사항:

• 데이터 유형 없음 - 모든 것이 텍스트임(앞에 0이 있는 숫자는 손상됨, 긴 계좌 번호는 과학적 표기법이 됨)
• 여러 시트 지원 없음
• 서식 또는 수식 없음
• 메타데이터 없음(계좌 정보 없음, 중복 감지 ID 없음)

최적: 최대 호환성 - 거의 모든 회계 프로그램, 데이터베이스 및 스프레드시트에서 CSV를 가져올 수 있습니다. QBO/OFX를 사용할 수 없을 때의 보편적인 대체 수단입니다.

QBO (QuickBooks Web Connect)

무엇인가: QuickBooks(데스크톱 및 온라인 모두)의 가져오기 형식입니다. QBO 파일은 QuickBooks별 확장이 있는 OFX 사양을 기반으로 합니다.

중요 설명: ".QBO"는 "QuickBooks Online"을 의미하지 않습니다. QuickBooks Web Connect 형식을 나타내며 QuickBooks 데스크톱 및 QuickBooks 온라인 모두와 함께 작동합니다.

거래당 필수 필드:

• TRNTYPE - 거래 유형(DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED - YYYYMMDD 형식의 날짜
• TRNAMT - 금액(차변은 음수)
• FITID - 금융 기관 거래 ID
• NAME - 수취인/설명

FITID가 중요한 이유: QuickBooks는 각 계정에 대해 가져온 모든 FITID를 추적합니다. 동일한 FITID가 있는 거래가 다시 가져와지면 QuickBooks는 이를 조용히 건너뜁니다. 사용자가 겹치는 거래 내역서 기간을 다시 가져올 때 중복 항목을 방지합니다. 이 자동 중복 감지는 QBO가 CSV보다 갖는 가장 큰 장점입니다.

추가 데이터: QBO는 계좌 ID, 은행 ID(라우팅 번호), 통화, 수표 번호, 메모 및 최종 잔액도 전달합니다. 이는 모든 가져오기 형식 중에서 QuickBooks에 가장 풍부한 데이터 세트입니다.

최적: QuickBooks 사용자(데스크톱 및 온라인). 자동 중복 감지 및 거래 유형 분류를 통해 가장 풍부한 가져오기 환경을 제공합니다.

OFX (Open Financial Exchange)

역사: Microsoft, Intuit 및 CheckFree에서 제작. 1997년 2월에 버전 1.0 출시.

버전 진화:

• OFX 1.0–1.6 (1997–1999): SGML 기반 구문(닫는 태그 불필요)
• OFX 2.0+ (2000–현재): XML 기반(올바른 닫는 태그, 잘 구성된 XML)

많은 은행이 최대 호환성을 위해 여전히 OFX 1.x(SGML)를 생성합니다.

현재 거버넌스: 2019년에 OFX 컨소시엄은 Financial Data Exchange(FDX) 컨소시엄으로 통합되었으며, 현재 사양을 관리합니다. FDX는 200개 이상의 회원사와 7,600만 개의 소비자 계좌를 보유하고 있습니다.

OFX가 보편적인 표준인 이유: OFX는 은행 계좌를 은행 피드를 통해 회계 소프트웨어에 직접 연결할 때 사용되는 형식과 동일합니다. 파일 가져오기에도 동일한 형식이 작동합니다.

Xero 사용자에게 최적: Xero는 수동 열 매핑 없이 OFX 파일을 자동으로 가져옵니다. 파일을 업로드하면 올바른 날짜, 금액 및 설명과 함께 거래가 즉시 표시됩니다. Wave, Sage, FreshBooks 및 대부분의 회계 소프트웨어에서도 작동합니다.

QFX (Quicken Financial Exchange)

무엇인가: Quicken 전용으로 사용되는 Intuit의 OFX 독점 변형입니다. QFX 파일은 추가 독점 필드가 있는 표준 OFX 파일입니다.

주요 독점 필드: INTU.BID - Quicken 은행 식별자. 이 숫자 ID는 Quicken의 내부 데이터베이스에 있는 은행에 매핑됩니다. 이 필드가 없으면 Quicken은 파일을 가져오는 것을 거부합니다.

표준 OFX와의 차이점:

• 헤더에 INTU.BID 필요
• 기타 INTU.* 접두사 필드 포함 가능
• 금융 기관은 QFX 다운로드를 제공하기 위해 Intuit에 라이선스 수수료를 지불합니다.
• Quicken은 INTU.BID 필드가 없는 표준 OFX 파일을 가져오지 않습니다.

최적: Quicken 개인 금융 소프트웨어 사용자. 필수 형식 - 다른 대안은 작동하지 않습니다.

QIF (Quicken Interchange Format)

무엇인가: Quicken을 위해 Intuit에서 개발한 레거시 일반 텍스트 형식입니다. 태그-값 쌍, 한 줄에 하나씩, 단일 문자 태그 사용: D는 날짜, T는 금액, P는 수취인, L은 범주, M은 메모, N은 수표 번호, ^는 레코드 끝.

교체된 이유: QIF는 중복 감지 메커니즘(FITID와 유사한 것 없음), 계좌 식별 필드 없음, 은행 라우팅 정보 없음, 잔액 데이터 없음, 구현 간 일관되지 않은 날짜 형식을 누락했습니다.

여전히 관련성 있음: 일부 회계 소프트웨어(Xero, Sage, GnuCash)는 여전히 QIF 가져오기를 수락합니다. 레거시 시스템 마이그레이션에 유용합니다.

JSON (JavaScript Object Notation)

현재 상태: JSON은 아직 은행 거래 내역서 파일의 표준은 아니지만 점점 더 많이 사용되고 있습니다:

• 오픈 뱅킹 API (영국 오픈 뱅킹 표준, PSD2 베를린 그룹)
• FDX API (Financial Data Exchange - OFX의 후속, 200개 이상의 회원사)
• Plaid, Yodlee, MX 및 기타 데이터 집계기 API
• 개발자 및 자동화 워크플로

채택 증가: 오픈 뱅킹 규정(유럽의 PSD2, 미국의 CFPB 1033조)은 JSON API 채택을 가속화하고 있습니다. FDX API는 JSON/REST와 OAuth 2.0을 사용하며 금융 데이터 교환의 미래 방향을 나타냅니다.

최적: 자동화된 워크플로, 핀테크 통합, 사용자 지정 대시보드 및 오픈 뱅킹 API 통합을 구축하는 개발자.

형식 비교 한눈에 보기

회계 소프트웨어 호환성

귀하의 회계 소프트웨어는 어떤 형식을 지원합니까?

일반 규칙: 소프트웨어가 지원하는 경우 CSV보다 QBO/OFX를 사용하십시오. FITID를 통한 중복 감지 기능만으로도 몇 시간의 정리 작업이 절약됩니다.

국제 형식 차이

해외 은행 거래 내역서를 다루는 경우 대부분의 변환 도구를 방해하는 형식 차이를 접하게 될 것입니다.

날짜 형식

모호성 문제: "03/04/2026"은 미국에서는 3월 4일이지만 유럽에서는 4월 3일입니다. 거래 내역서의 모든 날짜에 일(day) 값이 12 이하인 경우, 출신 국가를 알지 못하면 올바른 형식을 결정할 알고리즘적 방법이 없습니다. 변환 도구는 거래 내역서의 모든 날짜를 스캔하여 12보다 큰 값을 찾아 형식을 결정해야 합니다.

숫자 형식

유럽 은행의 "10.000,45"는 10.00045가 아니라 만 사십오 센트를 의미합니다. 이를 잘못 처리하면 10,000배의 오류가 발생합니다.

통화 기호 배치

• 미국/영국: 금액 앞 기호: $1,234.56 / £1,234.56
• 프랑스, 독일, 스페인: 금액 뒤 기호: 1.234,56 €
• 아일랜드, 네덜란드: 금액 앞 기호: €1,234.56
• 일본: 금액 앞 기호: ¥123,456

문자 인코딩

• UTF-8 - 보편적 표준, 모든 스크립트 지원
• GBK/GB2312 - 간체 중국어(중국 은행에서 사용)
• Shift_JIS - 일본어(일본 은행에서 사용)
• Big5 - 번체 중국어(대만, 홍콩)
• EUC-KR - 한국어
• ISO 8859-1 - 서유럽
• Windows-1252 - 서유럽(레거시)
• Windows-1256 - 아랍어

올바른 인코딩 감지 없이 미국 시스템에서 중국 또는 일본 은행 거래 내역서를 열면 문자가 깨집니다. PDFSub는 130개 이상의 언어를 지원하며 날짜 형식, 숫자 형식 및 문자 인코딩을 자동으로 감지합니다. 여기에는 오른쪽에서 왼쪽으로 쓰는 아랍어 및 히브리어, CJK 문자 및 모든 유럽 문자 세트가 포함됩니다.

일반적인 은행 거래 내역서 요소

거래 날짜 대 처리 날짜 대 가치 날짜

은행 거래 내역서에는 단일 거래에 대해 여러 날짜가 포함될 수 있습니다:

• 거래 날짜 - 구매 또는 이체가 실제로 발생한 날짜
• 처리 날짜 - 은행이 처리하고 기록한 날짜(신용 카드 구매의 경우 일반적으로 1-3 영업일 후)
• 가치 날짜 - 자금이 실제로 사용 가능하게 된 날짜(이자 계산에 영향을 미침, 국제 은행에서 일반적)

대부분의 소비자 거래 내역서는 처리 날짜만 표시합니다. 기업 거래 내역서는 종종 거래 날짜와 처리 날짜를 모두 포함합니다.

차변/대변 표시

은행은 차변과 대변을 다르게 표시합니다:

• 부호 있는 금액: 차변은 -87.50, 대변은 +3,500.00
• 별도 열: "인출" 및 "입금"
• 약어: 차변은 "DR", 대변은 "CR"(영국/영연방에서 일반적)
• 괄호: 차변은 (87.50)(회계 관례)

실행 잔액

• 거래별 잔액 - 모든 거래 후 업데이트됨(미국 소비자 거래 내역서에서 가장 일반적)
• 일별 잔액만 - 각 일의 끝에 표시되는 잔액(기업 거래 내역서에서 일반적)
• 실행 잔액 없음 - 시작 및 종료 잔액만(일부 국제 거래 내역서)

실행 잔액은 검증에 유용합니다. 각 거래가 다음 줄로 잔액을 올바르게 이동하는지 확인할 수 있습니다.

표준 헤더 정보

대부분의 은행 거래 내역서에는 다음이 포함됩니다: 계좌 소유자 이름, 계좌 번호(종종 부분적으로 마스킹됨), 거래 내역서 기간, 시작 및 종료 잔액, 총 입금 및 인출, 은행 라우팅/정렬 코드/SWIFT BIC.

비밀번호 보호

은행이 PDF를 암호화하는 방법

은행은 일반적으로 AES-128 또는 AES-256 암호화를 사용합니다. 두 가지 보호 모드가 있습니다:

• 사용자 비밀번호(열기 비밀번호): 파일을 열려면 필요
• 소유자 비밀번호(권한 비밀번호): PDF는 열리지만 편집/복사가 제한될 수 있음

일반적인 비밀번호 패턴

기타 일반적인 패턴에는 계좌 번호의 마지막 4자리, 고객 ID 또는 회원 번호가 포함됩니다. 은행은 일반적으로 전자 거래 내역서 기능을 처음 활성화할 때 비밀번호 패턴을 알려줍니다.

여러 페이지 거래 내역서의 과제

긴 거래 내역서(수백 건의 거래가 있는 기업 계좌)는 여러 가지 추출 과제를 야기합니다:

분할 거래

거래 설명이 한 페이지 하단에서 시작하여 다음 페이지 상단으로 이어질 수 있습니다. 변환기는 연속 줄을 감지하고 이를 단일 거래로 병합해야 합니다.

반복되는 헤더 및 바닥글

대부분의 은행은 모든 페이지에 열 헤더를 반복하며, 페이지 번호, 법적 고지 사항 및 마케팅 텍스트도 포함됩니다. 이러한 항목은 식별하여 거래 데이터에서 제외해야 합니다.

연속 줄

많은 거래에는 여러 줄의 설명이 있습니다:

01/15  ACH 전자 차변 공급업체 법인 $3,200.00  $2,000.00 REF#123456789 송장 2026-001 공급업체 법인 미수금 계정

2행과 3행은 1행 거래에 속하는 연속 줄입니다. 일반적으로 날짜와 금액이 없으며 설명 열과 동일한 x 좌표에 들여쓰기되어 나타납니다.

잔액 이월

일부 은행은 연속 페이지 상단에 "잔액 이월" 또는 "이월 잔액" 줄을 포함합니다. 이는 정보 제공용이며 거래가 아니므로 추출된 데이터에서 제외해야 합니다.

일반적인 거래 약어

은행 거래 내역서에는 기관마다 다른 약어가 사용됩니다:

알아야 할 산업 표준

이러한 형식은 기업 은행 및 재무 관리에서 사용됩니다. 직접 접할 일은 거의 없지만, 이 형식을 이해하면 은행 거래 내역서가 작동하는 방식을 설명해 줍니다.

BAI2 (Bank Administration Institute)

ERP 시스템(SAP, Oracle)에서 자동 현금 관리 및 은행 조정에 사용됩니다. 고정 너비 ASCII 형식으로 거래 유형 코드(예: 165 = 사전 승인 ACH 신용, 455 = ACH 차변, 495 = 와이어 송금 출금)가 있습니다. 1987년에 처음 출시되었으며 현재 ASC X9에서 관리합니다.

SWIFT MT940 / MT942

전 세계 은행에서 기업 고객 및 재무 부서에서 사용하는 마감일(MT940) 및 일중(MT942) 은행 거래 내역서입니다. SWIFT는 하루에 약 4,500만 건의 메시지를 처리합니다. 콜론으로 구분된 필드 식별자가 있는 태그 기반 형식입니다.

ISO 20022 (camt.053)

MT940을 대체하는 최신 XML 기반 형식입니다. ISO 20022 보편적 금융 메시징 표준의 일부입니다. MT940보다 풍부한 데이터, 필드 길이 제한 없음, XSD 유효성 검사가 포함된 기계 구문 분석 가능한 XML입니다. SWIFT는 MT 메시지에서 ISO 20022로 전환하고 있습니다. SEPA(단일 유로 결제 지역)는 유럽 결제에 대한 camt 형식을 의무화합니다.

NACHA ACH

미국에서 자동 청산소(ACH) 거래를 위한 파일 형식입니다. 고정 너비 ASCII, 줄당 정확히 94자입니다. ACH는 미국에서 연간 약 300억 건의 거래를 처리합니다. 은행 거래 내역서에 "ACH CREDIT" 또는 "ACH DEBIT"가 표시될 때, 기본 거래는 은행 간에 NACHA 형식으로 전송되었습니다.

워크플로에 맞는 올바른 형식 선택하기

결정 가이드

QBO를 사용하는 경우: QuickBooks(데스크톱 또는 온라인)를 사용하는 경우. 거래 유형 분류, FITID를 통한 중복 감지 및 가장 풍부한 가져오기 메타데이터를 얻을 수 있습니다.

OFX를 사용하는 경우: Xero, Sage, Wave 또는 기타 OFX 호환 소프트웨어를 사용하는 경우. Xero는 수동 열 구성 없이 필드를 자동으로 매핑합니다.

QFX를 사용하는 경우: Quicken을 사용하는 경우. Quicken이 지원하는 유일한 형식입니다.

Excel을 사용하는 경우: 가져오기 전에 데이터를 검토, 분석 또는 조작해야 하는 경우. 피벗 테이블을 만들거나, 수식을 실행하거나, 보고서를 준비합니다.

CSV를 사용하는 경우: 위에 나열되지 않은 소프트웨어를 사용하거나 최대 시스템 호환성이 필요한 경우. 열을 수동으로 매핑할 준비를 하십시오.

JSON을 사용하는 경우: 자동화된 워크플로, API 통합 또는 사용자 지정 보고 시스템을 구축하는 경우.

전문가 팁

• 소프트웨어에서 지원하는 경우 CSV보다 항상 QBO/OFX를 사용하십시오. FITID를 통한 중복 감지 기능만으로도 수동 정리 시간을 절약할 수 있습니다.
• 변환된 파일과 함께 원본 PDF를 보관하십시오. 감사 추적 및 원본 문서입니다.
• 모든 가져오기 후 확인하십시오. 시작/종료 잔액 및 몇 가지 무작위 거래를 샘플링하여 확인하십시오.
• 소프트웨어에 맞는 형식 일치 - 회계 플랫폼의 네이티브 형식을 사용하면 수동 열 매핑을 피하고 자동 기능을 사용할 수 있습니다.

무료 체험

첫 거래 내역서 변환을 시작할 준비가 되셨나요? 지금 PDF 업로드 - PDFSub는 Excel, CSV, QBO, OFX, QFX 및 JSON으로 변환합니다. 디지털 거래 내역서는 최대 개인 정보 보호를 위해 브라우저에서 완전히 처리됩니다. 모든 형식에 대한 전체 액세스 권한으로 7일 무료 평가판을 시작하십시오.