세무사무소 은행 거래내역 PDF 일괄 엑셀 변환

세무사무소나 회계사무소에서 여러 고객의 은행 거래내역을 받으면 “PDF를 Excel로 바꾸는 작업”보다 더 큰 문제가 생깁니다. 고객, 법인, 계좌, 은행, 통화, 월이 섞인 상태에서 한 파일을 잘못 선택하거나 원본을 찾지 못하면 변환 속도가 빨라도 결산 업무가 정확해지는 것은 아닙니다.

세무사무소 은행 거래내역 PDF 일괄 엑셀 변환의 핵심은 최대한 많이 한꺼번에 넣는 것이 아닙니다. 고객 또는 법인별로 작업 묶음(로트)을 분리하고, 추적 가능한 파일명을 사용하고, 각 결과를 원본에 대조한 뒤, 분석 목적이면 병합하고 회계 업로드 목적이면 필요한 형식으로 나누는 것입니다.

2026년 8월 현재 업로드 화면의 한 작업 묶음은 최대 15개 파일, 전체 100페이지, 파일당 50MB까지 처리할 수 있습니다. 병합 출력은 XLSX·CSV에 source_file 열을 추가하고, 원본별 XLSX·CSV·OFX 출력은 ZIP으로 제공합니다. 최신 한도와 크레딧은 요금제에서 다시 확인하세요. 기술적 상한이 고객 분리, 문서 품질, 내부 보안정책과 검토 가능량까지 대신 판단하지는 않습니다.

한 장의 명세서부터 변환 원리를 확인하고 싶다면 은행 거래내역 PDF를 Excel로 변환하는 가이드를 먼저 읽어도 좋습니다. 이 글은 그다음 단계인 다중 고객·다중 은행·다중 월 운영에 집중합니다.

한눈에 보는 일괄 변환 6단계

1. 고객 또는 법인별로 파일을 분리합니다.
2. 파일명에 계좌 별칭과 기간을 넣습니다.
3. 제한 안에서 작업 묶음을 업로드합니다.
4. 원본별 결과와 예외를 확인합니다.
5. 분석용은 병합하고 업로드용은 파일별로 유지합니다.
6. source_file, 거래 건수, 부호와 잔액을 검증합니다.

일괄 변환 전에 작업 묶음의 경계를 먼저 정한다

한 번에 15개 파일을 받을 수 있다고 해서 서로 무관한 문서를 한 로트에 넣는 것이 좋은 운영은 아닙니다. 가장 먼저 “이 로트의 소유자와 목적이 무엇인가?”를 한 문장으로 답할 수 있어야 합니다.

권장되는 1차 분리 기준은 다음과 같습니다.

1. 고객 또는 법인: 다른 고객의 자료를 같은 로트에 섞지 않습니다.
2. 업무 목적: 월 결산, 과거 자료 보완, 세무대리인 인계, 감사 대응처럼 목적을 구분합니다.
3. 계좌·통화: 목적지 템플릿이나 검토 규칙이 다르면 계좌 또는 통화별로 나눕니다.
4. 기간: 누락과 중복을 확인할 수 있도록 월, 분기 또는 합의된 기간으로 제한합니다.
5. 접근 권한: 담당자나 검토자가 다르면 기술적으로 합칠 수 있어도 분리합니다.

예를 들어 같은 고객의 운영계좌와 급여계좌라도 접근 권한이 다르면 별도 로트가 낫습니다. 반대로 같은 고객, 같은 통화, 같은 검토자, 같은 기간이라면 여러 은행 양식을 한 로트에서 처리하고 source_file로 원본을 추적할 수 있습니다.

로트 이름도 기준을 드러내야 합니다. 2026-08_고객A_월결산_KRW_담당자처럼 기간, 고객 코드, 목적을 넣되 전체 계좌번호나 주민등록번호 같은 불필요한 민감정보는 제외하세요.

실제 제품 제한 안에서 용량을 계획하는 법

BankStatementLab의 인증된 업로드 제한은 다음과 같습니다.

