SAP IMG OB13 Posting Period Variant 설정 방법 가이드

 

프로젝트 초기, 기간통제 설정에서 막힌 적 있으신가요?

SAP FI 프로젝트 초기 세팅 단계에서 이런 질문을 정말 자주 받습니다. “왜 전표가 갑자기 안 열리죠?”, “회사코드마다 기간 통제는 어디서 하는 거예요?”, “OB52만 보면 되는 거 아닌가요?” 실제 프로젝트에서 이런 케이스가 있었는데요, 운영 담당자가 OB52에서 분명히 기간을 열었다고 하는데 특정 회사코드에서는 여전히 전표 입력이 막히는 상황이었습니다. 원인은 단순했습니다. OBBP 연결을 확인하지 않았던 거죠.

많은 분들이 SAP FI 기간통제는 OB52만 알면 된다고 생각하시지만, 실제 구조는 그렇게 단순하지 않습니다. 기간통제 설정은 OB13 → OBBP → OB52로 이어지는 구조로 이해해야 정확합니다. OB13에서 Posting Period Variant라는 기간 통제 규칙의 틀을 만들고, OBBP에서 그 Variant를 회사코드에 연결한 뒤, OB52에서 실제로 어떤 기간을 열고 닫을지 운영하게 됩니다.

이런 분께 특히 도움이 됩니다

• FI 모듈을 처음 세팅하는 주니어 컨설턴트
• 회사코드별 Posting Period Variant 설정 방법을 빠르게 정리해야 하는 운영 담당자
• OB13, OBBP, OB52의 차이를 명확히 이해하고 싶은 실무자

이 글에서는 SAP OB13 설정부터 OBBP 회사코드 연결, OB52 기간 오픈/클로징까지 전체 흐름을 다룹니다. OB52 vs OB13 차이와 ECC vs S/4HANA 기간통제 구조 차이도 함께 정리했습니다.

본 글은 ECC 6.0 기준으로 작성되었으며, S/4HANA 변경사항은 별도 표기했습니다.

 

 

SAP FI 기간통제 설정의 전체 구조

SAP FI의 Posting Period Control은 단일 트랜잭션으로 끝나는 설정이 아니라 설계와 운영이 분리된 구조입니다. 큰 그림으로 보면 세 가지 레이어로 이해할 수 있습니다.

Posting Period Variant의 역할

Posting Period Variant는 쉽게 말해 기간 통제 규칙의 이름표이자 틀입니다. 예를 들어 동일한 월마감 정책을 적용받는 여러 회사코드가 있다면 하나의 Variant로 묶어 관리할 수 있습니다. Variant 자체가 기간을 여닫는 것은 아니고, 어떤 회사코드가 어떤 통제 체계를 따를 것인가를 정의하는 기준 단위라고 보는 것이 정확합니다.

 

회사코드 연결의 중요성

각 회사코드는 반드시 하나의 Posting Period Variant를 할당받아야 합니다. 이 연결 작업이 바로 OBBP입니다. 이 단계가 중요한 이유는 OB52에서 Variant 기준으로 기간을 열고 닫기 때문입니다. 즉, 회사코드는 직접 OB52를 바라보는 것이 아니라 자신에게 연결된 Variant를 통해 기간 통제를 적용받습니다.

 

실제 운영 통제는 OB52에서

실제 운영에서 몇 월까지 열려 있는지, 특정 계정유형만 추가로 열 것인지를 제어하는 곳이 OB52입니다. 따라서 실무적으로는 아래처럼 이해하면 쉽습니다.

단계	트랜잭션	역할	변경 빈도
1단계	OB13	틀 만들기 (설계)	낮음
2단계	OBBP	회사코드 연결	낮음
3단계	OB52	실제 운영 (기간 열고 닫기)	높음

OB13 설정의 실제 의미

