2026. 5. 9. 20:47ㆍSAP CO/CATEGORY 4: 고급 주제 (Advanced)
들어가며
지난 글에서는 가격 차이가 정산을 거쳐 자재(MAT)와 CO-PA로 흘러가는 과정을 다루었습니다. 마지막 질문이 남습니다.
"그 차이가 도착한 CO-PA가 정확히 무엇이며, 거기서 어떤 분석이 가능한가?"
이 질문은 단순히 보고서 구조의 문제가 아닙니다. 재무 회계와 관리 회계가 결산마다 서로 다른 숫자를 보고하는 정합성 이슈, 매출 시점에 단일 COGS 계정에 묶여 제품별·원가 항목별 마진 분석이 불가능했던 한계 — 이러한 영역에서 SAP S/4HANA가 제시하는 해법이 Margin Analysis입니다.
이번 글은 세 가지 CO-PA 방식의 차이부터 시작해, S/4HANA가 Margin Analysis를 표준으로 권장하는 이유, 도입 시 현실적인 고려사항, 그리고 핵심 강점인 COGS Splitting까지 알아보겠습니다.
1. CO-PA의 세 가지 방식
S/4HANA에서 SAP의 CO-PA(Profitability Analysis, 수익성 분석)는 다음 세 가지 형태로 정리됩니다.
| 구분 | Costing-based CO-PA | Account-based CO-PA | Margin Analysis |
| 데이터 저장 | 별도 테이블 (CE1xxxx 등) | 기존 CO 라인 아이템 테이블(COEP 등) | ACDOCA (Universal Journal) |
| 저장 단위 | Value Field | G/L Account / Cost Element | G/L Account + 약 60개 특성 |
| FI 정합성 | 별도 reconciliation 필요 | 자동 정합 | Reconciled by Design |
Costing-based CO-PA의 한계
ECC 시절 한국 기업의 다수가 Costing-based CO-PA를 사용했습니다. Value Field(사용자 정의 금액 버킷)를 통한 유연한 분석과, SD 통계 조건이나 평가(Valuation) 기능으로 재무에 없는 가공 데이터까지 다룰 수 있었기 때문입니다.
다만 다음과 같은 구조적 한계가 존재합니다.
| 1) 재무(FI)와 별도 데이터베이스 | ACDOCA와 다른 테이블에 저장되어 손익계산서와 마진 보고서가 다른 숫자를 보여주는 사고가 빈번 |
| 2) COGS 단일 기표 | 출고 시 COGS가 하나의 G/L 계정에 총액으로 기표되어 FI 측 원가 구성 분해 불가 |
| 3) Variance 단일 인식 | 9가지 카테고리별 분해를 위해 KEI1 매핑이 추가로 필요 |
2. Margin Analysis의 핵심 메커니즘
Margin Analysis는 "Universal Journal에 통합된 진화된 Account-based CO-PA"입니다.
2.1 Single Source of Truth 구조
S/4HANA의 모든 회계 전표는 ACDOCA(Universal Journal) 단일 테이블에 저장됩니다. Margin Analysis는 이 ACDOCA에 CO-PA 특성(Characteristic)을 직접 컬럼으로 추가하여 작동합니다.

