SAP 수입 은행별 L/C 한도 사용률 점검 — 신용장 점유액을 다시 계산해 약정 한도와 은행 통지에 견주고 해제 후보를 가리는 수입 자금 화면

소개 영상블로그 목차 순서대로 · 자막 포함8개 장면 · 1분 22초처음 연 화면 → 점검 필요만 조회 → 해제 후보 → 통화별 · 구간별 → 한도 상세 → 대사 결과

주요 재생 지점

도입 포인트 — 이 앱을 사용해야 하는 이유

수입 대금을 신용장(L/C)으로 치르는 회사에는 늘 같은 질문이 따라붙습니다. 이 은행에 한도가 얼마나 남았나, 은행이 말하는 사용액과 우리 장부가 같은가, 다 쓴 신용장이 한도를 붙잡고 있지는 않은가. 지금 이 답들은 은행 통지서 · 구매 · 자금 담당의 엑셀에 흩어져 있어, 개설 직전에 한도가 모자란다는 것을 알게 되는 일이 생깁니다. 이 앱은 신용장 한 건 한 건의 점유액을 다시 계산해 은행 단위로 합치고, 어긋난 은행에는 이유 후보까지 붙여 먼저 볼 순서를 정해 줍니다.

한 줄 요약 — 조회만 하는 리포트는 사용률을 보여 줄 뿐 그 숫자가 믿을 만한지는 사람이 따집니다. 이 앱은 점유액을 미사용 잔액 + 선적 후 미결제로 풀어 신용장마다 계산하고, 은행 · 통화 · 유효기간 구간 어느 방향으로 더해도 같은지 대사식 아홉 가지로 스스로 검산합니다. 최종 판단은 회사와 은행이 하며, 이 화면은 점검 후보를 가리는 도구입니다.

핵심 포인트 여섯 가지

포인트	고객이 얻는 것	지금 방식이라면
① 은행별 사용률을 다시 계산	신용장별 점유액을 합쳐 약정 한도 대비 사용률과 여유 한도를 은행마다 보여 줍니다.	은행 통지서와 엑셀 표를 사람이 맞춥니다.
② 은행 통지와 견주기	은행이 통지한 사용액과 재계산 점유액의 차이를 금액과 비율로 보여 주고, 취소 미반영 후보를 함께 적습니다.	차이가 있다는 것은 알아도 어느 신용장 때문인지 하나씩 뒤집니다.
③ 해제 후보를 걷어 낸 사용률	유효기간이 지났는데 잔액이 남은 신용장을 가려 풀면 사용률이 얼마로 내려가는지 미리 보여 줍니다.	만기 지난 신용장은 담당자 기억에 의존합니다.
④ 만기 구간으로 보기	점유액을 유효기간이 가까운 순서로 나눠 언제 한도가 풀릴지, 언제 연장을 정해야 할지 알려 줍니다.	신용장 목록을 만기 순으로 따로 정렬합니다.
⑤ 통화는 합치지 않는다	다른 통화의 외화는 더하지 않고 원화 환산 금액으로만 합산해 통화별 점유를 따로 볼 수 있습니다.	통화가 섞인 합계를 환산해 놓고 근거를 잃어버립니다.
⑥ 스스로 하는 대사	화면의 모든 합계가 서로 맞는지 아홉 줄로 보여 주어 숫자를 믿는 근거를 같은 화면에서 확인합니다.	검산은 검토자가 따로 합니다.

이 글은 먼저 실제 화면 일곱 장을 보고, 이어서 SAP 표준 기능과 어디가 이어지는지, 운영으로 올릴 때의 CDS 구성, 그리고 도입 상담에서 자주 나오는 질문 순서로 구성했습니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 가상 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

처음 열었을 때

