SAP FICO 해설: 구축을 망가뜨리는 7가지

SAP FICO는 하나로 움직이는 두 모듈입니다. 재무회계(FI)는 감사인과 규제 당국이 보는 숫자를 만듭니다. 관리회계(CO)는 경영진이 사업을 운영하는 데 쓰는 숫자를 만듭니다. S/4HANA에서는 둘 다 하나의 Universal Journal에 전기됩니다. 이 글은 S/4HANA 재무 워크스트림을 시작하거나, 운영하거나, 구제하는 재무 책임자, 프로그램 디렉터, FICO 컨설턴트를 위한 것입니다. FI와 CO가 어떻게 맞물리는지, SAP의 나머지 부분과 어디서 연결되는지, 그리고 구축을 망가뜨리는 일곱 가지 결정을 설명합니다. 사용자 인수 테스트(UAT)에 들어가기 전에 글 끝부분의 준비 체크리스트를 활용하십시오.

저는 25년간 블루프린트부터 지원까지 전 라이프사이클에 걸쳐 SAP FICO 프로젝트에서 일했고, 같은 패턴이 반복됩니다. 기술적인 문제도 있습니다. 그보다 더 자주는 초기에 서둘렀거나 놓친 결정에서 비롯됩니다.

2026년이라는 시점이 중요합니다. SAP ECC는 2027년 말에 주류 유지보수가 끝나므로, 아직 ECC를 쓰는 재무팀 대부분은 마이그레이션 중이거나 곧 시작합니다. 아래의 실수는 ECC 때보다 S/4HANA 프로그램에서 더 큰 비용을 치릅니다. Universal Journal은 나중에 나쁜 설계를 흡수할 여지를 더 적게 남기기 때문입니다.

**재무회계(FI)**는 바깥을 향합니다. 법정 컴플라이언스, 대차대조표, 손익계산서처럼 회사 밖으로 나가는 숫자입니다. SAP의 모든 재무 거래는 결국 FI에 도달합니다.

**관리회계(CO)**는 안을 향합니다. 경영 의사결정을 위한 비용 추적, 예산, 수익성입니다. 코스트 센터는 돈이 어디서 쓰이는지 보여 줍니다. 수익성 분석은 고객, 지역, 제품별 마진을 보여 줍니다.

실무에서는 둘을 분리할 수 없습니다. 매입채무(AP)의 공급업체 송장은 총계정원장에 전기되고 코스트 센터 리포트로 흘러갈 수 있습니다. 자산 구매는 장부를 갱신하고 비용 계획에 영향을 줍니다. FI가 어디서 끝나고 CO가 어디서 시작하며 어디서 겹치는지 아는 것이 재무 지식과 버튼 조작 지식을 가르는 기준입니다.

S/4HANA에서는 경계가 더 흐려집니다. Universal Journal(테이블 ACDOCA)은 FI와 CO 라인 아이템을 하나의 레코드에 저장합니다. 설계에 영향을 주는 결과가 두 가지 있습니다. 원가 요소는 이제 별도의 마스터 데이터가 아니라 원가 요소 범주를 가진 G/L 계정입니다. 그리고 SAP가 권장하는 수익성 모델은 Margin Analysis(계정 기반 CO-PA)입니다. 원가 기반 CO-PA는 온프레미스와 프라이빗 에디션에는 여전히 있습니다. 그러나 SAP의 학습 자료는 분명합니다. S/4HANA Cloud에서는 제공되지 않으며, 신규 투자는 Margin Analysis로 갑니다.

FICO 팀이 구성하는 주요 컴포넌트는 다음과 같습니다.

컴포넌트	영역	관리하는 대상
총계정원장(FI-GL)	FI	모든 재무 거래의 중앙 기록, 법정 보고의 기반
매입채무(FI-AP)	FI	공급업체 송장, 지급, 부채
매출채권(FI-AR)	FI	고객 송장, 수금, 신용
자산 회계(FI-AA)	FI	고정 자산의 취득, 감가상각, 폐기
은행 회계	FI	은행 명세서, 대사, 현금 포지션
코스트 센터 회계	CO	부서 또는 기능별 비용
내부 오더	CO	행사, 캠페인, 소규모 프로젝트를 위한 임시 비용 집계
손익 센터 회계	CO	사업 단위별 매출과 비용
Margin Analysis(CO-PA)	CO	고객, 제품, 채널, 지역별 마진