이 Single Source of Truth 구조는 다음을 보장합니다.
- 재무 손익계산서와 CO-PA 마진 보고서의 숫자가 항상 일치
- 별도 reconciliation 작업 불필요
- G/L → 제품 → 고객으로의 단일 경로 드릴다운
💡 'Single Source of Truth'는 SAP의 공식 표현
마케팅 슬로건이 아니라 ACDOCA 데이터 모델 자체를 설명하는 SAP 공식 용어입니다. SAP Press 공식 블로그는 이를 "Universal Journal은 ACDOCA라는 단일 테이블에 라인 아이템 상세를 캡처하여 조직 전체의 Single Source of Truth로 작동한다"로 정의합니다. 즉 재무 회계와 관리 회계의 전통적 분리가 더 이상 적용되지 않는, 데이터 모델 차원의 통합을 의미합니다.
3. Costing-based CO-PA vs. Margin Analysis 구조 비교
S/4HANA 전환(Brown-field)을 준비하는 기업이 가장 면밀히 검토해야 하는 차이점입니다.
3.1 데이터 저장 방식
| 항목 | Costing-based CO-PA | Margin Analysis |
| 저장 테이블 | CE1xxxx, CE2xxxx, CE3xxxx, CE4xxxx | ACDOCA (단일) |
| 저장 단위 | Value Field | G/L Account |
| 특성 개수 | 운영 단위(Operating Concern) 정의 | 표준 + 사용자 정의 합쳐 최대 약 60개 |
| 통화 | 운영 단위 통화 + 회사 코드 통화 | ACDOCA의 모든 통화 (최대 10개) |
3.2 정합성(Reconciliation)
Costing-based CO-PA는 SD 인보이스, FI 매출 전표, CO-PA 매출 데이터가 각각 다른 시점·다른 데이터베이스에 기록되어, 결산 시 KEAT 같은 도구로 수동 정합 작업이 필요합니다.
Margin Analysis는 ACDOCA 한 곳에 통합 저장되므로 Reconciled by Design(설계상 정합) 상태입니다. 정합 작업이라는 개념 자체가 사라집니다.
📖 Reconciliation이란 무엇인가?
Reconciliation은 FI(재무 회계)와 CO/CO-PA(관리 회계) 간의 숫자를 일치시키는 정합 작업입니다. ECC 환경에서는 같은 거래임에도 FI 손익계산서의 매출·매출원가와 CO-PA 보고서의 숫자가 일치하지 않는 사례가 빈번했고, 그 원인은 다음과 같습니다.
- 시점 차이: Costing-based CO-PA는 인보이스 시점에 매출/COGS 동시 인식, FI는 출고 시점 COGS·인보이스 시점 매출을 별도 인식
- 계정 매핑 누락: PA Transfer Structure에서 Value Field 매핑이 빠진 G/L 계정의 금액이 CO-PA로 전송되지 않음
- 수동 FI 전표: 수익성 세그먼트(Profitability Segment) 지정 없이 입력된 FI 전표가 CO-PA에 미반영
- 반올림 차이: 통화 환산 등에서 발생
ECC에서는 매월 결산 시 KEAT(CO-PA 라인 아이템과 FI 비교), FAGLL03(GL 라인 아이템 조회), KE24(CO-PA 라인 아이템 추적), Reconciliation Ledger(KALC, KALA, Cross-company 차이 조정용 별도 원장) 등의 도구로 차이를 식별하고 조정 전표를 입력하는 작업이 CO 컨설턴트의 핵심 결산 업무 중 하나였습니다.
S/4HANA에서는 ACDOCA 단일 테이블에 FI와 CO-PA 데이터가 같은 라인으로 저장되므로 본질적으로 정합 차이가 발생할 구조 자체가 사라집니다. SAP Community 공식 블로그는 이를 "reconciliation efforts are enforced by design"(정합 작업이 설계상 강제된다)으로 표현합니다.
3.3 변동 분석(Variance)
| 항목 | Costing-based CO-PA | Margin Analysis |
| 변동 인식 | Total Variance만 자동, 9개 카테고리는 KEI1 매핑 필요 | 9개 카테고리별 G/L 자동 분리 (Splitting 적용 시) |
| Value Field 매핑 | 필수 (PA Transfer Structure) | 불필요 (G/L 자체가 차이 항목) |
9개 카테고리별로 분리된 G/L 계정 자체가 Margin Analysis의 분석 차원이 되므로, 별도 매핑 없이 카테고리별 마진 영향 분석이 가능합니다.
3.4 분석 시점
- Costing-based CO-PA: 인보이스(Billing) 시점에 매출과 COGS가 함께 인식 (Costing-based 평가)
- Margin Analysis: 출고(Goods Issue) 시점에 COGS, 인보이스 시점에 매출 인식 (재무 회계 원칙 준수)

