SAP SD: 무엇을 하며 구축은 어디서 무너지는가

SAP SD(Sales and Distribution, 판매 및 유통)는 SAP에서 주문-수금(Order-to-Cash)을 운영합니다. 견적, 판매 오더, 납품, 청구, 그리고 재무로의 인계입니다. S/4HANA에서는 프로젝트 범위에 영향을 줄 만한 방식으로 달라집니다. 고객은 비즈니스 파트너가 되고, 신용 관리는 SAP Credit Management로 옮겨 가며, 리베이트는 조건 계약으로 옮겨 가고, 청구는 유니버설 저널(Universal Journal)에 곧바로 전기됩니다. 이 글은 SD가 무엇을 하고 어디서 무너지는지 알아야 하는 영업 운영 리드, 재무 컨트롤러, 프로젝트 매니저를 위한 것입니다. 두 번째 질문에 대한 짧은 답은 이렇습니다. 고객 마스터 데이터, 가격 조건, 가용성 점검, 계정 결정입니다. 이 네 가지를 Go-Live 전에 실제 데이터로 테스트하십시오.

SAP 전체 구축 직후의 한 롤아웃에서, 주문-수금 단계는 설계한 그대로 구축되었습니다. 프로세스 맵 위에서는 아무 문제가 없어 보였습니다. 생산에서 재고 업데이트가 어떻게 들어오고 있는지는 아무도 확인하지 않았습니다.

영업은 고객에게 5일이라고 말했습니다. 제조는 10일에 가깝다는 것을 알고 있었습니다.

그 간극이 치른 대가는 납기 지연만이 아니었습니다. 신뢰를 잃었고, 신뢰는 설정값 하나보다 되살리기가 훨씬 어렵습니다.

SD는 물류 체인의 맨 앞에 있습니다. 문서의 연쇄를 통해 고객의 관심을 청구서로 바꿉니다.

1. 문의: 고객이 가격이나 가용성을 묻습니다
2. 견적: 유효 기간이 있는 공식 가격 및 납품 제안
3. 판매 오더: 고객이 확정하면 가용성 점검이 실행되고 납품 일자가 확정됩니다
4. 납품: 창고에서 피킹과 포장을 하고, 출고(Goods Issue)로 재고가 줄어듭니다
5. 청구: 청구서가 회계 문서와 함께 생성됩니다
6. 결제: 재무가 입금액을 미결 항목에 대해 반제 처리합니다

각 문서는 앞선 문서를 참조합니다. 이 문서 흐름이 주문-수금을 추적 가능하게 만듭니다. 연쇄가 깨끗하면 모든 청구서를 최초 요청까지 거슬러 추적할 수 있습니다. 문서가 순서를 어겨 생성되거나 건너뛰어지면 리포팅이 깨지고 분쟁이 뒤따릅니다.

1. 01문의가격이나 가용성을 문의
2. 02견적유효 일자가 있는 공식 제안
3. 03판매 오더가용성 점검으로 일자 확정
4. 04납품피킹, 포장, 출고
5. 05청구청구서와 회계 문서
6. 06결제재무가 미결 항목을 반제

모든 청구서를 최초 요청까지 추적할 수 있음

잘 구축하면 이 연쇄는 수작업 인계를 없애 줍니다. 한 제조업 고객사는 SD가 가동된 뒤 주문-수금 주기를 40% 줄였는데, 대부분 영업, 창고, 재무 사이의 인계를 없앤 덕분이었습니다.

판매 오더와 가용성 점검

판매 오더 처리는 SD 설정 노력의 대부분이 모이는 곳입니다. 오더 유형, 아이템 범주, 납품 일정 라인, 가용성 점검이 여기에 속합니다.

ATP(Available-to-Promise)는 비즈니스에 가장 중요한 부분입니다. 요청한 일자를 재고, 입고 예정량, 기존 확약량으로 맞출 수 있는지 점검합니다. 제대로 설정하면 영업은 시스템이 실제로 약속할 수 있는 것을 고객에게 말합니다. 잘못 설정하면 영업은 인도하기를 바라는 것을 고객에게 말합니다.

서두의 롤아웃에서는 생산에서 재고 업데이트가 어떻게 들어오는지 아무도 확인하지 않았습니다. 영업은 플랜트가 맞출 수 없는 일자를 제시하고 있었습니다.