OB13은 Posting Period Variant를 정의하는 Customizing 트랜잭션입니다. 여기서 중요한 점은 OB13이 기간 자체를 여닫는 화면이 아니라는 것입니다. OB13은 오히려 다음과 같은 설계 결정을 반영하는 곳입니다. 회사코드마다 Variant를 따로 둘 것인가, 동일한 마감 정책을 쓰는 회사코드는 하나의 Variant로 묶을 것인가, 운영 조직 구조와 내부통제 수준을 어떻게 반영할 것인가 같은 결정들이죠.

예를 들어 한국 법인은 KR01, 해외 법인은 GL01, 테스트용 회사코드는 TS01처럼 Variant를 분리할 수 있습니다. 혹은 여러 회사코드가 동일한 월마감 정책을 따른다면 하나의 Variant로 통합해 운영 효율을 높일 수도 있습니다.

OB52 vs OB13 차이를 명확히 이해하기

이 둘은 자주 같이 언급되지만 역할은 완전히 다릅니다. OB13은 Posting Period Variant를 생성하고 정의하는 구조 설계 영역입니다. 프로젝트 초기 설정에서 주로 사용하며 상대적으로 변경 빈도가 낮습니다. 반면 OB52는 실제 오픈과 클로즈 기간을 관리하는 운영 통제 영역입니다. 월마감, 결산, 예외 처리 시 자주 사용하며 변경 빈도가 매우 높습니다. 정리하면 OB13은 설계, OB52는 운영입니다.

SAP가 이런 구조를 만든 이유

SAP의 기간통제 구조는 단순해 보이지 않지만 대규모 조직 운영에는 매우 적합합니다. 다수 회사코드를 동일 정책으로 묶을 수 있고, 계정유형별로 오픈 기간을 다르게 설정할 수 있으며, 운영과 설계를 분리하여 내부통제를 강화할 수 있습니다. 예를 들어 G/L은 이미 닫았지만 AP 전표는 며칠 더 입력받아야 하는 경우가 있습니다. 이런 현실적인 운영 니즈를 반영하려면 Variant, Company Code Assignment, OB52의 계정유형별 통제가 모두 필요합니다.

S/4HANA 변경사항: 기본 개념은 ECC와 동일하지만 Universal Journal(ACDOCA) 환경과 Ledger 기반 회계 운영이 일반화되면서 기간 통제 영향 범위를 더 넓게 봐야 합니다. Ledger별 재무 보고 요구사항 증가, 병렬회계 시 통제 설계 복잡도 상승, Central Finance 환경에서 소스와 타깃 시스템 간 기간 불일치 가능성이 커졌습니다.

 

 

OB13 설정부터 OB52 운영까지 단계별 구성

이제 실제 설정 흐름을 OB13에서 OBBP를 거쳐 OB52까지 순서대로 살펴보겠습니다.

SAP OB13 설정: Posting Period Variant 생성

IMG 경로

SPRO → Financial Accounting → Financial Accounting Global Settings
→ Document → Posting Periods
→ Define Variants for Open Posting Periods

관련 T-code: OB13

이 단계에서는 Posting Period Variant를 생성합니다. 즉, 회사코드가 참조하게 될 기간 통제 단위를 만드는 것입니다.

 

주요 필드 설명

• Variant ID: Posting Period Variant의 식별자로 보통 4자리 내외의 규칙적인 코드를 사용합니다
• Description: Variant 설명으로 회사군, 지역, 운영 목적이 드러나도록 작성하는 것이 좋습니다

예를 들어 KR01은 Korea Company Codes, HQ01은 Headquarter Companies, TEST는 Test Company Codes처럼 명명할 수 있습니다.

 

설계 시 고려사항

Variant를 너무 세분화하면 운영이 복잡해지고, 너무 통합하면 예외 관리가 어려워집니다. 따라서 월마감 일정이 동일한가, AP와 AR 추가 오픈 정책이 같은가, 내부통제 수준이 같은가, 결산 승인 프로세스가 같은가 같은 기준으로 판단하는 것이 좋습니다.

운영 조직 구조도 반영해야 합니다. 예를 들어 지역별 Shared Service Center가 다른 경우 Variant를 분리하는 편이 운영상 유리할 수 있습니다. 초기에는 회사코드가 몇 개 없더라도 향후 법인 추가, 인수합병, 글로벌 확장 가능성을 고려해 명명 규칙과 분류 기준을 정해두는 것이 좋습니다.

