연재: SAP BPC vs Group Reporting 연결 엔진 비교 (4/5) ① 비교의 틀 · ② 아키텍처 · ③ 데이터 모델 · ④ 프로세스 · ⑤ 시사점과 용어 대응표
지난 두 회차에서 아키텍처와 데이터 모델을 비교했습니다. 이번 회차에서는 실제 연결결산이 언제, 어떤 순서로 처리되는지를 일곱 가지 측면에서 살펴봅니다.
1. 연결결산 전체 흐름: 단계는 같고, 통제의 주체가 다르다
연결결산의 단계 자체는 두 엔진이 같습니다. 차이는 GR이 Data Monitor와 Consolidation Monitor의 Task 순서로 실행 통제를 시스템 안에 갖고 있다는 점입니다.
단계 | BPC (Standard) | GR (Public Cloud) | GR 실행 단위 |
|---|---|---|---|
1. 수집·검증 | DM Package 적재, Input Schedule, Controls 검증 | Release Task, Flexible Upload, Validation Task | Data Monitor |
2. 환산 | FX Business Rule (DM Package·Monitor에서 실행) | Currency Translation Task | Data Monitor |
3. 내부거래 | IC Matching 보고서, IC Booking → US Elim | ICMR 대사, Elimination Task | Consolidation Monitor |
4. 투자자본 상계 | 연결 Business Rule + 커스텀 투자자본 로직 | CoI Task, Automatic Posting(비지배지분) | Consolidation Monitor |
5. 마감 통제 | BPF, Work Status, 기초 이월 점검 | Task 상태·차단, Version | — |
6. 보고 | EPM Add-in 보고서 (Excel 수식·레이아웃) | Fiori·SAC 보고 (FS Item 계층구조) | — |
BPC 경험자가 GR을 볼 때: BPC에서 Package와 BPF 설계로 정하던 실행 순서가 GR에서는 Task 구성으로 고정됩니다. 순서를 바꾸려면 설정을 바꿔야 합니다.
GR 경험자가 BPC를 볼 때: BPC의 실행 순서는 DM Package와 BPF 설계에 달려 있습니다. 고객별 Package 구성과 실행 절차서를 먼저 확인해야 합니다.
2. 데이터 수집과 검증
GR에서는 데이터 수집 경로가 둘로 나뉩니다. 통합 법인은 반복 실행할 수 있는 델타 릴리스로, 비통합 법인은 Flexible Upload로 수집합니다. 검증은 Data Monitor의 Task로 수행됩니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
통합 법인 | BW 추출 → DM Package 적재 (ERP와 BPC가 분리) | Release Task로 ACDOCA → ACDOCU 반영. 원장 변경 시 델타로 재실행 |
비통합 법인 | Input Schedule 입력 또는 Flat File 업로드 | Flexible Upload (YTD 누적 입력 지원) |
매핑·변환 | Transformation·Conversion 파일로 계정·법인 코드 변환 | G/L 계정 → FS Item 매핑. 매핑되지 않은 계정은 Release 시 오류로 드러남 |
검증 | Controls(Consolidation Central)로 검증 규칙 정의·실행 | Validation Rule을 Data Monitor Task로 실행하고 결과가 Task 상태에 반영 |
BPC 경험자가 GR을 볼 때: Transformation·Conversion 파일에서 처리하던 매핑이 FS Item 매핑 설정으로 옮겨갑니다. 매핑되지 않은 계정은 Release 단계에서 오류로 드러나므로, 매핑 누락을 사후가 아니라 수집 시점에 발견할 수 있습니다.
GR 경험자가 BPC를 볼 때: BPC에 수집된 데이터는 적재 시점의 사본입니다. 원장이 수정된 뒤 다시 적재했는지 반드시 확인해야 합니다.
3. 내부거래 대사와 제거
BPC의 IC Matching, IC Booking, US Elim 방식이 GR에서는 ICMR(Intercompany Matching and Reconciliation) 대사와 Elimination Method 기반 제거로 바뀝니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
대사 | IC Matching 보고서(EPM)로 법인 간 잔액 비교 | ICMR에서 대사 규칙으로 매칭하고 차이를 관리 |
대사 키 | Entity, IntCo, Account 조합 | Consolidation Unit, Partner Unit, FS Item 등 대사 규칙에 정의한 키 |
차이 처리 | IC Booking Rule로 차이를 지정 계정에 전기 | ICMR에서 차이 원인을 관리하고, 제거 시 차이를 지정 FS Item으로 처리 |
제거 | US Elim 또는 Eliminations & Adjustments Rule로 제거 | Elimination Method를 Task에 할당해 제거 |
BPC 경험자가 GR을 볼 때: ICMR은 단순한 비교 보고서가 아니라 대사 규칙과 차이 관리를 갖춘 별도 기능입니다. 원장 전표에 거래 상대(파트너) 정보가 정확히 입력되어 있어야 한다는 것이 선행 조건입니다.
GR 경험자가 BPC를 볼 때: BPC의 제거 결과는 IC Booking과 US Elim 두 Rule이 함께 만든 것입니다. 차이가 어디서 생겼는지 확인하려면 두 Rule을 함께 봐야 합니다.
4. 투자자본 상계와 비지배지분
비지배지분 배분은 GR 표준 기능으로 처리됩니다. 반면 투자 이벤트 이력을 기반으로 한 투자자본 상계는 두 엔진 모두 확장 영역에 속하며, GR에서는 RAP로 계산한 결과를 API로 전기하는 구조가 됩니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
표준 상계 | 연결 Business Rule (연결 방법별 규칙 테이블) | Rule Based CoI가 표준 (Activity Based는 티켓 요청 시 사용 가능) |
비지배지분 | 연결 Business Rule에서 지분율(PCON, POWN) 기반 배분 | Automatic Posting Rule에 Consolidation Unit별 지분율 설정 (추가 개발 불필요) |
이력 기반 상계 | 투자자본 이력 Model + Script Logic·BAdI로 계산 | 커스텀 테이블 + RAP로 계산한 뒤 Released API로 연결 분개 전기 |
실행 위치 | DM Package, Consolidation Monitor | Consolidation Monitor Task (표준) + 확장 앱 (커스텀) |
BPC 경험자가 GR을 볼 때: BPC에서 연결 Rule 하나로 처리하던 상계가 GR에서는 표준 Method와 확장 로직으로 나뉩니다. 어느 부분을 표준에 맡길지 경계부터 정해야 합니다.
GR 경험자가 BPC를 볼 때: BPC의 상계 결과에는 표준 Rule과 커스텀 로직이 섞여 있습니다. 상계 금액을 검증할 때는 커스텀 Model의 이력 데이터까지 추적해야 합니다.
5. 기초 잔액 이월과 정합성
BPC는 매 기간 기초 잔액을 이월하고, 이월 결과가 맞는지 사후에 점검하는 절차를 결산에 넣어야 합니다. GR은 기간별 증감이 누적되는 구조라 연중에는 기간별 이월 작업이 필요 없습니다. (GR의 연도 이월 세부 통제는 이 연재의 범위에서 제외했습니다.)
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
이월 작업 | Copy Opening(Carry-forward) Rule로 기초 Flow를 매 기간 채움 | 연중에는 기간 증감이 누적되므로 기간별 이월 작업 없음 |
전기 수정 시 | 이월 후 전기를 수정하면 '기초 ≠ 전기 말'이 생기므로 이월을 다시 실행해야 함 | 전기 수정분이 누적 잔액에 그대로 반영 |
정합성 확인 | '기초 = 전기 말' 대사 보고서와 Controls로 사후 점검 | 저장 구조로 유지되어 별도 대사 절차 불필요 |
이 차이는 지난 회차의 저장 방식(YTD 대 Periodic)에서 그대로 이어집니다. BPC는 기간이 독립적이어서 단절 결산에 유리한 대신, 기간 사이의 연결을 이월 절차로 보장해야 합니다.
BPC 경험자가 GR을 볼 때: 결산 절차서에 있던 기초 이월과 대사 단계가 GR 연중 결산에서는 사라집니다. 대신 전기 수정이 당기에 바로 영향을 주므로, 확정된 기간의 Task 차단 관리가 중요해집니다.
GR 경험자가 BPC를 볼 때: BPC에서는 기초 잔액이 자동으로 이어지지 않습니다. 전기 수정이 있었다면 이월 재실행과 '기초·전기 말' 대사를 반드시 확인해야 합니다.
6. 마감 통제와 거버넌스
BPF와 Work Status 중심의 통제가 GR에서는 Monitor의 Task 상태, Task 차단, Version 기반 통제로 대체됩니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
진행 관리 | BPF(Business Process Flow)로 단계, 담당자, 순서를 안내 | Data Monitor와 Consolidation Monitor의 Task 상태로 진행 관리 |
데이터 보호 | Work Status로 법인·기간·데이터 유형별 입력 잠금 | Task 차단(Block)으로 확정된 단계와 데이터 보호 |
버전 관리 | Category 멤버로 실적, 계획, 시뮬레이션 구분 | Version(특수 버전 포함)으로 결과를 분리하고 버전별 설정 차이 허용 |
감사 추적 | Journal, AuditTrail, 변경 로그 | 연결 전표와 Document Type 단위 추적 |
BPC 경험자가 GR을 볼 때: BPF 같은 사용자 안내 화면을 기대하면 안 됩니다. GR에서는 Monitor의 Task 상태 자체가 진행 관리 수단이자 통제 수단입니다.
GR 경험자가 BPC를 볼 때: BPC에서 Work Status가 걸리지 않은 데이터는 마감 후에도 바뀔 수 있습니다. Work Status가 어디까지 설정되어 있는지 확인해야 합니다.
7. 연결 보고와 공시
BPC는 셀 단위의 자유로운 레이아웃으로 비정형 보고에 강합니다. GR은 계층구조 기반 보고로 수치 일관성을 확보하는 대신, 주석 같은 비정형 양식은 따로 대응해야 합니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
계정 정렬·소계 | 시트에서 행 순서와 소계를 자유롭게 배치 | FS Item 계층구조에 따라 결정 |
계산 | Excel 수식과 Local Member로 셀 단위 계산 | 쿼리와 계층구조에 정의 |
수치 일관성 | 보고서마다 수식이 달라 같은 항목도 수치가 다를 수 있음 | 보고 로직이 시스템에 일원화되어 보고서 간 수치 일치 |
주석·공시 | Excel 양식으로 주석까지 직접 작성 가능 | 표준 보고만으로는 비정형 주석 작성에 한계가 있어 별도 도구나 확장 필요 |
국내 연결결산에서는 K-IFRS 연결 주석과 DART 공시 대응이 중요한 비중을 차지합니다. 그래서 GR을 도입할 때 비정형 공시 양식을 무엇으로 작성할지는 초기에 정해야 할 설계 과제입니다.
BPC 경험자가 GR을 볼 때: EPM 보고서 수식에 들어 있던 로직을 목록으로 정리하고, 이를 계층구조, 쿼리, 외부 도구 중 어디로 옮길지 결정해야 합니다.
GR 경험자가 BPC를 볼 때: BPC 보고서의 숫자를 검증할 때는 시스템 데이터뿐 아니라 시트 안의 수식과 Local Member까지 확인해야 합니다.
이번 회차 정리
연결결산의 단계는 같지만, GR은 Task 순서와 상태로 실행 통제를 시스템 안에 갖고 있습니다.
기초 잔액 정합성은 BPC에서는 절차로, GR에서는 저장 구조로 보장됩니다.
투자자본의 이력 기반 상계와 비정형 공시 양식은 두 엔진 모두 표준 밖의 설계가 필요한 영역입니다.
마지막 회차에서는 지금까지의 비교를 바탕으로, 한쪽 엔진에 익숙한 컨설턴트가 상대 엔진을 볼 때 어디서 오해가 생기는지를 정리하겠습니다.
참고 자료