ERP-결재 연동 구조의 고급 패턴

기업의 결재 시스템과 ERP 연계는 단순한 “승인 → 전표 생성”을 넘어, 비용 통제·예산 관리·부서별 검증 로직·Reversal·Sync 등을 포함한 복잡한 구조를 가집니다. 본 문서는 중견·대기업에서 실제로 사용하는 고급 연동 패턴을 중심으로 설명합니다.

1. 실시간 API + 비동기 큐 결합형 구조

가장 진화된 기업들은 실시간 API + 비동기 메시지 큐를 결합해 안정성과 속도를 동시에 확보합니다.

[결재 승인]
   ↓ (Sync API)
[ERP 인터페이스 서버]
   ↓ (Async Queue: Kafka, SQS, RabbitMQ)
[전표 생성 Processor]
   ↓
[ERP FI/CO 반영]
   ↓
[Callback → 결재 시스템]
  

특징:

• 실시간 API로 승인 직후 ERP로 데이터 전달
• 전표 생성은 큐 기반 Processor에서 비동기 처리 → 안정성과 재처리 가능
• ERP 부하를 분산하고, 장애 시 재시도 가능

2. Reversal 자동 연동 패턴 (결재 취소 ↔ ERP 반전)

중견·대기업에서는 결재 취소 시 ERP 전표를 자동 반전(Reversal)하는 구조를 사용합니다.

상황	ERP 처리 로직
결재 승인됨	전표 생성(JE Posting)
결재 취소됨	반전 전표 생성(Reverse Document)

[결재 취소]
   ↓
[ERP Reverse API 호출]
   ↓
[Reverse Document 생성]
   ↓
[결재 시스템에 반전 문서번호 등록]
  

이 구조는 회계 감사 시 요구되는 변경 추적(Traceability)을 크게 향상시킵니다.

3. 예산(Commitment) 실시간 연동 패턴

예산 집행 관리가 중요한 조직은 예산 승인 → 지출 결재 → 전표까지 모두 Commitment 기반으로 연결합니다.

[지출 결재 Draft]
   ↓ (예산 체크 API)
[Commitment 생성 또는 증액 요청]
   ↓
[결재 승인]
   ↓
[ERP 전표 생성 → Commitment 확정]
  

대표 특징:

• 실시간 예산 검증으로 초과 집행 방지
• Commitment 변경 이력까지 결재 시스템에서 추적
• 사전 승인(Pre-Approval) vs 사후 정산(Post-Settle) 모두 지원

4. 마스터 데이터(MDM) 양방향 동기화

GL, 코스트센터, 프로젝트 코드 등 마스터 데이터는 ERP 기준이므로, 고급 패턴에서는 ERP → 결재 시스템으로 자동 동기화합니다.

두 가지 동기화 방식:

• Batch Sync (야간 또는 1시간 단위)
• Event 기반 Trigger Sync (MDM 변경 발생 시 즉시)

특히 플랫폼 기업·제조업에서는 MDM 변경이 잦아 이벤트 기반 Sync + 캐시 업데이트 조합을 많이 사용합니다.

5. Approval Rule Engine + ERP Rule 연동 구조

고도화된 기업은 결재 라우팅 규칙과 ERP 회계 규칙을 분리하여 운영합니다.

영역	규칙 내용
결재 시스템 Rule	금액별 승인자, 조직 구조, SOD, 복합 조건
ERP Rule	계정 매핑, 세금 코드, 예산 체크, CO 배분

그 후 전표 생성 시 두 Rule Engine을 결합해 결재 룰 → ERP 회계 처리로 자연스럽게 연결되도록 설계합니다.

6. 대량 결재(수백~수천 건) 처리 패턴

클라우드 기반 그룹웨어·ERP 환경에서 빈번한 고급 패턴입니다.

• Bulk Approval API 사용
• 메시지 청크(Chunk) 단위 분할
• 전표 생성 Processor 여러 개 병렬 실행
• 성공분/실패분 분리 저장 및 Retry Queue 운영

[500건 승인] 
   ↓
[Batch → 청크 분할(50건씩)]
   ↓
[멀티 Processor 병렬 실행]
   ↓
[성공/실패 Log 분리]
   ↓
[실패분 Retry Queue로 재처리]
  

7. ERP Locking & 중복 전표 방지 패턴

ERP 연동에서 가장 중요한 두 가지 문제:

• 중복 전표 생성(Duplicate JE)
• ERP Locking Deadlock

이를 방지하기 위한 고급 패턴:

1. 결재 문서 ID 기반 Idempotent 처리 → 동일 요청은 한 번만 전표 생성
2. ERP Lock Timeout 자동 재시도
3. 전표 번호 반환 시 Redis 캐시 저장
4. Callback 이후 상태 최종 저장(Transaction Boundary 분리)

8. 전체 고급 아키텍처 다이어그램

[결재 시스템]
   ├─ Rule Engine
   ├─ SOD/조직 승인 로직
   ├─ Pre-Validation (MDM, 예산)
   ↓ (API)
[ERP 인터페이스 Layer]
   ├─ Validation
   ├─ Queue Producer
   ↓ (Kafka/SQS)
[전표 생성 Processor]
   ├─ 회계 룰 매핑
   ├─ 전표 생성(FI/CO)
   ├─ Reversal 처리
   ↓
[ERP Main FI/CO]
   ↓
[Callback Layer]
   ↓
[결재 시스템 상태 업데이트]
  

이 구조는 대규모 트래픽, 복잡한 결재 규칙, 예산/회계 통합 요구가 큰 기업에서 널리 사용되는 고급 패턴입니다.

다음 요청이 있다면, 이 내용을 바탕으로 아키텍처 이미지(SVG)나 “전표 생성 Processor 상세 로직 편”도 제작해 드릴 수 있습니다.