가격 결정과 조건

가격 결정은 SD에서 가장 과소평가되는 설정입니다. 첫 청구서 분쟁이 생기기 전까지는 단순해 보입니다.

SD의 조건 기법은 기본 가격, 고객 할인, 수량 구간 할인, 할증, 운임, 세금을 처리합니다. 각 요소는 접근 순서를 가진 조건 유형이며, 값은 조건 레코드가 보유합니다.

제가 가장 흔히 보는 가격 문제는 Go-Live 때 설정된 뒤 한 번도 갱신되지 않은 낡은 가격 조건입니다. 비즈니스는 할인을 재협상했는데 아무도 SD의 조건 레코드를 갱신하지 않고, 청구서는 틀리며, 분쟁은 매출채권 부서로 떨어집니다.

가격 거버넌스는 설정이 아니라 프로세스에 관한 결정입니다. 누군가는 조건 레코드 유지보수를 책임져야 합니다.

출하

납품 처리는 피킹, 포장, 출고를 포함합니다. 출고는 핵심 이벤트입니다. 재고 감소를 전기하고, 납품을 청구 대상 목록에 올리며, 실제 납품 일자를 기록합니다. 출하 지점과 경로 결정이 납품이 생성되는 방식을 통제합니다. 유통 네트워크가 복잡한 기업은 SAP Transportation Management(TM)로 이를 확장합니다.

청구, 계정 결정, 세금

청구는 납품을 청구서로 바꾸고 회계 문서를 생성합니다. 계정 결정은 판매 조직, 고객과 자재의 계정 지정 그룹, 조건 유형을 바탕으로 각 청구 아이템을 매출, 세금, 기타 G/L 계정에 매핑합니다. 이것이 틀리면 청구서는 엉뚱한 계정에 전기되고, 재무는 월 마감 때서야 알게 됩니다.

세금 결정도 똑같이 깨지기 쉽습니다. 고객의 세금 분류, 자재의 세금 분류, 납품하는 국가 또는 관할 지역에 따라 달라집니다. 불일치가 생기면 과세 대상 판매에 세금이 붙지 않은 청구서가 나오거나, 면세 대상에 세금이 붙을 수 있습니다.

신용 관리

신용 점검은 고객을 신용 한도 너머로 끌고 갈 오더를 차단하거나 표시합니다. 한도가 유지보수될 때만 작동합니다. Go-Live 때 정해 둔 고정 한도는 결제 행태와 거래량이 달라지면서 아무 의미도 갖지 못하게 됩니다.

한도가 고객의 통상 주문 규모보다 낮아지면 모든 오더가 자동으로 차단됩니다. 그러면 영업팀은 한도 검토를 요청하는 대신 차단을 해제하는 법을 익힙니다.

그것은 신용 관리가 아닙니다. 우회 방법일 뿐입니다.

SD의 구조 요소와 각 요소가 연결되는 대상은 다음과 같습니다.

구조 요소	SAP SD에서의 목적	주요 연결
판매 조직	최상위 판매 단위로, 판매 조건과 책임을 맡음	FI의 회사 코드에 지정됨
유통 경로	제품이 고객에게 도달하는 방식(도매, 소매, 직판)	가격 결정, 마스터 데이터, 파트너 결정을 통제
제품군	판매 조직 안의 제품 그룹	리포팅과 출력을 위한 자재 그룹화
판매 영역	판매 조직, 유통 경로, 제품군의 조합	모든 판매 문서와 고객 레코드에 필수
판매 사무소	지역별 판매 단위	지역별 리포팅과 파트너 결정
판매 그룹	판매 사무소 내의 팀	오더의 담당자
출하 지점	상품이 출하되는 장소	SD를 창고 관리와 운송에 연결
플랜트	생산 또는 공급 단위	재고의 출처이며 출하 지점과 연결됨

판매 영역이 실무 단위입니다. 고객 판매 데이터는 판매 영역별로 유지보수되고, 모든 판매 문서는 하나의 판매 영역 안에서 생성됩니다. 많은 마이그레이션이 여기서 발목을 잡힙니다. 판매 영역에 깔끔하게 매핑되지 않는 레거시 고객 레코드는 로드하기 전에 제대로 준비해야 합니다.

