다중 통화 은행 명세서 처리 방법

고객 목록이 세 국가에 걸쳐 있습니다. 한 고객은 독일에서, 다른 고객은 일본에서, 세 번째 고객은 인도에서 은행 업무를 봅니다. 매달 유로, 엔, 루피화로 된 은행 명세서를 받게 되는데, 날짜 표기 방식, 소수점 처리 방식, 금액 표기 방식이 단일 지역용으로 설계된 도구를 혼란스럽게 할 수 있습니다.

국제 회계의 현실에 오신 것을 환영합니다. 다중 통화 은행 명세서 처리는 단순히 환율에 관한 것이 아닙니다. 국가마다 숫자, 날짜, 금융 문서를 형식화하는 근본적인 차이에 관한 것입니다. 이 중 하나라도 잘못 처리하면 QuickBooks, Xero 또는 Zoho Books로의 가져오기가 완전히 실패하거나, 더 나쁘게는 잘못된 데이터를 조용히 가져오게 됩니다.

이 가이드에서는 다중 통화 은행 명세서의 과제와 이를 올바르게 처리하기 위한 실용적인 워크플로를 다룹니다.

한눈에 보기: 여섯 국가, 여섯 가지 규약

세부 사항으로 들어가기 전에, 동일한 세 건의 거래 내역이 여섯 국가에서 어떻게 보이는지 비교해 보겠습니다. 날짜 형식, 소수점 구분 기호, 천 단위 구분 기호, 통화 위치가 모두 독립적으로 다르기 때문에 일반적인 "국제" 도구는 일반적으로 지역별로 네 가지 중 두 가지만 올바르게 처리합니다.

이 가이드를 블로그에서 사용하고 싶으신가요? 이 임베드 코드를 복사하세요:

국제 형식의 세 가지 계층

다른 국가의 은행 명세서를 처리할 때는 지역별로 다른 세 가지 독립적인 형식 시스템을 다루게 됩니다.

계층 1: 날짜 형식

동일한 여섯 자리 숫자 - 03, 06, 2026 - 는 명세서가 발행된 위치에 따라 완전히 다른 날짜를 나타냅니다.

첫 두 가지는 위험 지대입니다. 일이 12 이하일 때 03/06/2026은 모호합니다. 3월 6일 또는 6월 3일일 수 있습니다. 변환 도구가 잘못 추측하면 명세서의 모든 날짜가 몇 달씩 틀리게 됩니다. 이는 오류를 일으키지 않고, 조정 시점(또는 더 나쁘게는 세금 신고 시점)에 발견하지 못할 수 있는 잘못된 데이터를 조용히 생성합니다.

계층 2: 숫자 형식

국가별 숫자 형식은 변환 오류의 가장 흔한 원인 중 하나입니다.

인도 숫자 체계는 특별히 언급할 가치가 있습니다. 인도는 서구의 천 단위 구분 대신 라크(1,00,000 = 100,000)와 크로르(1,00,00,000 = 10,000,000) 그룹화를 사용합니다. 인도 회계사에게 12,34,567.89로 보이는 숫자는 서구 표기법으로 1,234,567.89입니다. 세 자리 그룹화를 가정하는 표준 변환 도구는 인도 형식의 숫자를 잘못 해석합니다.

계층 3: 통화 기호 및 위치

일부 통화는 소수 자리를 사용하지 않고(일본 엔, 한국 원), 일부는 세 자리 소수점을 사용하며(바레인 디나르, 쿠웨이트 디나르), 아랍어와 같은 오른쪽에서 왼쪽으로 쓰는 언어는 또 다른 차원을 더합니다. 명세서 자체가 오른쪽에서 왼쪽으로 읽힐 수 있지만 숫자는 왼쪽에서 오른쪽으로 읽힙니다.

표준 도구가 다중 통화 처리에 실패하는 이유

대부분의 은행 명세서 변환 도구는 일반적으로 미국을 기준으로 단일 지역용으로 제작되었습니다. 이 도구들은 다음과 같이 가정합니다.

• 날짜는 MM/DD/YYYY 형식입니다.
• 쉼표는 천 단위를 구분하고 마침표는 소수점을 구분합니다.
• 통화 기호는 금액 앞에 배치됩니다.
• 텍스트는 왼쪽에서 오른쪽으로 읽힙니다.

