SAP 재경 담당자가 알아야 할 전표 처리 복잡성과 테스트 자동화

기업의 디지털 전환이 가속화되면서 SAP ERP 시스템의 안정적 운영이 더욱 중요해지고 있습니다. 특히 재경 모듈의 카드 전표 처리는 매일 발생하는 업무임에도 불구하고, 그 복잡성으로 인해 많은 기업들이 테스트 과정에서 어려움을 겪고 있습니다.

SAP ERP 전표의 다양성과 복잡성

SAP ERP를 사용하는 기업에서 매일 처리되는 전표는 그 종류와 형태가 매우 다양합니다. 이러한 전표들은 다음과 같은 다양한 요소들로 인해 복잡성을 갖게 됩니다:

• 출처별 다양성: 법인카드, 개인카드 대급, 현금, 계좌이체, 외화 거래 등 결제 수단과 증빙 서류에 따른 차이

• 계정과목별 다양성: 접대비, 복리후생비, 출장비, 교육훈련비, 사무용품비 등 수십 가지 계정과목별 처리 방식

• 승인절차별 다양성: 금액별, 부서별, 계정별로 상이한 결재 라인과 승인 규칙

• 시점별 다양성: 실시간 처리, 일괄 처리, 당월/전월/선급/미지급 등 회계 기간별 처리 차이

• 세무/컴플라이언스 다양성: 과세/면세/영세율 구분, 원천세 처리, 연간 한도 관리 등 법적 기준

단순해 보이는 전표 처리지만, 실제 SAP 시스템에서는 이러한 요소들이 복합적으로 작용하여 매우 복잡한 양상을 보입니다.

1. 출처: 결제 수단과 증빙의 혼재

SAP에서 처리되는 카드 전표는 그 출처에 따라 완전히 다른 처리 방식을 요구합니다.

법인카드 처리의 복잡성 (T-code: FB60, F-44)

법인카드 사용 내역은 카드사에서 기업의 SAP 시스템으로 자동 전송되는데, 카드사마다 전송 시점과 방식이 달라 처리 복잡성이 증가합니다.

• 정산일 차이: 삼성카드(매월 10일), 신한카드(매월 15일), 현대카드(매월 20일) 등 각기 다른 정산일

• 인터페이스 전송 방식: 삼성카드(매일 오후 6시 XML), 신한카드(실시간 전송, 주말은 월요일 일괄), 현대카드(2시간 간격 배치, 해외거래 72시간 지연)

개인카드 대급 처리의 복잡성 (T-code: F-02, F-48)

개인카드 대급은 직원이 개인카드로 먼저 결제한 후 회사가 돌려주는 방식으로, 여러 시스템을 거치며 처리되어 테스트 복잡성이 증가합니다.

• 복합 시스템 연계: 경비정산시스템(직원 신청) → SAP F-02(대급 전표 생성) → SAP F-48(직원에게 송금)

• 추가 검증 항목: 개인별 월 50만원 한도 체크, 부가세 자동 계산 확인

이처럼 출처만 달라져도 사용하는 T-code부터 입력 방식, 데이터 처리 절차까지 모든 것이 달라집니다.

2. 승인 절차: 복잡한 결재 라인

금액과 계정과목에 따라 결재라인이 달라지며, SAP 워크플로우에서 각 조건별 승인 로직을 모두 검증해야 하므로 테스트 복잡성이 증가합니다.

금액별 승인 매트릭스

• 10만원 이하: 팀장 승인 (1단계)

• 50만원 이하: 팀장 → 부서장 (2단계)

• 100만원 이하: 팀장 → 부서장 → 담당임원 (3단계)

• 500만원 초과: 이사회 승인 필요 (5단계)

예외 상황 처리

• 긴급승인: 사후 3일 내 정식 승인 절차 이행

• 대리승인: 출장/휴가 시 사전 위임장 기반 처리

• 소급승인: 1개월 초과 시 별도 사유서 첨부

이러한 다양한 조건들로 인해 SAP 시스템에서는 각 상황별로 승인 로직이 정상 작동하는지 검증해야 합니다.

3. 계정 과목: 다양한 비용 분류와 처리 방식

주요 비용 계정과목과 처리 방식

• 복리후생비 (T-code: FB60): 단체보험, 체육대회, 야유회

• 접대비 (T-code: FB60): 거래처 접대, 선물비

• 출장비 (T-code: FB60): 교통비, 숙박비, 식비

