실무에서 바로 쓰는 SAP OBB8 Payment Term 설정 가이드

ZTERM은 코드가 아니라 계산 규칙입니다

Payment Term을 단순히 “30일 지급”, “2% 10일 할인” 정도로 이해하고 계신가요? 만약 그렇다면  실무업무 하실 때 아마 고전할 확율이 많습니다.  SAP 안에서는 ZTERM이 계산 규칙을 가리키는 키이고, 그 규칙의 실제 저장과 계산 기준은 주로 T052에서 확인합니다. 즉, 전표에는 ZTERM이 들어가지만 SAP는 그 값을 보고 다시 계산 규칙을 읽습니다.

이때 핵심은 세 가지입니다.

• ZTERM: 어떤 지급 조건을 쓸지 지정하는 키

• Baseline Date: 며칠을 셀지 시작하는 기준일

• Due Date / Discount Date: 실제 만기일과 현금할인 적용 기한

 

실제 흐름은 보통 이렇게 이해하면 됩니다.

 

1. FB60 또는 MIRO에서 전표를 입력한다.

2. 전표, 마스터, 참조문서 기준으로 ZTERM이 결정된다.

3. Baseline Date가 결정된다.

4. SAP가 T052의 규칙을 읽는다.

5. 현금할인 기간과 순지급 만기일을 계산한다.

6. 계산된 결과가 미결항목 관리와 F110 지급대상 선정에 영향을 준다.

OBB8에서 무엇을 설정했고, 실제로 어떤 필드가 전표 결과를 바꾸는가

실무에서 많이 사용하는 경로는 다음과 같습니다.

SPRO → Financial Accounting → Accounts Payable → Business Transactions → Incoming Invoices/Credit Memos → Maintain Terms of Payment

통상적으로 이 설정은 T-code OBB8로 바로 진입해 관리합니다.

OBB8에서 봐야 할 포인트는 단순히 지급조건 키 생성 여부가 아닙니다. 각 필드가 만기일 계산에 직접 관여합니다.

1) Payment Term Key

이 키가 바로 ZTERM입니다. Vendor Master, 구매문서, 송장전표에서 참조됩니다. 운영에서 중요한 포인트는 “같은 ZTERM이 여러 회사코드에서 동일하게 해석되는가”보다 먼저, 해당 클라이언트에 그 키가 실제로 존재하는가입니다.

 

2) Baseline Date Calculation

여기가 만기일 오류의 출발점인 경우가 많습니다. 보통 기준일은 다음 유형으로 이해하면 됩니다.

• Document Date 기준: 거래 발생일 중심

• Posting Date 기준: 회계 반영일 중심

• Entry Date 기준: 실제 입력일 중심

• 별도 입력 또는 무기본값: 전표 입력 시 직접 결정 필요

같은 “30일 후 지급”이라도 문서일이 5월 28일이고 전기일이 6월 1일이면 결과는 달라집니다. 월마감 직전 입력인지, 익월 초 입력인지에 따라 지급월 자체가 바뀔 수 있습니다. 이 차이가 F110 지급제안에서 예상과 다르게 보이는 원인으로 이어집니다.

참고로 SAP 증빙일과 전기일에서 잠시 이야기해보면, SAP 전표에서 증빙일(Document Date)과 전기일(Posting Date)은 둘 다 전표 헤더(BKPF 테이블)에 입력하는 날짜지만 의미와 용도가 다릅니다. 증빙일(Document Date, BKPF-BLDAT)은 원천 증빙 자체에 적힌 날짜입니다. 거래처가 발행한 송장에 인쇄된 날짜, 계약서 날짜, 입금표 날짜처럼 외부 문서에 기재된 실제 날짜를 그대로 입력합니다. SAP 내부의 회계 처리와는 무관하게 “그 증빙이 언제 만들어졌는가”를 나타냅니다.

전기일(Posting Date, BKPF-BUDAT)은 그 거래가 회계장부에 반영되는 날짜입니다. 이 날짜가 회계기간(Posting Period)과 회계연도를 결정하고, GL 잔액과 재무제표가 어느 시점에 인식되는지를 좌우합니다. 마감된 기간에는 전기일을 가진 전표를 입력할 수 없는 것도 이 때문입니다.