**처음 연 화면 — 다섯 은행을 한 표에** — 다섯 은행의 약정 한도 · 점유액 · 사용률 · 은행 통지 차이가 한 표에 놓입니다. 위쪽 요약에는 은행 5 · 약정 한도 22,000,000,000원 · 점유액 15,873,496,575원 · 전체 사용률 72.15% · 점검 필요 은행 3 · 해제 후보 1,647,400,425원이 뜹니다.

조회조건은 모두 선택이고 "전체"로 두면 조건을 보내지 않습니다. 화면을 열면 기본 조건으로 한 번 자동 조회합니다. 모든 금액은 원화 환산이며 서로 다른 통화의 외화는 합치지 않습니다. 한도 · 환율 · 기준은 모두 가정값이라고 화면 맨 위에 적어 두었습니다.

**점검 필요만 조회 — 먼저 볼 은행** — 점검 상태를 "점검 필요"로 고르고 입력 칸에서 Enter 키로 조회한 결과입니다. 한도 초과 · 점검 기준 이상 · 통지 차이가 있는 은행만 남습니다.

라온은행은 사용률 105.58% 로 약정 한도를 넘었고(여유 한도 −128,318,465원), 다온은행은 92.48% 로 점검 기준(90%)을 넘었으며, 마루은행은 사용률은 47.98% 이지만 은행 통지 사용액이 재계산 점유액보다 1,064,433,440원 큽니다. 한 은행에 둘 이상 걸리면 가장 무거운 코드를 대표로 하고 나머지는 점검 내용에 이어 적습니다.

남은 한도와 만기 보기

**해제 후보 신용장 — 쓰지 않고 남은 한도** — L/C 내역 탭에서 해제 후보만 고른 결과입니다. 유효기간이 기준일을 지났는데 미사용 잔액이 남은 신용장 7건이 나옵니다.

해제 후보의 미사용 잔액을 원화로 바꿔 더하면 1,647,400,425원입니다. 이것은 "풀면 이만큼 여유가 생길 수 있다"는 후보일 뿐이고, 실제로 풀 수 있는지는 거래 은행과 회사가 정합니다. 화면은 해제 가능 여부를 단정하지 않고 "확인 필요"로만 적습니다.

**통화별 — 외화는 합치지 않는다** — 은행 · 통화마다 점유를 외화와 원화로 따로 집계한 탭입니다. 서로 다른 통화의 외화는 합치지 않고 원화 환산 금액으로만 합산합니다.

통화별 행 13개의 원화 점유를 모두 더하면 15,873,496,575원으로, 은행별 점유 합계와 같아야 합니다. 이 일치가 대사 03 번이며 차이는 0 입니다. 환율은 기준일 가정값이라 실제 고시값이 아닙니다.

**유효기간 구간 — 언제 풀리는가** — 점유액을 유효기간이 가까운 순서(경과 · 30일 이내 · 31~60일 · 61~90일 · 91일 이상)로 나눈 탭입니다.

구간 25행의 합계도 은행별 점유 합계와 같습니다(대사 04). 경과 구간은 해제 후보와 겹치고, 30일 이내 구간은 선적 예정이 있는지 연장할지 정해야 하는 자리입니다. 구간 경계는 샘플 기준일 2026-09-30 을 가정해 나눈 것입니다.

숫자를 믿어도 되는가

**대사 결과 — 스스로 한 검산** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

은행 한 곳을 풀어 보기

SAP 표준 기능 확장 포인트

이 앱은 표준을 대체하지 않습니다. 구매 오더 · 대금 결제는 표준이 이미 기록하고 있고, 끊기는 곳은 신용장 한도 점유를 은행 단위로 모아 약정 한도와 은행 통지에 견주는 자리입니다. 표준이 하는 일은 그대로 두고 그 자리만 이어 붙입니다.

표준에서 어디를 보는가

