발주서를 PDF로 받는다고 해서 모두 같은 방식으로 자동화할 수 있는 것은 아닙니다. 문자 선택이 가능한 PDF와 스캔본·사진 PDF는 처리 방식이 완전히 다릅니다. 특히 스캔 발주서는 단순한 ‘PDF → Excel 변환’이 아니라 OCR 인식 → 항목 구조화 → 품번 매핑 → 값 검증 → 예외 검토 → ERP용 데이터 생성까지 이어져야 실제 업무 자동화가 됩니다.
이 글에서는 스캔 PDF·사진 발주서를 자동 처리하려는 기업이 개발 전에 반드시 확인해야 할 항목과, OCR만 붙였을 때 왜 실무에서 오류가 남는지 정리합니다.
발주서 OCR 자동화란?
OCR(Optical Character Recognition)은 이미지에 있는 글자를 문자 데이터로 바꾸는 기술입니다. 하지만 발주 업무에서는 글자를 읽는 것만으로는 충분하지 않습니다.
예를 들어 OCR이 다음 문장을 읽었다고 해도:
- AB-102 / SUS BRACKET / 25EA / 3,500
- 납기 2026-09-12
시스템은 각각을 거래처 품번, 품명, 수량, 단가, 납기일로 정확히 분리해야 합니다. 이후 내부 품번으로 매칭하고 수량·단가 형식을 검증한 뒤 ERP 업로드용 열 순서로 다시 만들어야 합니다.
즉 실무에서 필요한 것은 OCR 자체가 아니라 문서 인식 이후의 업무 규칙까지 포함한 파이프라인입니다.
먼저 확인할 것: 문자 PDF인가, 스캔 PDF인가?
가장 먼저 해야 할 일은 발주서 파일을 두 종류로 나누는 것입니다.
| 구분 | 특징 | 자동화 방식 |
|---|---|---|
| 문자 PDF | 마우스로 글자를 선택·복사할 수 있음 | 텍스트 추출 후 표 구조화 |
| 스캔·사진 PDF | 페이지 전체가 이미지처럼 되어 있음 | OCR + 레이아웃 분석 + 검증 필요 |
문자 PDF는 비교적 규칙 기반 자동화가 잘 맞습니다. 반면 스캔본은 해상도, 회전, 표 선, 도장, 손글씨, 팩스 노이즈 등에 따라 인식률이 크게 달라질 수 있습니다.
SearchesOTD의 발주서 → Excel 표준 변환기는 문자 추출이 가능한 PDF·Excel·CSV를 빠르게 표준화하는 용도입니다. 이미지로만 된 스캔 PDF는 일부러 지원 대상으로 두지 않았습니다. 인식이 불확실한데도 정상 결과처럼 보여주는 것보다, OCR이 필요한 문서는 별도 흐름으로 분리하는 편이 안전하기 때문입니다.
발주서 OCR 자동화 전에 확인할 6가지
1. 거래처별 문서 형식이 몇 개인가
거래처가 5곳이고 양식이 거의 고정되어 있다면 규칙 기반으로 빠르게 안정화할 수 있습니다. 반대로 거래처가 수십~수백 곳이고 Excel·사진·스캔 PDF·손글씨가 섞이면 문서 분류와 예외 처리 설계가 먼저 필요합니다.
실제로 2026년 위시켓에 공개된 한 프로젝트는 약 200개 거래처의 Excel·Image 발주서를 자동 인식해 거래명세서를 생성하는 과제를 제시했고, 예상 금액 2,000만원·예상 기간 90일로 등록됐습니다. 이는 시장 평균 가격이 아니라 해당 발주자가 공개한 예상 범위이지만, 거래처 양식 수가 커질수록 문제가 단순 OCR을 넘어선다는 점을 보여줍니다. 공개 프로젝트 보기
2. 어떤 값을 반드시 뽑아야 하는가
OCR 개발을 시작하기 전에 출력 열부터 정해야 합니다. 예를 들어 다음처럼 표준 필드를 먼저 고정합니다.
- 거래처명
- 발주번호
- 발주일
- 거래처 품번
- 품명·규격
- 수량
- 단가
- 납기일
- 납품처
필드 정의가 없으면 OCR 결과가 아무리 좋아도 ERP나 후속 Excel 작업에 바로 연결되지 않습니다.
3. 0/O, 1/I 같은 오인식을 어떻게 처리할 것인가
품번에서는 문자 하나가 틀리면 전혀 다른 자재가 될 수 있습니다. 예를 들어 AB0-101과 ABO-101을 임의로 같은 값으로 처리하면 안 됩니다.
따라서 자동화 시스템은 ‘무조건 수정’보다 다음 방식이 안전합니다.
- 정확히 일치하면 자동 승인
- 후보가 하나면 사용자 확인
- 후보가 여러 개면 예외 목록으로 분리
- 일치 항목이 없으면 신규 품번 또는 매핑 필요로 표시
거래처 품번과 내부 품번이 별도로 운영된다면 거래처 품번 → 내부 품번 자동 매핑 도구처럼 매핑 테이블을 독립적으로 관리하는 구조가 유리합니다.
4. 숫자와 날짜에 검증 규칙이 있는가
수량 10을 1.0으로 읽거나, 단가의 쉼표를 잘못 해석하면 OCR 성공처럼 보이면서 실제 업무 오류가 발생합니다. 납기일 역시 거래처마다 9/12, 2026.09.12, SEP-12처럼 표기가 다를 수 있습니다.
그래서 OCR 뒤에는 최소한 다음 검증이 필요합니다.
- 수량이 숫자인지
- 음수·0 수량이 허용되는지
- 단가와 합계가 일치하는지
- 날짜가 실제 날짜인지
- 필수 품번이 비어 있지 않은지
- 발주번호 중복 여부
5. 사람이 확인해야 할 예외를 남겨둘 것인가
좋은 자동화는 모든 문서를 100% 무인 처리한다고 주장하는 시스템이 아닙니다. 확실한 데이터는 자동으로 통과시키고, 애매한 데이터만 사람이 보는 구조가 현실적입니다.
예를 들어 OCR 신뢰도가 낮거나 품번 매칭에 실패한 행만 ‘검토 필요’ 시트로 분리하면 담당자는 전체 300행을 다시 보는 대신 5~10행만 확인하면 됩니다.
이 방식은 자동화 도입 초기에 특히 중요합니다. 문서 유형이 늘어나도 오류를 숨기지 않고 확인 가능한 형태로 운영할 수 있기 때문입니다.
6. ERP에 바로 입력할 것인가, 업로드 파일까지만 만들 것인가
처음부터 ERP 자동 입력까지 연결하면 권한, API, 중복 등록, 실패 복구, 감사 로그 같은 문제가 한꺼번에 생깁니다. 그래서 초기에는 다음처럼 단계적으로 시작하는 편이 안전합니다.
- 문서에서 데이터 추출
- 내부 품번 매칭
- 검증 및 예외 표시
- ERP 공식 업로드 양식으로 변환
- 담당자가 검토 후 ERP에 업로드
이 구조를 시험하려면 ERP 업로드용 Excel 열 매핑 변환기를 사용할 수 있습니다. 원본 Excel과 ERP 공식 업로드 템플릿을 넣고 어떤 열을 어디로 보낼지 먼저 확인하는 도구입니다.
권장 구조: OCR부터 ERP까지 한 번에 연결하지 마세요
스캔 발주서 자동화는 다음 파이프라인으로 나누면 관리가 쉬워집니다.
메일·폴더 수신 → 파일 형식 분류 → OCR 또는 텍스트 추출 → 표준 필드 변환 → 거래처 품번 매핑 → 수량·단가·날짜 검증 → 예외 검토 → ERP 업로드 Excel/CSV 생성
이렇게 단계를 분리하면 어느 지점에서 오류가 발생했는지 바로 알 수 있습니다. 거래처 양식이 추가되어도 전체 프로그램을 다시 만드는 대신 문서 인식 규칙이나 매핑 테이블만 보강할 수 있습니다.
실제 공개 프로젝트에서도 OCR 뒤의 업무 흐름이 핵심입니다
2025년 공개된 또 다른 위시켓 프로젝트는 다양한 발주서를 정리하고 이카운트 ERP 견적 등록·문서 비교까지 연결하는 시스템을 예상 금액 1,500만원·예상 기간 60일로 제시했습니다. 이 역시 실제 계약 금액이나 시장 평균이 아니라 발주자가 공개한 예상 조건입니다. 공개 프로젝트 보기
두 사례에서 공통적으로 보이는 것은 OCR 자체보다 문서 구조화, ERP 연결, 비교·검증, 여러 양식 대응이 프로젝트 범위를 키운다는 점입니다.
자동화 상담 전에 준비하면 좋은 샘플
개발 가능 여부를 빠르게 판단하려면 아래 자료를 준비하는 것이 좋습니다.
- 실제 발주서 5~20개: 거래처별로 서로 다른 양식 포함
- 스캔본과 문자 PDF를 구분한 샘플
- 현재 사람이 작성하는 결과 Excel
- 거래처 품번 ↔ 내부 품번 매핑표
- ERP 공식 업로드 양식
- 반드시 사람이 확인해야 하는 업무 규칙
개인정보·계좌정보·불필요한 고객정보는 제거한 샘플을 사용하는 것을 권장합니다.
먼저 무료도구로 자동화 가능한 구간을 확인해보세요
모든 발주서가 OCR을 필요로 하는 것은 아닙니다. 문자 PDF·Excel·CSV가 대부분이라면 훨씬 단순한 구조로 시작할 수 있습니다.
스캔 PDF·사진·손글씨 비중이 높거나 거래처 양식이 지나치게 다양하다면 무료도구만으로 억지로 처리하기보다, 실제 샘플을 기준으로 자동화 가능 구간과 예외 처리 방식을 먼저 설계하는 편이 낫습니다.
실제 업무를 기준으로 자동화 범위를 확인하고 싶다면 업무 자동화 무료 진단에서 샘플과 현재 작업 흐름을 보내주세요. 현재 업무 → 자동화 가능한 단계 → 사람이 남겨야 할 검토 단계 순으로 정리해드립니다.