이러한 도구에 15.03.2026 형식의 날짜와 1.234,56 EUR와 같은 금액이 있는 독일 은행 명세서를 입력하면, 도구가 충돌하거나, 쓰레기 데이터를 생성하거나, 최악의 경우 쉼표와 마침표를 조용히 바꾸어 1.234,56을 1,234.56(올바름) 또는 1.234(쉼표였던 소수점 이하를 모두 잃음)으로 만듭니다.

PDFSub가 다중 통화 명세서를 처리하는 방법

PDFSub의 은행 명세서 변환기는 처음부터 국제적인 사용을 염두에 두고 제작되었습니다. 각 복잡성 계층을 처리하는 방법은 다음과 같습니다.

자동 언어 및 형식 감지

PDFSub는 130개 이상의 언어를 지원하며 은행 명세서의 언어를 자동으로 감지합니다. 독일어 명세서를 식별하면 자동으로 독일어 형식 규칙을 적용합니다. 일본어 명세서는 일본어 규칙을 트리거합니다. SBI의 인도 명세서는 인도 숫자 그룹화를 트리거합니다.

이 감지는 문서 수준에서 이루어지므로 각 명세서에 대해 로캘을 수동으로 구성할 필요가 없습니다.

지능형 날짜 구문 분석

PDFSub가 모호한 날짜를 만나면 명세서의 컨텍스트 단서를 사용하여 해결합니다.

• 명세서 헤더 날짜 - 명세서 기간 날짜는 일반적으로 모호하지 않습니다(예: "명세서 기간: 2026년 1월 1일 - 1월 31일").
• 순차 논리 - 거래가 연대순으로 나타나고 날짜가 패턴을 따르면 형식을 추론할 수 있습니다.
• 은행 템플릿 인식 - PDFSub는 20,000개 이상의 은행 템플릿을 인식하며, 이 중 상당수는 알려진 날짜 형식 규칙을 가지고 있습니다.

숫자 형식 정규화

추출 중에 PDFSub는 대상 애플리케이션에 적합한 표준 형식으로 모든 숫자를 정규화합니다.

• 독일어 1.234,56은 CSV 출력에서 1234.56이 됩니다.
• 인도어 12,34,567.89는 1234567.89가 됩니다.
• 프랑스어 1 234 567,89는 1234567.89가 됩니다.

정규화 대상은 내보내기 형식과 대상 회계 소프트웨어에 따라 달라집니다. 미국 로캘의 QuickBooks로 가져오는 경우 숫자는 마침표를 소수점으로 사용하여 형식화됩니다. 독일 로캘 시스템으로 가져오는 경우 도구는 쉼표 소수점 형식을 유지할 수 있습니다.

통화 기호 처리

PDFSub는 추출 중에 통화 기호를 제거하면서 통화 정보를 메타데이터에 보존합니다. 이렇게 하면 회계 소프트웨어에서 금액 구문 분석을 방해하는 기호가 제거됩니다(일반적으로 원시 숫자 예상).

다중 통화 처리를 위한 실용적인 워크플로

여러 국가의 명세서를 처리하는 회계사를 위한 단계별 워크플로는 다음과 같습니다.

1단계: 통화별 명세서 정리

폴더 구조를 만듭니다.

고객_이름/ USD/ checking_2026-01.pdf checking_2026-02.pdf EUR/ sparkasse_2026-01.pdf sparkasse_2026-02.pdf INR/ sbi_2026-01.pdf sbi_2026-02.pdf

2단계: 각 명세서 변환

PDFSub의 은행 명세서 변환기를 통해 각 명세서를 처리합니다.

1. PDF 업로드
2. PDFSub가 언어와 형식을 자동 감지합니다.
3. 추출된 거래 내역 검토 - 원본과 날짜 및 금액 확인
4. 대상 형식(CSV, Excel, OFX, QBO, QIF)으로 내보내기

중요 검토 단계: 각 변환에 대해 최소 3-5개의 거래 내역을 무작위로 확인합니다.

• 원본 PDF의 날짜를 변환된 출력과 비교합니다.
• 큰 금액(천 단위 구분 기호 포함)을 변환된 출력과 비교합니다.
• 작은 금액(소수점 포함)을 변환된 출력과 비교합니다.
• 거래 건수가 일치하는지 확인합니다.