문서 · 기능	표준에서 보는 곳	표준이 못 하는 일	이 앱이 더하는 것
구매 발주	구매 오더 조회 `ME23N` (헤더 `EKKO` · 품목 `EKPO`)	신용장 개설 금액과 은행 한도 점유를 이어 보여 주지 않습니다.	발주 금액 · 통화를 L/C 개설의 근거로 삼아 점유 계산에 씁니다.
대금 결제	공급자 개별 항목 `FBL1N`	결제가 신용장 점유를 얼마나 풀었는지 은행 한도 관점으로 모으지 않습니다.	선적 후 미결제와 결제 완료 금액을 나눠 점유에 반영합니다.
환율	환율표 `TCURR`	신용장 점유를 어느 일자 환율로 환산할지 정하지 않습니다.	기준일 환율로 원화 환산해 외화와 원화를 따로 보여 줍니다(이 자료에서는 가정값).
L/C 개설 · 은행 약정 한도	회사마다 다름 — 표준 위치는 확인 필요	한도 점유를 은행별로 합산해 약정에 견주는 표준 화면을 확정하기 어렵습니다.	신용장 원장과 약정 한도를 이 앱의 서비스 구조로 받아 사용률을 계산합니다.
은행 통지	은행 자료(전문 · 통지서) — 연결 방식 확인 필요	통지 사용액과 장부 점유의 차이를 신용장 단위로 풀지 않습니다.	통지 − 재계산 점유 차이와 취소 미반영 후보를 보여 줍니다.

표의 표준 이름은 일반적인 배치를 적은 것입니다. 신용장 개설 정보와 은행 약정 한도를 어느 테이블이나 사용자 정의 구조가 들고 있는지는 환경마다 다르므로, 도입 전에 가장 먼저 확인합니다.

이 앱의 서비스 구성

엔티티셋	건수(검증용 자료)	한 행이 뜻하는 것
`BankSet`	5	은행 한 곳 — 약정 한도 · 점유액 · 사용률 · 통지 차이 · 해제 후 사용률 · 판정
`LcSet`	60	신용장 한 건 — 금액 분해 · 점유(외화/원화) · 해제 후보 · 판정 문장
`CurSet`	13	은행 × 통화 — 외화 점유와 원화 환산
`BucketSet`	25	은행 × 유효기간 구간 — 건수와 점유액
`ReconSet`	9	대사 한 줄 — 좌변 · 우변 · 검사 건수 · 차이 건수 · 점검 대상 건수

서비스 이름은 lclimit_srv 이고 OData V2 입니다. 화면은 $filter · $orderby · $top · $inlinecount 와 읽기 전용 펑션 하나(GetMaxUtilPct, 필터를 건 은행들의 최고 사용률)만 씁니다. 같은 주소를 CDS 기반 서비스가 이어받으면 화면은 고치지 않아도 됩니다.

대사 결과 — 전수 검증

번호	대사	검사 건수	차이 건수
01	L/C별 점유액 합계 = 은행별 점유액	60	0
02	점유 외화 × 기준일 환율 = L/C 원화 점유	60	0
03	통화별 원화 점유 합계 = 은행별 점유액	13	0
04	유효기간 구간 합계 = 은행별 점유액	25	0
05	개설 금액 = 선적 사용 금액 + 미사용 잔액	60	0
06	점유 금액 = 미사용 잔액 + 선적 후 미결제 (진행 중 L/C)	60	0
07	은행 통지 사용액 − 취소 미반영 = 재계산 점유액	5	0 (점검 대상 3)
08	점유액 − 해제 후보 = 해제 후 점유액	60	0 (점검 대상 7)
09	약정 한도 = 점유액 + 여유 한도	5	0 (점검 대상 1)

모든 대사에서 차이는 0 입니다. 원화 점유 합계 15,873,496,575원이 신용장별 · 은행별 · 통화별 · 만기 구간별 어느 경로로 더해도 같습니다.

CDS 구성

데모를 신청하신 고객께 공개되는 내용입니다

CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.