FI와 CO 간 대사가 사라졌습니다. 저널이 하나이고 별도의 합계 테이블이 없으므로, ECC에서 컨설턴트 일수를 잡아먹던 기간 말 대사는 대부분 사라집니다. 그 이면도 있습니다. 코스트 센터 설계와 수익성 특성이 설계 단계에서 정확해야 합니다. 실수를 가려 줄 집계 계층이 없습니다.

연결과 계획이 새로운 자리로 옮겨 갔습니다. SAP는 연결 부문에서는 S/4HANA Group Reporting을 SAP Business Planning and Consolidation(BPC)의 후속으로, 계획 부문에서는 SAP Analytics Cloud를 후속으로 포지셔닝합니다. BPC의 주류 유지보수는 2027년에 끝납니다. 아직 BPC를 운영 중이라면 어떻게 해야 하는지는 SAP BPC 가이드에서 다룹니다.

Joule은 실재하지만 범위가 좁습니다. SAP의 2025년 중반 AI 릴리스 노트에는 Joule을 통한 고정 자산 마스터 데이터 생성, 은행 명세서 모니터링 같은 재무 활용 사례가 올라 있습니다. 연체 항목을 독촉하는 매출채권 에이전트도 설명되어 있습니다. 2025년 5월부터 정식 제공 중인 SAP Joule for Consultants는 SAP Note와 Activate 콘텐츠를 바탕으로 구성 관련 질문에 답합니다. 모두 데이터가 깨끗할 때 더 잘 작동합니다. 어느 것도 잘못된 설계를 고쳐 주지는 않습니다.

Clean Core는 ‘커스터마이징’의 의미를 바꿉니다. S/4HANA Cloud Public Edition에서는 코어를 전혀 수정할 수 없습니다. 프라이빗 에디션과 온프레미스에서는 수정할 수 있지만, 수정할 때마다 업그레이드 노력과 리그레션 리스크가 늘어납니다. 전기 규칙을 위한 Z 테이블, 세금 로직을 위한 인핸스먼트, CO-PA의 ABAP 도출 같은 ECC 시절의 습관은 이제 표준 구성이나 SAP BTP의 사이드 바이 사이드 확장에 속합니다. 그만큼 아래 4번 실수의 비중이 커집니다.

FICO는 거의 모든 다른 SAP 모듈과 연결됩니다. 통합 문제의 대부분은 인계 지점에서 생깁니다. 각 팀이 자기 영역만 테스트하고, 연결 부분은 아무도 테스트하지 않기 때문입니다.

모듈	통합 지점	S/4HANA에서 일어나는 일
MM(자재 관리)	GR/IR 청산, 송장 전기, 재고 평가	입고가 ACDOCA에 GR/IR 항목을 전기하고, 공급업체 송장이 이를 청산하며 AP에 전기됨
SD(영업 및 유통)	청구, 매출, 매출채권, 신용	청구가 Universal Journal에서 매출과 매출채권을 갱신하며, 계약에 필요한 경우 IFRS 15는 Revenue Accounting and Reporting을 사용
PP(생산 계획)	생산 원가, WIP, 차이	오더 원가가 ACDOCA에 누적되고, WIP와 차이는 같은 저널 안에서 정산됨
HCM / 급여	급여 전기, 원가 배부	급여 결과가 비용과 부채로 FI에 전기되고 코스트 센터로 흘러감
PS(프로젝트 시스템)	예산, 정산, 프로젝트 매출	프로젝트 원가와 매출이 FI/CO에 전기되어 즉시 확인할 수 있음
PM(설비 보전)	보전 오더 원가	노무비와 자재비가 오더에 집계되어 CO로 정산됨
Group Reporting	연결	ACDOCA를 직접 읽으며 별도의 연결 데이터베이스가 없음

Universal Journal은 이 통합이 실패하는 방식을 바꿉니다. ECC에서 FI-CO 차이는 대사 문제로 드러났습니다. S/4HANA에서는 잘못된 계정에 전기된 MM 전기가 실제 분개를 만들고, 이를 역분개하고 다시 전기해야 합니다. 감사 지적도 더 빨리 나옵니다. 이런 인계의 물류 측면은 SAP SD와 SAP PP 가이드를 참고하십시오.

1. 01MM 입고재고 수량과 재고 가치 갱신
2. 02계정 결정평가 클래스가 G/L 계정을 결정
3. 03ACDOCA의 GR/IR 항목FI와 CO가 함께 쓰는 Universal Journal 라인 하나
4. 04공급업체 송장GR/IR 항목을 청산
5. 05매입채무총계정원장에 전기되고 코스트 센터 리포트로 흐를 수 있음

