재고 역분개(반품·취소) 처리 방법 — 되돌리기의 회계

ERP에서 이미 처리한 거래를 되돌려야 할 때가 있다. 거래처에 제품 100개를 출고했는데 20개가 반품됐다. 입고한 원재료 일부를 공급업체에 돌려보내야 한다. 생산실적을 잘못 등록했다. 출고수량을 100개로 입력해야 하는데 1,000개로 입력했다. 화면에서는 모두 비슷하게 보인다 — “잘못됐으니 취소하면 되는 것 아닌가?”

하지만 회계와 재고에서는 이 넷을 같은 방식으로 처리하면 안 된다. 반품(Return)·취소(Cancellation)·정정(Correction)·역분개(Reversal)는 관련은 있지만 같은 개념이 아니다. 어떤 거래는 반대 Transaction을 만들어야 하고, 어떤 거래는 아직 확정되지 않아 취소만 하면 되고, 단순 입력오류는 정정이 필요할 수 있으며, 이미 마감된 기간의 오류라면 또 다른 판단이 필요하다. 중요한 건 모든 걸 ’역분개’라 부르는 게 아니라 원래 무슨 일이 발생했고 지금 무엇을 되돌리려는지 구분하는 것이다.

첫 번째 — 발주서를 만들었지만 아직 물건이 오지 않았다

구매담당자가 원재료 1,000kg을 주문했는데 공급업체와 협의한 뒤 주문을 취소했다. 아직 입고되지 않았고 매입도 확정되지 않았다. 이 경우 창고에 원재료가 들어온 적이 없다. 따라서 원재료 재고를 1,000kg 감소시키는 ’역재고 Transaction’을 만들 이유가 없다 — 원래 증가한 재고가 없기 때문이다. 회계분개도 발주서 작성만으로 생성되지 않는 구조라면 되돌릴 분개 자체가 없다. 필요한 건 Purchase Order의 취소다.

이 차이는 중요하다. 모든 문서 삭제나 취소를 재고 복원 + 회계 역분개로 구현하면 실제 발생하지 않은 재고거래를 만들어낸다. 업무문서가 취소된 것과 이미 발생한 경제적 거래를 되돌리는 것은 다르다. 그래서 시스템에서는 발주·입고·매입확정 같은 업무단계를 구분해야 한다.

두 번째 — 원재료가 실제 입고된 뒤 공급업체에 반품했다

이번엔 다르다. 원재료 1,000kg이 실제로 입고돼 재고에 반영됐고, 이후 품질문제로 200kg을 공급업체에 반환하기로 했다. 이제 실제 물류가 발생한다 — 창고에서 200kg이 나간다. 따라서 구매발주를 단순히 1,000kg에서 800kg으로 수정하면 실제 이력이 사라진다. 기록상 처음부터 800kg만 입고된 것처럼 보이기 때문이다. 실제로는 1,000kg 입고 후 200kg 반품이 발생했고, 이 두 사건은 의미가 다르다.

LOT 관리가 필요한 원재료라면 어떤 입고 LOT에서 200kg이 반환됐는지도 확인할 수 있어야 한다. 회계에서도 이미 인식된 매입이나 채무가 있다면 반품에 따른 처리가 필요하다. 다만 이를 최초 분개의 차변·대변을 기계적으로 뒤집는 문제로만 보면 부족하다. 세금계산서 처리·거래조건·결제상태·회계정책에 따라 실제 처리할 항목이 달라진다. ERP가 할 일은 최초 입고를 지우는 게 아니라 원입고 Transaction과 구매반품 Transaction을 연결해 남기는 것이다.

세 번째 — 제품 100개를 판매했고 20개가 돌아왔다

판매반품은 더 복잡하다. 처음 100개가 출고됐고 고객이 그중 20개를 반품했다. 여기에는 최소 세 관점이 있다 — 고객과의 판매거래, 회계상 매출과 매출원가, 실제로 돌아온 제품의 재고상태. “20개가 반품됐으니 완제품 재고 20개를 바로 복원한다”고 처리하면 식품제조업에서는 문제가 생긴다. 반품된 제품이 물리적으로 돌아왔다는 사실과 정상 판매가능재고가 20개 증가했다는 것은 같은 의미가 아니기 때문이다.

반품제품은 먼저 ’수량’과 ’상태’를 구분한다