데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모 신청하기 Google 계정으로 로그인

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 적었습니다.

숫자와 판정

은행별 L/C 한도 사용률 점검은 무엇을 합니까?

은행이 준 약정 한도에 대해 회사의 신용장이 얼마나 한도를 쓰고 있는지를 신용장 단위로 다시 계산해 은행마다 합산하고, 은행이 통지한 사용액과 견주어 어긋난 곳을 가립니다. 한도 초과 · 점검 기준 이상 · 통지 차이 · 해제 후보를 한 화면에서 먼저 볼 순서대로 보여 주는 점검 도구이며, 한도를 바꾸거나 신용장을 취소하지는 않습니다.

점유액은 무엇을 기준으로 계산합니까?

진행 중인 신용장의 미사용 잔액과 선적 후 아직 결제하지 않은 금액을 더한 값을 기준일 환율로 원화 환산한 것입니다. 종결 · 취소된 신용장은 제외합니다. 개설 금액 = 선적 사용 + 미사용, 선적 후 미결제 = 선적 사용 − 결제 완료의 관계가 성립해야 하며 대사 05 · 06 번이 이를 전수로 확인합니다. 회계기준이 정한 산식이 아니라 한도 운영을 점검하기 위한 업무 지표이고, 회사와 은행의 약정 방식이 다르면 정의부터 맞춰야 합니다.

사용률과 여유 한도는 어떻게 구합니까?

사용률 = 점유액 ÷ 약정 한도 × 100, 여유 한도 = 약정 한도 − 점유액입니다. 이 자료에서 라온은행은 점유액이 약정 한도 2,300,000,000원을 넘어 사용률 105.58%, 여유 한도 −128,318,465원이었습니다. 전체로는 점유액 15,873,496,575원이 약정 한도 합계 22,000,000,000원의 72.15% 입니다.

판정 코드는 어떻게 나뉩니까?

은행 단위로 한도 초과(OVER) · 점검 기준 이상(NEAR) · 통지 차이(NOTI) · 주의(WARN)를 두고, 신용장 단위로 해제 후보(REL) · 취소 미반영(PEN) · 유효기간 임박(EXP)을 둡니다. OVER · NEAR · NOTI · REL · PEN 은 점검 필요, WARN · EXP 는 주의(정보), 나머지는 정상입니다. 한 은행에 둘 이상 걸리면 OVER → NEAR → NOTI → WARN 순으로 대표 코드를 정합니다. 이 순서는 스케치이며 도입 때 회사 기준으로 합의해야 합니다.

주의 80%, 점검 90%, 통지 허용 오차 0.5% 는 어디서 온 숫자입니까?

가정값입니다. 샘플을 만들면서 임의로 둔 값이고 화면 맨 위에도 그렇게 적혀 있습니다. 실제 기준은 은행 약정서와 회사의 자금 운용 기준으로 정해야 하며, 같은 자료라도 기준을 바꾸면 점검 필요 건수가 달라집니다.

해제 후보는 풀어도 되는 한도입니까?

아닙니다. 유효기간이 기준일을 지났는데 미사용 잔액이 남은 신용장을 해제를 검토할 후보로 올린 것입니다. 이 자료의 후보는 7건, 미사용 잔액의 원화 환산 합계 1,647,400,425원입니다. 실제로 취소할 수 있는지, 수익자 동의나 연장 협의가 필요한지는 거래 은행과 회사가 정하며 화면은 "확인 필요"까지만 말합니다.

해제 후 사용률은 어디에 쓰입니까?

해제 후보를 모두 풀었다고 가정했을 때의 사용률입니다. 라온은행은 105.58% 에서 88.49% 로, 나래은행은 86.18% 에서 69.27% 로 내려갑니다. 한도 초과 은행이 해제만으로 정리될 수 있는지, 아니면 신규 개설을 미뤄야 하는지를 가늠하는 참고 지표입니다.

