SAP OB07 환율 타입 설정 방법을 OB07, OBBS, OB08와 TCURF·TCURR 기준으로 정리했습니다. 외화 전표 오류, 환산 금액 이상, 외화평가 차이 원인까지 바로 추적할 수 있습니다.
외화 전표는 되는데 금액이 이상하다면, OB07만 보면 거의 놓칩니다
SAP OB07 환율 타입 설정 방법을 제대로 이해하지 못하면, 외화 전표 오류와 재무제표 불일치가 반복됩니다.
현업에서는 보통 이렇게 시작합니다.
OB07에서 환율 타입은 이미 만들었습니다. 그런데 FB50이나 F-02에서 외화 전표를 입력할 때 기대한 환율이 잡히지 않거나, TCURR에는 환율이 있는데 환산 금액이 이상하게 계산됩니다. 더 늦게는 외화평가 실행 시점에 결과가 예상과 다르게 나오면서 문제를 찾기 시작합니다.
여기서 많이 헷갈립니다.
환율 타입은 “OB07에서 키 하나 만드는 작업”이 아닙니다. 실제로는 다음 구조를 같이 봐야 합니다.
- OB07: 환율 타입 정의
- OBBS: 환산 비율 정의
- OB08: 실제 환율값 입력
- TCURF: 환산 비율 저장
- TCURR: 환율값 저장
즉, 문제의 본질은 단일 T-code가 아니라 OB07–TCURF–TCURR의 일관성입니다.
주니어는 설정 흐름을 이해해야 하고, 운영 담당자는 오류 원인을 빠르게 분기해야 하며, 시니어는 DEV 반영 전 검증 체크리스트를 잡아야 합니다. 이 글은 “어떻게 설정하느냐”보다 “설정 후 무엇을 검증해야 하느냐”에 더 무게를 둡니다.

환율 타입은 환율 자체가 아니라 ‘사용 목적’을 구분하는 키입니다
환율 타입은 숫자 환율이 아닙니다.
같은 USD/KRW라도 어떤 업무 목적으로 쓸 것인지를 구분하는 기준 키입니다.
대표적으로 많이 보는 예시는 아래와 같습니다.
- M: 평균환율 성격으로 기본 FI 환산에서 자주 사용
- B: 은행 매입/매도 환율 성격으로 운용
- G: 평가 또는 특정 재무보고 목적용으로 운용 가능
- Z*: 회사 내부 운영 목적의 커스텀 환율 타입
이 구조가 필요한 이유는 단순합니다.
동일 통화쌍이라도 실제 거래 환산, 월말 외화평가, Treasury 평가, 내부관리 환산이 모두 같은 기준을 쓰지 않을 수 있기 때문입니다.
SAP 내부 흐름을 간단히 정리하면 이렇습니다.
-
환율 타입이 정의되어 있어야 합니다.
-
통화쌍별 환산 비율이 맞아야 합니다.
-
유효일자 기준 환율값이 존재해야 합니다.
-
전표 입력이나 평가 프로그램이 그 조합을 읽어 환산합니다.
실무에서는 이 순서 중 하나라도 빠지면 문제가 납니다.
특히 TCURR 값만 있고 TCURF가 비어 있는 경우, JPY나 IDR처럼 단위 이슈가 있는 통화에서 금액이 100배 또는 100분의 1처럼 보이는 현상이 발생할 수 있습니다. 화면상으로는 단순해 보이지만, 내부적으로는 데이터 성격이 다릅니다.