• 교육훈련비 (T-code: FB60): 외부교육, 도서구입

• 비품 (T-code: F-90): 가구, 사무기기

각 계정과목마다 사용하는 T-code가 다르고, 입력해야 하는 필수 필드, 승인 절차, 세무 처리 방식이 모두 상이합니다.

4. 회계 시점: 회계 기간의 복잡성

전표 처리 시점에 따라 회계 처리 방식이 달라집니다.

회계 기간별 처리 복잡성

• 당월 처리 (T-code: FB60): 3월 사용 → 3월 바로 처리 (가장 단순)

• 전월 소급 처리 (T-code: FBRA, FB60): 3월 사용 → 4월 영수증 접수 → FBRA(기간 재오픈) → FB60(소급 처리)

• 선급 처리 (T-code: F-02, F-03): 4월 출장 예정 → 3월 미리 결제 → F-02(선급금 처리) → 4월 사용 시 F-03(정산)

• 미지급 처리 (T-code: F-02, F-44): 3월 사용 → 4월 청구서 예정 → F-02(미지급금 전표 생성) → 실제 청구 시 F-44(정리)

5. 세무 처리: 부가세 자동 처리의 복잡성

SAP ERP에서 부가세 처리는 사용자가 직접 세율을 입력하는 것이 아니라, 시스템이 거래처, 품목, 계정과목, 금액 등을 종합 분석해서 자동으로 Tax Code를 결정합니다. 이러한 자동 판단 로직의 복잡성이 테스트의 난이도를 기하급수적으로 증가시킵니다.

시스템 자동 판단의 예시

• 동일한 "도서 구입"도 상황별 다른 처리: 일반 도서(면세 V0) vs 전자책(과세 V1) vs 해외 직수입(영세율 VE)

• 거래처 정보 기반 자동 구분: 국내 법인(V1) vs 해외 법인(VE) vs 개인사업자(V1+원천세)

• 계정과목별 특수 처리: 접대비 연간 한도 초과 시 자동으로 V1 → V2(불공제)로 전환

• 복합 조건 판단: 해외업체 + 컨설팅 서비스 = VE(영세율) + 역과세 적용

자동 판단 로직이 참조하는 정보 예시

• IF (Vendor Master: 해외법인) AND (Service Type: 컨설팅)

  THEN Tax_Code = "VE" + 역과세 처리

• IF (G/L Account: 접대비) AND (연간 누적액 > 한도)

  THEN Tax_Code = "V2" (불공제)

• IF (Material Master: 면세 대상) AND (Vendor: 국내)

  THEN Tax_Code = "V0" (면세)

이처럼 시스템이 여러 마스터 데이터와 거래 조건을 실시간으로 분석해서 적절한 Tax Code를 자동 결정하는 복잡한 로직을 모두 검증하려면, 자동화된 테스트가 필수적입니다.

복잡한 조합과 수동 테스트의 한계

앞서 살펴본 다양한 요소들(출처, 승인절차, 계정과목, 시점, 세무처리)이 조합될 때 발생하는 경우의 수는 기하급수적으로 증가합니다.

이제 이러한 다양성 요소들이 실제로 어떤 문제를 만들어내는지 구체적으로 살펴보겠습니다.

실제 조합 사례

• 법인카드(삼성) × 접대비 × 임원승인 × 전월소급 × 과세거래

• 개인카드대급 × 출장비 × 2단계승인 × 당월처리 × 면세거래

• 현금지출 × 복리후생비 × 인사합의 × 선급처리 × 불공제세액

한 기업에서 월평균 처리하는 전표가 800건이라고 할 때:

• 출처별 다양성: 7가지

• 계정과목별 다양성: 20가지

• 승인절차별 다양성: 10가지

• 시점별 다양성: 4가지

• 세무처리 다양성: 5가지

이론적 조합 수: 7 × 20 × 10 × 4 × 5 = 28,000가지

수동 테스트와 샘플 데이터의 한계: 복잡성 검증이 불가능한 이유

수동 테스트는 필연적으로 샘플 데이터에 의존

사람이 직접 테스트하는 수동 방식에서는 시간과 비용의 제약으로 인해 소량의 샘플 데이터로만 테스트를 수행할 수밖에 없습니다. 일반적으로 50-100건의 샘플 데이터로 테스트하게 되어 다양한 변수를 검증하기 어려운 낮은 커버리지에 그치게 됩니다.

