다통화 은행 거래 내역서 처리 방법

귀하의 고객 리스트가 세 국가에 걸쳐 있다고 가정해 보겠습니다. 한 고객은 독일 은행을 이용하고, 다른 고객은 일본, 세 번째 고객은 인도 은행을 이용합니다. 매달 유로, 엔, 루피화로 된 은행 거래 내역서를 받게 되는데, 날짜 표기 방식이 다르고 소수점 처리 방식도 다르며, 금액 형식 또한 단일 로캘용으로 설계된 도구로는 처리하기 까다로운 방식으로 구성되어 있습니다.

이것이 바로 국제 회계 업무의 현실입니다. 다통화 은행 거래 내역서 처리는 단순히 환율만의 문제가 아닙니다. 국가마다 숫자, 날짜, 금융 문서를 형식화하는 근본적인 차이를 이해해야 합니다. 이를 잘못 처리하면 QuickBooks, Xero 또는 Zoho Books로 데이터를 가져올 때 오류가 발생하거나, 더 심각하게는 잘못된 데이터가 그대로 입력될 수 있습니다.

이 가이드에서는 다통화 은행 거래 내역서 처리 시 발생하는 문제점과 이를 올바르게 해결하기 위한 실무 워크플로우를 다룹니다.

국제 형식의 세 가지 레이어

서로 다른 국가의 은행 거래 내역서를 처리할 때는 로캘에 따라 달라지는 세 가지 독립적인 형식 시스템을 다루어야 합니다.

레이어 1: 날짜 형식

03, 06, 2026이라는 동일한 숫자가 내역서가 발행된 위치에 따라 완전히 다른 날짜를 나타낼 수 있습니다.

형식	관례	사용 국가	예시
MM/DD/YYYY	월-일-연도	미국, 필리핀	03/06/2026 = 3월 6일
DD/MM/YYYY	일-월-연도	영국, EU, 인도, 호주	03/06/2026 = 6월 3일
YYYY/MM/DD	연도/월/일	한국, 일본, 중국	2026/03/06 = 3월 6일
DD.MM.YYYY	일.월.연도	독일, 오스트리아, 스위스	03.06.2026 = 6월 3일
DD-MM-YYYY	일-월-연도	인도 (대체 형식)	03-06-2026 = 6월 3일
YYYY-MM-DD	ISO 8601	국제 표준	2026-03-06 = 3월 6일

가장 위험한 구간은 처음 두 가지입니다. 일이 12 이하일 때 03/06/2026은 3월 6일인지 6월 3일인지 모호합니다. 변환 도구가 이를 잘못 추측하면 내역서의 모든 날짜가 몇 달씩 어긋나게 됩니다. 이는 오류 메시지를 띄우지 않고 '조용히' 잘못된 데이터를 생성하며, 계정 조정(reconciliation) 단계나 세무 신고 시점이 되어서야 발견될 수 있습니다.

레이어 2: 숫자 형식

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