ECC에서 이전한다면 범위에 반영해야 할 SD 변경 사항은 다음과 같습니다. SAP는 S/4HANA 문서에서 이 영역을 “Sales”로 분류하지만, 대부분의 팀은 여전히 SD라고 부릅니다.

ECCS/4HANA

고객ECC고객 마스터 레코드S/4HANA고객 역할이 있는 비즈니스 파트너

신용 관리ECCFI-AR-CRS/4HANASAP Credit Management(FIN-FSCM-CR), 선택 사항 아님

리베이트ECCSD 리베이트 처리, 인덱스에서 재구성S/4HANASettlement Management의 조건 계약

가용성 점검ECC기본 제품 가용성 점검S/4HANAAdvanced ATP: 할당, 백오더, 대체 플랜트

청구ECCFI와 CO를 별도로 대사S/4HANA유니버설 저널(ACDOCA)의 라인 아이템 하나

수익 인식ECC많은 프로그램에서 맞춤 이연 로직S/4HANASAP Revenue Accounting and Reporting, 별도 라이선스

1. 고객은 비즈니스 파트너입니다. 고객 마스터 데이터는 고객 역할이 있는 비즈니스 파트너를 통해 유지보수합니다. 전환 시에는 전환이 실행되기 전에 고객-공급업체 통합(customer-vendor integration)을 설정해야 합니다.
2. 신용 관리는 SAP Credit Management로 옮겨 갑니다. ECC의 신용 관리(FI-AR-CR)는 S/4HANA에서 사용할 수 없습니다. SAP Credit Management(FIN-FSCM-CR)이 그 후속이므로, 전환 시 신용 데이터와 설정을 마이그레이션해야 합니다. 선택 사항이 아닙니다.
3. 리베이트는 조건 계약으로 옮겨 갑니다. 기존 SD 리베이트 처리는 Settlement Management(조건 계약 관리)로 대체됩니다. 리베이트 조건은 인덱스에서 재구성되지 않고 즉시 적용됩니다.
4. Advanced ATP. S/4HANA의 Advanced ATP는 제품 할당, 백오더 처리, 플랜트 간 대체 기반 확약, 납품 릴리스, 공급 지정을 추가합니다. S/4HANA Cloud에서는 이 기능이 표준 라이선스에 포함됩니다. 온프레미스에서는 활성화하면 전용 라이선스가 필요합니다.
5. 청구는 유니버설 저널에 전기됩니다. FI, CO, 수익성 분석이 ACDOCA의 라인 아이템 하나를 공유하므로, ECC에서 하던 FI-CO 대사 작업이 사라집니다. 대신 계정 결정 오류는 즉시 엉뚱한 계정에 전기되는 것이고, 라인 아이템 수준에서 그대로 보입니다.
6. 수익 인식. IFRS 15에 따른 다중 요소 계약, 구독, 장기 서비스에서는 SAP Revenue Accounting and Reporting이 많은 ECC 프로그램이 만들었던 맞춤 이연 로직을 대체합니다. 별도 라이선스이며, 연말에 발견할 것이 아니라 Go-Live 전에 설계해야 합니다.

Clean Core는 SD 커스터마이징을 다루는 방식을 바꿉니다. 퍼블릭 클라우드에서는 코어에 커스텀 코드를 넣을 수 없습니다. 프라이빗 클라우드와 온프레미스에서는 가능하지만 업그레이드를 매번 더 어렵게 만듭니다. 기존 가격 결정 Z 루틴 대부분은 표준 조건 유형, 포뮬라, BAdI로 대체할 수 있습니다. 정말로 남는 것은 SAP BTP의 사이드 바이 사이드 확장에 둬야 합니다. 이 결정은 제 Clean Core 가이드에서 다룹니다.

SD와 MM

가용성 점검은 MM에서 재고를 읽고, 출고는 재고 이동을 전기합니다. 재고 데이터가 틀리면 ATP 결과를 믿을 수 없습니다. 재고가 실제로는 출하 지점에 없어서 출고가 실패하면 납품을 완료할 수 없고 청구가 멈춥니다. 마스터 데이터와 규율로 둘을 맞춰 두십시오. 표준 전기를 우회하는 수작업 재고 조정은 하지 않아야 합니다.

SD와 PP

