거래처가 보낸 PDF 주문서를 AI가 읽었습니다. 고객명, 제품 코드, 수량과 납기 요청일까지 화면에 정확하게 채웠습니다. 담당자는 이제 주문 입력이 자동화됐다고 생각합니다.

문제는 그다음에 생깁니다. 제품 코드의 영문 O를 숫자 0으로 읽었거나, 단가 열에서 할인 전 가격을 가져왔거나, 같은 주문서가 이메일과 메신저로 두 번 들어왔을 수 있습니다.

주문서를 읽는 것과 주문을 확정하는 것은 다른 일입니다. 앞쪽은 문서에서 값을 찾는 일이고, 뒤쪽은 회사가 재고·매출·납기를 책임지는 일입니다. 두 단계 사이에 검증과 예외 처리가 있어야 합니다.

ERP 주문 테이블 앞에 검토 대기 공간을 둡니다

AI가 추출한 값을 곧바로 정식 주문으로 저장하지 않습니다. 먼저 검토 대기 주문으로 받습니다.

대기 기록에는 추출값만 넣지 않습니다.

  • 원본 주문서와 받은 이메일
  • 필드별 원문 위치
  • AI가 선택한 값과 다른 후보
  • 고객·제품 후보의 내부 ID
  • 검증을 통과하지 못한 이유
  • 처리 상태와 담당자

담당자는 AI 결과와 원문을 한 화면에서 비교할 수 있어야 합니다. 잘못 승인된 주문이 생기면 어느 원본과 어떤 추출 결과에서 시작됐는지도 다시 찾을 수 있어야 합니다.

검토 결과는 세 갈래로 나눕니다.

결과조건다음 단계
자동 승인필수 값과 회사 규칙을 모두 통과ERP 주문 생성
담당자 검토확신이 낮거나 규칙과 충돌수정·승인·반려
기준정보 요청고객·제품을 확정할 수 없음신규 등록 또는 정보 보완

저는 처음부터 자동 승인률을 높이지 않습니다. 잘못된 주문이 정식 데이터로 들어가지 않으면서 담당자의 반복 입력이 줄어드는지부터 확인합니다.

고객명은 문자열이 아니라 거래 관계입니다

주문서에는 회사명이 제각각 적힙니다. 법인명, 브랜드명, 지점명과 담당자 이름이 섞이고 띄어쓰기나 영문 표기도 달라집니다.

이름이 비슷하다는 이유만으로 기존 거래처에 자동 연결하면 청구 주체나 납품처가 바뀔 수 있습니다. 고객을 찾을 때는 이름 외에도 다음 정보를 함께 봅니다.

  • 사업자 식별 정보
  • 주문을 보낸 담당자 이메일과 도메인
  • 납품·청구 주소
  • 고객이 사용하는 주문번호 형식
  • 과거 주문과 계약 관계

후보가 하나로 좁혀지지 않으면 AI가 추측해 확정하지 않습니다. A사 본사와 A사 부산지점 가운데 담당자가 하나를 고르고, 승인된 연결을 다음 주문의 매칭 규칙으로 남깁니다.

제품은 비슷한 이름보다 판매 규칙을 봅니다

ERP에서 색상, 규격과 포장 단위가 다르면 별도 제품일 수 있습니다. 주문서의 ABC-100과 ERP의 ABC-100-B가 비슷해 보여도 같은 품목이라고 단정할 수 없습니다.

제품 후보를 고를 때는 코드와 설명뿐 아니라 다음 조건을 확인합니다.

  • 현재 판매 중인 제품인가
  • 해당 고객에게 허용된 규격인가
  • 최소 주문 수량과 포장 단위가 맞는가
  • 대체·후속 제품으로 승인된 관계가 있는가
  • 납기 안에 공급할 재고와 생산 가능성이 있는가

제품을 찾지 못했다고 새 품목을 자동 생성하지 않습니다. 임시 품목이 쌓이면 재고와 매출 분석이 갈라집니다. 담당자가 기존 제품을 선택하거나, 정식 기준정보 등록을 요청하도록 별도 절차를 둡니다.

읽기 정확도와 주문 유효성을 나눕니다

수량 120을 정확히 읽었다고 주문이 유효한 것은 아닙니다. 평소 12개씩 주문하는 고객이라면 한 자리 오타일 수 있고, 포장 단위가 50개라면 허용되지 않는 수량일 수 있습니다.

입력값은 형식뿐 아니라 업무 맥락에서 올바른지도 검증해야 합니다. 가격이 허용 범위에 있는지, 납기일이 주문일보다 뒤인지, 제품과 포장 단위의 조합이 가능한지 확인하는 방식입니다.[1]

필드마다 오류 비용도 다릅니다.

필드오류의 영향기본 처리
고객 메모표현·줄바꿈 수정사후 수정 가능
납품 주소오배송승인 전 주소 대조
제품·수량재고·생산 변경제품 규칙과 단위 검증
단가·할인·세액청구·정산 오류계약 가격과 승인 확인
납기생산 불가 약속재고·일정 대조

