Guide

SAP Distribution vs Assessment: 같은 1억원을 배부해도 관리손익이 다르게 보이는 이유

SAP CO에서 Distribution과 Assessment를 설명할 때 흔히 “둘 다 비용을 나눠주는 기능”이라고 말한다.

기능적으로는 맞지만 실무에서는 이 차이를 훨씬 중요하게 봐야 한다.

같은 1억원을 같은 부서들에 똑같은 비율로 배부하더라도 receiver에서 비용이 어떤 모습으로 남는가가 다르기 때문이다.

Receiver에 어떤 정보를 남길 것인가가 두 방식의 핵심 차이다

Distribution과 Assessment는 단순히 같은 금액을 다른 방식으로 보내는 선택이 아니다. Receiver에서 원래 비용종류의 상세를 계속 보고 싶은지, 아니면 관리목적의 공통비 묶음으로 보고 싶은지가 방식 선택의 기준이 된다. 따라서 배부 설계는 Sender에서 출발하되 최종 Receiver 보고서에서 필요한 정보수준을 먼저 정하는 편이 일관적이다.

SAP의 Distribution은 primary cost를 receiver로 배부하면서 원래 primary cost element, 즉 S/4HANA 관점에서는 해당 G/L account의 원래 성격을 유지한다.

예를 들어 본사 관리부서에 다음 비용이 있다고 하자.

  • 급여 5,000만원
  • 임차료 3,000만원
  • 전산비 2,000만원

총 1억원을 세 사업부에 Distribution하면 receiver에서도 급여·임차료·전산비라는 원래 비용구조가 유지된다.

따라서 사업부 담당자는 “본사에서 총 3천만원이 왔다”가 아니라 그 안에 어떤 원가가 들어있는지를 볼 수 있다.

Assessment는 primary cost뿐 아니라 secondary cost도 배부할 수 있고, receiver에는 assessment용 secondary cost element를 사용해 금액을 전달한다.

위의 급여·임차료·전산비 1억원을 Assessment하면 receiver에서는 예를 들어 “본사 공통비 배부”라는 하나 또는 몇 개의 관리항목으로 나타낼 수 있다.

원래 비용계정의 상세는 sender 쪽에서 확인하고 receiver에는 왜 부담한 비용인지에 더 초점을 맞춘 구조다.

관리 질문 더 자연스러운 방식
이 사업부가 최종적으로 어떤 원가종류를 부담했는가? Distribution
본사·지원부문에서 받은 공통비가 얼마인가? Assessment
원래 G/L 성격을 receiver에서도 유지해야 하는가? Distribution
여러 원가를 관리 목적별 묶음으로 보여주고 싶은가? Assessment

따라서 기능의 차이보다 receiver의 관리보고서에서 어떤 정보를 보존할 것인가가 선택기준이 된다.

SAP CO에서 Sender의 급여·임차료·전산비를 Distribution하면 원래 primary G/L 성격이 Receiver에 유지되고 Assessment하면 관리목적 secondary cost element로 요약되며 두 방식 모두 Driver와 Cycle, Zero-sum 검증이 필요한 구조
같은 배부금액도 Receiver에 남는 정보구조는 다르다

회사 전체 비용은 안 바뀌어도 사업부 이익률은 크게 달라진다

A사업부 매출 100억원, 배부 전 영업이익 15억원이라고 하자.

본사 공통비 3억원을 A사업부에 배부하면 최종 관리이익은 12억원으로 내려간다.

회사 전체 관점에서는 새 비용이 생긴 것이 아니다.

이미 본사에 있던 비용이 A사업부로 이동했을 뿐이다.

하지만 A사업부 영업이익률은:

15% → 12%

로 달라진다.

따라서 allocation은 회사 전체 비용을 만드는 작업이 아니라 누가 비용을 책임질 것인가를 결정하는 작업이다.

배부방식보다 먼저 Driver의 인과성과 데이터 품질을 본다

배부방식을 정교하게 만들어도 Driver가 비용 발생과 관계없거나 데이터가 불안정하면 결과의 설명력은 떨어진다. Driver는 비용과의 인과관계, 반복적으로 확보 가능한 데이터, 관리자가 이해할 수 있는 설명 가능성을 함께 만족해야 한다. 그래야 배부결과를 숫자 이동이 아니라 관리정보로 사용할 수 있다.

배부방식을 완벽하게 선택해도 driver가 잘못되면 관리손익이 왜곡된다.

본사 IT 비용 12억원을 A·B·C 사업부에 배부한다고 하자.

매출액 비율이 50:30:20이라면:

  • A: 6억원
  • B: 3.6억원
  • C: 2.4억원

그런데 실제 IT 서비스 소비량은 사용자 수 기준 20:50:30이라면 전혀 다른 결과가 나온다.

어떤 driver가 옳은지는 비용의 발생원인에 따라 달라진다.