두 날짜는 같을 수도 있고 다를 수도 있습니다. 예를 들어 거래처가 3월 28일자로 발행한 송장을 우리가 4월 2일에 받아 입력하면 증빙일은 3월 28일, 전기일은 4월 2일이 됩니다. 이 경우 비용은 4월에 인식되지만 증빙 자체는 3월 문서라는 정보가 보존됩니다.

3) Cash Discount 1 / 2

할인율과 할인 일수를 정의합니다.
예를 들어 “10일 2%, 30일 순지급” 같은 조건을 만들 수 있습니다.

여기서 주의할 점이 있습니다. 할인율만 보고 설정하면 안 됩니다. 기간과 기준일이 함께 맞아야 실제 전표에서 현금할인이 계산됩니다. 할인율이 0이면 “할인이 없다”라기보다 해당 구간 계산이 의미를 잃는 구조가 될 수 있으므로, 설계 의도에 맞게 봐야 합니다.

 

4) Net Due Date

최종 만기일까지 며칠인지 정의합니다. 운영 관점에서는 이 값이 단순 표시값이 아니라, 지급 우선순위와 연체 판단의 기준이 된다는 점이 중요합니다.

 

5) Fixed Day / Additional Months

월말 지급, 익월 특정일 지급 같은 조건에서 자주 씁니다.
예를 들어 “익월 25일 지급”처럼 보이는 규칙을 만들 수 있는데, 이 필드를 넣는 순간 사용자는 단순한 일수 계산을 기대하면 안 됩니다. 같은 전표라도 문서일이 월말에 걸치면 만기일이 한 달 이상 밀려 보일 수 있습니다.

화면상으로는 단순해 보이지만, 내부적으로는 데이터 성격이 다릅니다. 순수 일수 계산인지, 고정일 계산인지부터 구분해야 합니다.

T052를 같이 봐야 디버깅이 됩니다

Payment Term 관련 이슈를 OBB8 화면에서만 보면 원인 분류가 잘 안 됩니다. 실제 확인은 T052를 함께 봐야 합니다.
이 테이블은 지급조건 계산에 필요한 핵심 값을 담고 있어, 디버깅이나 운영 이슈 분석 때 거의 기준점 역할을 합니다.

실무에서 자주 보는 필드는 다음과 같습니다.

확인 포인트	예시 필드	의미
지급조건 키	ZTERM	어떤 조건인지 식별
1차 할인일수	ZTAG1	첫 할인구간 일수
1차 할인율	ZPRZ1	첫 할인율
2차 할인일수	ZTAG2	두 번째 할인구간 일수
2차 할인율	ZPRZ2	두 번째 할인율
순지급 일수	ZTAG3	최종 만기일 계산 기준

시스템과 버전에 따라 화면 필드명 표현은 다소 차이가 있을 수 있지만, 전표에 들어간 ZTERM이 어떤 계산값으로 저장돼 있는지는 T052에서 먼저 확인하는 습관이 좋습니다.

이 부분은 특히 주니어 컨설턴트가 많이 놓칩니다. OBB8에서 “보였다”와 T052에 “원하는 값으로 반영되었다”는 같은 확인이 아닙니다. 전송 전후나 설정 변경 후에는 테이블 기준으로 한 번 더 점검하는 편이 안전합니다.

FB60에서 만기일이 예상과 다를 때 먼저 의심할 4가지

만기일 오류처럼 보이는 이슈는 사실 원인이 여러 갈래입니다. 아래 순서로 보면 빠릅니다.

증상/오류	원인	확인 위치	해결 방법	주의사항
같은 ZTERM인데 거래처마다 만기일이 다름	Baseline Date 기준 차이 또는 마스터 기본값 차이	FB60 전표, 거래처 마스터, OBB8	기준일 소스 확인 후 재테스트	거래처별 입력 습관 차이도 영향
현금할인이 계산되지 않음	할인구간 일수/비율 설정 불일치, 기준일 계산 차이	OBB8, T052, 전표 Payment 관련 필드	할인일수와 기준일을 함께 검증	단순히 할인율만 보면 안 됨
F110에서 지급대상 누락	실제 만기일이 아직 도래하지 않았거나 지급블록/조건 불일치	F110 제안 로그, 전표 라인아이템	만기일과 지급조건을 같이 점검	Payment Term만의 문제로 단정 금지
Terms of payment 관련 정의 오류	ZTERM 미정의 또는 설정 누락	OBB8, 마스터/전표 입력 화면	지급조건 생성 또는 올바른 값 적용	조직 단위 영향은 시스템 확인 필요

 