고객에게 나갔다 돌아온 식품이라면 보관상태를 바로 확신하기 어렵다. 냉동제품이 적정온도로 유지됐는지, 포장이 훼손됐는지, 소비기한이 충분히 남았는지, 품질문제로 반품된 것인지 확인해야 할 수 있다. 따라서 물류상 반품수량 20개가 입고되더라도 즉시 정상 AVAILABLE 재고로 만들기보다 품질절차에 따라 별도의 반품·격리 위치나 품질상태에서 관리한다.

RETURNED → QC HOLD → REVIEW → RELEASED / DISPOSAL

검사 후 정상적으로 다시 쓸 수 있으면 적절한 재고상태로 전환하고, 못 쓰면 폐기나 별도의 부적합 처리로 이어진다. 특히 반품사유가 품질문제라면 해당 완제품 LOT만 볼 게 아니라 동일 LOT의 다른 출고처나 관련 생산 Batch까지 확인해야 한다. 이때 LOT Genealogy가 쓰인다.

회계상 반품과 창고의 반품은 같은 버튼으로 끝나지 않는다

판매반품의 회계처리는 기존 판매분개를 20% 반대로 만든다로만 설명하기 어렵다. 특히 반품권이 있는 판매에서는 애초의 판매시점부터 예상되는 반품을 고려한 회계처리가 적용될 수 있다. 그래서 ERP에서 판매반품 기능을 설계할 때는 물류의 실제 반품과 회계상 수익·환불·재고 처리를 구분할 수 있어야 한다. 중소 제조기업의 일반적인 단순 반품에서는 기존 거래에 대응하는 매출·매출원가 조정이 발생하지만, 모든 거래에 하나의 고정 분개식을 적용하는 건 위험하다. 시스템에서는 회계 Rule을 회사 정책에 맞게 설정하고, 반품 Transaction은 원판매 Transaction과 연결해 근거를 남기는 방식이 적절하다.

네 번째 — 생산실적을 잘못 입력했다

이번엔 실제 반품이 아니다. 생산담당자가 완제품 100개를 만들었는데 실수로 1,000개라고 입력했다. 900개가 실제로 생산됐다가 사라진 게 아니라 단순 입력오류다. 그런데 잘못된 생산실적이 이미 확정돼 재고 1,000개가 생성되고 원재료 소비와 원가계산까지 이어졌다면 복잡해진다. 완제품 생산실적만 100개로 수정하면 원재료 재고와 생산원가가 기존 1,000개 기준으로 남을 수 있다.

따라서 시스템에서는 그 생산실적이 어디까지 후속처리를 발생시켰는지 확인해야 한다. 아직 확정 전이면 수정이 가능하고, 이미 재고·원가 Transaction이 생성됐다면 기존 Transaction을 취소하고 올바른 생산실적을 다시 생성하는 게 더 명확하며, 이미 회계마감까지 끝났다면 회사의 오류수정 정책과 회계기준에 따른 추가 판단이 필요하다. 즉 ’틀린 숫자를 고친다’는 같은 행동도 거래가 어느 단계까지 진행됐는지에 따라 처리방법이 달라진다.

그래서 ERP에는 Delete보다 Cancel이 중요하다

ERP 개발에서는 DB의 한 행을 삭제하는 게 가장 간단하다. 하지만 실제 업무시스템에서는 간단한 방법이 항상 좋은 방법은 아니다. 이미 확정된 거래를 물리적으로 삭제하면 누가 만들었는지, 언제 확정됐는지, 왜 취소됐는지, 어떤 후속 Transaction이 발생했는지 확인하기 어려워진다. 그래서 확정된 주요 거래는 원본을 유지하고 취소 Transaction 또는 취소이력을 남기는 방식이 더 안전하다.

다만 이것이 “ERP에서는 어떤 데이터도 절대 삭제하면 안 된다”는 뜻은 아니다. 아직 확정되지 않은 Draft 문서나 잘못 생성된 임시 데이터까지 회계거래처럼 영구보존할 필요는 없다. 핵심은 업무적으로 효력이 발생한 Transaction과 단순 작성중 문서를 구분하는 것이다.

부분반품에서는 ’비율’보다 실제 대상이 중요하다