3단계: 회계 소프트웨어용으로 표준화

회계 소프트웨어로 가져오기 전에 일관성을 보장합니다.

• 모든 날짜를 동일한 형식으로 - YYYY-MM-DD가 여러 로캘에서 호환됩니다.
• 모든 금액을 동일한 숫자 형식으로 - 소수점, 천 단위 구분 기호 없음
• 통화별 계정 식별 - 회계 소프트웨어의 각 은행 계정은 올바른 통화로 설정해야 합니다.
• 일관된 열 구조 - 날짜, 설명, 금액 (또는 날짜, 설명, 차변, 대변)

4단계: 가져오기 및 조정

각 통화의 거래 내역을 회계 소프트웨어의 해당 은행 계정으로 가져옵니다. 주요 사항:

• 통화별 별도 계정 - 동일한 계정에 EUR 및 USD 거래 내역을 혼합하지 마십시오.
• 환율 처리 - 거래 수준에서 환율을 설정하거나 소프트웨어의 내장 환율 서비스를 사용합니다.
• 각 계정 독립적으로 조정 - 변환된 거래 내역을 원본 통화의 은행 잔액과 일치시킵니다.

환율 고려 사항

다중 통화 처리는 종종 어느 시점에서든 환율 변환을 포함합니다. 몇 가지 중요한 원칙:

추출 중에 변환하지 마십시오. 은행 명세서 변환 단계에서는 거래 내역을 원래 통화로 유지하십시오. 환율은 회계 소프트웨어에서 추적, 감사 및 조정할 수 있으므로 해당 소프트웨어에서 변환하십시오.

원본 금액을 기록하십시오. 귀하의 장부는 항상 변환된 금액 옆에 원래 통화 금액을 표시해야 합니다. 이는 감사 추적 및 원본 은행 명세서와의 조정에 필수적입니다.

일별 대 월별 요율. 대부분의 회계 목적상 거래 날짜의 일별 환율이 가장 정확합니다. 월 평균 요율은 많은 관할권에서 세금 목적으로 허용되지만 정확도는 떨어집니다.

회계 소프트웨어가 처리합니다. QuickBooks, Xero, Zoho Books 및 대부분의 최신 플랫폼에는 내장된 다중 통화 기능이 있습니다. 은행 명세서 파일에서 환율 변환을 시도하지 말고 소프트웨어에서 처리하도록 하십시오.

오른쪽에서 왼쪽으로 쓰는 언어 명세서

아랍어, 히브리어, 페르시아어, 우르두어 은행 명세서는 추가적인 과제를 제시합니다. 바로 오른쪽에서 왼쪽(RTL) 텍스트 방향입니다. 명세서 레이아웃은 예상하는 것과 유사할 수 있습니다. 계정 정보는 오른쪽에, 금액은 왼쪽에, 텍스트는 오른쪽에서 왼쪽으로 읽힙니다.

PDFSub는 RTL 명세서를 기본적으로 처리합니다. 추출 엔진은 시각적 레이아웃 방향을 해석하려고 시도하는 대신 실제 문자 데이터(PDF에 명시적인 방향 표시가 포함됨)를 읽습니다. 이는 아랍어 은행 명세서가 영어 명세서와 동일한 정확도로 추출된다는 것을 의미합니다.

아랍어 또는 히브리어 명세서를 다루는 경우 워크플로는 다른 언어와 동일합니다. 업로드, 자동 감지, 검토, 내보내기.

흔한 다중 통화 변환 실수

실수 1: 모든 날짜에 MM/DD를 가정하는 것

영국 은행 명세서의 03/06/2026 날짜는 3월 6일이 아니라 6월 3일입니다. 도구가 미국 형식을 가정하면 명세서의 모든 날짜가 틀립니다. 명세서 기간 헤더와 비교하여 날짜 형식을 항상 확인하십시오.

실수 2: 천 단위 구분 기호 규칙 무시

독일 금액 1.234는 1.234가 아니라 1234입니다. 도구가 마침표를 소수점 구분 기호로 취급하면 금액이 1000으로 나뉩니다.

실수 3: 추출 중에 통화 변환

은행 명세서 추출 단계에서 EUR 금액을 USD로 변환하면 나중에 감사하거나 조정할 수 없는 환율이 데이터에 고정됩니다. 원본 통화 금액을 유지하고 회계 소프트웨어에서 변환하십시오.