OBBP 회사코드 연결

IMG 경로

SPRO → Financial Accounting → Financial Accounting Global Settings
→ Document → Posting Periods
→ Assign Variants to Company Code

관련 T-code: OBBP

OB13에서 만든 Posting Period Variant를 실제 회사코드에 연결합니다. 즉, 회사코드 1000은 KR01 Variant 사용, 회사코드 2000은 KR01 Variant 사용, 회사코드 3000은 GL01 Variant 사용처럼 지정하는 단계입니다.

 

주요 설정 항목

필드	설명	비고
Company Code	대상 회사코드	필수
Posting Period Variant	OB13에서 생성한 Variant	선행 조건: OB13 완료

선행 조건: OB13에서 Variant가 먼저 생성되어 있어야 합니다.

후행 영향: 이후 OB52에서 Variant 기준으로 기간을 제어하게 됩니다. 잘못 연결되면 기간 통제가 엉뚱하게 적용됩니다.

실무에서는 신규 회사코드 생성 후 OBBP 연결을 빠뜨리지 않았는지, 운영과 테스트 시스템 간 Variant 매핑이 동일한지, Cutover 직전 회사코드별 Variant 배정이 최종 확정되었는지 반드시 확인해야 합니다. 이 단계는 단순해 보이지만 기간 미오픈 이슈의 숨은 원인이 되는 경우가 많습니다.

OB52 기간 오픈과 클로징 설정

IMG 경로

SPRO → Financial Accounting → Financial Accounting Global Settings
→ Document → Posting Periods
→ Open and Close Posting Periods

관련 T-code: OB52

여기서 실제 Posting Period를 열고 닫습니다. 즉, 사용자 입장에서는 가장 직접적인 운영 통제 화면입니다.

 

주요 필드 상세

Variant: 어떤 Posting Period Variant에 대해 기간을 제어할지 지정합니다. 이 Variant를 사용하는 모든 회사코드에 영향이 갑니다.

Account Type: 계정유형별로 허용 기간을 다르게 줄 수 있습니다.

Account Type	의미	실무 활용
A	Asset	자산 전표 통제
D	Customer	고객 전표 통제
K	Vendor	공급업체 전표 통제
M	Material	자재 전표 통제
S	G/L Account	일반회계 전표 통제
+	All Account Types	전체 계정유형 통제

실무에서는 +만 열어두기보다 필요한 계정유형만 구분해서 운영하는 경우가 많습니다.

From Period / To Period: 허용할 회계기간 범위를 설정합니다. 예를 들어 2024년 12월까지만 허용하거나 다음 회계연도 1월을 선개방하는 형태로 운영할 수 있습니다.

Authorization Group: 특정 사용자만 해당 기간 통제 항목을 변경할 수 있도록 통제하는 필드입니다. 내부통제 관점에서 매우 중요하지만 프로젝트 초기에는 종종 설계가 누락됩니다.

실무에서 자주 사용하는 패턴

첫 번째 패턴은 GL은 닫고 AP와 AR은 추가 오픈하는 방식입니다. S는 당월까지만 오픈하고 D와 K는 며칠 더 다음 입력을 허용합니다. 이 방식은 월마감 이후 늦게 들어오는 고객이나 공급업체 전표 처리에 유용합니다.

두 번째 패턴은 특정 계정유형만 선개방하는 것입니다. 다음 월 전표를 미리 입력해야 하는 경우 특정 계정유형만 차기 기간을 열어둘 수 있습니다.

세 번째 패턴은 결산 중 예외 오픈입니다. 감사 수정분, 재분개, 정산 전표 입력을 위해 제한적으로 기간을 다시 여는 경우가 있습니다. 이때 Authorization Group을 함께 사용하면 통제 수준을 높일 수 있습니다.

 

 

실무에서 꼭 알아야 할 주요 포인트

기간통제 설정에서 가장 흔한 실수들