100개 중 20개가 반품됐다고 모든 값을 20%씩 되돌리면 된다고 생각하기 쉽다. 수량만 보면 20%가 맞다. 하지만 제조업에서는 어떤 20개인지가 중요하다. 100개 출고가 LOT A 60개 / LOT B 40개로 구성됐는데 반품된 20개가 전부 LOT B라면 재고복원도 LOT B에 연결돼야 한다. 두 LOT에 12개·8개로 비율배분하면 실제 재고이력이 왜곡된다. 원가도 LOT나 출고단위에 따라 적용된 장부금액이 다를 수 있다. 그래서 부분반품에서는 가능하면 원출고 · 반품수량 · 실제 반품 LOT · 원거래 금액을 기준으로 처리한다. ’20% 반품’보다 ’원래 나간 것 중 무엇이 돌아왔는가’가 더 중요한 질문이다.

이미 사용한 원재료를 매입반품으로 돌릴 수는 없다

원재료 1,000kg을 입고한 뒤 800kg을 생산에 썼다. 그런데 구매거래 전체를 취소한다고 원입고 1,000kg을 역수행하면 재고가 음수가 되거나 이미 생산된 완제품과 원재료의 연결이 깨진다. 이 경우 시스템은 단순 취소를 허용하기보다 이미 후속 Transaction이 존재한다는 사실을 확인해야 한다. 원입고 LOT가 생산 Batch에 쓰였다면 그 관계를 먼저 검토한다. ERP에서 거래는 독립된 행이 아니라 앞 거래의 결과가 다음 거래의 원인이 된다. 그래서 이미 후속거래가 발생한 Transaction을 취소할 때는 뒤에 연결된 거래가 있는지 확인하는 Dependency Check가 중요하다.

이미 판매된 완제품의 생산실적도 마음대로 취소할 수 없다

같은 원리가 생산에도 적용된다. 완제품 LOT가 생성됐고 이미 일부가 고객에게 출고됐다면 생산실적을 단순 취소할 수 없다. 생산을 취소하면 완제품 재고가 사라져야 하지만 그중 일부는 이미 나가 있다. 이때 시스템은 “취소할 수 없습니다”라고 막거나, 후속거래를 먼저 정상적으로 되돌리도록 안내해야 한다. 이런 통제 없이 모든 Transaction에 취소버튼을 열어두면 재고수량은 맞아 보여도 LOT Genealogy가 끊어진다.

반품은 원래 LOT를 유지하되 품질상태는 달라질 수 있다

제품이 고객에게 나갔다 돌아왔다고 새로운 생산 LOT가 만들어진 건 아니다. 그래서 원래 출고된 LOT와의 관계를 유지하는 게 추적성 측면에서 중요하다. 하지만 같은 LOT 번호라고 반품제품과 공장에 계속 보관돼 있던 정상제품을 물리적으로 섞어 관리해야 한다는 뜻은 아니다. 같은 LOT A라도 시스템에서는 정상재고 / 반품검사대기 / 품질보류처럼 서로 다른 Location이나 Quality Status로 나눌 수 있다. 이렇게 해야 LOT Genealogy는 유지하면서도 실제 사용가능 여부를 구분한다.

’재고가 돌아왔다’와 ’재고자산 가치가 돌아왔다’도 항상 같지 않다

반품제품이 물리적으로 돌아왔다고 최초 출고 당시의 장부금액이 아무 조건 없이 그대로 복원된다고 단정하기 어렵다. 제품이 훼손됐거나 가치가 감소했을 수 있기 때문이다. 특히 반품권이 있는 판매에 관한 회계기준에서는 반환제품을 회수할 권리를 측정할 때 제품 회수에 예상되는 원가와 반환제품 가치의 잠재적 감소도 고려한다. 이것은 ERP에서 반품입고 수량과 회계상 가치평가를 별도 개념으로 볼 필요가 있다는 좋은 사례다. 수량 20개가 돌아왔다는 사실만으로 그 20개의 경제적 가치까지 자동으로 결정되는 것은 아니다.

마감된 달의 거래는 ’무조건 당기 역분개’라고 정하면 안 된다

