erpkaizen

가치를 재는 법

청구서를 두 번 만들지 않기: 만들기 전에 회계 장부에 묻는다, 209건 중 199건은 이미 있었다

측정 있음 글 2026년 11월 4일 약 10분
두 권의 장부: ERP는 납품의 청구서를 만들기 전에 PO 번호로 회계 프로그램의 장부에 먼저 묻는다. 이미 전표가 있다는 답이므로 ERP는 두 번째 청구서를 만들지 않고 그 전표를 납품에 연결한다. 실제 데이터가 아님. ERP 납품 · PO 회계 프로그램 이 PO 청구서 있나? 있음 — 전표 기록됨 이미 있음 — 다시 만들지 않음 만들기 전에 장부에 묻는다 가져온 청구서는 되돌려 보내지 않는다
청구서를 만들기 전에 ERP는 PO 번호로 회계 프로그램의 장부에 묻습니다. 전표가 있으면 납품에 연결하고 두 번째 청구서는 만들지 않습니다.

청구서 발행을 회계 프로그램에서 ERP로 옮길 때, 양쪽이 모두 청구서를 만드는 기간이 생깁니다. ERP가 만들기 전에 회계 장부에 직접 묻는다면 한 번의 전환에서 중복 몇 건을 피할 수 있을까 — 정리하지 않아도 되는 중복 한 건은 얼마의 가치일까?

청구서 발행을 ERP로 옮기는 몇 주 동안, 몇 건의 납품이 양쪽에서 청구되는가 — 그리고 정리하는 데 얼마가 드는가?

ERP가 매달 만드는 청구서 수, 두 시스템이 나란히 도는 주 수, 회계 담당자가 아직 회계 프로그램에 입력하는 비율만 있으면 됩니다. 나머지는 모두 거기서 나옵니다. 모두 고칠 수 있습니다.

ERP 청구로 옮기는 고객 그룹 기준
ERP가 만들기 시작한 날부터 회계가 입력을 멈출 때까지
처음 2주 측정: 209건 중 199건
두 번 세어지는 매출을 보여 주기 위한 것 — 효과에 더하지 않음

계산된 값(전환 기간 전체)

ERP가 만드는 청구서–
양쪽에 다 있음–
먼저 묻지 않으면 두 건이 됨–
두 번 세어지는 매출(동)–
가정 — 열어서 하나씩 보고 고치기

두 권의 장부

시간

전환 기간의 두 장부 — 면적은 비례 실선 원: ERP가 만든 청구서 · 점선 원: 회계 프로그램에 입력된 청구서 · 겹친 부분: 같은 납품이 양쪽에
전환 기간의 두 장부 — 면적은 비례

A. 청구서마다 손으로 찾지 않아도 됨–
B. 중복을 찾아 취소하지 않아도 됨–
C. 전자세금계산서를 취소·대체하지 않아도 됨–
D. 묻지 못한 회차 다시 보기–
전환 기간 전체, 금액으로–

이것은 추정이지 약속이 아닙니다. 회계 프로그램에 아직 입력하는 비율을 0, 손으로 찾는 분을 0, 다시 보는 분을 0으로 두면 모든 항목이 0이 됩니다. 두 번 세어지는 매출은 보여 주기만 하고 더하지 않습니다. 바로잡아야 할 오류이지 번 돈이 아닙니다.

어느 날 아침 7시 30분, 기계가 유통 체인 납품서 한 장에 대해 청구서를 작성했습니다. 같은 날 아침, 회계 담당자는 늘 하던 대로 바로 그 납품서를 회계 프로그램에 입력했습니다. 회계 프로그램에서 ERP로 넘어오는 동기화는 12시 15분에야 실행되었기 때문에, 7시 30분에 ERP는 아무것도 보지 못했습니다. 그 결과는 납품서 한 장에 청구서 두 건, 두 개의 장부에 하나씩이었고, 따로 놓고 보면 어느 장부도 틀리지 않았습니다.

누구의 잘못도 아닙니다. 청구서 작성 업무를 회계 프로그램에서 ERP로 옮기는 모든 전환 기간이 이런 모양입니다. 새 시스템이 충분히 오래 돌아가기 전에 아무도 옛 시스템을 끌 엄두를 내지 못하기 때문에, 두 곳이 함께 청구서를 작성하는 기간이 생깁니다. 실제 시스템에서 측정해 보니, 그런 전환의 처음 2주 동안 납품서에 대해 기계가 작성한 청구서 209건 중 199건, 즉 95%가 회계 프로그램에도 이미 있었고, 금액은 3억 1,900만 동이었습니다.