SPRO에서 어디를 보고, 어떤 순서로 맞춰야 하는가
환율 타입 설정 단계는 보통 아래 순서로 보는 것이 가장 안전합니다.
- OB07 → 환율 타입 정의
- OBBS → Translation Ratios 정의
- OB08 → 환율값 입력
- 전표/평가 테스트 → 실제 적용 확인
1) OB07에서 먼저 확인할 것
일반적으로 안내되는 경로는 다음과 같습니다.
SPRO → SAP Reference IMG → General Settings → Currencies → Check Exchange Rate Types
일부 시스템에서는 상위 노드 표시가 SAP NetWeaver 기준으로 보일 수 있습니다. IMG 메뉴 구성은 릴리즈에 따라 화면상 표현 차이가 있을 수 있으므로, 메뉴명이 약간 다르면 T-code 기준으로 확인하는 것이 빠릅니다.
OB07에서 핵심은 환율 타입 키를 만드는 것 자체보다, 이 타입을 어떤 목적으로 쓸지 명확히 정하는 것입니다.
실무에서 체크할 포인트:
- 기존 표준 타입 M을 그대로 쓸지
- Z타입을 따로 만들지
- Buying/Selling Rate 구분이 필요한지
- Fixed Rate 성격으로 관리할지
이 설정은 직접 전표를 만들지는 않습니다.
다만 이후 전표 입력, 외화평가, TRM 평가, 인터페이스 로직에서 어떤 환율 타입을 읽을지 결정하는 출발점이 됩니다. 그래서 OB07만 생성하고 실제 프로그램에서 그 타입을 참조하지 않으면, “만들어놨는데 안 쓰인다”는 상황이 생깁니다.
2) OBBS에서 자주 빠뜨리는 Translation Ratio
다음으로 봐야 하는 곳이 OBBS입니다.
일반적으로 확인 경로는 다음과 같습니다.
SPRO → SAP Reference IMG → General Settings → Currencies → Define Translation Ratios for Currency Translation
이 설정의 저장 테이블로 많이 확인하는 것이 TCURF입니다.
여기서 핵심은 이것이 환율값이 아니라는 점입니다.
환산 비율, 즉 통화 단위를 어떻게 해석할지를 정의하는 영역입니다.
예를 들어:
- USD : EUR 는 보통 1:1로 보는 경우가 많습니다.
- USD : JPY 는 운영 방식에 따라 1:100 같은 비율 정의가 중요할 수 있습니다.
이 부분은 실제 운영에서 꼭 나눠서 봐야 합니다.
특히 환율 자체는 TCURR에 있어도, 비율 정의가 없거나 잘못되어 있으면 전표 환산 금액이 비정상적으로 계산될 수 있습니다. 처음 등록하는 환율의 경우에는 반드시 요청한 현업에게 환산비율이 맞는지 확인하고, 금액이 정상적으로 계산되는지 확인을 받아야 합니다.
3) OB08에서 실제 환율값을 넣는다
실제 숫자 환율은 보통 OB08에서 관리합니다.
SPRO → SAP Reference IMG → General Settings → Currencies → Enter Exchange Rates
저장 테이블은 일반적으로 TCURR입니다.
주요 확인 포인트:
- 환율 타입
- From Currency / To Currency
- Valid From Date
- Exchange Rate
운영자가 자주 놓치는 것은 유효일자입니다.
“환율은 있는데 못 읽는다”는 이슈 상당수는 값이 없어서가 아니라, 전표일자 또는 평가기준일에 맞는 유효일자 환율이 없기 때문입니다.
특히 월말 외화평가나 백데이팅 전표에서는 더 자주 드러납니다. 보통 회사에서는 환율이 들어오지 않은 경우 해당일자 외화 전표를 치지 못하도록 Exit을 걸어두기도 합니다.
왜 전표 입력 시점이 아니라 나중에 문제가 터지는가
이 설정은 직접 전표를 발생시키는 IMG가 아닙니다.
그렇지만 후속 프로그램에서 금액 계산 로직에 들어가기 때문에, 설정 오류가 늦게 드러나는 경우가 많습니다.
내부 처리 로직 관점에서 보면 최소한 아래 세 가지를 이해해야 합니다.
첫째, SAP는 환율 타입 + 통화쌍 + 유효일자를 함께 읽습니다
전표 입력 또는 평가 시점에 시스템은 단순히 “USD/KRW 환율”만 보는 것이 아닙니다.
- 어떤 환율 타입인가
- 어떤 통화쌍인가
- 기준일자가 언제인가
- 환산 비율이 어떻게 정의됐는가
이 조합이 맞아야 정상 환산이 됩니다.

둘째, TCURR만 맞아도 충분하지 않습니다
실무에서 가장 흔한 착각입니다.
TCURR에 값이 있으면 끝이라고 생각하기 쉽습니다. 하지만 SAP는 필요한 경우 TCURF의 환산 단위도 함께 고려합니다. 그래서 JPY, IDR처럼 자리수 체감이 큰 통화는 특히 주의해야 합니다.

