SAP FI 자동지급(F110) 오류의 대부분은 FBZP customizing 순서가 뒤엉켜 발생합니다. FBZP는 단순 지급 설정이 아니라 전체 지급 프로세스를 통제하는 룰 엔진이며, All Company Codes → Paying Company Codes → Payment Methods (Country) → Payment Methods (Company Code) → Bank Determination 순서를 반드시 지켜야 합니다. S/4HANA 환경에서는 BP Vendor 지급 설정과 FI12_HBANK 기반 House Bank 구조까지 함께 확인해야 하며, Bank Determination은 단순 매핑이 아닌 지급 우선순위 정책 설계로 접근해야 합니다. 이 글은 ECC 6.0 및 S/4HANA 모두 적용 가능한 실무 중심 가이드입니다.
SAP FI에서 자동지급(F110)을 설정하다 보면 이상하게 비슷한 오류가 계속 반복되는 경우가 많습니다. 분명 Payment Method도 만들었고, House Bank도 등록했는데 실행만 하면 Bank Determination 오류, 지급방법 미인식, 계좌 누락 같은 문제가 다시 발생하죠. 실제 프로젝트에서 이런 케이스를 수없이 봤는데요, 대부분의 원인은 단순합니다. IMG FBZP customizing 순서가 뒤엉켜 있기 때문입니다.
프로젝트 초기에 지급 구조를 빠르게 맞추려다 보면 Company Code 설정보다 Payment Method를 먼저 만들거나, FI12_HBANK에서 계좌는 생성했지만 FBZP Bank Determination 연결을 놓치는 일이 자주 발생합니다. 운영 단계에서도 오류가 날 때마다 하나씩 땜질식으로 수정하다 보면 결국 전체 지급 구조가 꼬이게 되죠.
이런 분께 특히 도움이 됩니다:
- FI 모듈 주니어/중급 컨설턴트로 지급 설정 전체 구조를 처음부터 정리해야 하는 경우
- 운영 담당자로 FBZP 오류를 반복 수정하고 있지만 원인 구조가 잘 안 보이는 경우
- S/4HANA 환경에서 BP Vendor 지급 설정까지 함께 이해해야 하는 경우
이번 글에서는 SPRO FBZP customizing 전체 구조, Company Code부터 Payment Method, Bank Selection까지의 올바른 순서, FI12 / FI12_HBANK 계정 생성과 연결, 그리고 KR vs Global 지급방법 설정 차이를 실무 중심으로 정리해드리겠습니다.
FBZP는 단순 설정이 아니라 지급 프로세스 전체를 통제하는 룰 엔진
많은 분들이 FBZP를 그냥 “지급 설정 트랜잭션” 정도로 이해하시는데요, 실무적으로 FBZP는 그보다 훨씬 중요합니다. FBZP는 SAP 자동지급 프로세스 전체를 통제하는 룰 엔진이라고 보는 게 정확합니다.
SAP FI에서 FBZP의 위치를 보면, F110 자동지급 프로그램의 핵심 customizing이자 Vendor Master(S/4HANA에서는 BP Vendor 지급 설정), Bank Master, G/L 계정과 모두 연결되는 중심축입니다. F110에서 지급을 실행할 때 시스템은 단순히 “지급해도 되는지”만 보는 것이 아니라 어떤 회사코드가 지급을 수행하는가, 어떤 지급방법을 사용할 수 있는가, 어떤 Vendor가 어떤 지급방법을 허용하는가, 어떤 House Bank / Account를 선택할 것인가, 지급매체 파일은 어떤 형식으로 생성할 것인가를 모두 함께 판단합니다.
왜 이렇게 복잡한 구조일까요? 국가별 규정(KR vs Global)과 회사별 정책, 은행별 제약을 동시에 반영해야 하기 때문입니다. KR에서는 은행 파일 포맷과 전자지급 관련 제약이 많고, US는 ACH 기반, 유럽은 SEPA 구조를 따르죠. 이런 다양한 요구를 하나의 지급 구조 안에서 관리하려면 계층적 설정 구조가 필수입니다.
FBZP의 핵심 구조는 4단 레이어로 이해하면 가장 명확합니다: All Company Codes → Paying Company Codes → Payment Methods (Country / Company Code) → Bank Determination. 이 구조는 위에서 아래로 흐르기 때문에 순서가 틀리면 반드시 오류가 발생합니다.
ECC 6.0 vs S/4HANA 차이점
이 글은 ECC 6.0 및 S/4HANA 모두 적용 가능하지만, S/4HANA 특화 사항은 별도 표기하겠습니다.
| 구분 | ECC 6.0 | S/4HANA |
|---|---|---|
| FBZP 기본 구조 | 4단 레이어 동일 | 4단 레이어 동일 |
| Vendor 관리 | LFA1/LFB1 기반 | BP(Business Partner) 기반 |
| House Bank 트랜잭션 | FI12 | FI12_HBANK |
| BP Role 영향 | 없음 | FLVN00, FLCU00 등 고려 필요 |
| 지급 설정 위치 | Vendor Master | BP → Company Code Data → Payment Transactions |
S/4HANA 변경사항: Vendor 마스터가 Business Partner로 통합되면서 지급 설정 확인 경로가 복잡해졌습니다. BP의 Supplier Role과 Company Code Data에서 Payment Transactions를 반드시 확인해야 하며, 기존 LFA1 기반 데이터 이관 시 지급방법 누락이 자주 발생합니다.
SPRO FBZP customizing IMG 설정 경로 및 단계
전체 IMG 경로는 다음과 같습니다:
SPRO → Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Program Configuration
실무에서 가장 중요한 것은 이 안의 설정을 반드시 순서대로 진행해야 한다는 점입니다. 아래 순서를 지키지 않으면 나중에 설정 누락 부분을 찾느라 시간이 훨씬 더 많이 걸립니다.
반드시 지켜야 하는 FBZP 설정 순서
① All Company Codes 설정
가장 먼저 해야 하는 것은 회사코드의 기본 지급 파라미터 설정입니다. 여기서는 각 회사코드가 자동지급 구조 안에서 어떤 기본 속성을 가질지 정의합니다.
주요 설정 필드:
- Paying Company Code (실제 지급 수행 주체)
- Tolerance 및 기본 지급방법 관련 파라미터
- 지급 관련 기준값
선행조건: 해당 Company Code가 이미 생성되어 있어야 합니다.
실무적으로 이 단계가 먼저 정리되지 않으면 뒤에서 Payment Method나 Bank를 아무리 잘 설정해도 시스템은 “이 회사코드가 누구를 통해 지급을 수행하는지”를 명확히 이해하지 못합니다. 특히 그룹사나 Shared Service 구조에서는 한 회사가 여러 회사 대신 지급하는 경우가 많아 이 설정이 매우 중요합니다.
② Paying Company Codes 설정
다음은 실제 지급을 수행하는 회사코드를 정의하는 단계입니다. All Company Codes가 “지급 구조의 기본 틀”이라면, Paying Company Codes는 “누가 실제로 돈을 보내는가”를 결정합니다.
주요 설정 필드:
- Minimum Amount (최소 지급금액)
- Payment per Vendor 여부
- Special G/L 처리 여부
- 지급 주체 정의
Shared Service Center(SSC) 형태에서는 이 설정의 중요도가 매우 높습니다. 예를 들어 회사 A의 전표를 지급은 회사 B가 대신 수행할 수 있는데, 이 구조가 명확하지 않으면 F110에서 지급 제안은 잡히더라도 실제 실행 시 지급 주체 충돌이 발생할 수 있습니다.
③ Payment Methods in Country 설정
이 단계에서는 국가별 지급방법을 정의합니다. 즉, 지급방법 자체의 공통 특성을 국가 레벨에서 먼저 만드는 것이죠. 예를 들어 KR에서는 계좌이체, 수표, 어음, 전자지급 파일 기반 송금 등을 정의할 수 있습니다.
주요 설정 필드:
- Payment Medium (지급매체)
- Required Master Data (필수 마스터 데이터)
- Form / DMEE 관련 설정
- 국가별 법적 요구사항 반영
KR vs Global 관점에서 중요한 차이점:
| 구분 | KR 특징 | Global 특징 |
|---|---|---|
| 지급 포맷 | 은행별 특화 포맷 요구 | 국가별 표준 (ACH, SEPA 등) |
| 전자지급 | 전자금융망, 펌뱅킹 등 제약 많음 | SWIFT, SEPA 등 국제 표준 |
| Payment Medium | DMEE 구조 필수 | Payment Medium Workbench 활용 |
| 법적 요구사항 | 금융실명제, 전자금융거래법 | 국가별 규정 상이 |
Country 레벨 Payment Method는 단순 코드 정의가 아니라 각 국가의 지급 규정과 은행 포맷 요구사항을 반영하는 기반입니다. 이 설정 없이는 회사코드에서 활성화조차 불가능합니다.
④ Payment Methods in Company Code 설정
Country 레벨에서 지급방법을 만들었다면, 이제 특정 회사코드가 그 지급방법을 실제 사용할 수 있도록 활성화해야 합니다. 이 단계가 빠지면 “Payment method not defined for company code” 오류가 매우 자주 발생합니다.
주요 설정 필드:
- Minimum / Maximum Amount (금액 범위)
- Bank Selection Control (은행 선택 제어)
- Payment Medium Variant (지급매체 변형)
- 회사코드별 활성화 여부
Country 레벨 Payment Method는 “국가적으로 이런 지급방식이 있다”는 뜻이고, Company Code 레벨 Payment Method는 “우리 회사가 이 방식을 실제로 쓰겠다”는 선언입니다. 즉, 둘은 완전히 별개의 설정입니다.
S/4HANA BP Vendor 지급 설정과의 연결: 아무리 FBZP에서 지급방법을 활성화해도 Vendor(BP)의 지급 설정에 동일 Payment Method가 없으면 지급이 되지 않습니다. 반드시 BP → Supplier 역할 → Company Code Data → Payment Transactions에서 해당 Payment Method 존재 여부를 확인해야 합니다.
⑤ Bank Determination 설정
실무에서 가장 많이 꼬이고, 가장 자주 문제를 일으키는 부분이 바로 Bank Determination입니다. 이 단계에서는 지급 시 시스템이 어떤 House Bank와 어떤 계좌를 사용할지 결정합니다.
구성 요소:
- Ranking Order (우선순위)
- Bank Accounts (계좌 목록)
- Available Amount (사용 가능 금액)
- 통화/금액 조건
Bank Determination 우선순위 흐름:
F110 지급 실행
└─> Ranking Order 1번 확인
├─ [조건 충족] → 계좌 잔액 확인
│ ├─ [잔액 충분] → 통화 적합성 확인
│ │ ├─ [통화 일치] → 해당 House Bank 선택 (완료)
│ │ └─ [통화 불일치] → Ranking Order 2번으로 이동
│ └─ [잔액 부족] → Ranking Order 2번으로 이동
└─ [조건 미충족] → Ranking Order 2번 확인
├─ [조건 충족] → 계좌 잔액 확인 (동일 흐름 반복)
└─ [모두 미충족] → "No valid house bank found" 오류 발생실무 핵심 포인트: Ranking Order를 잘못 잡으면 시스템이 특정 계좌만 계속 사용합니다. 예를 들어 HB01은 Ranking 1, HB02는 Ranking 2인데 HB01의 조건이 항상 충족되도록 되어 있다면 HB02는 사실상 사용되지 않습니다. 그래서 Bank Determination은 단순한 매핑이 아니라 지급 우선순위 정책 설계에 가깝습니다.
⑥ FI12 / FI12_HBANK 계정 생성
마지막으로, 실제 사용할 House Bank와 Account ID 그리고 연결 G/L 계정을 생성해야 합니다.
관련 T-code:
- ECC:
FI12 - S/4HANA:
FI12_HBANK
기본 구성:
- House Bank ID
- Account ID
- Bank Account Number
- 연결 G/L 계정 (은행계좌 관리 계정)
여기서 생성된 House Bank / Account가 FBZP의 Bank Determination에서 참조됩니다. 즉, FI12 또는 FI12_HBANK에서 계좌를 만들고, FBZP에서 해당 계좌를 지급 로직에 연결해야 F110이 실제 지급 계좌를 선택할 수 있습니다. 계좌만 생성하고 FBZP에 연결하지 않으면 “No valid house bank found” 오류가 발생합니다.
주요 포인트 및 실무 팁
FBZP는 순서를 틀리면 거의 무조건 재작업이다
현장에서 30년 넘게 프로젝트를 하면서 느낀 건, FBZP는 순서가 생명이라는 점입니다. 가장 안전한 순서는 Company Code → Paying Company Code → Payment Method Country → Payment Method Company Code → House Bank → Bank Determination입니다. 중간에 순서를 바꾸면 나중에 설정이 누락된 부분을 찾느라 시간이 더 많이 걸립니다.
가장 흔한 실수 3가지
실수 1: Country Payment Method만 만들고 Company Code에 할당 안 함
이 경우 시스템은 국가에는 존재하는 지급방법이지만 회사코드에서는 사용할 수 없다고 판단합니다. F110 실행 시 “Payment method not defined for company code” 오류가 나죠.
실수 2: Vendor(BP)에 Payment Method 누락
FBZP는 완벽한데, Vendor 마스터 또는 BP의 Payment Transactions에 동일 지급방법이 없어서 실패하는 경우가 정말 많습니다. 특히 S/4HANA 전환 시 BP 데이터 이관 과정에서 자주 발생합니다.
실수 3: FI12_HBANK 계정은 있는데 FBZP 연결 안 됨
계좌 생성과 지급 로직 연결은 완전히 별개의 작업입니다. 이 부분이 매우 자주 빠지는데, House Bank를 만들었다고 해서 자동으로 F110이 인식하지 않습니다.
S/4HANA 전환 시 반드시 체크할 항목
S/4HANA 환경에서는 특히 아래를 체크해야 합니다:
- BP Vendor 지급 설정 존재 여부 (BP → Company Code Data → Payment Transactions)
- 기존 Vendor(LFA1/LFB1 기반) 지급방법 이관 상태
- Supplier Role에서 Payment Transactions 정합성
- House Bank 구조가 FI12_HBANK 기준으로 정리되었는지
프로젝트 시 반드시 함께 확인하는 영역
FBZP만 보고 끝내면 안 됩니다. 실제 지급 운영까지 고려하면 아래 영역도 같이 확인해야 합니다:
- 국가별 지급 포맷 (KR은행 파일 포맷, SWIFT, SEPA 등)
- DMEE (Data Medium Exchange Engine) 구조
- Payment Medium Workbench 설정
- Bank Determination 우선순위 실제 테스트
운영 팁
운영 중에는 오류 메시지만 보고 바로 customizing 수정하지 말고 반드시 F110 Proposal 로그를 먼저 확인해야 합니다. 제가 추천하는 습관은 다음과 같습니다:
- F110 Proposal 로그 우선 분석
- Bank Selection trace 확인
- Vendor/BP 지급방법 점검
- House Bank 및 G/L 연결 확인
이 순서대로 확인하면 대부분의 문제 원인을 빠르게 찾을 수 있습니다.
자주 발생하는 SAP Error Code와 해결 방법
| Error Message | 발생 원인 | 해결 방법 | 주요 발생 화면 |
|---|---|---|---|
| Payment method not defined for company code | Company Code 레벨에서 지급방법 미설정 | FBZP → Payment Methods in Company Code 확인, 금액 범위 및 Payment Medium Variant 점검 | F110, F-53 |
| No valid house bank found | Bank Determination 설정 누락, FI12_HBANK 계좌 생성 누락, House Bank 존재하지만 FBZP 연결 안 됨 | FI12_HBANK에서 House Bank/Account 생성 확인, 연결 G/L 계정 확인, FBZP → Bank Determination에서 Ranking/Account 매핑 확인 | F110 |
| Payment method not permitted for vendor | Vendor 또는 BP 지급설정에 해당 Payment Method 없음 | BP → Company Code Data → Payment Transactions 확인, 지급방법 설정 존재 여부 및 Block 여부 점검 | F110, F-58 |
주요 발생 트랜잭션:
- F110: Automatic Payment Run (가장 빈번)
- F-53: Post Outgoing Payments
- F-58: Payment with Printout
실제 운영 현장에서는 이 세 가지 오류가 전체 FBZP 관련 오류의 80% 이상을 차지합니다. 각 오류별로 위 표의 해결 순서를 따라가면 대부분 해결됩니다.
마무리
FBZP는 단순한 지급 설정이 아니라 지급 로직 전체를 결정하는 구조입니다. 그래서 접근 방식도 달라야 합니다. 그냥 오류가 날 때마다 항목 하나씩 수정하는 방식이 아니라, SPRO FBZP customizing을 순서 기반으로 설계하고 FI12 / FI12_HBANK, BP Vendor 지급 설정, Bank Determination을 하나의 흐름으로 봐야 합니다.
핵심 요약:
- FBZP는 전체 지급 프로세스를 통제하는 룰 엔진으로, Company Code → Payment Method → Bank 순서가 절대적
- S/4HANA에서는 BP Vendor 설정까지 반드시 확인해야 하며, FI12_HBANK 기반 구조로 전환 필요
- Bank Determination은 단순 매핑이 아니라 지급 우선순위 정책 설계라는 관점으로 접근해야 함
한 번 제대로 구조를 잡아두면 이후 운영 난이도가 급격히 낮아집니다. 처음에는 복잡해 보이지만, 이 순서만 지키면 지급 관련 오류의 대부분은 사전에 예방할 수 있습니다.
여러분은 FBZP 설정 시 어떤 부분에서 가장 어려움을 겪으셨나요? 댓글로 경험을 공유해주시면 함께 고민해보겠습니다.
다음 글에서는 “F110 자동지급 실행 시 로그 분석 방법 (실무 디버깅 중심)”을 다룰 예정입니다. F110 Proposal 로그를 어떻게 읽고, Bank Selection trace를 어떻게 분석하는지 실무 중심으로 정리하겠습니다.
시리즈로 함께 읽으면 좋은 글:
- FBZP 심화: DMEE / Payment Medium Workbench 완전 정리
- S/4HANA BP Vendor 지급 구조 완전 가이드
- Bank Communication Management(BCM) 연계 실무 포인트
참고 출처:
- SAP Help Portal: Payment Program Configuration (FBZP)
- SAP Note 2811822: S/4HANA House Bank Management
- SAP Community: Automatic Payment Program Best Practices