이 글의 질문은 이렇습니다. 작성하기 전에 ERP가 회계 프로그램의 장부에 그 PO의 청구서가 이미 있는지 직접 묻는다면, 한 번의 전환에서 중복 청구서를 몇 건이나 피할 수 있고, 치우지 않아도 되는 중복 청구서 한 건은 얼마의 가치가 있을까요?

1. 무엇이 바뀌는가

  1. 작성하기 전에 묻습니다. 「청구 가능」한 납품서마다, 청구서를 만들기 전에 ERP는 회계 담당자 컴퓨터의 읽기 전용 통로를 통해 회계 프로그램의 장부에 이 납품서의 입고 확인서 번호나 PO 번호를 담은 판매 전표가 있는지 묻습니다.
  2. 이미 있으면 ⇒ 다시 작성하지 않습니다. 납품서는 「청구 완료」 항목으로 넘어가고, 전표 번호와 함께 「회계 프로그램에 이미 있음」이 명시됩니다. 동기화가 그 청구서를 가져오면, 그것은 납품서에 연결되어, 누가 납품서를 열든 그 청구서를 볼 수 있습니다.
  3. 전환일부터 — 동기화가 판매 청구서 가져오기를 멈추는 날 — ERP가 청구서를 보관하는 곳이 됩니다. ERP는 체인이 실제로 입고한 수량에 따라 작성하고, 전표 번호와 함께 「회계 프로그램에 이미 있음」으로 표시하여, 그쪽으로 다시는 거꾸로 보내지 않습니다.
  4. 회계 프로그램에서 가져온 청구서는 절대 거꾸로 보내지지 않습니다. 이런 청구서에서는 보내기 버튼이 사라지고, 누군가 다른 경로로 호출하면 보내기 명령이 거부됩니다.
  5. 매 실행 후 다시 묻습니다. ERP가 작성했지만 아직 보내지 못한 청구서는 회계 장부에 다시 물어봅니다. 기계가 작성한 뒤에 회계 담당자가 입력할 수도 있기 때문입니다.
  6. 두 방향에 같은 규칙. 동기화가 입고 확인서 번호, PO 번호 또는 ERP 청구서 번호가 기존 ERP 청구서와 같은 판매 전표를 만나면, 그것을 불러오지 않고 짝을 맞춥니다. 불러오면 ERP에서 매출이 두 번 잡히기 때문입니다.

ERP 청구서를 회계 프로그램으로 보내는 일은 별개의 기능입니다. 여기서는 그 기능도 기록하기 전에 먼저 묻는다는 것만 알면 됩니다.

회계 담당자 컴퓨터가 꺼져 있을 때 — 7시 30분 실행에서 자주 겪는 일입니다 — ERP는 물을 수 없습니다. 처음에는 기계가 완전히 멈췄습니다 (「중복보다는 지연이 낫다」). 매일 아침 청구서가 하나도 없었기 때문에 방식을 바꿨습니다. 가장 최근 동기화를 바탕으로 그대로 작성하되, 그 실행은 묻지 못했다고 명시하고, 실행 후의 재질의 단계와 동기화 시의 짝맞춤 단계가 빠져나간 부분을 잡도록 합니다.

2. 10월 30일에 측정한 것

경우건수금액
기계가 작성했지만 회계 프로그램에도 이미 있던 청구서 — 보내기 전에 알아챔1993억 1,940만
회계 프로그램에서 가져온 청구서가 있는 납품서 — 연결하고 다시 작성하지 않음1173억 270만
작성 전에 장부에 물었더니 이미 있던 납품서 — 작성하지 않음66,670만
이미 있다고 알아챈 것3226억 8,880만

이 단계들이 생기기 전에는, 회계 프로그램에 이미 청구서가 있던 납품서 87장이 검토 화면에서 잘못된 항목에 놓여 있었습니다. 60장은 「입고 확인서 대기」, 13장은 「검토 필요」, 그리고 14장은 「청구 가능」으로 회계 담당자에게 두 번째 작성을 권하고 있었습니다. 그리고 중복 청구서 한 건은 실제로 발생했습니다. ERP가 직접 묻는 법을 알기 전, 이 글 첫머리의 바로 그 아침 납품서입니다.