국가/지역	천 단위 구분 기호	소수점 구분 기호	예시 (100만 달러 50센트)
미국, 영국, 호주	쉼표 (,)	마침표 (.)	1,000,000.50
독일, 프랑스, 이탈리아, 스페인	마침표 (.)	쉼표 (,)	1.000.000,50
프랑스 (대체 형식)	공백	쉼표 (,)	1 000 000,50
인도	쉼표 (라크/크로르 단위)	마침표 (.)	10,00,000.50
스위스	아포스트로피 (')	마침표 (.)	1'000'000.50
한국, 일본, 중국	없음 (또는 쉼표)	없음 (소수점 없음, 원/엔은 정수 단위)	1,000,000

인도의 숫자 체계는 특별한 주의가 필요합니다. 인도는 서구의 천 단위 그룹화 대신 라크(lakh, 1,00,000 = 10만)와 크로르(crore, 1,00,00,000 = 1,000만) 그룹화를 사용합니다. 인도 회계사에게 12,34,567.89로 보이는 숫자는 서구 표기법으로 1,234,567.89입니다. 3자리 그룹화를 가정하는 표준 변환 도구는 인도 형식의 숫자를 잘못 해석할 가능성이 큽니다.

레이어 3: 통화 기호 및 위치

통화	기호	위치	예시
미국 달러	$	금액 앞	$1,234.56
유로	EUR	앞 또는 뒤	EUR1.234,56 또는 1.234,56 EUR
영국 파운드	GBP	금액 앞	GBP1,234.56
일본 엔	JPY	금액 앞	JPY1,234
인도 루피	INR 또는 Rs	금액 앞	INR12,34,567
사우디 리얄	ر.س	금액 뒤 (RTL)	١٢٣٤ ر.س
브라질 헤알	R$	금액 앞	R$1.234,56
스위스 프랑	CHF	금액 앞	CHF1'234.56

일본 엔화나 한국 원화처럼 소수점을 사용하지 않는 통화도 있습니다. 반면 바레인 디나르나 쿠웨이트 디나르처럼 소수점 세 자리를 사용하는 경우도 있습니다. 또한 아랍어와 같은 우측에서 좌측으로 읽는(RTL) 언어는 내역서 자체는 우측에서 좌측으로 읽히지만 숫자는 좌측에서 우측으로 읽히는 복잡성을 더합니다.

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

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

날짜는 MM/DD/YYYY 형식이다.
쉼표는 천 단위를, 마침표는 소수점을 구분한다.
통화 기호는 금액 앞에 위치한다.
텍스트는 왼쪽에서 오른쪽으로 읽는다.

이러한 도구에 날짜가 15.03.2026이고 금액이 1.234,56 EUR인 독일 은행 내역서를 입력하면, 도구가 충돌하거나 쓰레기 데이터를 생성합니다. 최악의 경우 쉼표와 마침표를 자동으로 바꿔버려 1.234,56을 1,234.56(정상)으로 만들거나, 1.234로 만들어 소수점 이하 데이터를 모두 유실시키기도 합니다.

PDFSub의 다통화 내역서 처리 방식

PDFSub의 은행 거래 내역서 변환기는 처음부터 국제적인 사용을 염두에 두고 설계되었습니다. 복잡한 각 레이어를 처리하는 방법은 다음과 같습니다.

자동 언어 및 형식 감지

PDFSub은 130개 이상의 언어를 지원하며 은행 거래 내역서의 언어를 자동으로 감지합니다. 독일어 내역서임을 확인하면 자동으로 독일어 형식 관례를 적용합니다. 일본어 내역서는 일본 관례를, 인도 국립은행(SBI)의 내역서는 인도 숫자 그룹화 방식을 따릅니다.

이 감지는 문서 수준에서 이루어지므로 각 내역서마다 로캘을 수동으로 설정할 필요가 없습니다.

지능형 날짜 파싱

PDFSub은 모호한 날짜를 발견하면 내역서의 문맥 단서를 사용하여 이를 해결합니다.

내역서 헤더 날짜 — 내역서 기간 날짜는 보통 모호하지 않습니다 (예: "Statement Period: January 1 - January 31, 2026").
순차적 로직 — 거래가 연대순으로 나타나고 날짜가 특정 패턴을 따르면 형식을 유추할 수 있습니다.
은행 템플릿 인식 — PDFSub은 20,000개 이상의 은행 템플릿을 인식하며, 이 중 상당수는 이미 알려진 날짜 형식 관례를 가지고 있습니다.

숫자 형식 표준화

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

독일의 1.234,56은 CSV 출력 시 1234.56이 됩니다.
인도의 12,34,567.89는 1234567.89가 됩니다.
프랑스의 1 234 567,89는 1234567.89가 됩니다.
스위스의 1'234.56은 1234.56으로 유지됩니다.

정규화 대상은 내보내기 형식과 대상 회계 소프트웨어에 따라 달라집니다. 미국 로캘의 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의 은행 거래 내역서 변환기를 통해 각 내역서를 처리합니다.

PDF 업로드
PDFSub이 언어 및 형식을 자동 감지
추출된 거래 내역 검토 — 원본과 날짜 및 금액 대조
대상 형식(CSV, Excel, OFX, QBO, QIF)으로 내보내기

중요 검토 단계: 각 변환 시 최소 3~5개의 거래를 무작위로 확인하세요.

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

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

회계 소프트웨어로 가져오기 전에 일관성을 확보하세요.

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

4단계: 가져오기 및 조정

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

통화별 계좌 분리 — 동일한 계좌에 EUR과 USD 거래를 섞지 마세요.
환율 처리 — 거래 수준에서 환율을 설정하거나 소프트웨어의 내장 환율 서비스를 사용하세요.
각 계좌를 독립적으로 조정 — 변환된 거래를 원래 통화의 은행 잔액과 대조하세요.

환율 고려 사항

다통화 처리에는 어느 시점에서든 환율 변환이 포함됩니다. 몇 가지 중요한 원칙은 다음과 같습니다.

추출 중에 변환하지 마세요. 은행 거래 내역서 변환 단계에서는 거래를 원래 통화로 유지하세요. 환율 변환은 환율을 추적, 감사 및 조정할 수 있는 회계 소프트웨어 내에서 수행하는 것이 좋습니다.

원래 금액을 기록하세요. 장부에는 항상 변환된 금액과 함께 원래 통화 금액이 표시되어야 합니다. 이는 감사 추적 및 원본 은행 거래 내역서와의 대조를 위해 필수적입니다.

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

회계 소프트웨어가 이를 처리합니다. QuickBooks, Xero, Zoho Books 및 대부분의 현대적인 플랫폼에는 다통화 기능이 내장되어 있습니다. 환율 변환은 소프트웨어에 맡기고 은행 거래 내역서 파일에서 직접 처리하려고 하지 마세요.

우측에서 좌측으로 읽는(RTL) 언어 내역서

아랍어, 히브리어, 페르시아어, 우르두어로 된 은행 거래 내역서는 텍스트 방향(RTL)이라는 추가적인 과제를 안겨줍니다. 내역서 레이아웃이 우리가 예상하는 것과 반대일 수 있습니다. 계좌 정보는 오른쪽에, 금액은 왼쪽에 있으며 텍스트는 오른쪽에서 왼쪽으로 읽힙니다.

PDFSub은 RTL 내역서를 기본적으로 지원합니다. 추출 엔진은 시각적 레이아웃 방향을 해석하려 하기보다 PDF 내의 기본 텍스트 데이터(명시적인 방향 마커가 포함됨)를 읽습니다. 즉, 아랍어 은행 거래 내역서도 영어 내역서와 동일한 정확도로 추출됩니다.

아랍어 또는 히브리어 내역서로 작업하는 경우 워크플로우는 다른 언어와 동일합니다. 업로드, 자동 감지, 검토, 내보내기 순으로 진행하면 됩니다.

다통화 변환 시 흔히 하는 실수

실수 1: 모든 날짜를 MM/DD로 가정함

영국 은행 내역서의 03/06/2026은 3월 6일이 아니라 6월 3일입니다. 도구가 미국 형식을 가정하면 내역서의 모든 날짜가 틀리게 됩니다. 항상 내역서 헤더의 기간을 확인하여 날짜 형식을 검증하세요.

실수 2: 천 단위 구분 기호 관례 무시

독일 내역서의 금액 1.234는 1.234가 아니라 1,234(천이백삼십사)입니다. 도구가 마침표를 소수점 구분 기호로 취급하면 금액을 1,000으로 나눈 꼴이 됩니다.

실수 3: 추출 중 통화 변환

은행 거래 내역서 추출 단계에서 EUR 금액을 USD로 변환하면 나중에 감사하거나 조정할 수 없는 환율이 데이터에 고정되어 버립니다. 원래 통화 금액을 유지하고 회계 소프트웨어에서 변환하세요.

실수 4: 한 번의 가져오기에 여러 통화 혼합

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

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

인도의 라크와 크로르 그룹화는 자주 오해를 받습니다. 10,00,000은 100,000이나 1,000,000.0이 아니라 1,000,000(10라크 = 100만)입니다.

자주 묻는 질문(FAQ)

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를 업로드하고, 추출 내용을 검토하고, 회계 소프트웨어가 기대하는 형식으로 내보내기만 하면 됩니다.

다통화 은행 거래 내역서 처리하기 — 전 세계 모든 은행의 언어와 형식을 자동으로 감지합니다.