북키퍼를 위한 다중 클라이언트 은행 거래 내역서 처리 가이드 (2026)
북키퍼가 여러 클라이언트의 은행 거래 내역서를 효율적으로 처리하는 방법. 일괄 변환, 형식 표준화, 5개에서 50개 이상 클라이언트로 확장하는 방법을 다룹니다.
클라이언트가 22명입니다. 14개 은행을 사용합니다. 매달 47개의 은행 계좌에서 거래 내역서가 생성됩니다. 일부 클라이언트는 PDF를 이메일로 보냅니다. 다른 클라이언트는 로그인 정보를 제공하고 직접 다운로드하도록 기대합니다. 분기별 회의에서 종이 인쇄물을 건네주는 경우도 있습니다.
금요일까지 이 모든 거래 내역서를 각 클라이언트가 사용하는 QuickBooks, Xero, Sage 등 어떤 소프트웨어든 조정해야 합니다.
이것이 바로 다중 클라이언트 북키핑의 현실입니다. 평균적인 북키퍼는 1530명의 클라이언트를 관리하며, 각 클라이언트는 25개의 은행 계좌를 가지고 있습니다. 이는 매달 30~150개의 은행 거래 내역서가 다양한 형식으로, 다른 은행에서, 다른 회계 플랫폼을 대상으로 생성된다는 의미입니다. 게다가 신용카드 거래 내역서, 대출 계좌, 그리고 가끔 추가로 끼워 넣는 증권 거래 내역서까지 처리해야 합니다.
이 가이드에서는 수신되는 거래 내역서 정리부터 일괄 변환, 회계 소프트웨어 가져오기, 그리고 서비스로서의 가격 책정까지 확장 가능한 은행 거래 내역서 처리 워크플로 구축 방법을 다룹니다.
다중 클라이언트 은행 거래 내역서 문제
단일 클라이언트 북키퍼는 쉽습니다. 한 은행의 형식을 배우고, 하나의 회계 파일을 설정하고, 하나의 워크플로를 개발합니다. 매달 반복합니다.
다중 클라이언트 북키핑은 완전히 다른 문제입니다. 새로운 클라이언트가 추가될 때마다 복잡성이 배가되며, 월말에 일치하지 않는 파일 더미에 파묻히기 전까지는 명확하지 않은 방식으로 문제가 누적됩니다.
다른 은행은 다른 형식을 의미합니다
Chase 거래 내역서는 Bank of America 거래 내역서와 전혀 다릅니다. Wells Fargo의 레이아웃은 US Bank와 다릅니다. 지역 신용협동조합은 완전히 다른 템플릿을 사용합니다. 각 은행은 날짜, 설명, 금액 및 잔액을 표시하는 고유한 방식을 가지고 있습니다.
14개 은행의 거래 내역서를 처리할 때, 본질적으로 14가지 다른 데이터 형식을 배우는 것이며 — 은행이 거래 내역서 템플릿을 업데이트할 때 언제든지 변경될 수 있습니다.
다른 파일 명명 규칙
한 은행은 PDF 파일 이름을 Statement_2026-02.pdf로 지정합니다. 다른 은행은 eStatement_AcctXXXX1234_Feb2026.pdf를 사용합니다. 세 번째 은행은 단순히 document.pdf라고 부릅니다. 매달 수십 개의 거래 내역서를 다운로드할 때, 다른 클라이언트의 동일한 파일 이름은 빠르게 심각한 문제가 됩니다.
다른 거래 내역서 주기
대부분의 은행은 월별 거래 내역서를 발행하지만, 주기 날짜는 다릅니다. 클라이언트 A의 Chase 거래 내역서는 1일부터 31일까지입니다. 클라이언트 B의 Chase 거래 내역서는 15일부터 14일까지입니다. 클라이언트 C의 Wells Fargo 거래 내역서는 22일에 마감됩니다. 어떤 기간을 받았고 어떤 기간이 아직 미결인지 추적하려면 자체 추적 시스템이 필요합니다.
다른 회계 소프트웨어 대상
클라이언트 A는 QuickBooks Online을 사용하며 QBO 파일이 필요합니다. 클라이언트 B는 Xero를 사용하며 OFX가 필요합니다. 클라이언트 C는 Sage를 사용하며 CSV를 선호합니다. 클라이언트 D는 Wave를 사용하며 특정 열 헤더가 있는 CSV를 원합니다. 각 대상 형식에는 날짜 형식, 거래 구조 및 필드 매핑에 대한 자체 요구 사항이 있습니다.
암호로 보호된 거래 내역서
은행은 점점 더 암호로 PDF 거래 내역서를 암호화합니다. 각 클라이언트의 거래 내역서는 다른 암호를 사용할 수 있습니다. 종종 계좌 번호의 마지막 네 자릿수, 계좌 소유자의 SSN 또는 은행별 조합입니다. 다른 모든 클라이언트 자격 증명과 함께 20개 이상의 PDF 암호를 관리하는 것은 또 다른 마찰을 추가합니다.
효율적인 거래 내역서 처리 워크플로 구축
매달 은행 거래 내역서에 30시간을 소비하는 북키퍼와 8시간을 소비하는 북키퍼의 차이는 워크플로에 달려 있습니다. 다음은 확장 가능한 6단계 프로세스입니다.
1단계: 수집 프로세스 표준화
모든 클라이언트로부터 거래 내역서를 받는 일관된 방법이 필요합니다. 세 가지 주요 접근 방식:
직접 은행 액세스. 각 클라이언트의 은행에 로그인하여 거래 내역서를 직접 다운로드합니다. 이를 통해 타이밍과 파일 품질을 가장 잘 제어할 수 있지만, 수십 개의 은행 자격 증명을 관리하고 각 로그인에 대해 다단계 인증을 처리해야 합니다. 많은 북키퍼는 LastPass 또는 1Password와 같은 암호 관리자를 사용하여 이를 처리합니다.
클라이언트 포털. 클라이언트는 공유 폴더(Google Drive, Dropbox, SharePoint) 또는 연습 관리 포털에 거래 내역서를 업로드합니다. 다운로드 작업을 오프로드하지만 변동성이 발생합니다. 클라이언트는 잘못된 월을 업로드하거나, 계좌를 잊거나, 디지털 다운로드 대신 스캔된 사본을 보낼 수 있습니다.
이메일. 가장 일반적이고 가장 비효율적인 방법입니다. 거래 내역서는 다른 클라이언트 서신과 섞여 받은 편지함으로 도착합니다. 파일 이름이 일관되지 않습니다. 처리하기 전에 정렬, 이름 변경 및 파일링하는 데 시간을 보냅니다.
대부분의 연습에 가장 좋은 접근 방식은 하이브리드입니다. 가장 큰 클라이언트의 경우 직접 은행 액세스(설정 시간 절약이 정당화되는 경우)와 나머지 모든 클라이언트를 위한 구조화된 클라이언트 포털입니다. 이메일은 최후의 수단으로 남겨둡니다.
2단계: 수신 거래 내역서 정리
무엇이든 변환하기 전에 모든 거래 내역서는 올바른 위치에 있어야 합니다. 일관된 폴더 구조는 "이것은 어느 클라이언트를 위한 것인가?"라는 질문을 제거하고 일괄 처리를 가능하게 합니다.
검증된 구조:
은행 거래 내역서/
├── 클라이언트 A - ABC Corp/
│ ├── Chase 비즈니스 당좌 예금 (****1234)/
│ │ ├── 2026-01-Statement.pdf
│ │ ├── 2026-02-Statement.pdf
│ │ └── ...
│ ├── Chase 비즈니스 저축 예금 (****5678)/
│ │ └── ...
│ └── Amex 비즈니스 플래티넘/
│ └── ...
├── 클라이언트 B - XYZ LLC/
│ ├── Wells Fargo 당좌 예금 (****9012)/
│ │ └── ...
│ └── ...
└── ...
핵심 원칙:
- 클라이언트 이름 우선. 은행이 아닌 클라이언트 기준으로 생각합니다.
- 계좌 유형 및 마지막 네 자릿수. 동일한 은행의 여러 계좌를 구별합니다.
- 일관된 날짜 형식.
YYYY-MM은 모든 파일 브라우저에서 연대순으로 정렬됩니다. - 즉시 이름 변경. 거래 내역서가 도착하는 즉시 규칙에 맞게 이름을 변경합니다.
document.pdf또는eStatement.pdf로 두지 마십시오.
3단계: 표준화된 형식으로 일괄 변환
이것이 대부분의 북키퍼가 가장 많은 시간을 잃는 부분입니다. 50개 이상의 PDF 거래 내역서를 하나씩 변환하거나, 스프레드시트에 수동으로 거래를 입력하거나, PDF에서 회계 소프트웨어로 복사-붙여넣기를 하는 것은 병목 현상입니다.
PDFSub의 은행 거래 내역서 변환기가 이 단계를 처리합니다. PDF 은행 거래 내역서를 업로드하면 8가지 형식(Excel, CSV, QBO(QuickBooks), OFX(Xero), QFX, QIF, JSON 또는 TSV) 중 선택한 형식으로 거래를 추출합니다. 전 세계 20,000개 이상의 은행 거래 내역서를 지원하므로 클라이언트가 Chase, 지역 신용협동조합 또는 국제 기관을 이용하든 상관없습니다.
다중 클라이언트 북키퍼의 경우 워크플로는 다음과 같습니다.
- PDFSub의 은행 거래 내역서 변환기 열기
- 거래 내역서 업로드 (대부분의 처리는 브라우저에서 이루어집니다. 표준 디지털 PDF의 경우 파일이 기기를 벗어나지 않습니다)
- 클라이언트의 회계 소프트웨어와 일치하는 출력 형식 선택
- 변환된 파일 다운로드
- 다음 거래 내역서에 대해 반복
월 $29의 비즈니스 플랜 + BSC 추가 기능 (500페이지)은 최대 20명의 클라이언트를 보유한 대부분의 북키퍼에게 적합합니다. 50명 이상의 클라이언트를 처리하는 더 많은 양의 연습은 추가 크레딧 추가 기능을 고려해야 합니다. 모든 플랜에는 7일 무료 체험이 포함됩니다.
4단계: 클라이언트의 회계 소프트웨어로 가져오기
변환된 파일을 사용하여 각 클라이언트의 회계 소프트웨어로 가져옵니다:
- QuickBooks Online 클라이언트: QBO 파일을 직접 업로드합니다. QBO는 QuickBooks의 기본 형식이므로 열 매핑이 필요하지 않습니다. 전체 안내는 QuickBooks로 은행 거래 내역서 가져오기 가이드를 참조하십시오.
- Xero 클라이언트: 은행 거래 내역서 가져오기 기능을 통해 OFX 파일을 업로드합니다. OFX는 거래 구조를 유지하고 CSV 가져오기에 문제가 되는 날짜 형식 문제를 피합니다. Xero로 은행 거래 내역서 가져오기 가이드를 참조하십시오.
- Sage 및 기타 클라이언트: 각 플랫폼이 예상하는 열 구조와 함께 CSV를 사용합니다. 대부분의 회계 소프트웨어는 CSV를 허용하지만, 필요한 열 순서와 날짜 형식은 다릅니다.
5단계: 조정 및 검토
자동화는 추출 및 가져오기를 처리하지만, 조정은 여전히 인간의 판단이 필요합니다.
- 가져온 거래를 은행 거래 내역서의 시작 및 종료 잔액과 일치시킵니다.
- 가져오지 못한 거래를 표시합니다 (부분 페이지 추출, 특이한 형식).
- 클라이언트가 은행 피드를 활성화한 경우 중복을 확인합니다.
- 클라이언트의 계정 원장을 사용하여 거래를 분류합니다.
6단계: 문서화 및 보관
조정 후 원본 PDF 거래 내역서와 변환된 파일 및 조정 메모를 함께 보관합니다. 이렇게 하면 감사 추적이 생성되고 나중에 질문이 발생할 경우 거래 내역서를 다시 처리하기 쉬워집니다.
은행 거래 내역서 처리를 위한 클라이언트 온보딩
새로운 클라이언트마다 은행 거래 내역서에 대한 구조화된 온보딩 프로세스가 필요합니다. 이 단계를 건너뛰면 누락된 거래 내역서를 추적하고 계좌 혼란을 풀기 위해 몇 달을 보낼 것입니다.
은행 계좌 목록 작성
온보딩 중에 클라이언트가 보유한 모든 은행 계좌를 문서화합니다:
| 필드 | 예시 |
|---|---|
| 은행 이름 | Chase |
| 계좌 유형 | 비즈니스 당좌 예금 |
| 마지막 4자리 | 1234 |
| 거래 내역서 주기 | 1일–31일 |
| 거래 내역서 배달 | 디지털 PDF (클라이언트 포털) |
| PDF 암호 | SSN 마지막 4자리 |
| 대상 소프트웨어 | QuickBooks Online |
| 대상 형식 | QBO |
이 목록은 월별 체크리스트가 됩니다. 거래 내역서가 도착하면 체크합니다. 하나가 누락되면 무엇을 후속 조치해야 하는지 정확히 알 수 있습니다.
은행 액세스 확보 대 거래 내역서 수신
직접 은행 액세스와 클라이언트로부터 거래 내역서를 받는 것 사이의 결정은 볼륨과 신뢰 수준에 따라 달라집니다:
- 직접 액세스는 3개 이상의 계좌를 가진 클라이언트 또는 제 시간에 거래 내역서를 보내는 데 신뢰할 수 없는 클라이언트에게 가장 적합합니다. 설정 시간이 더 많이 걸리지만 월별 후속 주기를 제거합니다.
- 클라이언트 제공 거래 내역서는 1-2개의 계좌를 가진 체계적인 클라이언트에게 효과적입니다. 설정은 덜하지만 클라이언트의 응답성에 의존합니다.
처리 시간 기대치 설정
계약서에 거래 내역서가 언제 필요한지, 그리고 클라이언트가 언제 조정된 장부를 기대할 수 있는지 정의합니다. 일반적인 프레임워크:
- 다음 달 5일까지 거래 내역서 제출
- 15일까지 장부 조정
- 20일까지 월별 요약 보고서 제공
5개에서 50개 이상 클라이언트로 확장
5개 클라이언트에게 효과적인 워크플로는 20개에서는 무너집니다. 성장에 따라 수학이 어떻게 변하는지 살펴보겠습니다.
시간 벤치마크: 수동 대 자동
| 클라이언트 수 | 계좌 (추정) | 월별 거래 내역서 | 수동 (각 20분) | 자동 (각 3분) | 월별 절약 |
|---|---|---|---|---|---|
| 5 | 12 | 12 | 4시간 | 36분 | 3.4시간 |
| 15 | 40 | 40 | 13.3시간 | 2시간 | 11.3시간 |
| 30 | 80 | 80 | 26.7시간 | 4시간 | 22.7시간 |
| 50 | 135 | 135 | 45시간 | 6.75시간 | 38.25시간 |
클라이언트 30명일 때, 은행 거래 내역서 처리만으로도 매달 거의 27시간이 소요됩니다. 이는 3일 이상에 해당합니다. 변환 단계를 자동화하면 대부분의 시간을 되찾을 수 있습니다.
언제 고용하고 언제 자동화할지
흔한 실수는 워크플로를 자동화하기 전에 주니어 북키퍼를 고용하여 은행 거래 내역서 처리를 담당하게 하는 것입니다. 고용은 월 $3,000–$5,000의 비용을 추가합니다. 은행 거래 내역서 변환기로 자동화하면 월 $25–$35의 비용으로 수동 작업의 80%를 제거합니다.
결정 프레임워크:
- 20명 미만: 먼저 자동화합니다. 좋은 도구를 갖춘 한 명의 북키퍼가 이 볼륨을 처리할 수 있습니다.
- 20–40명: 가능한 모든 것을 자동화한 다음 나머지 수동 작업(분류, 클라이언트 커뮤니케이션, 복잡한 조정)을 위해 고용합니다.
- 40명 이상: 자동화와 직원이 모두 필요합니다. 그러나 직원은 데이터 입력이 아닌 판단 작업을 해야 합니다.
은행 거래 내역서 처리 서비스를 위한 가격 책정
일부 북키퍼는 은행 거래 내역서 처리를 별도로 청구합니다. 다른 사람들은 월별 리테이너에 포함시킵니다. 어느 쪽이든 수익성 있게 가격을 책정하려면 거래 내역서당 비용을 알아야 합니다.
거래 내역서당 비용 (자동화):
- 변환기 구독: 월 $29 (500페이지) (비즈니스 $14 + BSC 추가 기능 $15; 페이지당 약 100–125개의 거래 내역서, 각 4페이지)
- 귀하의 시간: 시간당 요율 기준 거래 내역서당 약 3분
- 시간당 $75의 유효 요율: 노동 시간당 $3.75 + 소프트웨어 비용 약 $0.20 = 거래 내역서당 약 $4
일반적인 가격 모델:
| 모델 | 일반 범위 | 최적 |
|---|---|---|
| 거래 내역서당 | 각 $8–$25 | 변동 볼륨의 클라이언트 |
| 월별 리테이너 (거래 내역서 포함) | 월 $300–$800 | 풀 서비스 북키핑 클라이언트 |
| 계좌당 월별 | 계좌당 $15–$50 | 예측 가능한 반복 수익 |
거래 내역서당 $15 (시장 가격의 중간값)에 자동화 비용 $4를 사용하면 마진으로 거래 내역서당 $11를 얻습니다. 월 80개의 거래 내역서를 처리하는 북키퍼는 은행 거래 내역서 처리만으로 월 $880의 이익을 창출합니다.
일반적인 다중 클라이언트 과제
클라이언트가 잘못된 월 또는 잘못된 계좌를 보냅니다
이것은 끊임없이 발생합니다. 워크플로에 확인 단계를 구축하십시오. 거래 내역서를 변환하기 전에 계좌 번호와 거래 내역서 기간이 예상과 일치하는지 확인하십시오. 온보딩 시 작성한 은행 계좌 목록은 10초 확인으로 만듭니다.
스캔된 거래 내역서 대 디지털 거래 내역서
디지털 PDF(은행 웹사이트에서 직접 다운로드)는 깨끗하고 빠르게 변환됩니다. 스캔된 PDF(사진 촬영 또는 스캐너를 통해 처리)는 품질이 낮고 OCR 처리가 필요합니다.
항상 클라이언트에게 종이 사본을 스캔하는 대신 은행 웹사이트에서 직접 거래 내역서를 다운로드하도록 지시하십시오. 디지털 거래 내역서는 더 나은 변환 정확도와 더 빠른 처리를 생성합니다. 스캔된 거래 내역서를 피할 수 없을 때, PDFSub의 AI 기반 추출 계층은 OCR을 자동으로 처리합니다. 그러나 정확도는 일반적으로 기본 디지털 PDF보다 5~10% 낮습니다.
다른 형식을 사용하는 국제 클라이언트
국제 은행 계좌를 가진 클라이언트를 서비스하는 경우 다른 날짜 형식(DD/MM/YYYY 대 MM/DD/YYYY), 다른 소수 구분 기호(쉼표 대 마침표) 및 다른 통화 기호를 접하게 됩니다. PDFSub는 130개 이상의 언어로 된 거래 내역서를 지원하며 국제 날짜 및 숫자 형식을 처리하므로 대부분의 수동 재서식 작업을 제거합니다.
연중 은행을 변경하는 클라이언트
클라이언트가 은행을 변경하면 전환을 처리해야 합니다. 이전 은행의 부분 최종 거래 내역서와 새 은행의 부분 첫 거래 내역서입니다. 은행 계좌 목록을 업데이트하고 폴더 구조를 조정하며 전환 날짜를 기록하여 누락 또는 중복을 설명합니다.
회계 소프트웨어별 거래 내역서 처리
각 회계 플랫폼에는 선호하는 가져오기 형식이 있습니다. 올바른 형식을 사용하면 시간을 소모하는 열 매핑, 날짜 재서식 및 가져오기 오류 문제 해결을 제거할 수 있습니다.
QuickBooks Online 클라이언트
최적 형식: QBO
QBO(Web Connect)는 QuickBooks의 기본 은행 거래 형식입니다. 거래 날짜, 금액, 설명 및 거래 유형을 QuickBooks가 수동 매핑 없이 읽을 수 있는 구조로 포함합니다. 파일을 업로드하고 은행 계좌를 선택하면 거래가 범주화를 위해 은행 피드에 나타납니다.
자세한 안내는 QuickBooks Online으로 은행 거래 내역서 가져오기 가이드를 참조하십시오.
대체: CSV. QuickBooks는 CSV 업로드를 허용하지만 열을 수동으로 매핑하고 날짜가 MM/DD/YYYY 형식인지 확인해야 합니다. QBO를 사용할 수 없을 때만 CSV를 사용하십시오.
Xero 클라이언트
최적 형식: OFX
OFX(Open Financial Exchange)는 Xero가 선호하는 가져오기 형식입니다. 거래 구조를 유지하고 차변/대변 분류를 자동으로 처리합니다. Xero는 CSV도 허용하지만 OFX는 CSV 가져오기를 오류 발생 가능하게 만드는 날짜 형식 및 열 매핑 문제를 피합니다.
전체 가져오기 프로세스는 Xero로 은행 거래 내역서 가져오기 가이드를 참조하십시오.
Sage 클라이언트
최적 형식: CSV
Sage 제품(Sage 50, Sage Business Cloud)은 주로 CSV 가져오기를 허용합니다. 필요한 열 구조는 Sage 버전에 따라 다르지만 대부분은 다음과 같은 형식을 예상합니다: 날짜, 설명, 참조, 금액(또는 별도의 차변/대변 열). PDFSub의 CSV 출력은 Sage 요구 사항에 맞게 조정할 수 있는 깨끗하고 구조화된 데이터를 제공합니다.
Wave 및 FreshBooks 클라이언트
최적 형식: CSV 또는 OFX
Wave는 CSV 및 OFX 가져오기를 모두 허용합니다. FreshBooks는 CSV를 지원합니다. 두 플랫폼 모두 날짜, 설명 및 금액 열이 있는 깨끗한 CSV는 안정적으로 작동합니다. QBO 및 OFX도 Wave에서 수동 열 선택을 피하려는 경우 옵션입니다.
빠른 참조
| 회계 소프트웨어 | 최적 형식 | 대체 | 주요 고려 사항 |
|---|---|---|---|
| QuickBooks Online | QBO | CSV | QBO는 열 매핑이 필요하지 않습니다 |
| QuickBooks Desktop | QBO / QFX | IIF | 데스크톱 버전은 QFX도 허용합니다 |
| Xero | OFX | CSV | OFX는 날짜 형식 문제를 피합니다 |
| Sage 50 | CSV | OFX | Sage 버전에 따라 열 순서 확인 |
| Sage Business Cloud | CSV | — | 특정 날짜 형식이 필요합니다 |
| Wave | OFX | CSV | OFX는 가장 깔끔한 가져오기 경로입니다 |
| FreshBooks | CSV | — | 간단한 날짜/설명/금액 |
도구 상자
은행 거래 내역서 변환은 다중 클라이언트 북키핑 도구 상자의 한 부분입니다. 잘 갖춰진 연습에서 사용하는 도구는 다음과 같습니다.
은행 거래 내역서 변환기
PDFSub의 은행 거래 내역서 변환기는 이 워크플로를 위해 특별히 제작되었습니다. 20,000개 이상의 은행 형식을 지원하고 8가지 파일 형식(Excel, CSV, QBO, OFX, QFX, QIF, JSON, TSV)으로 출력하며 대부분의 거래 내역서를 서버에 업로드하지 않고 브라우저에서 처리합니다.
북키퍼에게 주요 이점은 형식 유연성(동일한 거래 내역서를 한 클라이언트에게는 QBO로, 다른 클라이언트에게는 OFX로 변환)과 언어 지원(국제 클라이언트를 보유한 회사를 위한 130개 이상의 언어)입니다.
플랜은 월 $10부터 시작하며, 은행 거래 내역서 변환은 월 $29(비즈니스 + BSC 추가 기능, 500페이지)이며 7일 무료 체험이 제공됩니다.
클라우드 스토리지
Google Drive, Dropbox 또는 OneDrive를 사용하여 거래 내역서를 클라이언트별로 정리합니다. 어떤 것을 선택하든 이전에 설명한 폴더 구조를 사용하고 일관된 파일 이름을 강제합니다. 클라이언트와 공유 폴더는 거래 내역서 수집 포털 역할을 합니다.
연습 관리 소프트웨어
Karbon, Jetpack Workflow 또는 Financial Cents와 같은 도구는 어떤 클라이언트의 거래 내역서가 수신, 처리 및 조정되었는지 추적하는 데 도움이 됩니다. 클라이언트 30명 이상일 경우 스프레드시트 체크리스트로는 충분하지 않습니다. 마감일 및 상태 추적이 있는 작업 관리가 필요합니다.
클라이언트 커뮤니케이션 포털
전용 포털(Liscio, Canopy, Hubdoc)이든 명확한 지침이 있는 공유 클라우드 폴더이든, 클라이언트가 거래 내역서를 제출할 지정된 장소가 필요합니다. 클라이언트가 파일을 보낼 수 있는 채널이 적을수록 이메일 스레드에서 누락되는 거래 내역서가 줄어듭니다.
자주 묻는 질문
북키퍼가 한 달에 현실적으로 처리할 수 있는 은행 거래 내역서 수는 몇 개입니까?
자동화된 변환 워크플로를 사용하면 한 명의 북키퍼가 다른 북키핑 작업과 함께 월 100150개의 은행 거래 내역서를 처리할 수 있습니다. 자동화 없이는 품질이 저하되기 전에 그 수는 3050개로 줄어듭니다. 병목 현상은 데이터 입력에서 범주화 및 조정(실제로 전문 지식이 필요한 작업)으로 이동합니다.
은행 거래 내역서 처리를 별도로 청구해야 합니까?
가격 모델에 따라 다릅니다. 시간당 요금을 청구하는 경우 은행 거래 내역서 처리가 시간당 요금에 포함됩니다. 가치 기반 또는 고정 요금 가격 책정을 사용하는 경우 월별 리테이너에 포함시키거나 거래 내역서당 청구할 수 있습니다($8–$25가 일반적인 범위). 일부 클라이언트가 다른 클라이언트보다 훨씬 더 많은 계좌를 가지고 있는 경우 별도 청구가 합리적입니다.
클라이언트에게 어떤 형식으로 거래 내역서를 보내달라고 요청해야 합니까?
항상 은행 온라인 포털에서 직접 다운로드한 기본 디지털 PDF를 요청하십시오. 이것이 가장 높은 변환 정확도를 생성합니다. 가능한 한 스캔된 PDF, 스크린샷 또는 종이 거래 내역서는 피하십시오. 클라이언트가 종이를 고집하면 대신 은행 앱을 사용하여 디지털 사본을 다운로드하도록 요청하십시오.
여러 클라이언트의 은행 거래 내역서 암호를 어떻게 처리합니까?
클라이언트 은행 거래 내역서 암호에 대한 별도의 볼트 또는 범주가 있는 암호 관리자(1Password, LastPass 또는 Bitwarden)를 사용하십시오. 온보딩 중에 클라이언트의 은행 계좌 목록과 함께 각 암호를 문서화하십시오. 스프레드시트, 스티커 메모 또는 이메일에 암호를 저장하지 마십시오.
국제 은행의 거래 내역서를 처리할 수 있습니까?
예. PDFSub는 유럽, 아시아, 중동, 라틴 아메리카 및 아프리카의 은행을 포함하여 전 세계 20,000개 이상의 은행에서 130개 이상의 언어로 된 거래 내역서를 지원합니다. 국제 거래 내역서는 종종 다른 날짜 형식과 소수 구분 기호를 사용하며, PDFSub의 파서는 이를 자동으로 처리합니다.
거래 내역서가 올바르게 변환되지 않으면 어떻게 됩니까?
먼저 스캔된 복사본이 아닌 기본 디지털 PDF인지 확인하십시오. 거래 내역서가 디지털이고 여전히 실패하면 PDFSub의 다단계 추출 시스템은 브라우저 기반 추출에서 서버 측 구문 분석, AI 기반 추출에 이르기까지 점점 더 강력한 구문 분석 방법을 통해 에스컬레이션됩니다. 자동 변환에 저항하는 드문 거래 내역서의 경우, 자동화된 워크플로를 완전히 포기하는 것보다 해당 거래 내역서만 수동으로 입력하는 것이 더 효율적입니다.
클라이언트 은행 데이터를 안전하게 유지하려면 어떻게 해야 합니까?
세 가지 원칙: 노출 최소화, 전송 중 및 저장 중 암호화, 완료 시 삭제. PDFSub와 같이 브라우저에서 데이터를 처리하는 은행 거래 내역서 변환기를 사용하고 타사 서버에 업로드하지 마십시오. 이중 인증이 있는 암호화된 클라우드 스토리지에 거래 내역서를 저장하십시오. 그리고 관할권의 데이터 보존 요구 사항을 따르십시오. 필요한 것보다 더 오래 거래 내역서를 보관하지 마십시오.