4. SAP가 Margin Analysis를 표준으로 권장하는 이유
SAP는 공식 문서를 통해 Costing-based CO-PA의 신규 개발을 중단하고, Margin Analysis에 집중하겠다고 명시했습니다.
① Reconciled by Design: ACDOCA 통합 저장 자체가 정합성을 보장
② 다중 차원 지원: 약 60개 특성, 최대 10개 통화, 다중 원장(Ledger) 직접 활용
③ Predictive Accounting: 수주(Sales Order) 단계의 손익 예측 가능
④ COGS Splitting: 매출 시점 COGS를 원가 구성 요소별 G/L로 분리
⑤ Cloud 환경 필수: S/4HANA Cloud에서는 Margin Analysis만 사용 가능
5. Margin Analysis의 현재 한계와 도입 시 현실적 고려사항
SAP의 전략 방향은 명확하지만, Margin Analysis가 Costing-based CO-PA를 100% 대체하기에는 아직 진화 중인 솔루션입니다. 도입 결정 전에 다음 한계점을 사실 그대로 인지할 필요가 있습니다.
5.1 기능적 한계
"현재 Margin Analysis는 Costing-based CO-PA의 모든 기능을 포함하지 않으며, 유연성 또한 Costing-based CO-PA 수준에 도달하지 못한 상태입니다. User exit 등을 통해 광범위하게 커스터마이징 된 Profitability Analysis를 운영하는 고객은 S/4HANA 전환 시(특히 Brownfield 프로젝트) 두 방식의 병행 사용이 권장됩니다."
SAP Press 또한 *"Margin analysis will get additional functionality in future releases"*라고 명시하여 현재도 진화 중인 솔루션임을 공식적으로 인정하고 있습니다.
5.2 구체적인 한계 항목
여러 출처에서 공통적으로 지적되는 항목입니다.
① Value Field 기반 커스텀 로직 부재
ECC에서 Value Field와 ABAP User Exit으로 구현한 복잡한 평가 로직은 G/L 기반으로 재설계 필요
② 마이그레이션 도구의 부재
ECC의 Costing-based CO-PA 이력 데이터를 Margin Analysis 형식으로 자동 변환하는 표준 도구가 SAP에서 제공되지 않음
③ 보고서 재구성 부담
기존 KE30 등 사용자 정의 보고서를 ACDOCA 기반의 Fiori 앱(F2376 등)이나 Margin Analysis 보고서로 신규 설계 필요
④ 신기능의 학습 비용
Event-Based Revenue Recognition, COGS Splitting, Top-Down Distribution 등 신규 개념의 컨설턴트·사용자 학습 필요
5.3 ECC Costing-based CO-PA 운영 기업의 합리적 접근
현재 ECC에서 Costing-based CO-PA를 운영 중인 환경에서 S/4HANA 전환을 검토한다면 다음 순서가 합리적입니다.
- 현재 보고서 자산 인벤토리 작성: 사용 중인 Value Field, User Exit, Custom 보고서 목록 정리
- Margin Analysis 매핑 가능성 검토: 각 항목이 G/L Account + Characteristic 조합으로 표현 가능한지 확인
- Brownfield 시 병행 운영: Costing-based 보고서를 즉시 폐기하지 않고, S/4HANA on-premise에서 두 방식 병행 활성화로 시작
- 단계적 이행: 분기·반기 단위로 보고서를 Margin Analysis로 이행하며 Costing-based 의존도를 점진적으로 축소
💡 SAP 공식 가이드 SAP Community 공식 블로그는 "S/4HANA on-premise 전환 전, Margin Analysis가 모든 요구사항을 커버할 수 있는지, 그리고 Costing-based CO-PA를 비활성화 상태로 둘 수 있는지를 사전 검증할 것"을 권고합니다.
6. COGS Splitting — Margin Analysis의 핵심 강점
6.1 COGS Splitting 미적용 시
ECC 또는 Splitting 미적용 환경에서 매출 출고 시점의 회계 전표는 단일 COGS 계정에 총액으로 기표됩니다.

