[SAP ERP/SCM] 위탁재고(Consignment)란? 개념정리

[SAP ERP/SCM] 위탁재고(Consignment)의 모든 것: 개념부터 MM/SD 프로세스, 재무 통합 및 데이터 구조까지 완벽 정리

기업의 공급망 관리(SCM)가 고도화됨에 따라 재고 유지 비용(Inventory Holding Cost)을 최소화하고 자본 유동성을 확보하는 것은 기업 생존의 핵심 과제가 되었습니다.

이를 해결하기 위한 대표적인 선진 SCM 기법 중 하나가 바로 위탁재고(Consignment) 관리입니다.

 

SAP ERP(S/4HANA 및 ECC)는 이러한 위탁 프로세스를 표준 기능으로 완벽하게 지원하고 있습니다.

본 포스팅에서는 위탁의 기본 개념부터 구매(MM), 영업(SD) 관점의 프로세스, 재무(FI)와의 통합, 그리고 실제 SAP 시스템에서 이 데이터들이 어디서 어떻게 관리되는지 전문가 관점에서 상세히 파헤쳐 보겠습니다.

---

1. 위탁(Consignment)이란 무엇인가? (SCM 및 비즈니스 관점)

SCM 관점에서 위탁(Consignment)이란 '물리적인 재고의 위치'와 '재고의 법적 소유권(Ownership)'이 분리되는 특수한 재고 관리 형태를 말합니다.

 

일반적으로 물건을 구매하여 우리 창고에 입고하면 즉시 우리의 자산(재고)으로 잡히고 대금 지급 의무(매입채무)가 발생합니다.

하지만 위탁의 경우, 공급업체(Vendor)가 우리 회사의 창고에 물건을 가져다 놓지만(물리적 입고), 우리가 그 물건을 실제로 사용(투입/판매)하기 전까지는 소유권이 공급업체에 있는 것으로 간주합니다.

비즈니스적 기대 효과

• 구매자(Buyer) 입장: 재고를 창고에 보유하고 있어도 사용 전까지는 재무제표상 자산/부채로 잡히지 않으므로 운전자본(Working Capital)을 획기적으로 개선할 수 있습니다. 또한 자재 부족으로 인한 생산 차질을 예방할 수 있습니다. (VMI - Vendor Managed Inventory 전략과 자주 결합됩니다.)
• 공급자(Vendor) 입장: 고객사 창고에 자사 제품을 미리 배치함으로써 경쟁사 대비 납기 경쟁력(Lead Time 제로화)을 확보하고, 장기적이고 안정적인 거래 관계(Lock-in 효과)를 구축할 수 있습니다.

SAP에서는 이러한 위탁을 크게 두 가지 방향으로 나누어 관리합니다.

1. 공급업체 위탁 (Vendor Consignment - MM 영역): 우리가 협력사로부터 위탁재고를 받아 우리 창고에 보관하는 경우.
2. 고객 위탁 (Customer Consignment - SD 영역): 우리가 고객사 창고에 우리 제품을 위탁재고로 제공하는 경우.

---

2. 공급업체 위탁재고 (Vendor Consignment - SAP MM)

MM(자재 관리) 모듈에서의 위탁은 협력사의 부품이나 원자재를 우리 공장에 쌓아두고, 생산에 투입하는 순간 소유권이 이전되며 대금을 정산하는 프로세스입니다.

2.1 사전 마스터 데이터 세팅 (Master Data)

위탁 프로세스를 정상적으로 수행하기 위해서는 특별한 마스터 데이터 설정이 필수적입니다.