은행 통지 사용액과 차이가 나면 어떻게 봅니까?

통지 차이 = 은행 통지 사용액 − 재계산 점유액이고, 절대 차이가 점유액의 0.5% 를 넘으면 "점검 필요"로 올립니다. 이 자료에서는 라온은행 +311,819,750원(12.84%), 마루은행 +1,064,433,440원(52.82%) 이었습니다. 샘플은 회사가 취소했지만 은행에 반영되지 않은 신용장 3건을 차이의 원인 후보로 보여 주며, 운영에서는 결제 반영 시차 · 환율 차이 · 취소 미반영 순으로 은행 자료와 대조해 확인합니다. 원인은 단정하지 않습니다.

환율은 무엇을 씁니까?

통화별 기준일 환율을 한 표로 둔 가정값(USD · EUR · JPY · CNY)을 외화 점유에 곱해 원 단위로 반올림합니다. 실제 고시값이 아닙니다. 운영에서는 어느 일자의 환율(개설일 · 기준일 · 마감일)을 쓸지부터 합의해야 하고, SAP 에서는 환율표(TCURR)에서 읽는 구성이 일반적입니다.

대사 결과 탭은 무엇을 보여 줍니까?

화면의 숫자가 서로 맞는지 스스로 검산한 아홉 줄입니다. L/C 별 합계 = 은행별 합계, 외화 × 환율 = 원화, 통화별 합계 · 구간별 합계 = 은행별 합계, 개설 = 선적 + 미사용, 점유 = 미사용 + 미결제, 통지 − 취소 미반영 = 재계산 점유, 점유 − 해제 후보 = 해제 후 점유, 약정 한도 = 점유 + 여유 한도로 이루어지며 이 자료에서는 모두 차이 0 입니다(07~09 번은 점검 대상을 함께 세어 줍니다).

화면과 조회

조회조건에 필수가 있습니까?

없습니다. 은행 · 통화 · 점검 상태 · 해제 후보 · 유효기간(부터/까지)은 모두 선택이며 "전체"를 고르면 그 조건은 서비스로 보내지 않습니다. 통화 · 해제 후보 · 유효기간 조건은 L/C 내역 탭과 통화별 탭에 적용되고, 은행별 한도는 통화를 가르지 않고 집계합니다.

조회 버튼 말고 Enter 로도 조회됩니까?

됩니다. 유효기간 입력 칸에서 Enter 를 누르면 같은 조회가 돌고, 조회 버튼은 조건 영역 안 입력 칸들의 가장 오른쪽에 있으며 초기화 버튼이 그 옆에 있습니다. 화면을 열면 기본 조건(전체)으로 한 번 자동 조회합니다.

탭이 다섯 개인 이유가 있습니까?

같은 자료를 다섯 번 다르게 묶은 것입니다. 은행별 한도 → L/C 내역 → 통화별 → 유효기간 구간 → 대사 결과 순으로 보시면 됩니다. 앞의 네 탭은 합계가 서로 같아야 하고, 마지막 탭이 그 일치를 스스로 확인합니다.

행을 누르면 무엇이 열립니까?

그 은행의 한도 상세 창입니다. 점유 · 통지 차이 · 해제 후 사용률과 진행 중인 신용장 목록이 함께 나옵니다. 신용장 단위의 점검 내용은 L/C 내역 탭의 판정 문장으로도 읽을 수 있습니다.

CSV 로 내려받을 수 있습니까?

화면 아래 버튼이 지금 열려 있는 탭의 내용을 UTF-8 CSV 로 내려받습니다. 필터를 건 상태라면 걸린 결과만 담깁니다.

설계와 기술

OData 서비스는 어떻게 생겼습니까?