6.2 작동 원리
COGS Splitting은 자재의 표준 원가 산정(Standard Cost Estimate)에 정의된 Cost Component Structure(원가 요소 구조, OKTZ)를 기반으로 작동합니다.

매출 출고 시 COGS Splitting은 이 분해 정보를 가져와 각 원가 요소를 별도 G/L 계정에 분리 기표합니다.
6.3 IMG 설정 경로 및 단계
SPRO → Financial Accounting
→ General Ledger Accounting
→ Periodic Processing
→ Integration
→ Materials Management
→ Define Accounts for Splitting the Cost of Goods Sold

Step 1: 원가 구성 요소별 G/L 계정 신규 생성 (T-CODE: FS00)
다음 속성으로 생성합니다.
- G/L Account Type: Primary Costs or Revenue
- Cost Element Category: 1 (Primary Costs / Cost-Reducing Revenues)
| G/L 계정 | (예시)명칭 매핑 | Cost Component |
| 50301000 | COGS - Direct Material | ① 직접 재료비 |
| 50302000 | COGS - Direct Labor | ② 직접 노무비 |
| 50303000 | COGS - Manufacturing OH | ③ 제조간접비 |
Step 2: Cost Splitting Profile 정의 (예: Z8000)
- Splitting Profile 생성 후 Controlling Area에 할당
- Account-Based Split 체크 여부 결정
- 체크 시: Source Account의 모든 전기에 대해 항상 분할
- 미체크 시: SD 출고 거래에 대해서만 분할 (일반적 권장)
Step 3: Source Account 지정
매출 출고 시 GBB-VAY로 결정되는 표준 COGS 계정(예: 54083000)을 Source Account로 지정합니다. Strategy Sequence(전략 순서)를 정의해 분할 기준이 될 표준원가 산정의 우선순위를 설정합니다.

Step 4: Target Accounts 설정
- 각 Cost Component별 Target G/L 계정 매핑
- Default 체크박스 1개 필수 지정 — 매핑되지 않은 잔액 처리용

Step 5: Company Code 할당 및 Valid From 날짜 지정

6.4 적용 후 회계 전표 및 효과

재무 전표만 보아도 어떤 자재의 매출이고 그 원가 구성이 어떻게 되는지가 한 번에 식별됩니다.
6.5 Actual Costing(실제원가)과의 연동
COGS Splitting은 Standard Cost Estimate뿐 아니라 Material Ledger(자재원장)의 Actual Cost Component Split(실제원가 구성 분해)도 분할 기준으로 사용할 수 있습니다.
Splitting Profile 설정 시 "Split Revalued Consumption with Actual Cost Component Split" 옵션을 활성화하면, ML 결산 후 실제원가 기반으로 COGS가 재분해됩니다.
💡 두 Splitting의 차이 — 혼동 주의
- Variance Splitting(이전 글): ML Actual Costing과 동시 사용 시 충돌 가능성
- COGS Splitting(이번 글): ML Actual Costing과 자연스럽게 연동
이름이 비슷하나 적용 시점과 설계 의도가 다릅니다.
7. 가격차이의 종착지 — 시리즈 전체 흐름
이 시리즈에서 추적해 온 차이가 Margin Analysis에서 어떻게 분석되는지의 다이어그램입니다.

전 과정이 ACDOCA 단일 데이터 위에서 구현되므로 어느 단계의 어떤 숫자도 재무 손익계산서와 일치합니다.
이번 글로 표준원가 산정 → 변동 분석 → 정산 → 수익성 분석까지 한 사이클의 큰 흐름이 마무리됩니다.
감사합니다.