실제 프로젝트에서 이런 케이스가 있었는데요, OB13에서 Variant를 잘 만들어두고도 OBBP 연결을 누락해서 전표 입력이 막히는 상황이었습니다. Variant를 잘 만들어도 회사코드에 연결하지 않으면 아무 의미가 없습니다. 생성 후 반드시 OBBP까지 확인해야 합니다.

OB52에서 Account Type 설정 오류도 빈번합니다. 예를 들어 G/L 계정만 열어두었는데 사용자는 Vendor Invoice를 입력하려고 하면 전표가 막힐 수 있습니다. 이 경우 사용자는 기간이 안 열려 있다고 말하지만 실제로는 계정유형 불일치가 원인입니다.

+와 개별 Account Type 설정 충돌도 자주 오해되는 부분입니다. 실무에서는 +를 열면 모든 것이 해결된다고 생각하는 경우가 있지만, 운영 정책상 개별 타입을 별도 관리할 때는 우선순위와 설정 구조를 함께 검토해야 합니다.

테스트 시나리오 부족도 큰 문제입니다. 월마감 직전, 차기기간 선오픈, AP만 추가 오픈, 예외 수정전표 처리 등 실제 운영 시나리오를 충분히 테스트하지 않으면 오픈 후 장애가 발생하기 쉽습니다.

프로젝트 시 반드시 확인하는 체크리스트

여러 프로젝트를 수행하면서 느낀 점은, 아래 체크리스트만 제대로 지켜도 기간통제 관련 이슈의 80% 이상을 예방할 수 있다는 것입니다.

• 회사코드별 Variant 설계 기준이 문서화되어 있는가
• OBBP 연결이 모든 대상 회사코드에 반영되었는가
• OB52 계정유형별 운영 정책이 정의되어 있는가
• Authorization Group 사용 여부가 결정되었는가
• 월마감과 결산 예외 시나리오 테스트가 완료되었는가
• 테스트 시스템과 운영 시스템의 설정 차이가 통제되고 있는가
• 신규 회사코드 생성 프로세스에 OBBP 검토가 포함되어 있는가

ECC와 S/4HANA 기간통제 실무 차이

ECC 환경에서는 전통적인 FI 운영 중심으로 회사코드 및 계정유형별 기간 통제가 주된 관심사였습니다. 상대적으로 구조가 단순하게 보일 수 있죠. 반면 S/4HANA에서는 Universal Journal 기반으로 영향 범위가 더 통합적입니다. 병렬회계, Ledger, Central Finance까지 고려해야 하며, 단순히 기간이 열렸는가를 넘어서 어떤 회계 관점에서 어떤 영향이 있는가까지 봐야 합니다.

S/4HANA에서는 Ledger 관련 요구사항 때문에 기간 통제와 결산 정책 정렬이 더 중요합니다. Central Finance 환경에서는 소스 시스템은 열려 있는데 타깃은 닫혀 있는 문제가 발생할 수 있습니다. 재무와 현금관리, 결제 프로세스가 더 긴밀하게 연결되어 있어 통제 실패의 영향이 커질 수 있습니다.

FI와 TR 관점 추가 포인트

기간통제는 순수 FI 전표 입력에만 영향을 주는 것이 아닙니다. Treasury and Risk Management(TRM)나 현금관리 프로세스에서도 간접적으로 중요합니다.

TRM에서 발생하는 회계 전표 역시 결국 FI Posting Period 통제의 영향을 받을 수 있습니다. 따라서 Treasury 운영팀과 FI 마감 일정이 맞지 않으면 전표 생성 오류가 발생할 수 있습니다. Cash Management나 BCM에서도 결제 실행 타이밍과 회계기간 통제가 맞지 않으면, 승인된 지급 건이 회계 포스팅 단계에서 막히는 문제가 발생할 수 있습니다.

즉, 월마감 정책은 FI 팀만의 문제가 아니라 Treasury, AP, AR, Cash Management와 연동된 운영 정책으로 봐야 합니다.

 

 

대표 Error Code 해결 방법