항목	한 로트의 제한	운영상 확인할 점
파일 수	최대 100개	고객·법인 분리 원칙을 깨면서 채우지 않기
전체 페이지	최대 100페이지	파일 수보다 전체 페이지가 먼저 상한에 도달할 수 있음
파일 크기	파일당 최대 50MB	고해상도 스캔의 페이지 수와 가독성을 함께 확인
크레딧	Standard 1페이지당 1, Advanced 2	로트 페이지 수와 선택 모드에 맞춰 사전 확인

예를 들어 20개 파일이 각각 6페이지라면 파일 수는 제한 안이지만 전체 120페이지이므로 한 로트에 들어가지 않습니다. 반대로 100개의 단일 페이지 파일은 페이지와 파일 수가 모두 상한에 닿습니다. 여기서 예시는 제한 계산을 설명할 뿐, 한 번에 상한까지 처리하라는 권장은 아닙니다.

대량 업무에서는 검토할 수 있는 크기도 상한입니다. 담당자가 원본과 결과를 충분히 대조할 수 있는 단위로 나누고, 다음 로트로 넘어가기 전에 출력 수, 예외, 승인 상태를 마감하세요.

파일명 규칙이 source_file의 품질을 결정한다

병합 결과의 source_file은 업로드된 원본 이름을 기준으로 거래 행의 출처를 알려줍니다. 따라서 scan001.pdf, 다운로드(7).pdf, 통장.pdf 같은 이름으로 시작하면 병합 후에도 원본을 찾기 어렵습니다.

실무 파일명 예시는 다음과 같습니다.

고객코드_계좌별칭또는끝4자리_YYYY-MM_은행별칭.pdf

예를 들면 다음처럼 쓸 수 있습니다.

• ACME_운영4521_2026-07_은행A.pdf
• ACME_급여7890_2026-07_은행B.pdf
• BETA_외화1122_2026-Q2_은행C.pdf

전체 계좌번호, 개인 이름, 주민등록번호를 파일명에 복제하지 마세요. 업무 시스템에서 이미 고객 코드와 권한을 관리한다면 최소한의 별칭만으로 추적할 수 있습니다. 파일명 변경 전후의 연결이 필요하면 로트 기록에 원래 이름을 보관하되 접근 권한을 제한합니다.

파일명이 유일한 키가 되어서는 안 됩니다. 고객 코드, 계좌 별칭, 명세 기간, 통화, 원본 페이지 수를 로트 목록에 별도 열로 두면 같은 이름의 재다운로드나 수정본을 구분하기 쉽습니다.

업로드 전 원본을 준비하는 체크리스트

필요한 기간과 페이지가 모두 있는지 확인

각 고객의 요청 목록과 실제 파일을 대조합니다. 월별 자료라면 누락 월과 중복 월을 표시하고, 첫 페이지의 계좌와 마지막 페이지의 마감 잔액이 같은 명세서에 속하는지 확인하세요. 여러 명세서를 하나로 스캔한 PDF는 계좌·기간별로 나누는 편이 원본 추적에 유리합니다.

디지털 PDF와 스캔을 구분

텍스트를 선택할 수 있는 디지털 PDF와 이미지형 스캔은 검토 포인트가 다릅니다. 스캔에서는 낮은 해상도, 기울어짐, 압축, 그림자, 도장, 손글씨가 날짜와 숫자 판독에 영향을 줄 수 있습니다. 읽을 수 없는 페이지는 먼저 재스캔을 요청하고 “시스템이 알아서 추정할 것”이라고 넘기지 마세요.

안정적인 디지털 표가 반복된다면 Excel Power Query를 이용한 자체 흐름도 비교할 수 있습니다. Microsoft의 Power Query 데이터 원본 가져오기 안내는 감지된 표를 선택하고 변환하는 과정을 설명합니다. 다만 은행 레이아웃이 바뀌거나 스캔이 섞이면 규칙 유지와 예외 처리가 필요합니다.

비밀번호 보호 파일은 로컬에서 처리

잠긴 PDF는 BankStatementLab에 업로드할 수 없습니다. 문서 열람 권한과 현재 비밀번호가 있다면 본인 기기에서 작업용 사본의 잠금을 해제하고, 페이지 수·기간·첫 거래·마지막 거래가 유지됐는지 확인하세요. 비밀번호를 변환 서비스나 작업 메모에 남기지 않습니다.