셋째, 환율 타입이 실제 업무 프로세스에 연결되어 있어야 합니다
환율 타입을 만들어도 전표 입력, 평가 실행, 인터페이스 프로그램이 그 타입을 참조하지 않으면 아무 효과가 없습니다.
즉, 설정 자체보다 적용 지점이 중요합니다.
FI에서는 외화 전표 입력과 외화평가에서 차이가 드러나고, TRM이나 다른 모듈에서는 별도 로직 또는 목적별 환율 타입 사용이 있을 수 있습니다. 이 부분은 버전과 활성 기능에 따라 실제 참조 지점이 다를 수 있으므로 시스템에서 확인이 필요합니다.
회계적으로 보면 이 설정은 ‘금액 측정 기준’을 정하는 일입니다
환율 타입 설정은 계정결정처럼 차변/대변을 직접 만드는 설정은 아닙니다.
그래도 회계적으로는 매우 중요합니다. 이유는 전표 금액 측정 기준을 바꾸기 때문입니다.
예를 들어 외화 매입채무 전표를 입력한다고 보면:
| 구분 | Posting Key | 계정 예시 | 회계 8요소 | 의미 |
|---|---|---|---|---|
| 차변 | 40 | 원재료/비용 계정 | 비용 증가 | 회사 비용 인식 |
| 대변 | 31 | 공급업체 | 부채 증가 | 외화 채무 인식 |
여기서 환율 타입과 환율값이 잘못되면 무엇이 달라질까요?
- 원화 환산 금액이 틀어집니다.
- 공급업체 채무 잔액이 기대와 다르게 잡힙니다.
- 외화평가 기준금액이 달라집니다.
- 재무제표상 외화 관련 손익이 달라질 수 있습니다.
즉, 이 설정은 직접 분개를 만들지 않지만 분개 금액을 좌우합니다.
그래서 운영 반영 전에 AP, AR, 월말 평가까지 같이 테스트해야 합니다.

ECC와 S/4HANA에서 무엇이 같고 무엇이 실무적으로 달라지는가
핵심 구조 자체는 크게 다르지 않습니다.
- 환율 타입 정의
- 환산 비율 정의
- 유효일자별 환율 관리
이 기본 골격은 ECC와 S/4HANA 모두 동일한 이해로 접근해도 됩니다.
다만 실무적으로는 차이가 있습니다.
- S/4HANA에서는 Universal Journal 기반으로 금액 정합성 검증 범위가 더 넓게 체감될 수 있습니다.
- 외화평가 결과 확인 시 기존 총계정 중심 확인 외에 Universal Journal 기준 점검이 더 중요해집니다.
- 조회 방식은 CDS나 Fiori 앱 기반으로 확장될 수 있지만, 실제 환율 기본 데이터 검증은 여전히 TCURR, TCURF를 같이 보는 것이 가장 빠릅니다.
버전별 세부 동작이나 특정 앱 사용 여부는 시스템 구성에 따라 다를 수 있습니다.
그래도 운영자 관점에서는 “OB07만 보지 말고 TCURF와 TCURR를 함께 본다”는 원칙이 변하지 않습니다.
운영을 하시면서 만약 외화 관련 이슈가 발생했을 때 사용자가 “환율이 이상하다”고 말하면 바로 OB08부터 열지 마세요. 먼저 어떤 환율 타입이 실제 프로세스에서 사용되는지 확인하고, 그 다음 TCURR 유효일자, 마지막으로 TCURF 비율을 보아야 원인을 빨리 좁힐 수 있습니다.

QA에서 반드시 돌려봐야 하는 최소 검증 흐름
설정이 끝났다면 DEV에서 끝난 것이 아닙니다.
이 주제는 IMG 설정이므로 기본적으로 CTS 대상입니다. 즉, DEV에서 정의한 Customizing은 QA와 PRD로 이관할 수 있습니다. 다만 실제 환율값 운영 방식은 회사 정책에 따라 직접 입력 통제 여부가 다를 수 있으므로, PRD 운영 절차는 내부 통제를 따라야 합니다.
검증은 최소 아래 수준까지 가야 합니다.
| Step | 작업 | 입력값 예시 | 확인 화면/테이블 | 기대 결과 |
|---|---|---|---|---|
| 1 | 환율 타입 존재 확인 | Rate Type ZM | OB07 / 관련 IMG | 타입 존재 |
| 2 | 환산 비율 확인 | USD/JPY | OBBS / TCURF | 비율 정상 |
| 3 | 환율값 확인 | ZM, USD/JPY, 2026.05.01 | OB08 / TCURR | 유효일자 환율 존재 |
| 4 | 외화 전표 테스트 | 회사코드 1000, 통화 USD | FB50 또는 F-02 | 환산 금액 정상 |
| 5 | AP 또는 AR 테스트 | 공급업체/고객 전표 | FB60/FB70 등 운영 프로세스 | 서브레저 금액 정상 |
| 6 | 외화평가 확인 | 월말 기준일 | 관련 평가 실행 화면 | 기대 환산 결과 확인 |
입력값은 예시를 한번 들어보았는데요,
회사코드 1000, 환율 타입 ZM, 통화 USD/JPY 같은 값은 가상의 예시로 보면 됩니다.
실무에서는 최소 3개 시나리오를 나눠서 보는 것이 좋습니다.
-
직접 G/L 외화 전표
-
AP 또는 AR 외화 전표
-
월말 외화평가
이 세 가지가 모두 맞아야 실제 운영 반영 후 사고가 줄어듭니다.