• 자재 마스터 (Material Master): 일반 자재와 동일하게 생성하되, MRP View에서 특별 조달 유형(Special Procurement Type) '10'(위탁)으로 설정하여 MRP가 위탁 PR(구매요청)을 생성하도록 유도할 수 있습니다.
• 위탁 정보 레코드 (Consignment Info Record - T-Code: ME11): 이 부분이 가장 중요합니다. 일반 구매는 PO(구매오더) 생성 시점에 단가가 결정되지만, 위탁은 입고 시점이 아닌 '사용(Consumption) 시점'의 단가로 정산됩니다. 따라서 시스템은 PO가 아닌 위탁 정보 레코드(Info Category: 'K')에 유지된 조건(Condition) 단가를 읽어와 정산합니다.

2.2 프로세스 흐름 및 핵심 T-Code

1. 위탁 구매 오더 생성 (ME21N): 품목 범주(Item Category)를 'K' (위탁)로 지정하여 PO를 생성합니다. 이때 PO에는 단가와 금액이 '0'으로 표시됩니다. (소유권이 아직 넘어오지 않으므로 금액적 가치를 산정하지 않음), 비평가 재고(Non-valuated Stock )로 관리합니다.
2. 위탁 입고 (MIGO): 이동 유형(Movement Type) 101 K로 입고 처리합니다.
   • 재무적 영향: 물류 문서(Material Document)만 생성되고, 회계 문서(FI Document)는 생성되지 않습니다. 우리 재고자산이 아니기 때문입니다.
3. 재고 이체 또는 출고/사용 (MIGO):
   • 재고 이체 (Mvt 411 K): 위탁재고를 우리 회사 소유의 가용재고로 소유권 이전. (이때 회계 전표 발생: 재고자산 증가 / 미착 위탁 매입채무 증가)
   • 직접 출고 (Mvt 201 K / 261 K): 코스트 센터나 생산 오더로 직접 투입. (회계 전표 발생: 원재료비 증가 / 미착 위탁 매입채무 증가)
4. 위탁 정산 (MRKO): 일반적인 송장 검증(MIRO)을 사용하지 않습니다. 협력사가 송장을 보내는 것을 기다리지 않고, 우리가 사용한 내역을 바탕으로 자체적으로 부채를 확정 짓고 정산하는 MRKO (Consignment and Pipeline Settlement) 트랜잭션을 사용합니다.
   • MRKP (T-code) 정산흐름 : 소비/출고 발생(GI, 생산오더나 코스트 센터로 출고) - 부채 발생 - MRKO를 통해 송장 없이, 소비량 확정 후 공급업체에 지급할 채무 전표를 일괄 생성

 

---

3. 고객 위탁재고 (Customer Consignment - SAP SD)

SD(영업 및 배송) 모듈에서의 위탁은 우리가 고객사 창고로 물건을 보내고,

고객이 사용/판매했다고 통보할 때 매출을 인식하는 프로세스입니다.

 

이 프로세스는 4가지의 고유한 오더 유형(Order Type)과 이동 유형(Movement Type)의 조합으로 이루어집니다.

이를 정확히 이해하는 것이 핵심입니다.

 

3.1 프로세스의 4단계 (4-Step Process)

단계	설명	오더 유형 (Order Type)	이동 유형 (Movement Type)	재무/청구 (FI/Billing)
1. 위탁 보충 (Fill-up)	고객사 창고로 재고를 보냄. 여전히 우리 소유의 특별 재고(W)로 관리됨.	KB	631 (가용재고 -> 고객위탁재고)	미발생
2. 위탁 출고 (Issue)	고객이 재고를 사용/판매함. 소유권 이전 및 매출 인식 단계.	KE	633 (고객위탁재고 -> 출고)	매출원가 발생, 청구(Billing - F2) 생성
3. 위탁 반품 (Returns)	고객이 사용 처리했던 것을 취소하고 다시 고객 창고의 위탁재고로 돌려놓음.	KR	634 (출고취소 -> 고객위탁재고)	대변 메모(Credit Memo) 생성
4. 위탁 회수 (Pick-up)	고객 창고에 남아있는 안 팔린 위탁재고를 우리 공장으로 회수함.	KA	632 (고객위탁재고 -> 가용재고)	미발생