기존 거래가 7월에 발생했고 8월에 오류를 발견했다고 하자. “마감된 기간은 건드리지 말고 8월에 반대분개하면 된다”고 하나의 원칙으로 정하기 쉽다. 하지만 회계에서는 오류의 성격·중요성, 적용하는 회계기준에 따라 처리방법이 달라진다. 단순한 정상 반품이 8월에 발생한 것과, 7월 장부 자체가 잘못 작성됐다는 사실을 8월에 발견한 것은 다른 문제다. 전자는 8월에 새롭게 발생한 경제적 사건이지만 후자는 과거 오류의 수정 문제다. 따라서 ERP가 회계적 판단까지 임의로 결정해서는 안 된다. 시스템은 마감기간의 원거래를 보호하고, 필요하면 권한 있는 담당자가 적절한 조정 Transaction을 생성할 수 있게 지원하는 편이 안전하다.

세금계산서까지 발행됐다면 재고만 되돌려서는 안 된다

국내 B2B 거래에서는 이미 세금계산서가 발행된 뒤 반품이나 계약해제가 발생할 수 있다. 이 경우 재고와 회계만 수정하고 세금계산서 관련 처리를 놓치면 세무자료와 ERP 거래가 달라진다. 구체적인 수정세금계산서 발급사유와 작성일자는 부가가치세법령에 따라 판단해야 하므로 ERP가 모든 상황을 하나의 반품 Rule로 처리해선 안 된다. 실무적으로는 반품·취소 Transaction에 원거래 · 원세금계산서 · 수정세금계산서 · 회계조정을 연결할 수 있어야 한다. 이렇게 해야 물류의 취소와 세무의 정정이 따로 움직이지 않는다.

’역분개’라는 이름 때문에 모든 걸 반대로 만들 필요는 없다

역분개라는 표현을 넓게 쓰다 보면 기존 Transaction의 모든 필드에 마이너스 값을 붙이는 방식으로 구현하기 쉽다. 하지만 실제 업무는 그렇게 단순하지 않다.

판매반품 → 새로운 반품입고라는 물류 Event
구매반품 → 공급업체로 다시 출고되는 Event
생산취소 → 잘못 생성된 생산·소비 Transaction을 되돌리는 작업
회계 역분개 → 기존 회계효과를 반대방향으로 조정하는 개념

서로 연결되지만 동일하지 않다. 그래서 시스템에서는 하나의 거대한 REVERSE EVERYTHING 기능보다 업무의 의미에 맞는 취소·반품·정정 기능을 따로 두고 필요한 회계처리를 Rule로 연결하는 방식이 더 명확하다.

되돌리기를 잘 설계하면 정상거래의 구조도 보인다

ERP를 설계하다 보면 순방향 거래보다 취소기능에서 데이터 구조의 문제가 먼저 드러나는 경우가 있다.

• 원재료 입고를 취소하려는데 어느 생산에 쓰였는지 모르면 → LOT 연결이 부족한 것
• 판매반품을 처리하려는데 어느 LOT가 돌아왔는지 모르면 → 출고추적이 부족한 것
• 생산실적을 취소하려는데 어떤 원재료 소비가 연결됐는지 모르면 → 생산 Transaction 구조가 부족한 것
• 회계분개를 취소하려는데 어떤 업무거래에서 만들어졌는지 모르면 → Source Transaction 연결이 부족한 것

그래서 역분개를 단순한 회계기능으로만 보지 않는다. 정상적으로 발생한 거래를 정확하게 되돌릴 수 있다는 것은 처음 거래가 어떻게 만들어졌는지를 시스템이 알고 있다는 뜻이기 때문이다. 입고된 것을 되돌리려면 원입고를, 출고된 것을 반품받으려면 원출고를, 생산을 취소하려면 실제투입과 생산실적을, 분개를 되돌리려면 어떤 Transaction에서 그 분개가 만들어졌는지를 알아야 한다.

결국 좋은 역분개 기능은 마이너스 숫자를 만드는 기능이 아니다. 원거래를 보존한 상태에서 실제로 되돌아간 것만 되돌리고, 되돌릴 수 없는 것은 막으며, 그 이유와 결과를 다시 추적할 수 있게 만드는 기능이다.

참고 — 반품·계약해제의 매출·매출원가 조정, 수정세금계산서 발급사유·작성일자, 과거 오류의 수정 처리는 거래조건·회계기준·부가가치세법령에 따라 다르다. 실제 회계·세무 적용은 전문가 확인이 필요하다.