여기서 중요한 건 원인을 Customizing, Master Data, Transaction Data로 나눠 보는 것입니다.
– OBB8/T052 문제면 Customizing
– 거래처 기본값 문제면 Master Data
– 전표 입력 시 수기 변경이나 참조문서 영향이면 Transaction Data

이렇게 나누지 않으면, 설정팀과 운영팀이 서로 다른 화면만 보고 시간을 씁니다.

MIRO, FB60, Vendor/BP 기본값이 서로 다르게 작동할 수 있는 이유

같은 지급조건인데 FB60과 MIRO 결과가 다르게 보인다는 질문도 자주 나옵니다. 이건 화면이 달라서가 아니라 ZTERM 결정 우선순위와 참조 데이터가 다르기 때문입니다.

일반적으로는 다음을 함께 봐야 합니다.

• 거래처 마스터 또는 S/4HANA의 BP 기반 기본 지급조건

• 구매오더에 들어간 지급조건

• 송장 입력 시 수기 변경 여부

• 기준일 수기 입력 또는 기본값 파생 방식

 

예를 들어 MIRO는 구매문서의 영향을 더 강하게 받을 수 있고, FB60은 AP 전표 입력 맥락에서 거래처 기본값과 전표 입력값을 중심으로 보게 됩니다. 세부 결정 방식은 프로세스와 활성화 기능에 따라 차이가 있을 수 있으므로, 운영 시스템에서 실제 입력흐름을 확인하는 것이 안전합니다.

S/4HANA에서는 거래처가 BP 기반으로 관리되기 때문에 마스터 유지 방식이 ECC와 다르게 느껴질 수 있습니다. 다만 Payment Term 계산 자체의 핵심 개념, 즉 ZTERM과 기준일을 바탕으로 만기일이 계산된다는 구조는 그대로 이해하면 됩니다. 또한 S/4HANA에서는 Fiori 기반 라인아이템 앱에서 만기일과 관련 항목을 더 쉽게 분석할 수 있는 장점이 있습니다. 사용 중인 앱과 활성 범위는 시스템에서 확인이 필요합니다.

이 설정은 직접 전표를 만들지 않지만, 전표 상태를 바꿉니다

OBB8은 직접 회계전표를 생성하는 설정은 아닙니다. 그렇다고 영향이 약한 것도 아닙니다. 이 설정은 이후 생성되는 AP 전표의 지급조건, 할인 가능기간, 순지급 만기일을 결정하고, 그 결과가 지급 실행과 현금흐름 관리에 반영됩니다.

회계적으로 보면 Payment Term 자체가 차변/대변 계정을 바꾸는 것은 아닙니다. 그러나 아래 영향은 실무적으로 큽니다.

• 공급업체 미결항목의 만기 구조 변화

• 현금할인 적용 가능 여부 변화

• F110 지급시점 변화

• Cash Management나 예측 현금흐름 기준일 변화

 

즉, 전표 금액은 같아도 지급 시점이 바뀌면 운영 결과는 달라집니다.
그래서 OBB8은 “전표를 안 만드는 IMG”가 아니라 “전표의 후속 생명주기를 바꾸는 IMG”로 보는 편이 맞습니다.

 

QA에서 검증할 때는 날짜를 바꿔가며 비교해야 합니다

Payment Term은 설정만 보고 끝내면 거의 반드시 놓칩니다. QA에서는 최소한 아래 정도의 비교 테스트를 돌려보는 것이 좋습니다.