샘플 데이터로는 SAP 복잡성 검증이 불가능

하지만 이러한 샘플 데이터로는 앞서 살펴본 전표의 복잡성을 제대로 검증하기 어렵습니다:

1. 출처별 다양성: 삼성카드/신한카드/현대카드의 실제 전송 방식과 타이밍 차이는 실제 연동 데이터로만 검증 가능

2. 승인절차별 다양성: 10만원/50만원/100만원 경계선에서 실제 승인 로직은 실제 금액 데이터로만 확인 가능

3. 계정과목별 다양성: 접대비/복리후생비 등의 실제 처리 패턴은 실제 전표 데이터에서만 발견

4. 시점별 다양성: 당월/전월/선급/미지급의 실제 회계 처리는 실제 날짜와 금액으로만 검증

5. 부가세 자동 처리: 실제 거래처×품목×계정과목 조합은 실제 거래 히스토리에서만 나옴

실거래 데이터만이 발견할 수 있는 것들

• 예외 상황과 코너 케이스: 연말 접대비 한도 초과 직전의 미묘한 처리, 해외 거래처와의 복합 세무 처리

• 실제 업무 패턴: 특정 시간대 집중되는 대량 거래 처리, 월말 결산 시 몰리는 소급 처리

• 실제 운영 환경의 복잡성: 마스터 데이터 불일치로 인한 자동 판단 오류, 여러 시스템 간 타이밍 차이

따라서 SAP ERP 재경 모듈의 복잡성을 완전히 검증하려면 실제 거래 데이터를 기반으로 한 테스트 자동화가 필수적입니다.

PerfecTwin을 통한 실거래 기반 테스트 자동화

그렇다면 SAP ERP 재경 모듈의 이러한 복잡성을 어떻게 완벽하게 검증할 수 있을까요? 앞서 살펴본 카드사별 전송 방식, 승인 경계선, 복합 세무 처리 등의 모든 케이스를 빠짐없이 테스트하기 위해서는 PerfecTwin을 통한 실거래 데이터 기반의 테스트 자동화가 해답입니다.

1. 모든 실제 케이스 빠짐없이 검증

실거래 데이터의 완전한 재현

• 다양하고 복잡한 SAP 카드 전표 처리의 실제 업무 데이터를 그대로 재현

실제 연계 환경 완벽 시뮬레이션

• PerfecTwin Simulator로 연계 환경 구축 없이도 실제 카드사, 경비시스템 등과의 연동 상황을 완벽 재현

2. 대량 데이터 빠른 처리

PerfecTwin의 빠른 처리

• 앞서 살펴본 다양한 테스트 조합을 서버에 직접 전송하는 백엔드 방식으로 50배 빠른 속도로 처리

3. 예외 상황과 코너 케이스 완벽 발견

샘플 데이터로는 놓치기 쉬운 특수 상황들을 사전 발견

• 카드 한도 초과 직전의 복잡한 세무 처리, 해외 거래처와의 복합 부가세 판단 등 실제 운영에서만 나타나는 예외 케이스 발견

이처럼 PerfecTwin을 통한 실거래 기반 테스트 자동화는 실제 운영 데이터 패턴을 기반으로 SAP ERP의 모든 복잡성에 완벽하게 대응할 수 있습니다.

실제 적용 사례

소비재 제조사 A사

• 도입 전: 20여개가 넘는 유통채널에 대한 다양한 주문 패턴과 코너케이스를 수작업으로 테스트하는 데 한계

• 도입 후: PerfecTwin을 통해 최대 800만 건 이상 실제 운영 데이터 기반 테스트로 S/O 데이터 전수 재현 달성

• 효과: 20여개 유통채널 × 800만 건 데이터의 완전한 자동 검증 달성으로 수작업 테스트에서 벗어나 모든 주문 유형의 완전한 테스트 수행

결론

SAP ERP 카드 전표 처리는 출처, 승인절차, 계정과목, 시점, 세무처리 등이 복합적으로 작용하여 수만 가지 처리 케이스를 만들어냅니다. 이러한 복잡성은 기존 수동 테스트로는 완전히 검증하기 어려우며, 대부분의 예외 상황이 누락되어 운영 중 예상치 못한 오류로 이어집니다.

따라서 실제 운영 데이터 기반의 테스트 자동화를 통해서 모든 복잡성을 완벽하게 검증하고 안전한 ERP 시스템을 구축할 수 있습니다.