문서 인식 결과의 신뢰도는 사용 위험과 함께 봐야 합니다. 오류에 민감한 업무라면 필드별 임계값을 두고 기준 아래 결과를 버리거나 더 높은 수준의 검토로 보내는 방식이 필요합니다.[2]

신뢰도가 높아도 회사 규칙 검증은 생략하지 않습니다. AI는 문자를 잘 읽었을 뿐, 이번 고객에게 이 가격과 수량으로 팔아도 되는지까지 보장하지 않습니다.

같은 주문이 두 번 들어오는 경로를 막습니다

같은 주문서가 담당자 두 명에게 전달되거나 이메일과 메신저로 각각 들어올 수 있습니다. ERP 응답을 받기 전에 연결이 끊겨 자동화가 같은 주문을 다시 실행할 수도 있습니다.

중복 확인에는 한 값만 쓰지 않습니다.

  • 거래처의 주문번호
  • 이메일 메시지 ID
  • 첨부 파일 해시
  • 고객·주문일·총액의 조합
  • 이미 생성된 ERP 주문번호

주문번호가 같지만 수정 주문일 수도 있으므로 내용 차이도 봅니다. 같은 원본이면 중복으로 막고, 같은 주문번호의 수량·납기 변경이면 기존 주문 변경 절차로 보냅니다.

응답을 받지 못한 변경 요청은 바로 재시도하지 않습니다. 반복해도 같은 결과가 나오는 작업인지, 첫 요청이 ERP에 적용되지 않았는지 확인할 수 있어야 합니다.[3] 적용 여부를 모르면 실패가 아니라 미확인으로 두고 ERP의 실제 주문을 대조합니다.

예외 화면이 자동화의 품질을 결정합니다

새 고객, 처음 보는 제품명, 손으로 수정한 PDF와 한시적인 할인 조건은 반드시 생깁니다. 담당자에게 원본 주문서 전체를 다시 읽으라고 하면 자동화의 이점이 사라집니다.

예외 화면은 문제의 위치와 다음 행동을 바로 보여줘야 합니다.

  • 문제가 된 필드의 원문을 확대해 표시
  • AI가 선택한 값과 고객·제품 후보를 나란히 비교
  • 검증 실패 이유와 관련 회사 규칙 표시
  • 같은 거래처의 최근 승인값 제시
  • 승인·수정·반려·기준정보 요청 버튼 제공

사람이 수정한 결과는 기록하되 곧바로 모델 학습에 넣지는 않습니다. 일회성 예외인지 반복되는 매칭 규칙인지 먼저 구분하고, 기준정보 담당자가 승인한 규칙만 운영에 반영합니다.

검토 시간도 측정합니다. 한 건을 처음부터 다시 입력하는 데 3분이 걸렸는데 예외 화면을 확인하는 데도 3분이 걸린다면 복사 작업만 화면 이동으로 바뀐 것입니다.

가장 많이 오는 주문서 한 종류로 시작합니다

거래처마다 양식이 다르고 한 회사에서도 주문 방식이 바뀝니다. 모든 문서를 한 번에 처리하면 추출과 검증 규칙이 함께 복잡해집니다.

처음에는 주문량이 많고 양식이 비교적 안정적인 거래처 하나를 고릅니다. 최근 정상 주문뿐 아니라 다음 사례도 함께 시험합니다.

  • 취소·변경 주문
  • 같은 파일의 중복 발송
  • 손글씨로 수량을 고친 문서
  • 지점·브랜드명으로만 적힌 주문과 신규 거래처
  • 새 제품과 단종 제품
  • 평소 범위를 벗어난 수량·가격
  • 납기 요청을 맞출 수 없는 주문

확인할 성과는 평균 인식률 하나가 아닙니다.

  • 담당자가 다시 입력한 필드 수
  • 검토 대기 주문의 이유별 분류율
  • 잘못 자동 승인된 주문 수
  • ERP에 들어가기 전에 차단한 중복 수
  • 예외 한 건의 평균 검토 시간
  • 원본에서 ERP 주문번호까지 추적 가능한 비율

수동 처리 경로도 남겨 둡니다. 자동화가 멈추거나 새 양식이 들어왔을 때 담당자가 기존 방식으로 주문을 이어갈 수 있어야 합니다.

자동화의 완료 기준은 정식 주문입니다

AI가 주문서의 모든 필드를 읽은 장면은 데모의 끝일 수 있지만, 주문 업무의 끝은 아닙니다. 고객·제품·수량·가격·납기와 중복을 확인하고 ERP 주문번호가 원본에 연결돼야 합니다.

저는 중복 방지, 원본 추적, 예외 처리와 수동 복귀를 시험하기 전에는 자동 승인 범위를 넓히지 않습니다. 필드별 오류 비용과 실제 검토 시간을 보고 안전한 문서·고객·금액 범위부터 단계적으로 엽니다.

목표는 사람의 판단을 없애는 것이 아닙니다. 반복 입력은 줄이고, 회사가 책임져야 할 주문만 정식 데이터로 보내며, 나머지는 사람이 빠르게 판단할 수 있게 만드는 것입니다.

출처


#AI #ERP #주문서자동화 #문서AI #제조업자동화