6억 8,880만 동은 어떤 단계도 막지 않았다면 두 번 집계되었을 매출입니다. 그것은 벌어들인 돈이 아니며, 아래 계산표는 그것을 이익에 더하지 않습니다. 실제 돈은 들이지 않아도 되는 수고에 있습니다.

3. 첫 번째 원천: 청구서를 한 건씩 손으로 찾아볼 필요가 없음

묻는 기계가 없으면, 확실히 하는 유일한 방법은 보내기를 허락하기 전에 사람이 ERP 청구서를 하나하나 회계 프로그램에서 찾아보는 것입니다.

전환 1회 금액 = 전환 기간에 작성된 ERP 청구서 × 청구서 한 건 조회 시간(분) ÷ 60 × 시간당 비용
예시 매달 청구서 420건, 2주간 병행 운영: 약 194건. 청구서마다 PO 번호로 찾는 데 2분. 194 × 2 ÷ 60 ≈ 6.5시간 ≈ 39만 동.

측정 방법. 연속된 청구서 20건을 조회하는 시간을 재십시오. 신뢰도: 높음, 그러나 작음.

4. 두 번째 원천: 중복 청구서를 찾아내고 정리할 필요가 없음

전환 1회 금액 = 두 곳 모두에 있는 청구서 × (1 − 사람이 스스로 발견하는 비율) × 중복 청구서 한 건 정리 시간 × 시간당 비용
예시 194 × 95% ≈ 두 곳 모두에 있는 청구서 184건. 사람이 보내기 전에 70%를 스스로 발견하고, 30%가 빠져나갑니다: 중복 청구서 약 55건. 청구서마다 한 시간 — 찾아내고, 한쪽을 취소하고, 채권을 고치고, 기간 매출을 다시 확인합니다. 55 × 1 × 60,000 ≈ 330만 동.

측정 방법. 두 곳 모두에 있는 청구서 수는 측정된 숫자입니다(위의 95%). 사람이 스스로 발견하는 비율은 그렇지 않습니다. 회계 책임자에게 가장 최근 전환에서 중복 청구서를 몇 건이나 정리했는지, 그리고 언제 찾아냈는지 물어보십시오.

신뢰도: 보통. 가장 큰 원천이면서, 셀 수 없고 물어봐야 하는 숫자 위에 서 있습니다. 여러분의 직원이 거의 다 잡아낸다면 이 원천은 훨씬 작아집니다.

5. 세 번째 원천: 전자세금계산서를 취소하거나 대체할 필요가 없음

장부 안에 있는 중복 청구서는 내부에서 정리할 수 있습니다. 이미 전자세금계산서로 발행된 중복 청구서는 절차에 따라 취소하거나 대체해야 하고, 고객에게 설명해야 합니다.

전환 1회 금액 = 중복 청구서 × 전자 발행된 비율 × 청구서 한 건 취소 또는 대체 시간 × 시간당 비용
예시 55 × 20% = 전자세금계산서 11건, 건당 1.5시간. 11 × 1.5 × 60,000 ≈ 100만 동.

측정 방법. 지난 전환에서의 취소 확인서와 대체 계산서를 세십시오. 신뢰도: 보통 — 과소 추정일 수 있습니다. 특히 고객이 큰 체인이고 대체할 때마다 그들과 채권 대조를 한 번씩 해야 할 때 그렇습니다.

6. 되돌려 내야 하는 부분: 묻지 못한 실행

차감 = 묻지 못한 실행을 점검하는 월간 시간(분) ÷ 60 × 시간당 비용 × 전환 기간의 개월 수
예시 회계 담당자 컴퓨터가 꺼져 있던 실행의 요약을 읽는 데 매달 30분, 반 달 동안: 약 14,000동. 작지만, 유일한 빈틈이기 때문에 반드시 들여다봐야 합니다.

7. 합계

원천전환 1회 금액
청구서를 한 건씩 손으로 조회하지 않음39만
중복 청구서를 정리하지 않음332만
전자세금계산서를 취소, 대체하지 않음100만
묻지 못한 실행 점검−1만
전환 전체469만