FI와 CO가 함께 읽는 분개 하나

1. 주인 없는 마스터 데이터

대부분의 프로젝트는 첫 주에 마스터 데이터를 정리해야 한다는 데 합의합니다. 그러다 구성 작업이 주도권을 잡고, 일정이 빠듯해지면서 마스터 데이터가 뒤처집니다. 테스트 때까지.

UAE의 한 유통 고객사는 코스트 센터 계층이 완성된 것처럼 보였습니다. 명칭은 맞았고 합계도 균형을 이루었습니다. 통합 테스트에서 매장 비용이 말이 되지 않는 지역 책임자 아래에 나타났고, 일부 데이터는 아예 없었습니다.

그 구조는 매장이 실제로 운영되는 방식과 대조해 본 적이 없었습니다. 구축 팀의 가정 위에 세워진 것이었습니다. 코스트 센터 매핑과 리포팅 로직을 재구성하는 데 좋은 인력이 매달려서도 2주가 걸렸습니다.

단골 원인은 익숙합니다. 현재의 리포팅 요구를 확인하지 않고 기존 시스템에서 그대로 복사한 G/L 계정. 오래된 세금 데이터나 누락된 은행 정보가 있는 공급업체 마스터. 비용 흐름이 아니라 조직도를 따라가는 코스트 센터 계층. 뒤늦게 추가된 손익 센터. 블루프린트가 끝나기 전에 마스터 데이터에 책임자를 지정하십시오. 구조, 사용 현황, 공백에 대한 대략적인 점검만으로도 나중의 정리 작업 대부분을 막을 수 있습니다.

2. 컨트롤러 없이 구성한 CO

관리회계는 대개 두 번째로 밀립니다. FI는 일찍 설계되고 검토되고 테스트됩니다. CO는 더 단순해서 나중에 확정해도 된다는 논리로 덜 신경 쓰인 채 뒤따릅니다.

그럴 수 없습니다.

제가 참여한 통신사 프로젝트에서는 CO-PA를 늦게 구성했습니다. 테스트는 괜찮아 보였습니다. 전기가 통과했고 리포트도 실행되었습니다. 그런데 영업과 재무가 마진을 검토하자 상위 제품이 마이너스 수익성으로 나왔습니다. 핵심 원가 요소가 매핑되지 않았고 도출 규칙이 불완전했습니다. 이를 고치려면 이미 승인된 리포팅 구조를 다시 설계해야 했습니다.

CO는 리포트를 읽는 사람들, 즉 컨트롤러와 재무 이사가 설계에 함께할 때만 작동합니다. 이들은 시스템 흐름이 아니라 비용 행태와 마진으로 생각합니다. UAT가 아니라 블루프린트 단계에서 참여시키십시오.

3. 업무 사용자가 UAT에서 처음 시스템을 본다

UAT는 문제가 드러나는 자리이자, 문제를 발견하기에 가장 비싼 자리입니다. 설계는 확정되었고 구성은 거의 끝나 있기 때문입니다.

동남아시아 지주회사의 재무 혁신 프로젝트에서 UAT는 자신감 속에 시작되었습니다. 스크립트는 준비되어 있었고 기술 점검도 통과했습니다. 그런데 재무팀이 로그인하자 달라졌습니다. 많은 사용자에게 화면을 처음 보는 자리였습니다. 매일 쓰던 필드가 사라져 있었습니다. 설명 없이 새로운 단계가 생겨 있었습니다. 워크플로는 기술적으로는 말이 되지만 업무적으로는 말이 되지 않는 방식으로 다시 만들어져 있었습니다.

핵심 플로를 수정해야 했고, 일부 로직은 다시 만들어야 했습니다. 프로젝트는 몇 주를 잃었습니다.

사용자에게 미완성 화면을 일찍 보여 주십시오. 완성된 화면을 늦게 보여 주는 것보다 언제나 비용이 덜 듭니다.

4. 설정으로 충분한데 커스텀 개발을 한다

커스텀 코드는 더 빠르고 통제되는 것처럼 느껴집니다. 요청한 그대로를 얻을 수 있습니다. 시간이 지나면 테스트하기 어렵고, 바꾸기 어렵고, 깨지기 쉬워지며, S/4HANA에서는 수정할 때마다 업그레이드 노력이 늘어납니다.

