SAP 퍼블릭 클라우드 전환,
경비정산 시스템의 전표 연동을 다시 설계해야 하는 이유
Last Updated: 2026.09.29
안녕하세요, 전자구매 | 경비출장 | 전자계약 | 전자인장 구축 및 클라우드 기업 세포아소프트 입니다.
많은 기업이 SAP S/4HANA Cloud Public Edition(이하 SAP 퍼블릭 클라우드)으로의 전환을 준비하고 있습니다.
이때 경비정산 시스템(경비지출관리)과 SAP 간 전표 연동은 기존 구조를 그대로 옮기면 된다고 생각하기 쉽습니다.
하지만 온프레미스 시절에 구축한 인터페이스를 그대로 이관하면,
전표 한 건이 왜 넘어가지 않는지부터 다시 확인해야 하는 상황이 생깁니다.
이는 인터페이스 기술의 문제가 아닙니다. 연계 구조 자체를 새로 설계해야 하는 문제입니다.
SAP 퍼블릭 클라우드에서는 왜 기존 방식으로 전표를 넘길 수 없을까?
온프레미스 SAP에서는 기업별 요구사항에 맞춰 ABAP 프로그램을 개발하고, BAPI·RFC·IDoc으로 외부 시스템과
비교적 자유롭게 연계할 수 있었습니다.
SAP 퍼블릭 클라우드에서는 이 방식이 통하지 않습니다.
SAP 코드와 확장 기능을 명확히 분리하는 구조이며, 공식 공개된 API와 확장 포인트만 사용하도록 되어 있습니다.
대신 SAP는 공개 API의 호환성을 릴리스가 바뀌어도 유지해, 안정적인 업그레이드를 보장합니다.
SAP Core를 기업별로 수정하지 않고 표준을 지키는 Clean Core 원칙이 우선하기 때문입니다.
목 차
경비정산 AI 에이전트, 기술보다 업무 이해가 먼저인 이유는?
경비정산은 카드 사용내역을 입력하고 결재를 받는 단순 절차가 아니라, 사용자·부서장·회계 담당자가
서로 다른 기준으로 같은 거래를 판단하는 업무입니다. 동일한 법인카드 지출이라도 사내 회식이면 복리후생비,
거래처와의 미팅이면 접대비, 출장 중 식비면 출장비로 갈리는 식입니다.
가맹점 업종만 보고 계정과목을 정하는 수준의 판단으로는 이런 구분을 정확히 해낼 수 없습니다.
■ 개발 방식 변화
□ SAP 내부에 필요한 프로그램을 개별 개발하던 방식에서 표준 API가 허용하는 범위 내에서 연계 구조를 설계하는 방식으로의 전환
■ 전표 생성 경로 변화
□ 「경비정산 시스템 → SAP 내부 개발 프로그램 → 전표 생성」에서 「경비정산 시스템 → Integration Layer → SAP 표준 API → 전표 생성」으로의 전표 생성 경로 변화
■ 설계 시점 변화
□ 인터페이스 연결 단계가 아닌 구축 초기부터 데이터 항목과 연계 구조를 정의하는 사전 설계 중심의 접근
경비정산 시스템과 SAP를 잇는 Integration Layer는 어떤 역할을 할까?
SAP 퍼블릭 클라우드 환경에서 경비정산 시스템은 SAP Integration Suite(CPI) 같은 Integration Layer를 거쳐 SAP와 연결됩니다.
이 계층은 단순한 통로가 아닙니다. 경비정산 데이터를 SAP API가 요구하는 형식으로 바꾸고, SAP의 처리 결과를 다시 돌려주는 변환 역할을 맡습니다.
구축 초기에 어떤 업무 로직을 경비정산 시스템이 맡고, 어떤 변환 로직을 Integration Layer가 맡을지 명확히 나누지 않으면 이후 한쪽 시스템에 유지보수 부담이 쏠립니다.
■ 데이터 형식 변환
□ 경비정산 데이터를 SAP API 규격에 맞게 변환하고 시스템별 코드값을 매핑하며, SAP 처리 결과를 경비정산 시스템에서 활용 가능한 형태로 재변환하는 데이터 변환 체계
■ 역할 경계 사전 정의
□ 업무 로직과 데이터 변환 로직의 담당 영역을 구축 초기에 문서화하여 장애 발생 시 확인 대상과 책임 범위를 명확히 하는 역할 분리
■ 업무 언어와 회계 언어 분리
□ 현업 사용자는 비용항목·사용금액·사용목적·코스트센터 등 업무 언어를 사용하고, Company Code·G/L Account·Tax Code 등 SAP 회계 언어로의 변환은 시스템이 담당하는 구조
전표 유형마다 연동 설계가 달라야 하는 이유는?
경비정산 화면에서는 모두 같은 ‘전표 연동’처럼 보이지만, SAP가 요구하는 데이터와 후속 처리는 전표 유형마다 다릅니다.
예를 들어 법인카드 경비정산 전표와 세금계산서 전표를 하나의 Payload 구조로 묶으면,
한쪽에 필드가 추가될 때마다 전체 구조를 수정해야 합니다.
그래서 공통 Header와 업무 유형별 Line을 분리해 설계하는 것이 유지보수에 유리합니다.
■ 법인카드 경비정산 분리
□ 비용계정·부가세·카드 채무 처리 정보를 중심으로 다른 전표 유형과 구분하여 별도 Line으로 관리하는 법인카드 전표 처리
■ 선급금·취소 처리 구조화
□ 선급금의 Vendor Special G/L 처리와 정산 시 Clearing, 취소·역분개 시 원전표번호·회계연도·회사코드를 활용한 원전표 식별 체계
■ 기준정보 소유 시스템 일원화
□ G/L Account·Business Partner·Cost Center 등 주요 기준정보를 SAP 기준으로 통합 관리하여 시스템 간 기준정보 불일치를 최소화하는 관리 체계
전표를 보내는 것보다 그 이후가 더 중요한 이유는?
경비정산 시스템에서 SAP로 데이터를 전송했다고 업무가 끝나지 않습니다.
SAP에서 전표가 정상적으로 생성됐는지 확인하고, 실패했다면 담당자가 원인을 파악해 재처리할 수 있어야 합니다.
처리 결과(성공·실패), SAP 전표번호, 오류코드, 재처리 이력을 추적할 수 있어야 장애가 났을 때 「요청 데이터 → Integration Layer 변환 결과 → SAP 응답」 순서로 원인을 좁혀갈 수 있습니다.
■ 역할 분리를 통한 안정성 확보
□ 경비정산 시스템은 업무 처리, Integration Layer는 데이터 변환, SAP는 회계 기준을 담당하도록 구분하여 특정 시스템에 로직이 집중되는 것을 방지하는 구조
■ 재처리 체계 구축
□ 오류 발생 시점과 원인을 단계별로 추적하고 문제 재현과 복구 시간을 단축할 수 있도록 구성하는 재처리 체계
■ AI 활용 기반 마련
□ 계정과목 추천·증빙 적정성 검증 등 AI 기능 활용을 위해 증빙·전표·거래처·조직·예산 데이터를 함께 정리하는 데이터 기반 구축
마무리하며
지금 운영 중인 SAP 전표 연동이 온프레미스 시절 인터페이스를 옮겨온 것인지,
Clean Core 원칙에 맞춰 새로 설계한 것인지 점검해 볼 필요가 있습니다.
전표가 실패했을 때 어느 단계에서 막혔는지 바로 답할 수 있는지도 함께 확인해 볼 질문입니다.
SAP 퍼블릭 클라우드 연계는 정해진 답을 그대로 적용하는 작업이 아닙니다.
전표 유형, 기준정보 구조, 오류 처리 방식을 기업 환경에 맞게 설계해야 하고, 결국 연동을 얼마나 많이 직접 해봤는지가 결과를 좌우합니다.
세포아소프트는 경비정산 분야에서 SAP, Oracle ERP, 더존, 자체 개발 ERP까지 다양한 ERP와 연동해 왔습니다.
전자세금계산서 ASP, VAN사, 국세청 등 대내외 시스템 연계 경험도 폭넓게 갖추고 있습니다.
연동 환경이 달라져도 핵심은 같습니다.
업무와 회계의 경계를 정확히 나누고, 데이터가 어디서 어떻게 변환되는지 설계하는 일입니다.
세포아소프트는 수많은 ERP 연동 프로젝트로 그 설계 역량을 쌓아 왔습니다.
SAP 퍼블릭 클라우드 전환 환경에서도 경비정산 시스템과 SAP를 안정적으로 연결할 수 있는 이유입니다.
SAP는 표준을 지키고, 경비정산 시스템은 업무를 담당하며, Integration Layer가 둘을 연결하는 구조.
이것이 SAP 퍼블릭 클라우드 전환의 출발점이며, 세포아소프트가 경비정산 연동에서 지켜 온 원칙입니다.
