거래처가 보낸 PDF 주문서를 AI가 읽습니다. 고객명, 제품 코드, 수량과 납기 요청일까지 화면에 정확하게 채웠습니다. 담당자는 이제 주문 입력이 자동화됐다고 생각합니다.
문제는 그다음에 생깁니다. 제품 코드의 영문 O를 숫자 0으로 읽었거나, 단가 열에서 할인 전 가격을 가져왔거나, 같은 주문서가 이메일과 메신저로 두 번 들어왔을 수 있습니다.
주문서를 읽는 것과 주문을 확정하는 것은 다른 일입니다. 앞쪽은 문서 인식이고, 뒤쪽은 회사가 재고·매출·납기를 책임지는 업무입니다.
ERP 주문 테이블 앞에 대기 공간을 둡니다
AI가 추출한 값을 곧바로 정식 주문으로 저장하지 않는 편이 안전합니다. 먼저 검토 대기 주문으로 받습니다.
이곳에는 AI가 읽은 값만 넣지 않습니다. 원본 파일, 받은 이메일, 추출한 문장 위치, 고객 후보와 제품 후보도 함께 남깁니다. 담당자는 AI가 내놓은 결과와 원문을 한 화면에서 비교할 수 있어야 합니다.
검토 결과는 보통 세 갈래로 나뉩니다.
- 회사 규칙을 모두 통과한 주문은 자동 승인합니다.
- 값은 읽었지만 확신이 낮거나 규칙과 충돌하면 담당자에게 보냅니다.
- 고객이나 제품을 찾을 수 없으면 신규 등록 절차로 넘깁니다.
처음부터 자동 승인 비율을 높이는 것이 목표가 되어서는 안 됩니다. 잘못된 주문이 정식 데이터로 들어가지 않으면서 담당자의 반복 입력이 줄어드는지가 더 중요합니다.
고객명은 문자열이 아니라 거래 관계입니다
주문서에는 회사명이 제각각 적힙니다. 법인명, 브랜드명, 지점명과 담당자 이름이 섞여 들어옵니다. 띄어쓰기나 영문 표기가 다른 경우도 많습니다.
이름이 비슷하다는 이유만으로 기존 거래처에 자동 연결하면 청구 주체나 납품처가 바뀔 수 있습니다. 고객을 찾을 때는 이름 외에도 사업자 식별 정보, 기존 담당자 이메일, 납품 주소와 과거 주문을 함께 봐야 합니다.
후보가 하나로 좁혀지지 않으면 AI가 추측해서 확정하지 않도록 합니다. A사 본사와 A사 부산지점 가운데 무엇인지 사람이 고르게 하고, 그 선택을 다음 주문의 매칭 규칙에 반영합니다.
제품 코드는 한 글자만 틀려도 결과가 달라집니다
제품 설명은 자연어라서 비슷해도 괜찮아 보입니다. ERP는 그렇지 않습니다. 색상, 규격, 포장 단위가 다르면 별도 제품일 수 있습니다.
주문서의 ABC-100, ERP의 ABC-100-B와 단순히 유사도가 높다는 이유로 연결해서는 안 됩니다. 판매 중지 제품인지, 해당 고객에게 허용된 규격인지, 최소 주문 수량과 포장 단위가 맞는지도 확인해야 합니다.
제품을 찾지 못했을 때 AI가 새 품목을 자동 생성하는 것도 피해야 합니다. 임시 품목이 쌓이면 재고와 매출 분석이 다시 갈라집니다. 담당자가 기존 제품을 선택하거나 신규 품목 등록을 요청하도록 별도 절차를 두는 편이 낫습니다.
정확도보다 오류 한 건의 비용을 봅니다
문서 필드 대부분을 잘 읽어도 수량이나 단가 한 칸이 틀리면 주문 전체가 잘못될 수 있습니다. 그래서 평균 정확도만으로 자동 승인 범위를 정하기 어렵습니다.
필드마다 실패 비용이 다릅니다.
- 고객 메모의 줄바꿈 오류는 나중에 고쳐도 됩니다.
- 납품 주소 오류는 배송 사고로 이어질 수 있습니다.
- 수량과 포장 단위 오류는 재고와 생산 계획을 바꿉니다.
- 단가·세액·할인 조건 오류는 청구와 정산에 영향을 줍니다.
위험이 큰 필드는 값이 선명하게 읽혔더라도 회사 규칙을 한 번 더 통과시켜야 합니다. 주문 금액이 평소 범위에서 크게 벗어났는지, 계약 단가와 일치하는지, 납기 요청이 생산 가능 일정보다 빠르지 않은지 확인할 수 있습니다.
같은 주문을 두 번 넣지 않는 장치가 필요합니다
자동화는 실패하면 재시도합니다. 이메일 처리 중 ERP 응답을 받기 전에 연결이 끊기면 시스템은 주문이 등록되지 않았다고 판단하고 다시 실행할 수 있습니다. 실제 ERP에는 첫 주문이 이미 들어갔을 수도 있습니다.
고객 주문번호, 이메일 메시지 ID, 첨부 파일 해시와 거래처를 조합해 한 번 처리한 주문인지 확인해야 합니다. 정식 주문을 만든 뒤에는 ERP 주문번호를 검토 대기 기록에 돌려줍니다.
성공이라는 로그만 남기면 부족합니다. 어느 원본에서 어떤 주문번호를 만들었는지 연결되어야 담당자가 중복과 누락을 찾을 수 있습니다.
예외 화면이 자동화의 품질을 결정합니다
AI가 모르는 주문은 반드시 생깁니다. 새 고객, 처음 보는 제품명, 손으로 수정한 PDF와 한시적인 할인 조건이 들어옵니다.
담당자에게 원본 주문서 전체를 다시 읽으라고 하면 자동화의 이점이 사라집니다. 예외 화면에는 다음 정보가 바로 보여야 합니다.
- 문제가 된 필드와 원문 위치
- AI가 선택한 값과 다른 후보
- 검증을 통과하지 못한 이유
- 과거에 같은 거래처가 사용한 값
- 승인, 수정, 반려 중 담당자가 할 수 있는 행동
사람이 수정한 결과는 기록합니다. 다만 수정값을 곧바로 모델 학습에 넣지는 않습니다. 일회성 예외인지 반복되는 규칙인지 먼저 구분해야 합니다.
첫 자동화는 가장 많이 오는 주문서 한 종류로 시작합니다
거래처마다 양식이 다르고, 한 회사에서도 주문 방식이 바뀝니다. 모든 문서를 한 번에 처리하려고 하면 검증 규칙도 함께 복잡해집니다.
처음에는 주문량이 많고 양식이 비교적 안정적인 거래처 하나를 고르는 편이 좋습니다. 최근 주문서를 모아 정상 주문뿐 아니라 취소, 변경, 중복 발송과 손글씨 수정 사례도 함께 시험합니다.
그다음에 확인할 것은 문서 인식률보다 운영 결과입니다.
- 담당자가 다시 입력한 필드가 얼마나 줄었는가
- 검토 대기 주문이 이유별로 분류되는가
- 중복 주문이 정식 ERP 데이터에 들어가지 않았는가
- 잘못 승인된 주문을 원본까지 추적할 수 있는가
- 자동화가 멈췄을 때 사람이 기존 방식으로 처리할 수 있는가
AI 주문서 자동 입력은 충분히 실용적인 업무입니다. 다만 완성 기준은 문서를 읽었다는 데 있지 않습니다. 회사가 책임질 수 있는 주문만 정식 데이터로 넘기고, 나머지를 사람이 빠르게 판단할 수 있을 때 자동화가 운영에 들어갈 수 있습니다.
프로젝트 문의
이메일과 첨부 주문서를 ERP에 반복 입력하고 있다면 AI 모델부터 고르기보다 실제 주문 양식과 예외를 먼저 확인해야 합니다. MOSH는 고객·제품 매칭, 검증 규칙, 승인 화면과 ERP 연결 범위를 작은 PoC로 나눠 기술 타당성을 검토합니다.
참고 자료
#AI #ERP #주문서자동화 #문서AI #제조업자동화