KSU1 vs KSV1 원가배부 차이 #shorts #SAP #CO

이 글에서 다루는 내용과 도달 목표

SAP CO(관리회계)에서 월말 결산 때 공통비를 코스트센터 간에 넘기는 대표적인 두 가지 방식이 분배(Distribution)와 배부(Assessment)입니다. 이름이 비슷해 혼용되기 쉽지만, 원가요소(Cost Element)를 다루는 방식이 근본적으로 다르고, 그 차이가 원가 추적성과 결산 리포팅 품질을 좌우합니다. 이 글을 끝까지 읽으면 다음을 할 수 있게 됩니다.

분배와 배부의 전기(posting) 구조 차이를 테이블(COSP/COSS/COEP) 수준에서 설명할 수 있다
KSV1/KSU1으로 사이클(Cycle)-세그먼트(Segment)를 직접 설계할 수 있다
통계키수치(SKF), 고정 비율, 변동 기준 등 배분 기준을 시나리오에 맞게 선택할 수 있다
실무에서 "언제 분배, 언제 배부"인지 판단 기준을 세울 수 있다

먼저 갖추면 좋은 배경

코스트센터(Cost Center) 마스터(KS01/KS03)와 1차·2차 원가요소 개념, 그리고 CO 실제 전기(KB11N 등)를 한 번이라도 다뤄본 경험이 있으면 충분합니다. FI 총계정원장(G/L)과 CO의 관계, 특히 S/4HANA에서 원가요소가 G/L 계정으로 통합되었다는 점을 알고 있다면 이해가 훨씬 빠릅니다. 난이도는 중급(intermediate)입니다.

검증 환경과 준비물

이 글의 예제는 SAP S/4HANA 2023 (On-Premise) 기준으로 작성했으며, ECC 6.0에서도 트랜잭션 코드는 동일하게 동작합니다. 다만 저장 구조는 다릅니다. ECC는 COSP(1차 원가 합계)/COSS(2차 원가 합계)/COEP(라인아이템)에 기록되고, S/4HANA는 유니버설 저널 ACDOCA에 통합 기록되며 COSP/COSS는 호환성 뷰로 남아 있습니다. 준비물은 다음과 같습니다.

발신자 코스트센터: CC-9100(전산지원), CC-9200(총무)
수신자 코스트센터: CC-1000(생산1팀), CC-1100(생산2팀), CC-3000(영업)
2차 원가요소(카테고리 42): 9410000(IT비용배부) — S/4HANA에서는 FS00에서 계정유형 "Secondary Costs"로 생성
통계키수치: PC-CNT(PC 보유 대수, KK01로 생성, KB31N으로 실적 입력)
권한: 오브젝트 K_CSKS_SET 및 사이클 실행 권한

배부와 분배, 구조가 다르면 추적성이 다르다

두 방식 모두 "발신자 코스트센터의 원가를 수신자에게 옮긴다"는 목적은 같습니다. 차이는 어떤 원가요소로 옮기느냐입니다.

분배(Distribution, KSV1)는 원래의 1차 원가요소(primary cost element)를 그대로 유지합니다. CC-9100에 전기된 "전력비 1,000,000원"을 분배하면, 수신자 CC-1000에도 전력비라는 동일한 원가요소로 도착합니다. 비유하자면 택배 상자를 뜯지 않고 그대로 전달하는 것과 같습니다. 수신자 입장에서 "이 돈이 원래 무슨 성격의 비용이었는지"가 보존되므로 추적성이 높습니다. 단, 1차 원가요소만 분배할 수 있습니다.

배부(Assessment, KSU1)는 여러 1차 원가요소(급여, 감가상각비, 소모품비...)를 하나의 2차 원가요소(카테고리 42)로 묶어서 넘깁니다. 여러 상자를 하나의 큰 상자에 담아 "IT비용배부"라는 라벨 하나만 붙여 보내는 셈입니다. 수신자는 "IT부서에서 총 얼마 받았다"만 보이고 세부 내역은 발신자 쪽 리포트로 돌아가야 확인할 수 있습니다. 대신 세그먼트당 전기 라인 수가 크게 줄어 결산이 가볍고 빠릅니다.