필요한 절차는 비밀번호가 걸린 은행 거래내역 PDF 잠금 해제 후 변환 가이드에서 확인할 수 있습니다. 원본은 그대로 보존하고, 잠금 해제 사본은 작업이 끝난 뒤 조직의 보존 정책에 따라 삭제합니다.

세무사무소용 일괄 변환 6단계

1단계: 접수 목록과 원본 수를 맞춘다

고객별 요청 기간, 예상 파일 수, 예상 페이지 수, 계좌 수, 통화, 담당자, 마감일을 기록합니다. 받은 파일이 목록보다 적거나 기간이 겹치면 변환 전에 해결하세요. “출력은 잘 됐지만 원본 하나가 처음부터 없었다”는 문제는 추출 도구가 발견해 주지 못합니다.

2단계: 한 고객 또는 한 법인으로 로트를 만든다

업로드 화면에서 파일명과 페이지 합계를 다시 확인합니다. 한 로트가 15개 파일, 전체 100페이지, 파일당 50MB 안에 있는지 봅니다. 제한을 맞추기 위해 서로 다른 고객을 합치는 대신 같은 고객의 기간을 나누세요.

3단계: 처리 결과와 예외를 확인한다

각 원본에 대응하는 결과가 있는지, 실패 또는 부분 결과가 있는지 확인합니다. 표가 여러 개 감지됐다면 표의 계좌와 기간이 맞는지 봅니다. 열 이름이 비슷해도 실제 의미가 다를 수 있으므로 날짜, 적요, 출금, 입금, 금액, 잔액의 표본을 원본과 비교하세요.

4단계: 병합 또는 별도 출력을 선택한다

분석과 표준화가 목적이면 현재 화면에서 병합 XLSX·CSV를 선택할 수 있습니다. 병합 파일은 추출 결과에서 발견된 열의 합집합을 사용하고 각 행에 source_file을 넣습니다. 한 은행에만 있는 선택 열 때문에 빈 열이 생길 수 있으므로, 병합했다고 스키마가 자동으로 회계 프로그램 형식에 맞춰졌다고 생각해서는 안 됩니다.

고객·계좌별 템플릿, 통화, 접근 권한 또는 검토자가 다르면 파일별 출력을 선택합니다. 별도 출력은 원본별 파일을 ZIP으로 묶어 전달하므로 각 파일을 독립적으로 매핑하고 승인하기 좋습니다.

5단계: 문서 수준과 로트 수준을 모두 검증한다

문서마다 첫·마지막 거래, 날짜 순서, 입출금 부호, 큰 금액, 페이지 경계, 잔액 흐름을 확인합니다. 그다음 로트 전체에서 원본 수와 출력 수, source_file별 행 수, 통화와 법인 분리, 예외 담당자와 상태를 점검합니다.

6단계: 대상 시스템에 맞추고 작은 범위로 시험한다

BankStatementLab 결과는 검토 가능한 구조화 데이터이지 특정 회계 프로그램의 완성된 분개 파일이 아닙니다. 대상 프로그램의 최신 공식 문서와 샘플을 기준으로 필수 열, 날짜, 부호, 인코딩, 중복 처리를 맞춥니다. 자세한 매핑과 시험 업로드 순서는 은행 거래내역 PDF를 CSV로 변환해 회계 프로그램에 넣는 방법을 참고하세요.

고객 1명의 한 달치 작업 묶음으로 병합 결과 확인하기 →

병합 XLSX·CSV와 파일별 ZIP 비교

선택	출력 형태	적합한 상황	핵심 통제
병합 XLSX	하나의 통합 문서와 source_file	사람이 필터·수식·피벗으로 검토할 때	날짜·금액 형식과 빈 선택 열 확인
병합 CSV	하나의 CSV와 source_file	공통 스키마로 매핑하거나 다른 시스템에 넣을 때	UTF-8, 구분 기호, 부호, 열 순서 확인
파일별 ZIP	원본마다 별도 XLSX·CSV·OFX	고객·계좌·통화·목적지 템플릿이 다를 때	파일 수와 원본 수 일치, 이름 충돌 확인

source_file은 원본 추적에 매우 유용하지만 그 자체로 고객 코드, 계좌, 통화와 기간이 정확하다는 보증은 아닙니다. 업로드 전 파일명이 잘못됐다면 잘못된 이름이 그대로 따라옵니다. 병합 후에는 source_file별 행 수와 기간을 집계해 예상 목록과 비교하세요.