6개국에 걸친 글로벌 구축 프로젝트에서 일한 적이 있는데, 세금 로직이 전부 ABAP으로 만들어져 있었습니다. 국가별 규칙, 예외, 제품별 세율이었습니다. 작동은 했습니다. 하지만 표준 SAP는 이미 컨디션 타입, 세금 프로시저, 국가별 구성으로 이를 처리하고 있었습니다.

한 나라가 세율을 바꾸면 현업은 개발 요청을 올리고, 기다리고, 모든 것을 다시 테스트해야 했습니다. 처음에는 효율적으로 느껴졌던 것이 세금 변경 때마다 병목이 되었습니다. 이런 경우의 해법은 커스텀 테이블을 폐기하고, 로직을 표준 구성으로 옮기고, 정말 고유한 규칙만 작은 확장에 남기는 것입니다.

같은 패턴은 다른 곳에서도 나타납니다. 이미 구성으로 처리되는 전기 규칙에 대한 커스텀 검증. 표준 Fiori 앱이나 CDS 뷰가 있는데도 다시 만든 리포트. 변경 여지 없이 하드코딩된 승인 단계. 매번 한 가지를 물으십시오. 이 로직은 어디에 있으며, 다음 업그레이드를 별도 프로젝트 없이 견딜 수 있는가? 답이 "코어 안에 있다"이거나 "확인해 보지 않았다"라면 구성이나 BTP로 옮기십시오.

5. 점검하지 않은 통합 지점

테스트 중에 팀들은 자기 모듈에 집중합니다. 경계는 점검되지 않은 채 남습니다.

제조업 롤아웃에서 입고는 MM에서 정상적으로 처리되었습니다. 재고도 갱신되었습니다. 물류 쪽에는 불만이 없었습니다. FI에는 그 입고에 대한 분개가 없었습니다.

원인은 계정 결정에서 빠진 평가 클래스였습니다. MM은 오류 없이 처리했고 재무 전기는 만들어지지 않았습니다. 진단에 이틀이 걸렸습니다. 그사이 전기된 내용을 정리하는 데는 며칠이 더 걸렸습니다.

제가 본 비슷한 실패는 이렇습니다. 계정 결정의 공백 때문에 엉뚱한 매출 계정에 전기되는 SD 청구. PM에서 이루어졌지만 자산 회계에 도달하지 않는 자산 이전. MM 팀과 FI 팀이 서로 다르게 이해한 GR/IR 로직. 재무 책임자 한 명이 MM과 SD 테스트 스크립트를 검토하면 대부분 막을 수 있습니다. 전기가 어떤 모습이어야 하는지는 재무가 압니다. 물류 테스터는 모르는 경우가 많습니다.

6. 마지막 스프린트에서 설계한 리포팅

재무 정보를 만들어 내려고 존재하는 모듈인데도, 프로젝트는 놀라울 만큼 한결같이 리포팅을 마지막으로 미룹니다. 트랜잭션이 전기되게 하는 것이 먼저고, 리포트는 나중에 정리한다는 식입니다.

제가 Go-Live 이후 단계를 지원한 유럽의 소비재 고객사에서는 CO-PA가 구축되어 있었고, 필드는 매핑되고 도출은 구성되어 있었습니다. 첫 세그먼트 손익계산서는 헤더는 맞았지만 비용이 흩어지고 조각나 있었습니다. 매출은 정상이었습니다. 일부 값 필드는 아예 채워지지 않았습니다.

재무팀은 다시 Excel로 돌아갔습니다. 또다시. 제가 나서서 정리해야 했습니다. 리포팅에 대한 신뢰는 한번 잃으면 저절로 돌아오는 일이 드뭅니다.

채널별 마진이나 프로젝트별 비용이 사업에 중요하다면, 그 요구가 설계 단계에서 데이터를 어떻게 수집할지를 좌우해야 합니다. 2026년의 일반적인 리포팅 계층은 Universal Journal을 읽는 SAP Analytics Cloud입니다. 일부 GROW 및 RISE 패키지에는 포함되어 있고 다른 패키지에서는 별도로 판매되므로 계약서를 확인하십시오. 깔끔한 수익성 설계 위의 Analytics Cloud는 작동합니다. 반쯤 구성된 설계 위의 Analytics Cloud는 작동하지 않습니다. 자세한 내용은 SAP Analytics Cloud 가이드를 보십시오.

7. 팀 사이에 떨어진 예외 상황