수주 생산(make-to-order) 시나리오에서는 판매 오더가 생산을 직접 이끌 수 있어서, 확정된 일자는 생산 오더가 뒷받침하는 약속이 됩니다. 자재 마스터의 전략 그룹이 판매 오더와 예측이 서로 어떻게 작용하는지를 통제합니다. 이를 잘못 설정하면 둘이 상계되지 않고 합산되어 계획 실행이 수요를 과대 계상하고, 과잉 생산이 뒤따릅니다. 계획 측면은 제 SAP PP 가이드에서 다룹니다.

SD와 FI

청구 문서가 인터페이스입니다. 청구서마다 매출, 세금, 고객 미결 항목을 유니버설 저널에 전기하는 회계 문서가 생성됩니다. 고객 마스터의 지급 조건이 만기일을 결정합니다. 영업이 재무에 알리지 않고 조건을 협상하면, 시스템은 재무가 동의한 적 없는 조건을 강제하게 됩니다.

SD 설계가 모든 매출을 청구 시점에 인식하는 것으로 처리하는데 계약은 다르게 정하고 있다면, 사후 보완에는 큰 비용이 듭니다. 설계를 승인하기 전에 재무와 수익 인식 방식에 합의하십시오. 연동의 재무 측면은 제 SAP FICO 가이드를 참고하십시오.

Go-Live 이후 겪는 고통의 대부분은 네 곳에서 비롯됩니다.

준비되지 않은 고객 마스터. 모든 필드는 하류에서 의미가 있습니다. 세금 분류가 없으면 세금이 틀립니다. 지급 조건이 없으면 FI는 만기일을 계산할 수 없습니다. 출하 조건이 없으면 납품 일정 수립이 깨집니다. 물량은 계획이 가정한 것보다 많고 원천 데이터는 더 나쁘며, 정제에는 비즈니스 결정이 필요합니다. 일찍 시작하고, 이것을 기술적인 로드가 아니라 비즈니스 워크스트림으로 다루십시오. 방법은 SAP 데이터 마이그레이션이 실패하는 이유를 다룬 제 글에 있습니다.

유지보수되지 않는 가격 조건. 아무도 검토하지 않는 Go-Live 시점의 조건은 첫해 안에 청구서 분쟁이 됩니다.

현실과 단절된 가용성 점검. 낡은 데이터를 읽는 ATP는 비즈니스가 지킬 수 없는 약속을 만들어 냅니다. 단위 테스트에서 쓰는 깔끔한 테스트 데이터가 아니라 실제 생산과 재고 시나리오로 검증하십시오.

Go-Live 후에야 발견되는 계정 결정의 공백. 실제 계정과목표, 세금 코드, 자재 그룹으로 테스트하십시오. 일치하지 않는 세금 코드는 오더를 막거나, 무엇이 잘못되었는지 아무도 깨닫기 전에 청구서 분쟁을 일으킬 수 있습니다.

아래 표는 제가 UAT 승인 전에 하나씩 짚어 볼 체크리스트입니다.

리스크	영향	완화 방안
불완전한 고객 마스터	청구서 오류, 납품 실패, FI 전기 공백	데이터 워크스트림을 일찍 시작하고, 마이그레이션 전에 판매 영역별 필수 필드를 정의
낡은 가격 조건	청구서 분쟁, 잘못된 매출	Go-Live 때 조건 레코드 담당자와 검토 주기를 지정
PP 또는 MM과 단절된 ATP	믿을 수 없는 납품 약속	UAT 승인 전에 실제 계획 시나리오로 ATP 테스트
계정 결정의 공백	매출이 엉뚱한 계정에 전기됨	실제 계정과목표와 전체 세금 코드 세트로 테스트
일상이 된 신용 차단 해제	통제되지 않는 익스포저, 채권 분쟁	한도 검토를 강제하고, 처음 90일 동안 수동 해제를 추적
테스트되지 않은 출력	청구서와 납품서가 자동으로 발송되지 않음	Go-Live 전에 모든 출력 유형을 실제 인쇄 및 이메일 라우팅으로 테스트
어긋난 지급 조건	잘못된 만기일, 현금 예측 오류	고객 데이터를 로드하기 전에 영업과 재무가 조건에 합의

영업팀이 검토를 요청하는 대신 습관적으로 신용 차단을 해제하고 있다면, 습관이 굳기 전인 처음 90일 안에 바로잡으십시오.