OData V2 서비스(lclimit_srv)에 엔티티셋 다섯 개(BankSet · LcSet · CurSet · BucketSet · ReconSet)와 펑션 하나(GetMaxUtilPct)가 있습니다. 화면은 $filter · $orderby · $top · $inlinecount 와 이 펑션만 쓰고, 동작 이름이 붙은 주소는 없습니다. 같은 주소를 CDS 기반 서비스가 이어받으면 화면은 고치지 않아도 됩니다.

날짜 조건에서 흔히 생기는 문제는 어떻게 막았습니까?

시작과 끝 날짜를 or 로 묶어 내보내는 일이 있으면 모든 날짜가 통과해 버립니다. 그래서 시작과 끝을 and 한 묶음으로 보내고 서비스가 날짜 필터를 직접 해석합니다. 이 자료에서 유효기간 시작 이후 55건 · 종료 이전 6건 · 기간 안 9건으로 시험해 모두 일치했습니다.

데이터는 실제 고객 자료입니까?

아닙니다. 은행 · 거래처 · L/C 번호는 모두 검증용 가상 자료입니다. 가상 은행 5곳, L/C 60건(진행 46 · 종결 11 · 취소 3), 통화 USD · EUR · CNY · JPY 로 만들었고 기준일은 2026-09-30 로 가정했습니다.

운영 데이터가 수십만 건이면 어떻게 됩니까?

조회는 $top 으로 나눠 받을 수 있지만 합계와 탭 집계를 화면에서 더하는 부분은 느려집니다. 운영에서는 점유 계산과 은행별 집계를 CDS 뷰로 내려 DB 가 계산하게 하고 화면은 결과만 받습니다. CDS 구성 절의 뷰 순서가 그 설계입니다.

도입과 운영

이 앱이 최종 판단을 내려 줍니까?

아닙니다. 화면 맨 위에도 적혀 있듯 점검 후보를 가리는 조회 도구입니다. 한도 해제와 조정은 거래 은행과 회사가, 회계 처리와 공시 판단은 회사와 감사인이 합니다. 앱은 어느 은행을 먼저 열어 볼지 정해 줄 뿐 신용장을 취소하거나 한도를 바꾸지 않습니다.

어떤 회사에 맞습니까?

여러 은행에 신용장 한도를 나눠 두고 수입 대금을 L/C 로 치르는 회사입니다. 구매팀은 개설 계획을, 자금팀은 한도 여유를, 회계팀은 은행 통지와 장부를 따로 보기 때문에 한 은행의 사용률이 어디서 어긋나는지 한 줄로 설명하기 어려운 곳에 특히 맞습니다.

도입 때 가장 먼저 정할 것은 무엇입니까?

점유액의 정의(미사용 잔액 + 선적 후 미결제를 쓸지), 환율 기준일, 주의 · 점검 기준, 통지 허용 오차, 그리고 은행 통지 자료를 어떻게 받을지입니다. 도입 때 정해야 할 항목은 CDS 구성 절 끝에 표로 적었습니다.

권한은 어떻게 겁니까?

집계를 읽는 뷰에 회사코드 또는 자금 조직 범위의 권한(DCL)을 겁니다. 합계 뷰에 걸지 않으면 내 범위가 아닌 금액이 합계에서 빠진 만큼 보이는 경로가 생깁니다. 코드는 CDS 구성 절에 있습니다.

AI 는 쓰였습니까?

점유 계산과 판정에는 쓰지 않습니다. 모든 숫자는 규칙으로 계산되고 같은 입력이면 같은 결과가 나옵니다. 판정이 흔들리면 감사 때 설명할 수 없기 때문입니다.

현재 SAP 환경에서 어떻게 적용되는지 궁금합니다.

신용장 개설 정보와 은행 약정 한도를 SAP 의 어디에 두는지, 구매 오더와 어떻게 이어 두는지가 회사마다 다릅니다. 왼쪽 목차의 "문의하기"로 남겨 주시면 환경에 맞춰 어디까지 표준으로 되고 어디부터 확장이 필요한지 함께 살펴 드립니다.