이미 여러 CSV가 있다면 Power Query로 결합하기

은행 또는 변환 도구에서 파일별 CSV를 확보했다면 Excel Power Query로 폴더의 파일을 반복 결합할 수 있습니다. Microsoft의 폴더의 여러 파일 가져오기 안내는 같은 스키마와 형식을 가진 파일을 하나의 테이블로 결합하는 흐름을 설명합니다.

결합 전에 다음을 통일하세요.

• 원본 파일명 또는 고객·계좌 식별 열
• 날짜의 지역 설정과 데이터 형식
• 입금·출금 또는 하나의 부호 있는 금액 규칙
• 통화 열과 소수점 처리
• 필수 열 이름과 열 데이터 유형
• 소계, 머리글, 빈 행 제거 규칙

스키마가 다른 파일을 먼저 합친 뒤 출처를 추정하려 하지 마세요. 출처 열을 만든 다음 열을 표준화하는 순서가 중요합니다.

OFX는 병합 표와 별개의 내보내기 흐름

OFX를 XLSX·CSV 병합과 같은 방식으로 설명하면 안 됩니다. BankStatementLab은 검토된 계좌 또는 표별로 OFX 1.6 SGML 파일을 생성합니다. 여러 대상을 선택하면 별도의 OFX 파일들이 ZIP으로 묶일 수 있습니다. 하나의 source_file 열을 가진 병합 OFX를 만드는 방식이 아닙니다.

각 대상에는 계좌 식별정보, CHECKING 또는 SAVINGS 계정 유형, 통화, 마감 잔액이 필요합니다. 날짜·적요·금액 구조가 유효한지도 사전 확인됩니다. 같은 계좌에서 중복 거래 식별자가 충돌할 수 있는 조합은 그대로 내보내는 대신 검토가 필요합니다.

OFX 지원 여부는 대상 회계 프로그램의 최신 공식 문서에서 확인하세요. 특정 제품과의 범용 호환이나 직접 연동을 약속할 수 없습니다. 작은 기간의 별도 파일로 날짜, 금액 부호, 중복, 계좌, 마감 잔액을 시험한 뒤 나머지 범위를 진행하고, 맞지 않으면 CSV 매핑을 선택하세요.

문서별 검증: 원본 한 개를 끝까지 추적한다

대량 검증은 모든 셀을 무조건 다시 입력하는 작업이 아닙니다. 자동 검사와 위험 기반 표본을 조합하되, 각 문서가 원본으로 돌아갈 수 있어야 합니다.

필수 문서 체크

• 요청한 고객, 계좌, 기간과 일치합니다.
• 예상한 모든 페이지가 있습니다.
• 첫 거래와 마지막 거래 날짜가 원본과 같습니다.
• 입금 한 건과 출금 한 건 이상의 부호·금액이 같습니다.
• 페이지 전환부에 거래 누락, 중복 머리글, 잘린 적요가 없습니다.
• 같은 날짜와 같은 금액의 합법적인 반복 거래가 임의로 제거되지 않았습니다.
• 기초·기말 잔액이 있다면 순변동 관계를 확인했습니다.

잔액 검증의 일반적인 개념은 다음과 같습니다.

기초 잔액 + 기간 내 입금 - 기간 내 출금 = 기말 잔액

은행이 금액을 하나의 부호 있는 열로 표시한다면 기초 잔액 + 순변동 = 기말 잔액으로 맞출 수 있습니다. 다만 가용 잔액, 회계 잔액, 보류 거래의 정의가 다를 수 있으므로 명세서가 실제로 제공하는 잔액과 부호 규칙을 기준으로 하세요. 불일치는 오류 위치를 알려주지는 않지만 가져오기 준비가 끝나지 않았다는 신호입니다.

로트 수준 검증: 고객 자료 전체를 마감한다

문서별 검사가 끝나도 로트 전체가 완전하다는 보장은 없습니다. 다음 항목을 로트 기록에 남기세요.

• 요청 원본 수와 실제 접수 수
• 성공 출력 수, 실패 수, 재처리 수
• source_file별 거래 행 수
• 각 파일의 첫·마지막 거래일
• 통화와 계좌 별칭
• 기초·기말 잔액 검증 결과
• 예외 내용, 담당자, 처리 기한, 최종 상태
• 검토자와 승인 시각
• 대상 프로그램 시험 업로드 결과