구분	분배(Distribution)	배부(Assessment)
트랜잭션	KSV1(생성)/KSV5(실행)	KSU1(생성)/KSU5(실행)
원가요소	1차 원가요소 유지	2차 원가요소(카테고리 42)로 통합
이관 대상	1차 원가만	1차 + 2차 원가 모두 가능
추적성	높음(원가 성격 보존)	낮음(합계만 전달)
라인아이템 수	원가요소별로 생성되어 많음	적음(결산 성능 유리)
기록 테이블	COSP 갱신	COSS 갱신

실무 선택 기준은 일반적으로 이렇습니다. 수신 부서가 비용 성격별 분석을 해야 하는 유틸리티·임차료성 공통비는 분배, 지원부서(IT·총무·인사)처럼 "서비스 총액"으로 청구하는 성격이면 배부가 권장됩니다. 또한 발신자에 이미 2차 원가가 쌓여 있다면(예: 활동배부를 받은 코스트센터) 분배는 불가능하므로 배부를 써야 합니다.

단계별 실전 구성

1단계 — 기본: 총무비 분배 사이클(KSV1)

KSV1에서 사이클 ZDIS01, 시작일 2026-01-01로 생성한 뒤 세그먼트 SEG-GA를 추가합니다.

발신자(Sender): 코스트센터 CC-9200, 원가요소 그룹 ZGA-COST(임차료·전력비·수도광열비), 발신 규칙 = 전기 금액(Posted amounts) 100%
수신자(Receiver): CC-1000, CC-1100, CC-3000, 수신 추적 기준(Tracing Factor) = 고정 비율(Fixed percentages) 40/40/20

KSV5에서 기간 001, 2026 회계연도로 테스트 실행(Test Run) 후 결과를 확인하고 실전기(Update Run)합니다. 실행 후 KSB1에서 보면 CC-1000에 임차료·전력비가 각각의 1차 원가요소 그대로 도착해 있고, CC-9200의 해당 원가요소 잔액은 0이 됩니다.

2단계 — 실무: SKF 기반 IT비용 배부(KSU1) + 오류 대응

고정 비율은 조직이 바뀔 때마다 사이클을 수정해야 하므로, 실무에서는 통계키수치를 기준으로 잡는 경우가 많습니다. 월초에 KB31N으로 부서별 PC 대수를 입력합니다(CC-1000: 50대, CC-1100: 30대, CC-3000: 20대). KSU1에서 사이클 ZASM01, 세그먼트 SEG-IT를 만들고,

발신자: CC-9100, 배부 원가요소(Assessment Cost Element) = 9410000
수신자 추적 기준: 변동 부분(Variable portions), SKF PC-CNT 실적값

KSU5 실행 시 자주 만나는 오류와 대응은 이렇습니다. 수신자 SKF가 미입력이면 "추적 기준이 0" 오류(GA710 계열)가 나므로, 결산 체크리스트에 KB31N 입력을 사이클 실행 앞 단계로 고정하세요. 실행 로그는 반드시 세그먼트별 발신 금액 합계와 수신 금액 합계가 일치하는지 확인하고, 잘못 실행했다면 KSU5의 역분개(Reversal) 기능으로 같은 기간을 지정해 취소합니다. 라인아이템 검증은 COEP(ECC) 또는 ACDOCA(S/4HANA)에서 가능합니다.

-- S/4HANA: 배부 결과 검증 (업무거래 RKIU = Assessment 실제)
SELECT rcntr, kstar, SUM( hsl ) AS amount
  FROM acdoca
 WHERE rldnr  = '0L'
   AND gjahr  = '2026'
   AND poper  = '001'
   AND awtyp  = 'COBK'
   AND kstar  = '9410000'
 GROUP BY rcntr, kstar;

3단계 — 프로덕션: 성능·통제·자동화