실행은 되는데 결과가 이상할 때, 원인을 이렇게 나누면 빨라집니다
아래 표는 운영에서 자주 보는 증상들을 원인별로 나눈 것입니다.
| 증상/오류 | 원인 | 확인 위치 | 해결 방법 | 주의사항 |
|---|---|---|---|---|
| Exchange rate not found | 해당 일자 환율값 없음 | OB08 / TCURR | 유효일자 기준 환율 입력 | 전표일자와 평가기준일 분리 확인 |
| Translation ratio missing | 환산 비율 누락 | OBBS / TCURF | 통화쌍 비율 설정 | JPY, IDR 등 단위 이슈 주의 |
| No rate found for type XXX | 타입은 있으나 타입별 환율 없음 | OB07, OB08, TCURR | 환율 타입 + 통화쌍 조합으로 값 입력 | M 타입과 Z 타입 혼용 여부 확인 |
| 환율은 있는데 금액이 100배/100분의 1처럼 보임 | TCURF 비율 불일치 | TCURF, TCURR | 비율 재점검 후 테스트 | 운영 데이터 영향 전 재검증 필요 |
| OB07은 만들었는데 실전표에서 안 씀 | 프로세스 참조 환율 타입 불일치 | 전표 입력 규칙, 평가 설정, 인터페이스 로직 | 실제 사용 환율 타입 확인 후 정렬 | 모듈별 사용 타입이 다를 수 있음 |
이 표에서 핵심은 “설정 문제냐, 데이터 문제냐”를 먼저 나누는 것입니다.
- Customizing 문제: OB07, OBBS
- Master/기준 데이터 문제: TCURR 유효일자, 통화쌍
- 프로세스 적용 문제: 실제 참조하는 환율 타입 불일치
이렇게 분류하면 쓸데없이 테이블만 뒤지지 않게 됩니다.

운영 반영 전 마지막으로 체크할 것
이 주제는 단순 정의형이 아니라 운영 영향이 큽니다.
마지막 체크포인트를 짧게 정리하면 아래와 같습니다.
- 새 환율 타입 생성 시 네이밍 규칙을 먼저 정할 것
- OB07 생성 후 반드시 OBBS와 OB08까지 연계 확인할 것
- TCURR는 값 존재 여부보다 유효일자 적합성을 확인할 것
- JPY, IDR 등은 TCURF 비율을 먼저 의심할 것
- FI, TRM, 평가 프로그램이 같은 환율 타입을 쓰는지 확인할 것
- DEV 설정 완료 후 QA에서 외화 전표와 외화평가까지 검증할 것
- PRD 반영 전 운영팀이 환율 유지 주체와 입력 시점을 합의할 것
정리를 해보자면 환율 타입 설정은 작아 보일 수 있습니다.
하지만 실제로는 외화 전표, 평가 손익, 재무제표 정합성까지 연결됩니다.
그래서 OB07만 맞추고 끝내면 안 됩니다. OB07 → TCURF → TCURR → 실제 전표 검증까지 가야 비로소 설정이 끝난 것입니다.

참고 자료
- SAP Help Portal – Currency Translation — 환산 구조와 통화 관련 표준 개념을 확인할 때 참고할 수 있습니다.
- SAP Help – Exchange Rate Types — 환율 타입과 관련된 제품 문서 진입점으로 활용할 수 있습니다.
- SAP Notes — 버전별 세부 동작이나 개별 오류는 Support Portal에서 추가 확인이 필요합니다.
- SAP Best Practice — 통화 및 환율 운영 절차를 Best Practice 관점에서 참고할 수 있습니다.