기간통제와 관련해 자주 만나는 대표 에러는 M7053과 F5 165입니다. 에러 메시지는 Posting period is not open으로 단순하지만 원인은 여러 가지일 수 있습니다.

주요 발생 원인과 해결 방법

Error Code	Error Message	발생 원인	해결 방법
M7053	Posting period is not open	OB52 기간 미오픈	OB52에서 해당 Variant, 기간, 회계연도 확인
F5 165	Posting period is not open	잘못된 Variant 할당 (OBBP)	OBBP에서 회사코드 Variant 연결 확인
M7053	Posting period is not open	Account Type 불일치	OB52에서 A, D, K, S, M, + 설정 상태 검토
F5 165	Posting period is not open	전표 유형/업무 시나리오 오해	실제 포스팅 로직 기준으로 계정유형 재확인

문제가 발생하면 아래 순서대로 확인하는 것이 효율적입니다.

첫째, OB52에서 해당 Variant를 확인합니다. 어떤 Variant가 열려 있는지, 대상 기간이 맞는지, 회계연도까지 함께 확인해야 합니다.

둘째, OBBP에서 회사코드 Variant를 확인합니다. 이 회사코드가 정말 해당 Variant를 사용 중인지 검증하고, 테스트와 운영 회사코드 혼선 여부를 확인합니다.

셋째, Account Type을 확인합니다. 입력하려는 전표가 어떤 계정유형에 해당하는지 확인하고, A, D, K, S, M, + 설정 상태를 검토해야 합니다.

넷째, 전표 입력 화면 기준으로 프로세스를 재검토합니다. 단순 화면명이 아니라 실제 포스팅 로직 기준으로 판단해야 합니다.

자주 발생하는 화면

다음 트랜잭션에서 기간 미오픈 오류가 자주 발생합니다.

• FB50: G/L Account Posting
• FB60: Enter Incoming Invoices
• F-02: General Posting
• F-43: Enter Invoice
• F-22: Enter Customer Invoice
• TRM 거래 입력/정산 화면

특히 FB60 같은 Vendor Invoice 입력은 사용자가 FI 전표라고 생각하더라도 실제로는 Vendor 계정유형(K) 통제를 함께 봐야 하므로 주의가 필요합니다.

 

마무리: 기간통제의 핵심 정리

SAP FI 기간통제는 단순히 OB52만 아는 것으로 끝나지 않습니다. 정확한 구조는 OB13 설정 → OBBP 회사코드 연결 → OB52 운영으로 이해해야 합니다.

핵심을 다시 정리하면 이렇습니다.

• OB13은 Posting Period Variant를 정의하는 설계 단계
• OBBP는 회사코드에 Variant를 연결하는 매핑 단계
• OB52는 실제 기간을 열고 닫는 운영 단계

그리고 실무에서 정말 중요한 포인트는 아래 한 줄로 요약할 수 있습니다.

기간통제 문제의 90%는 OB52, 나머지 10%는 OBBP에서 발생한다

즉, 전표가 막혔을 때는 먼저 OB52를 보고, 문제가 없어 보이면 반드시 OBBP 연결까지 확인하는 습관이 필요합니다.

다음 단계 학습으로는 Authorization Group을 활용한 기간통제 고급 설정을 추천합니다. 특히 내부통제, 월마감 책임 분리, 긴급 오픈 승인 체계를 운영해야 하는 조직이라면 꼭 알아둘 필요가 있습니다.

비슷한 이슈를 겪으셨거나 다른 궁금한 점이 있다면 댓글로 공유해주세요. 함께 이야기 나누면서 더 나은 솔루션을 찾아갈 수 있을 것 같습니다.

다음에 읽으면 좋은 글

• OB52 Authorization Group 심화: 내부통제 강화 전략
• S/4HANA Ledger 기반 기간통제 설계 방법

 

참고 출처

• SAP Help Portal: Financial Accounting Global Settings
• SAP Note: Posting Period Variant Configuration
• SAP 공식 문서: Document Posting Periods (OB52)

SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.