실수 4: 하나의 가져오기에서 통화 혼합

독일 EUR 거래 내역을 QuickBooks의 USD 은행 계좌로 가져오면 잘못된 항목이 생성됩니다. 각 통화는 회계 소프트웨어에서 자체 은행 계좌가 필요합니다.

실수 5: 인도 숫자 그룹화 미확인

인도의 라크 및 크로르 그룹화는 자주 잘못 해석됩니다. 10,00,000은 1,000,000(십 라크 = 백만)이지 100,000 또는 1,000,000.0이 아닙니다.

자주 묻는 질문

PDFSub는 은행 명세서의 언어를 어떻게 감지하나요?

PDFSub는 PDF의 텍스트 콘텐츠를 분석하여 언어를 식별합니다. 일반적인 은행 용어, 헤더 패턴 및 문자 세트를 확인합니다. 130개 이상의 언어를 인식하고 날짜 및 숫자 구문 분석에 해당하는 로캘 규칙을 적용합니다. 데이터베이스에 있는 20,000개 이상의 은행에서 가져온 명세서의 경우, 은행 템플릿 인식을 사용하여 정확도를 높입니다.

여러 언어가 혼합된 은행 명세서를 처리할 수 있나요?

예. 일부 국제 은행은 현지 언어 헤더와 영어 거래 설명이 포함된 명세서를 발행합니다. PDFSub는 기본 언어를 감지하여 형식 규칙(날짜, 숫자)을 적용하고 거래 설명의 원본 텍스트는 언어에 관계없이 유지하여 혼합 언어 명세서를 처리합니다.

소수 자리가 없는 통화(JPY, KRW)는 어떻게 처리하나요?

PDFSub는 소수 자리를 사용하지 않는 통화를 인식하고 올바르게 처리합니다. 15,000으로 표시된 일본 은행 명세서는 소수 부분이 없는 15000으로 추출됩니다. 이는 일부 회계 소프트웨어에서 형식 문제를 일으킬 수 있는 .00을 엔화 금액에 추가하는 도구의 일반적인 오류를 방지합니다.

QuickBooks 또는 Xero로 가져올 때 환율은 어떻게 처리하나요?

QuickBooks와 Xero 모두 내장된 다중 통화 기능을 갖추고 있습니다. 각 통화로 은행 계좌를 만들고, 원래 통화로 거래 내역을 가져오고, 소프트웨어에서 환율을 적용하도록 합니다. QuickBooks는 통합 서비스의 일별 요율을 사용합니다. Xero는 수동 또는 자동 요율 입력을 허용합니다. 핵심은 사전 변환된 금액이 아닌 원본 통화 금액을 가져오는 것입니다.

은행 명세서 PDF가 비라틴 스크립트(아랍어, 중국어, 일본어)인 경우 어떻게 되나요?

PDFSub는 PDF 데이터 계층에서 텍스트를 추출하며, 이 계층에는 스크립트에 관계없이 실제 문자 데이터가 포함됩니다. 아랍어, 중국어, 일본어, 한국어, 힌디어 및 기타 비라틴 스크립트가 모두 지원됩니다. 추출된 거래 내역은 설명에 원본 스크립트를 유지하면서 날짜와 금액은 선택한 출력 형식으로 정규화합니다.

요약

다중 통화 은행 명세서 처리는 환율 이상의 것입니다. 국가마다 날짜, 숫자, 통화 금액을 작성하는 근본적인 형식 차이를 처리하는 것입니다. 이 중 하나라도 잘못 처리하면 시간이 지남에 따라 누적되는 조용한 데이터 오류가 발생합니다.

PDFSub는 130개 이상의 언어로 20,000개 이상의 은행에서 언어, 날짜 형식 및 숫자 규칙을 자동 감지하여 이러한 복잡성을 제거합니다. 고객이 프랑크푸르트, 도쿄 또는 뭄바이에 있는 은행을 이용하든 워크플로는 동일합니다. PDF를 업로드하고, 추출을 검토하고, 회계 소프트웨어가 예상하는 형식으로 내보냅니다.

다중 통화 은행 명세서 처리 - 전 세계 모든 은행의 언어 및 형식을 자동 감지합니다.