전체 거래 합계만 맞는지는 충분한 검증이 아닙니다. 한 파일의 누락 금액과 다른 파일의 중복 금액이 우연히 상쇄될 수 있습니다. source_file, 계좌, 기간별로 분리한 뒤 건수와 잔액을 확인해야 합니다.

서로 다른 은행 양식을 표준화하는 법

은행마다 같은 개념을 다른 열로 표현합니다. 거래일, 기장일, 처리일이 함께 있을 수 있고, 출금·입금을 나누거나 거래금액 하나에 부호를 쓰기도 합니다. 적요가 한 열일 수도 있고 거래 유형, 상대방, 메모로 나뉠 수도 있습니다.

공통 작업 스키마는 다음처럼 시작할 수 있습니다.

표준 열	가능한 원본 표현	처리 원칙
client_code	폴더·접수표의 고객 코드	파일 내용에서 추측하지 않고 접수 정보로 부여
account_alias	계좌 별칭·끝 네 자리	전체 계좌번호 노출 최소화
source_file	업로드 파일명	원본 추적을 위해 보존
transaction_date	거래일·기장일	어떤 날짜를 택했는지 규칙 기록
description	적요·내용·거래처	원문을 보존하고 분류 후보는 별도 열 사용
amount	거래금액 또는 입금·출금	하나의 일관된 부호 규칙 사용
balance	거래 후 잔액	원본에 있을 때 검증에 사용
currency	통화 표기·계좌 통화	다른 통화 합산 금지
review_status	신규 작업 열	미검토·예외·승인 등 상태 관리

표준화는 데이터 형식을 맞추는 작업이지 회계·세무 결정을 자동 확정하는 작업이 아닙니다. 적요 키워드로 후보를 만들 수는 있지만, 계정과목, 사업 관련성, 증빙 적격성은 담당자가 확인해야 합니다. 개인사업자의 검토 시트 예시는 사업용 계좌 거래내역 엑셀 정리 자동화에서 볼 수 있습니다.

민감정보를 다루는 로트의 운영 원칙

대량 로트에는 한 문서보다 더 많은 계좌와 거래 상대방 정보가 모입니다. 따라서 기술적 변환과 별도로 접근, 보존, 전달 규칙이 필요합니다.

최소 수집

업무에 필요하지 않은 계좌 전체 번호, 개인식별번호, 비밀번호를 파일명·작업표·메신저에 복제하지 마세요. 검토에 계좌 끝 네 자리만 필요하다면 그 수준으로 제한합니다.

역할별 접근

접수 담당자, 변환 담당자, 검토자, 최종 승인자가 모두 모든 고객 폴더를 볼 필요는 없습니다. 고객 또는 법인별 폴더 권한을 분리하고, 공유 링크의 대상과 만료를 관리하세요.

원본과 작업 사본 분리

원본 PDF는 읽기 전용으로 보존하고, 잠금 해제본·중간 CSV·병합 파일은 작업 영역에 둡니다. 작업 사본이 원본을 덮어쓰지 않도록 이름과 폴더를 분리합니다.

필요한 기간만 보존

법적·계약상 보존 의무와 조직 정책을 확인하고, 중간 산출물과 다운로드 폴더의 사본을 목적 없이 남기지 않습니다. 삭제 대상, 승인자, 삭제일을 작업 기록에 포함하면 “누군가 지웠을 것”이라는 추정을 피할 수 있습니다. 업로드 전에 처리 권한, 접근 통제, 하위 처리자와 보관·삭제 조건이 사무소의 의무에 맞는지 보안 페이지와 개인정보 처리방침에서 확인하세요. 서비스 사용만으로 규제 준수가 자동 보장되지는 않습니다.

본 글은 일반적인 업무 정보이며 세무·법률 자문이 아닙니다.

실제 업무 데이터로 도입 효과 계산하기

“대량 변환으로 매달 몇 시간을 무조건 절감한다”는 고정 수치를 사용하지 마세요. 은행 양식, 스캔 비율, 페이지 길이, 예외율, 검토 기준에 따라 결과가 달라집니다. 대표 로트의 도입 전후를 직접 측정하는 편이 정확합니다.