운영 환경에서는 세 가지를 챙깁니다. 첫째, 성능: 원가요소 성격별 구분이 계약상 필요 없다면 배부를 택해 라인아이템을 줄이고, 세그먼트를 과도하게 쪼개지 않습니다. 발신자별 세부 내역이 일부만 필요하면 배부 구조(Allocation Structure)를 정의해 원가요소 그룹별로 2차 원가요소를 2~3개로 나누는 절충안이 일반적입니다. 둘째, 통제: 사이클 실행을 결산 배치(스케줄 매니저 또는 잡)로 묶고, 실행 순서를 "분배 → 배부"로 고정합니다(배부가 먼저 돌면 이후 분배 대상 금액이 왜곡될 수 있음). 셋째, 검증 자동화: 발신자 잔액이 0인지 확인하는 간단한 점검 로직을 결산 후 자동 실행합니다.

" 결산 후 발신자 코스트센터 잔액 0 검증 (S/4HANA)
SELECT rcntr, SUM( hsl ) AS balance
  FROM acdoca
  WHERE rldnr = '0L' AND gjahr = @gv_year AND poper = @gv_period
    AND rcntr IN ( 'CC-9100', 'CC-9200' )
  GROUP BY rcntr
  INTO TABLE @DATA(lt_bal).

LOOP AT lt_bal INTO DATA(ls_bal) WHERE balance <> 0.
  " 잔액 존재 → 결산 담당자 알림 처리
  MESSAGE i001(zco) WITH ls_bal-rcntr ls_bal-balance.
ENDLOOP.

참고로 S/4HANA Cloud 및 최신 On-Premise에서는 Fiori 앱 "Manage Allocations" 기반의 유니버설 배분(Universal Allocation)이 KSU1/KSV1의 후속으로 제공되므로, 신규 구축이라면 이쪽 채택을 검토하는 것이 권장됩니다.

자주 겪는 문제와 해결 포인트

Q1. 배부를 실행했는데 수신자 원가가 원가요소별로 안 보입니다. 정상 동작입니다. 배부는 2차 원가요소 하나로 합산 전달되는 구조이므로, 성격별 분석이 필요하면 사이클을 분배로 재설계하거나 배부 구조로 2차 원가요소를 세분화해야 합니다.
Q2. KSV1 분배 사이클에 2차 원가요소를 넣었더니 이관이 안 됩니다. 분배는 1차 원가요소만 처리합니다. 발신자에 쌓인 2차 원가(활동배부 수신분 등)는 배부(KSU1)로만 넘길 수 있습니다.
Q3. 같은 기간에 KSU5를 두 번 실행해 금액이 중복됐습니다. 동일 사이클·동일 기간 재실행은 기존 결과를 대체하는 것이 기본 동작이지만, 사이클을 복사해 두 개를 돌렸다면 중복 전기됩니다. KSU5 역분개로 한쪽을 취소하고, 사이클 명명 규칙과 실행 잡 단일화로 재발을 막으세요.
Q4. 사이클 실행이 "잠금(lock)" 오류로 실패합니다. 같은 코스트센터를 발신자로 쓰는 다른 사이클이 병행 실행 중일 가능성이 높습니다. 결산 잡 순서를 직렬화하세요.
Q5. 반복 사이클(iterative) 설정 시 무한 순환이 걱정됩니다. 지원부서 간 상호 서비스(IT ↔ 총무)가 있으면 사이클 헤더의 반복(Iterative) 플래그를 켜야 수렴 계산이 수행됩니다. 끄면 실행 순서에 따라 잔액이 남을 수 있습니다.

여기서 더 나아가려면

이 글의 배분 로직을 이해했다면 자연스럽게 이어지는 주제는 세 가지입니다. 첫째, 활동유형(Activity Type) 기반 직접 활동배부(KB21N)와 요율 계산(KSPI) — 배부보다 인과관계가 정밀한 방식입니다. 둘째, 간접비 부과(Overhead Surcharge, Costing Sheet)와 템플릿 배부. 셋째, S/4HANA 유니버설 배분(Manage Allocations)으로의 전환 전략과 수익성분석(CO-PA) 배부(KEU1)까지 확장하면 CO 결산 전체 그림이 완성됩니다.

함께 보면 좋은 문서

댓글 0