프로젝트가 처리량이 많은 프로세스에 집중하는 것은 옳습니다. 하지만 그러다 보면 예외 상황이 드러날 때까지 한쪽으로 밀려납니다.

한 롤아웃에서 고객사는 회사 코드 세 개에 서로 다른 회계연도 변형 세 개를 갖고 있었습니다. 하나는 역년, 하나는 4월부터 3월까지, 하나는 4-4-5였습니다. 설계 단계에서 아무도 이를 짚지 않았습니다.

문제는 회사 간 대사에서 드러났습니다. 기간이 맞지 않았습니다. 회사 코드마다 마감 기준이 달라 재무는 제때 마감할 수 없었습니다. 이 문제 하나로 연결 결산이 2주 어긋났습니다.

계획에 한 시간을 잡아, 각 워크스트림이 자기 영역에서 특이한 점을 나열하게 하십시오. 세 가지를 물으십시오. 아직 모델링하지 않은 법적 규정이나 지역 규정이 있는가? SAP 밖에서 수작업 우회 방법을 운영하는 팀이 있는가? 선급금, 임시 저장 전표, 회사 간 상계 같은 기능을 쓰고 있는가? 예외 상황은 반드시 드러납니다. 문제는 그것이 설계 세션에서 드러나느냐, 월 마감 때 드러나느냐입니다.

UAT 시작 2주 전에 이 목록을 점검하십시오. "아니오"는 모두 책임자와 일자를 붙여 기록해야 할 리스크입니다.

1. 마스터 데이터 책임자 지정. 한 사람이 계정과목표, 코스트 센터 계층, 손익 센터, 공급업체 및 고객 마스터를 승인합니다. 책임자: 재무 이사.
2. 실제 비용 흐름에 맞춰 검증한 코스트 센터 계층. 조직도가 아닙니다. 책임자: 재무 컨트롤러.
3. 컨트롤러가 수익성 설계를 검토. 특성, 도출 규칙, 세그먼트 손익계산서 초안입니다. 책임자: 관리회계 팀장.
4. 핵심 사용자가 화면을 확인. UAT 스크립트를 작성하기 전에 프로세스마다 최소 한 번의 워크스루를 합니다. 책임자: 재무 프로세스 리드.
5. 커스텀 코드 목록 검토. 모든 인핸스먼트에는 표준 구성으로는 불가능했던 이유가 있습니다. 책임자: 솔루션 아키텍트.
6. 모듈 간 계정 결정 테스트. 입고, 공급업체 송장, 고객 청구, 생산 오더 정산이 각각 예상한 분개를 만들어 냅니다. 책임자: MM, SD, PP 리드와 함께하는 FICO 리드.
7. 실제 테스트 데이터로 만든 경영 리포트. 목업이 아닙니다. 책임자: CFO 조직과 함께하는 리포팅 리드.
8. 회사 코드 간 회계연도 변형, 통화, 회사 간 설정 비교. 책임자: FICO 리드.
9. 예외 상황 세션 개최. 발생액 계상, 선급금, 임시 저장 전표, 회사 간 상계, 국가별 세금 규칙. 책임자: 프로그램 매니저.

SAP FICO란 무엇이며 각 글자는 무엇을 뜻합니까?

FI는 재무회계(Financial Accounting), CO는 관리회계(Controlling)를 뜻합니다. 둘이 합쳐 SAP의 핵심 재무 모듈입니다.

FI는 외부 보고를 다룹니다. 총계정원장, 매입채무, 매출채권, 자산 회계, 은행 회계입니다. CO는 내부 관리 보고를 다룹니다. 코스트 센터, 내부 오더, 손익 센터, 수익성 분석입니다.

둘은 긴밀하게 연결되어 있습니다. S/4HANA에서는 하나의 Universal Journal을 공유하므로, 하나를 이해하지 않고는 다른 하나도 이해할 수 없습니다.

SAP FICO는 SAP MM, SD, PP와 어떻게 통합됩니까?

MM에서 FI로: 입고는 GR/IR 항목을 자동으로 전기합니다. 공급업체 송장이 이를 청산하고 매입채무에 전기됩니다. 계정 결정이 정확해야 합니다. 그렇지 않으면 MM은 처리되는데 재무 전표는 생기지 않습니다.

SD에서 FI로: 청구가 매출과 매출채권을 갱신합니다. SD 계정 결정에 공백이 있으면 매출이 엉뚱한 계정으로 가거나 어디에도 가지 않습니다.