현재 월 작업비용은 다음 구조로 계산할 수 있습니다.

월 인건비 = 월 문서 수 × 문서당 평균 처리분 ÷ 60 × 시간당 총비용

여기서 처리시간을 한 덩어리로 기록하지 말고 접수, 파일명 정리, 전사, 열 정리, 원본 검토, 예외 해결, 회계 프로그램 업로드로 나눕니다. 자동화 후에는 업로드, 대기, 예외 수정, 검증, 가져오기 시간을 같은 기준으로 측정합니다.

비교 항목은 다음과 같습니다.

• 현재 수작업 전사와 정리 시간
• 자동 추출 후 검토와 예외 처리 시간
• Standard 또는 Advanced의 페이지당 크레딧 사용량
• 교육, 보안 검토, 프로세스 문서화 비용
• 누락·중복·부호 오류로 인한 재작업
• 월별 문서 수와 변동 폭

디지털 PDF만 있는 쉬운 표본으로 평가하지 마세요. 실제 업무 비중에 맞춰 여러 은행, 짧고 긴 문서, 스캔, 다중 페이지, 다른 통화를 포함합니다. 자동화가 전사 시간을 줄여도 검토 시간은 남을 수 있으며, 그 결과를 그대로 비용 계산에 반영해야 합니다.

반복 가능한 폴더와 상태 흐름

복잡한 시스템 없이도 다음 다섯 상태를 구분하면 인계가 쉬워집니다.

1. 01_원본(Raw): 접수한 원본 PDF, 가능하면 읽기 전용
2. 02_작업(Working): 잠금 해제 사본, 변환 결과, 열 매핑 사본
3. 03_검토완료(Reviewed): 원본 대조와 예외 처리가 끝난 파일
4. 04_가져오기완료(Imported): 업로드 확인과 대사 증빙
5. 05_보관(Archive): 보존 정책상 필요한 원본과 최종 기록

파일을 옮길 때 담당자, 검토자, 로트 날짜, 원본 수, 출력 수, 예외 수를 기록합니다. 수정본에는 버전과 수정 이유를 남기고 final_final2.csv 같은 이름을 피하세요. 회계 프로그램에서 가져오기를 취소하거나 재실행했다면 그 상태도 로트 로그에 반영합니다.

검증 기준 및 출처

이 글은 2026년 8월에 업로드 화면의 최대 15개 파일·전체 100페이지·파일당 50MB 제한, 병합 XLSX·CSV의 source_file, 파일별 ZIP과 OFX 1.6 출력을 제품 코드 및 합성 다중 은행 문서로 다시 확인했습니다. 정확도나 절감 시간은 정량 수치로 주장하지 않으며 실제 업무 표본의 원본별 행과 출처 열을 검토해야 합니다. Power Query 설명은 Microsoft 공식 문서를 기준으로 했습니다.

자주 묻는 질문

BankStatementLab 한 번의 로트에 은행 거래내역 PDF를 몇 개까지 넣을 수 있나요?

현재 업로드 화면의 한 로트는 최대 15개 파일, 전체 100페이지까지 처리할 수 있고 파일 하나의 크기는 최대 50MB입니다. 실제 처리 가능 범위는 보유 크레딧과 문서 판독 가능 여부에도 영향을 받습니다. 제한 안에 들어가더라도 서로 다른 고객이나 법인을 한 로트에 섞지 않는 것이 검토와 접근 통제에 유리합니다.

여러 PDF를 하나의 Excel이나 CSV로 합칠 수 있나요?

네. 현재 화면의 병합 내보내기는 선택한 추출 결과의 열을 합쳐 하나의 XLSX 또는 CSV로 만들고 각 행에 source_file 열을 추가합니다. 서로 다른 스키마는 선택 열이 늘어날 수 있으므로 병합 후 표준 열을 매핑해야 합니다. 원본별 XLSX·CSV·OFX가 필요하면 ZIP으로 출력할 수 있습니다.

병합 파일과 파일별 ZIP 중 어느 것을 선택해야 하나요?

