공급처 청구서를 신뢰할 수 있는 데이터로 바꾸는 인보이스 OCR
청구서 재입력은 이제 그만. 선언한 필드로 거래처·번호·날짜·합계·품목을 읽어내고, 모든 값을 box·quad 좌표와 verified 판정, 그리고 확인 대상을 모은 data.review.flagged 와 함께 반환합니다.
받은편지함에 들어오는 청구서는 하나하나가 작은 입력 노동입니다. 누군가 PDF를 열어 거래처, 청구서 번호, 날짜, 세금 줄, 합계를 찾아 회계 시스템에 다시 입력합니다 — 품목이 필요하면 그것도 손으로 옮기죠. 느리고, 오타가 생기는 자리이며, 합계 하나만 잘못 쳐도 지급 처리가 멈춥니다.
인보이스 OCR은 원래 그 일을 대신해 줘야 합니다. 청구서를 읽어 필드를 돌려준다는 거죠. 문제는 대부분의 도구가 숫자를 건네며 그냥 믿으라고 한다는 점입니다. space-ocr는 선언한 필드로 청구서를 읽어내고, 모든 값을 페이지에서 읽어낸 영역과 함께 돌려줍니다 — 대조를 통과하지 못한 값을 모은 검토 목록도 함께요. 지급을 승인하기 전에 확인할 것은 페이지 전체가 아니라 그 몇 건입니다.
직접 확인할 수 있는 실제 청구서
아래 어느 항목이든 마우스를 올려 보세요 — 청구서 위의 박스가 그 값을 읽어낸 지점입니다. 거래처·발행일·청구 기간·지급 기한·청구 금액·합계, 그리고 각 품목은 모두 실제 파싱 결과에서 읽어온 것으로, 목업이 아닙니다.
Each value with a box carries a verified on-page location — in data.cells[path], that is box + 4-point quad + evidence.match_ratio — on a 0–1000 normalized grid (0,0 top-left → 1000,1000 bottom-right), the same shape the live API returns. Hover a field to trace it back to the pixels it came from.
space-ocr의 인보이스 OCR 작동 방식
앱에 청구서를 끌어다 놓으면 하나의 행으로 읽힙니다 — 거래처·날짜·금액, 그리고 품목은 정렬·필터·내보내기가 되는 하위 표로요. PDF 청구서는 먼저 페이지마다 이미지로 렌더링된 뒤 읽힙니다. API를 직접 호출한다면 페이지 이미지를 보내세요(공개 API는 래스터 이미지를 받습니다 — JPEG·PNG·GIF·BMP·TIFF·WebP). 돌아오는 구조화 결과는 동일합니다.
청구서를 처음부터 기술할 필요도, 템플릿을 고를 필요도 없습니다. 회계에서 쓰는 이름을 그대로 fields 로 보내고 청구서에 맞는 검사를 붙이거나, 처음 보는 양식이면 autoFields 를 보내고 돌아온 이름을 그대로 선언으로 씁니다. 품목은 children 을 가진 array 필드 하나입니다.
청구서 한 장에서 돌아오는 것:
data.values— 선언한 형태 그대로의 업무 데이터.data.cells[path]— 그 값의box와quad, 그리고verified·review·evidence(문자 대조 근거로text_match·printed_text·match_ratio를 포함).data.review.flagged— 검토 목록. 항목마다path와reasons가 있고reasons는 랭킹 순이라 0번이 대표입니다.data.normalized— 스칼라 타입을 선언한 필드의 파싱된 수치와 ISO 날짜.data.image— 모든 좌표가 기준으로 삼는 폭과 높이.
curl -s https://api.space-ocr.com/ocr/fields \
-H "Authorization: Bearer $SPACE_OCR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"image": "https://example.com/invoice-page-1.png",
"imageType": "url",
"fields": [
{ "name": "supplier", "type": "string", "required": true, "not_near": ["Bill To", "御中"] },
{ "name": "bill_to", "type": "string", "near": ["Bill To", "御中"] },
{ "name": "invoice_no", "type": "string", "required": true, "pattern": "^[A-Za-z0-9-]{4,}$" },
{ "name": "issue_date", "type": "date", "required": true },
{ "name": "due_date", "type": "date" },
{ "name": "subtotal", "type": "number", "min": 0 },
{ "name": "tax", "type": "number", "min": 0 },
{ "name": "total", "type": "number", "required": true, "min": 0 },
{
"name": "items", "type": "array",
"children": [
{ "name": "description", "type": "string" },
{ "name": "quantity", "type": "number" },
{ "name": "unit_price", "type": "number" },
{ "name": "amount", "type": "number" }
]
}
]
}'청구서를 OCR하는 방법
- 청구서 추가앱에 청구서(PDF 또는 이미지)를 끌어다 놓으면 각 페이지가 이미지로 렌더링되어 OCR 대기열에 들어갑니다. AP 자동화에서는 /upload에 보내고 읽기가 끝나면 웹훅을 받습니다.
- 필드 선언회계에서 쓰는 이름을 그대로 fields 로 보내고 청구서에 맞는 검사를 붙입니다 — 청구서 번호에 required, 날짜에 type date, 금액에 type number 와 min. 처음 보는 양식이면 autoFields 를 보내고 돌아온 이름을 선언으로 씁니다. 품목은 children 을 가진 array 필드 하나입니다.
- 구조화 결과 읽기업무 데이터는 data.values 에 있습니다. 좌표와 값별 판정은 data.cells[path](box·quad·verified·review·evidence)에 있고, 그 좌표의 기준 지면은 data.image 가 알려 줍니다.
- 장부에 올리기 전에 검증점수 임계값 대신 data.review.flagged 를 순회합니다. 항목마다 path 와 reasons 가 있으니 data.cells[path] 로 이동해 box 나 quad 를 사진 위에 강조하고 값을 고칩니다. 수정 사항은 원본 OCR 값 옆에 저장됩니다.
- 내보내기 또는 조회회계 가져오기용으로 CSV(UTF-8 BOM, 품목 펼쳐짐)를 내려받거나, 저장된 시트를 GET /view로 where·sort·select를 써서 조회합니다 — OCR 재실행도 추가 비용도 없습니다.
단순하고 예측 가능한 가격
1페이지 처리가 1크레딧 — ₩100(부가세 포함)이고, 앱에서 올리든 API로 부르든 같은 가격입니다. 모든 계정에 매월 100크레딧 무료 한도가 있고 카드 등록은 필요 없으며, 실패는 과금하지 않습니다. 정액 플랜은 월 크레딧 수·시트·저장공간을 추가합니다.