PP에서 FI/CO로: 생산 오더는 자재, 노무, 간접비를 집계합니다. CO는 재공품과 차이를 정산합니다. 수익성 설계가 약하면 그 비용이 마진 리포트에 도달하지 않습니다.

세 경우 모두 해법은 같습니다. 다른 워크스트림이 작성한 통합 테스트 스크립트를 재무 책임자가 검토해야 합니다.

SAP HANA와 SAP FICO는 어떻게 다릅니까?

계층이 다릅니다. SAP HANA는 인메모리 데이터베이스입니다. SAP FICO는 회계 담당자와 컨트롤러가 쓰는 재무 애플리케이션입니다.

S/4HANA에서는 HANA가 Universal Journal을 현실로 만듭니다. FI와 CO 데이터가 한 테이블에 있고, 배치 대사 없이 실시간으로 리포팅됩니다. HANA 성능 문제는 FICO 리포트가 얼마나 빨리 실행되는지에 영향을 줍니다. FICO 구성 문제는 그 리포트에 무엇이 담기는지를 결정합니다.

2026년에도 S/4HANA에서 SAP FICO는 여전히 유효합니까?

그렇습니다. 핵심 역량은 그대로 이어집니다. 계정 결정, 코스트 센터 설계, 수익성 설정, 기간 말 마감입니다. 기업은 여전히 트랜잭션뿐 아니라 재무 프로세스를 이해하는 사람이 필요합니다.

달라진 것은 수요가 있는 인재상입니다. 기업은 Universal Journal, Margin Analysis, Group Reporting, Clean Core 확장을 이해하고, 마이그레이션 중에 ECC의 어떤 커스터마이징을 폐기할지 조언할 수 있는 FICO 컨설턴트를 원합니다. ECC 주류 유지보수가 2027년에 끝나기 때문에 마이그레이션 업무가 수요를 높게 유지하고 있습니다.

FICO 커리어 이동을 계획 중이라면 SAPopedia의 커리어 경로가 역할별 역량을 정리해 주고, ERPCV 커리어 팩은 이력서에 S/4HANA 재무 경험을 보여 주는 데 도움이 됩니다.

Joule은 2026년 SAP FICO 구축을 어떻게 바꿉니까?

마케팅이 말하는 것보다는 적게, 회의론자가 짐작하는 것보다는 많이 바꿉니다. SAP Joule for Consultants는 SAP의 Note와 Activate 콘텐츠를 바탕으로 구성과 코드 관련 질문에 답하며, 표준 범위 조사 속도를 높여 줍니다. 시스템 안에서는 Joule이 고정 자산 마스터 데이터 생성, 은행 명세서 모니터링 같은 작업을 처리하고, SAP는 연체 채권 독촉 에이전트 같은 재무 에이전트를 출시했습니다.

다국가 세금, 그룹 리포팅 구조, 수익 인식에 대한 설계 판단은 어느 것도 대체하지 못합니다. 그리고 바탕에 있는 데이터만큼만 작동합니다. 파트너 제안서를 검토할 때는 AI 도구가 공수 추정에 어떻게 반영되었는지 물어보십시오.

새 구축에서 핵심 FICO 구성 단계는 무엇입니까?

기반은 대략 다음 순서로 구성합니다.

1. 회사 코드: 재무제표를 작성하는 법인입니다.
2. 회계연도 변형: 역년, 4월부터 3월까지, 4-4-5입니다. 서로 거래하는 회사 코드끼리 일관되게 유지하십시오.
3. 계정과목표: G/L 계정 목록으로, 가능하면 회사 코드 간에 공유합니다. 이 결정은 시스템 수명 동안 모든 리포트에 영향을 줍니다.
4. 전기 기간 변형: 어떤 기간에 전기할 수 있는지 정합니다.
5. 필드 상태 변형: 어떤 필드가 필수, 선택, 숨김인지 정합니다.
6. 세금 구성: 세금 코드, 세율, 국가 매핑입니다. 현지화의 복잡성 대부분이 여기에 있습니다.
7. 관리회계 구조: 관리 영역, 코스트 센터, 손익 센터, 내부 오더, 수익성 특성을 컨트롤러와 함께 설계합니다.
8. 계정 결정: MM, SD, PP 트랜잭션이 어떻게 FI 전기가 되는지 정합니다. Go-Live 전에 엔드 투 엔드 통합 테스트로 검증하십시오.