IT 비용에 매출액을 쓰는 것이 단순하기는 하지만 실제 resource consumption을 설명하지 못할 수 있다.

1. 인과성

비용이 증가하는 원인과 driver가 연결되는가?

예를 들어 주문처리 부서 비용이라면 매출액보다 주문건수가 더 설명력이 높을 수 있다.

2. 측정 가능성

이론적으로 좋은 driver라도 안정적으로 데이터를 얻을 수 없다면 매월 수작업과 오류가 증가한다.

3. 행동 왜곡 최소화

관리자가 배부비용을 줄이기 위해 실제 사업과 무관한 방식으로 driver를 조작하도록 유도해서는 안 된다.

배부기준은 계산식이면서 동시에 조직의 행동을 바꾸는 관리정책이다.

고정비를 매출 비율로 배부할 때 생기는 착시

사업부 A의 매출이 크게 성장했다고 하자.

본사비용은 그대로인데 배부기준이 매출액이면 A가 부담하는 본사비가 자동으로 늘어난다.

그 결과 A의 성장으로 회사 전체 수익성이 좋아졌는데도 A사업부의 관리이익 개선폭은 작게 보일 수 있다.

이것이 잘못이라고 단정할 수는 없다. 회사가 의도적으로 규모에 따라 공통비를 부담시키는 정책일 수도 있다.

중요한 것은 경영진이 성과 변화와 allocation rule 효과를 분리해서 볼 수 있어야 한다는 점이다.

Cycle은 재현 가능해야 하고 실행 후에는 Zero-sum을 검증한다

Cycle과 Segment는 다음 실행에서도 같은 규칙을 재현할 수 있도록 기준과 순서를 명확하게 남겨야 한다. 실행 뒤에는 Sender에서 빠진 금액과 Receiver에 배부된 금액이 일치하는지 Zero-sum부터 확인하면 설정오류나 누락을 빠르게 찾을 수 있다. 재현성과 금액 보존이 확보된 뒤에야 Driver별 상세분석이 의미를 가진다.

실무에서는 sender, receiver, tracing factor를 cycle과 segment로 구성한다.

여기서 관리상 중요한 것은 “이번 달 숫자가 맞았다”가 아니다.

다음 달에도 같은 정책으로 재현되고, 변경됐다면 왜 변경됐는지 알 수 있어야 한다.

따라서 최소한 다음 정보는 관리돼야 한다.

  • Cycle/segment 목적
  • Sender 범위
  • Receiver 범위
  • Driver 정의와 데이터 출처
  • 적용 시작·종료 시점
  • Rule 변경 사유
  • 실행 전후 금액 검증

단순한 내부비용 재배부라면 전체 관점에서는 sender credit과 receiver debit이 대응해야 한다.

따라서 가장 먼저:

배부 전 총액 = 배부 후 전체 총액

인지 확인한다.

그 다음:

  1. Sender가 의도한 만큼 credit됐는가
  2. Receiver 합계가 동일한가
  3. Driver 비율이 실제 입력데이터와 맞는가
  4. 예외 receiver가 누락되지 않았는가
  5. 전월 대비 큰 변화가 rule 변경인지 business change인지 구분되는가

를 본다.

Distribution과 Assessment를 너무 많이 섞으면 관리손익 설명이 어려워진다

한 조직에서는 Distribution, 다른 조직에서는 Assessment, 또 다른 곳에서는 수작업 reposting을 사용하면서 명확한 원칙이 없다면 최종 손익의 lineage를 설명하기 어려워진다.

따라서 기능별 자유도를 최대화하기보다 사용원칙을 정하는 편이 좋다.

예를 들어:

  • 원가종류의 원천정보가 receiver에서도 필요한 비용 → Distribution
  • 관리목적상 공통비 묶음으로 보는 것이 중요한 비용 → Assessment
  • 직접 원인·실적 수량이 명확한 경우 → 직접귀속 또는 activity 기반 방식 검토

처럼 정책을 정할 수 있다.

결론

Distribution과 Assessment의 핵심 차이는 메뉴가 아니라 정보를 어디까지 보존해 receiver에게 전달할 것인가다.

Distribution은 원래 primary account의 정체성을 유지하고, Assessment는 여러 비용을 secondary cost element로 요약해 관리목적을 강조할 수 있다.

그러나 어느 기능을 선택하든 잘못된 driver를 사용하면 제품·사업부·고객 수익성이 왜곡될 수 있다.

따라서 좋은 allocation 설계의 순서는:

비용의 원인 정의 → receiver 결정 → driver 결정 → 정보보존 수준 결정 → Distribution/Assessment 선택 → 실행 후 reconciliation

이다.

배부는 비용을 나누는 기술이 아니라 조직의 수익성을 어떤 논리로 설명할지 결정하는 관리회계 정책이다.