• 핵심 포인트: 고객 창고에 있는 재고는 우리 시스템에서 '고객 특별 재고 Indicator: W' (Special Stock W)로 관리되며, MMBE(재고조회)에서 고객별 위탁재고 수량을 정확히 파악할 수 있습니다.

---

4. SAP 데이터 구조: 이 지식과 데이터는 어디서 가져오는가?

실제 SAP 시스템 내에서 위탁 데이터가 흐르고 저장되는 핵심 테이블 출처는 다음과 같습니다.

4.1 MM (공급업체 위탁) 데이터 테이블 추적

1. 마스터 데이터 조회:
   • EINA / EINE: 구매 정보 레코드 테이블. EINE-BSORT 필드 등을 통해 정보 레코드 범주 '위탁(K)'을 확인하고 해당 단가를 조회합니다.
2. 트랜잭션 데이터 (입고/출고):
   • MATDOC (S/4HANA 기준): ECC 시절의 MKPF(헤더), MSEG(아이템)가 통합된 자재 문서 테이블입니다.
   • 데이터 추출 로직: 공급업체 위탁재고 이동을 보려면 MATDOC 테이블에서 SOBKZ(특별재고 지시자) = 'K' 인 데이터를 조회합니다.
   • MKOL (공급업체 특별 재고): 현재 우리 공장에 깔려 있는 공급업체별 위탁재고 잔량을 집계해서 보여주는 요약 테이블입니다. (MB54 T-code의 배경 테이블)
3. 정산 데이터 (MRKO):
   • RKWA (Consignment Withdrawals): 출고(201 K 등)가 발생하면 시스템은 이 테이블에 출고 내역과 사용 금액, 세금 정보를 기록합니다. MRKO 프로그램은 바로 이 RKWA 테이블을 읽어 상태값(STATUS: 미정산 -> 정산 완료)을 업데이트하고 FI 전표 헤더(BKPF), 아이템(BSEG) 테이블에 데이터를 기록하여 회계 처리합니다.

4.2 SD (고객 위탁) 데이터 테이블 추적

1. 영업 오더 및 딜리버리:
   • VBAK / VBAP: 위탁 오더 유형(KB, KE, KR, KA)으로 생성된 오더 헤더/아이템 정보를 담고 있습니다. 아이템 범주(Item Category)가 각각 KBN, KEN, KRN, KAN으로 다르게 지정됩니다.
   • LIKP / LIPS: 배송(Delivery) 정보.
2. 고객 위탁 재고 잔량:
   • MSKU (Special Stocks with Customer): 고객(KUNNR)별로 현재 얼마만큼의 위탁 자재(MATNR)가 남아있는지 재고 수량을 보여주는 핵심 테이블입니다. 위탁 보충(631) 시 수량이 증가하고, 위탁 출고(633) 시 수량이 차감됩니다.

---

5. 결론

SAP의 위탁(Consignment) 프로세스는 단순히 시스템 기능을 켜는 수준이 아니라, 구매, 영업, 물류 창고 관리, 그리고 재무 회계 부서 간의 긴밀한 협의가 필요한 크로스 펑셔널(Cross-functional) 프로세스입니다. 또한  단순한 물류 기능을 넘어 파트너십과 데이터 공유의 장점이 있습니다.

 

특히 프로젝트 구축 시 가장 많이 발생하는 이슈는 '단가 관리의 시점 차이'입니다.

위탁재고를 소비(출고)하는 시점의 Info Record 단가와 실제 공급업체가 생각하는 단가가 일치하지 않으면, MRKO 정산 시 오류가 발생하거나 재무적인 차이(Variance)가 발생하게 됩니다. 따라서 OBYC (자동 계정 지정) 설정 시 위탁 지급금(KON) 및 재고 평가 차이(AKO) 계정 매핑을 완벽하게 설계해야 합니다.