매달 청구서 420건, 2주 전환 한 번에 약 470만 동, 일회성입니다. 이 예시에서 두 번 집계되었을 매출 2억 8,500만 동에 비하면 작은 숫자이고, 바로 그것이 핵심입니다. 먼저 묻는 단계의 가치는 절약되는 인건비에 있지 않고, 사람이 발견하기를 기다리는 동안 장부가 결코 틀린 상태에 있지 않다는 데 있습니다. 매출이 두 번 집계된 채로 마감한 한 달은 이미 내보낸 틀린 보고서입니다. 계산표는 그것을 값으로 매길 수 없고, 매기려 하지도 않습니다.

8. 이 ROI는 어떤 가정 위에 서 있는가

양쪽이 같은 번호를 가지고 있습니다. 묻기는 회계 프로그램의 전표가 체인의 입고 확인서 번호나 PO 번호를 담고 있을 때만 작동합니다. PO가 없는 체인의 경우 회계 전표는 내부 번호를 담고 있어 비교할 것이 없습니다. 거기서는 ERP가 전환일로 중복을 막습니다. 전환일 이전의 납품서는 ERP에서 작성하지 않습니다.

전환일은 한 곳에서 읽어야 합니다. ERP는 전환일을 동기화의 설정에서 직접 읽고, 사본을 두지 않습니다. 읽기에 실패하면 기계는 안전한 쪽을 택합니다 — 회계 프로그램에 이미 있는 납품서는 작성하지 않습니다. 두 곳에 손으로 옮겨 적은 두 개의 전환일은 정확히 중요한 그날에 서로 어긋납니다.

회계 담당자 컴퓨터가 꺼져 있으면 묻기가 없습니다. 이른 아침 실행이 가장 자주 겪는 때입니다. 실행 후의 두 단계 — 재질의와 동기화 시의 짝맞춤 — 가 빠져나간 부분을 잡지만, 몇 시간 늦습니다. 매주 「묻지 못한」 실행 수를 세십시오. 그 숫자가 높으면 묻기 단계를 빼지 말고 실행 시간을 옮기십시오.

95%는 처음 몇 주에만 맞습니다. 그것은 회계 담당자가 아직 입력을 멈추지 않았을 때의 숫자입니다. 전환이 끝나면 이 숫자는 0에 가까워져야 하고, 그렇지 않다면 누군가 아직도 일을 두 번 하고 있다는 뜻입니다.

9. 여러분 회사에서 측정하기

  1. 전환 전. 전환할 고객 그룹의 월간 청구서 수를 기록하고, 가장 최근 전환에서 중복 청구서를 몇 건이나, 얼마나 걸려 정리했는지 물어보십시오.
  2. 전환 중. 매일 셉니다: ERP가 작성한 청구서, 그중 「회계 프로그램에 이미 있음」 건수, 이미 있어서 작성하지 않은 납품서 수, 묻지 못한 실행 수. 「이미 있음」 비율은 점점 줄어야 합니다.
  3. 전환 후. 실제로 남아 있는 중복 청구서를 셉니다: PO 번호 하나에 전표 두 개. 목표 숫자는 0이며, 쿼리 하나로 측정할 수 있습니다.

함께 읽기: 납품은 청구되기 전에 매장이 서명한 수량과도 맞아야 합니다 — 서명된 검수표의 당일 대조가 그 부분을 다룹니다.

10. 기억할 점

중복 청구서 하나는 두 가지 올바른 작업에서 생겨납니다. 기계는 올바르게 작성했고, 회계 담당자는 올바르게 입력했으며, 다만 아무도 상대에게 묻지 않았을 뿐입니다. 전환 기간에는 사람들이 옛 작업을 멈추는 것을 기억해 주기를 기대하지 마십시오. 새 시스템이 기록하기 전에 옛 시스템에 묻게 하고, 옛 시스템에서 가져온 모든 것이 결코 거꾸로 가지 않게 하십시오.

업무를 새 시스템으로 옮긴다고 해서 옛 시스템이 멈추는 것은 아닙니다. 둘이 함께 돌아가는 기간이 있다는 뜻입니다.

두 곳 모두에 있는 청구서 수, 가져온 청구서가 연결된 납품서 수, 작성하지 않은 납품서 수와 금액은 2026년 10월 30일 21시 40분 유통 체인에 신선 식품을 공급하는 한 공급업체의 실제 시스템에서 측정했으며, 익명 처리했습니다. 월간 청구서 수, 사람이 스스로 발견하는 비율, 전자 발행 비율, 소요 시간과 인건비는 예시 숫자입니다. 여러분 자신의 숫자로 바꾸십시오.

이어서 읽기