Step	작업	입력값 예시	확인 화면/테이블	기대 결과
1	OBB8 설정 확인	ZTERM = Z030	OBB8 / T052	지급조건 값 존재
2	거래처 기본값 확인	공급업체 예시 100000	BP 또는 거래처 관련 마스터 화면	기본 지급조건 확인
3	FB60 전표 입력	문서일 2026-05-28, 전기일 2026-06-01	FB60	기준일에 따라 만기일 계산
4	동일 조건 재실행	문서일만 2026-06-01로 변경	FB60	만기일 변화 비교 가능
5	다른 ZTERM 비교	ZTERM = Z010, Z030	FB60 / 전표 표시	할인일/만기일 차이 확인
6	후속 영향 확인	지급제안 실행 조건 예시	F110	지급대상 포함/제외 결과 확인

예시를 들었지만 테스트 방식은 실무에서 그대로 쓸 수 있습니다.
핵심은 두 가지입니다.

• 동일 금액, 다른 날짜

• 동일 날짜, 다른 ZTERM

이렇게 바꿔야 어떤 요소가 결과를 바꾸는지 분리해서 볼 수 있습니다. 하나씩만 바꾸지 않으면 원인이 섞입니다.

 

DEV, QA, PRD에서 어디까지 해야 하는가

OBB8은 전형적인 Customizing 성격의 설정입니다. 따라서 보통은 DEV에서 설정 후 QA로 이관해 통합 검증하고, PRD 반영 전 실제 전표 테스트 시나리오를 준비합니다.

구분	해야 할 일
DEV	OBB8 설정, ZTERM 설계, 단위 테스트
QA	CTS 반영 후 FB60/F110 통합 검증
PRD	운영 반영, 사용자 입력 가이드 정비, 초기 전표 모니터링
CTS 대상	OBB8 등 Customizing 변경
Local 실행 대상	일반적인 Payment Term 설정 자체는 아님. 다만 운영 전표 데이터는 각 시스템 데이터에 의존

 

주의할 점은 이겁니다. 설정은 CTS로 넘어가도 테스트 결과는 자동으로 보장되지 않습니다.
QA에서 정상이어도 PRD에서는 거래처 마스터 상태, 실제 문서일 패턴, 지급 실행 일정이 다를 수 있습니다. 그래서 운영 반영 전에는 최소한 다음 질문에 답할 수 있어야 합니다.

• 기준일이 문서일인지 전기일인지 사용자들이 알고 있는가

• Fixed Day가 들어간 조건을 어떤 거래처에 쓸지 정리됐는가

• F110 지급일정과 Payment Term 설계가 충돌하지 않는가

 

결국 확인 순서는 화면보다 계산 논리입니다

SAP OBB8 Payment Term 이슈는 설정 화면만 보면 해결이 안 되는 경우가 많습니다.
실제 운영업무나 프로젝트를 진행하면서 기억할 핵심은 간단합니다.

• ZTERM은 키일 뿐이고

• 실제 계산은 Baseline Date와 T052가 만든다

• 결과는 FB60 전표와 F110 지급에서 드러난다

 

만기일이 이상하면 OBB8부터 여는 습관보다,

1) 전표에 어떤 ZTERM이 들어갔는지
2) 기준일이 무엇으로 계산됐는지
3) T052에 어떤 일수와 할인율이 있는지
이 순서로 보는 편이 더 빠릅니다.

지금 운영 중인 대표 ZTERM 하나만 골라도 좋습니다. FB60에서 문서일과 전기일을 바꿔 두 번 입력해 보세요. 그 테스트 하나로도 왜 만기일이 틀어지는지 감이 잡히기 시작합니다.

참고 자료

• SAP S/4HANA Financial Accounting Documentation — Payment Term과 FI 동작 개념을 확인할 때 참고할 수 있는 공식 문서 모음

• SAP ERP Documentation — ECC 계열 기능과 테이블/기능 설명을 확인할 때 참고할 수 있는 공식 문서 모음

• SAP S/4HANA On-Premise Documentation — IMG 및 설정 관련 공식 문서 탐색 시작점

• SAP Best Practices Explorer — AP 프로세스 테스트 시나리오와 표준 프로세스 참고 자료

• SAP Support Portal — 실제 오류 메시지와 버전별 이슈는 시스템 상황에 맞춰 추가 확인 필요