여러 자료를 한 표에서 분석하거나 표준화할 때는 source_file이 있는 병합 파일이 편리합니다. 고객·계좌별로 회계 프로그램 템플릿, 통화, 접근 권한 또는 검토자가 다르면 파일별 ZIP이 더 안전할 수 있습니다. 목적지와 검토 단위에 따라 선택하고 원본 추적성을 유지하세요.

서로 다른 은행의 디지털 PDF와 스캔본을 같은 로트에 넣어도 되나요?

처리 자체는 가능하지만 결과 검토가 더 중요해집니다. 은행마다 열 순서, 날짜, 입출금 표시와 페이지 구조가 다르고 스캔 품질도 제각각입니다. 고객 또는 법인을 먼저 분리하고, 각 문서의 첫·마지막 거래, 페이지 경계, 부호와 잔액을 원본에 대조하세요.

비밀번호가 걸린 은행 거래내역 PDF는 일괄 변환할 수 있나요?

잠긴 상태로는 처리할 수 없습니다. 문서 열람 권한과 현재 비밀번호가 있다면 본인 기기에서 작업용 사본의 잠금을 해제하고 페이지와 기간이 유지됐는지 확인한 뒤 업로드하세요. 원본은 별도로 보존하고, 작업이 끝나면 내부 보존 정책에 따라 잠금 해제 사본을 삭제하세요.

대량 변환에서 거래 누락을 어떻게 확인하나요?

원본 파일 수와 출력 수를 먼저 맞추고, 문서별 거래 건수, 첫·마지막 날짜, 입출금 부호, 큰 금액, 페이지 경계를 확인하세요. 원본에 기초·기말 잔액이 있으면 기초 잔액과 순변동으로 기말 잔액을 대조합니다. 로트 수준에서는 source_file별 행 수와 예외 상태도 기록해야 합니다.

대량 OFX도 하나의 파일로 합쳐지나요?

OFX는 XLSX·CSV의 source_file 병합과 다른 흐름입니다. BankStatementLab은 검토된 계좌 또는 표별로 OFX 1.6 SGML 파일을 만들며 여러 대상이면 별도 OFX들이 ZIP으로 묶일 수 있습니다. 범용 호환이나 특정 회계 프로그램으로의 직접 가져오기를 보장하지 않으므로 각 대상의 공식 지원 형식으로 작은 범위를 시험하세요.

일괄 변환 도입 효과는 어떻게 계산해야 하나요?

고정된 절감 시간을 가정하지 말고 대표 로트로 전후를 측정하세요. 월 문서 수에 문서당 접수·전사·정리·검토 시간을 곱해 현재 비용을 구한 뒤, 업로드·예외 처리·검증·가져오기 시간과 크레딧 비용을 비교합니다. 은행, 스캔 품질, 페이지 수가 섞인 실제 표본을 사용해야 합니다.

결론: 상한까지 채우기보다 검증 가능한 로트를 만든다

세무사무소의 은행 거래내역 일괄 변환은 “PDF 여러 개를 한 번에 Excel로 만드는 기능”만으로 완성되지 않습니다. 고객 또는 법인별 분리, 파일명 규칙, 접수 목록, 원본 보존, source_file, 문서별 잔액 검증, 작업 묶음별 예외 기록, 작은 시험 업로드가 하나의 프로세스로 이어져야 합니다.

분석과 공통 정리가 목적이면 source_file이 포함된 병합 XLSX·CSV를 선택하고, 계좌별 템플릿이나 권한이 다르면 파일별 ZIP을 선택하세요. OFX가 필요하다면 계좌 또는 표별 파일로 다루고, 대상 프로그램의 공식 지원 범위에서 작은 기간으로 검증해야 합니다.

고객 한 명의 대표 작업 묶음으로 BankStatementLab 결과 확인하기 →. 원본 수와 출력 수를 맞추고, 거래일·적요·부호·잔액을 확인하고, 내부 검토와 시험 가져오기가 통과한 뒤 다음 고객과 더 큰 기간으로 범위를 확장하세요.

관련 기사

• 은행 거래내역 PDF를 Excel로 변환하는 전체 가이드
• 은행 거래내역 PDF를 CSV로 변환해 회계 프로그램에 넣는 법
• 개인사업자 통장 거래내역 엑셀 정리 자동화
• 비밀번호가 걸린 은행 거래내역 PDF 잠금 해제 후 변환