SAP SD란 무엇이며 어떤 일을 합니까?

SAP SD(Sales and Distribution)는 Order-to-Cash를 관리합니다. 문의, 견적, 판매 오더, 납품, 청구, 그리고 재무 회계로의 인계입니다. 문서 흐름이 각 단계를 앞 단계와 연결하므로 모든 청구서를 최초 오더까지 추적할 수 있습니다. 재고와 출고를 위해 MM과, 수주 생산과 가용성을 위해 PP와, 매출, 세금, 채권을 위해 FI와 연동됩니다.

SAP SD의 조직 구조는 무엇입니까?

실무 단위는 판매 영역으로, 판매 조직, 유통 경로, 제품군의 조합입니다. 모든 판매 문서는 판매 영역 안에서 생성되고 고객 판매 데이터는 판매 영역별로 유지보수됩니다. 그 아래에 리포팅과 책임을 위한 판매 사무소와 판매 그룹이 있습니다. 물류 측면에서는 출하 지점과 플랜트가 상품이 어디서 출하되는지를 결정합니다. 고객 데이터를 로드하기 전에 구조를 제대로 잡으십시오. 나중에 바꾸면 데이터를 다시 로드해야 합니다.

SAP SD에서 가격 결정은 어떻게 작동합니까?

가격 결정은 조건 기법을 사용합니다. 각 가격 요소는 조건 유형이고, 접근 순서가 어떤 조건 레코드를 적용할지 결정하며, 가격 결정 절차가 조건 유형을 순서대로 결합합니다. 대부분의 가격 분쟁은 설정 오류가 아니라 상업 조건이 바뀔 때 갱신되지 않은 조건 레코드에서 비롯됩니다.

SAP S/4HANA의 Advanced ATP란 무엇입니까?

Advanced Available-to-Promise(aATP)는 S/4HANA의 가용성 점검입니다. 기본 제품 가용성 점검에 더해 제품 할당, 백오더 처리, 플랜트 간 대체 기반 확약, 납품 릴리스, 공급 지정을 추가합니다. 이 기능은 S/4HANA Cloud에 포함되어 있고, 온프레미스에서는 활성화하면 전용 라이선스가 필요합니다. 공급이 제한적이거나 할당 규칙이 중요한 곳에 사용하십시오. 안정적인 공급망이라면 잘 설정한 기본 점검으로 충분한 경우가 많습니다.

SAP SD는 재무 회계와 어떻게 연동됩니까?

청구 문서를 통해서입니다. 청구 문서를 회계로 릴리스하면 매출, 세금, 고객 미결 항목에 대한 분개가 생성됩니다. 계정 결정이 판매 조직, 계정 지정 그룹, 조건 유형에서 G/L 계정을 결정합니다. 세금은 고객과 자재의 세금 분류에 따라 달라집니다. 고객 마스터의 지급 조건이 만기일을 정합니다. IFRS 15 사례에서는 SAP Revenue Accounting and Reporting이 매출을 이연하고 시간에 걸쳐 인식합니다.

ECC에서 S/4HANA로 옮기면 SAP SD에서 무엇이 달라집니까?

고객은 비즈니스 파트너가 됩니다. 신용 관리는 FI-AR-CR에서 SAP Credit Management로 옮겨 가며, 이는 필수입니다. 리베이트 처리는 Settlement Management의 조건 계약으로 대체됩니다. Advanced ATP를 사용할 수 있게 되고, 청구는 유니버설 저널에 전기됩니다. 이 모두를 일찍 범위에 넣으십시오. 하나하나가 설정, 데이터 마이그레이션, 테스트를 필요로 하기 때문입니다.

SAP SD 구축에서 가장 흔한 실수는 무엇입니까?

다섯 가지가 반복해서 나옵니다. 고객 마스터 데이터를 과소평가하는 것. Go-Live 이후 가격 조건에 담당자를 두지 않는 것. ATP를 깔끔한 데이터로만 테스트하는 것. 계정 결정을 단순화한 데이터로 테스트하는 것. 출력을 처음부터 끝까지 테스트하지 않는 것. 마지막은 놓치기 쉽습니다. 청구서가 자동으로 발송되지 않으면 누군가 손으로 출력하기 시작하고, 그 우회 방법이 영구화됩니다.