레이아웃이 어떻든, 인보이스 데이터를 Excel로 추출하는 방법

매달 거래처 인보이스가 받은 편지함을 가득 채운다면, 이미 그 과정을 잘 아실 겁니다. PDF를 하나씩 열어 인보이스 번호, 날짜, 합계를 찾고, 모든 항목 내역을 복사해 스프레드시트에 일일이 입력합니다. 그러고는 다음 거래처를 위해 똑같은 일을 반복하죠 — 이번 인보이스는 앞서 본 것과 전혀 닮지 않았는데도 말입니다.

바로 그 마지막 부분이 진짜 문제입니다. 인보이스의 양이 아니라, 어떤 두 거래처도 같은 방식으로 양식을 만들지 않는다는 점이 문제죠. 합계는 매번 다른 위치에 있고, 날짜 표기 방식도 다르며, 항목 내역 표의 열 구성도 제각각입니다. 사람은 별생각 없이 각 인보이스에 적응합니다. 하지만 대부분의 소프트웨어는 그러지 못합니다 — 그래서 수많은 팀이 결국 포기하고 모든 것을 손으로 다시 입력하고 마는 것이죠.

이 글에서는 거래처마다 별도의 템플릿을 만들고 유지하지 않고도 인보이스 데이터를 어떤 레이아웃에서든 깔끔한 Excel, CSV, JSON으로 뽑아내는 방법을 단계별로 살펴봅니다.

인보이스 추출이 보기보다 어려운 이유

고정된 단일 인보이스 템플릿 하나라면 쉽습니다. 문제는 그런 경우가 거의 없다는 데 있죠. 인보이스가 깔끔한 추출을 거부하는 몇 가지 이유를 보면 다음과 같습니다.

• 거래처마다 레이아웃이 다릅니다. 인보이스 번호, 청구 주소, 합계가 어디에 위치해야 하는지에 대한 업계 표준은 없습니다. 한 거래처에 맞춰 설정한 템플릿은 새 거래처가 첫 인보이스를 보내는 순간 무너집니다.
• “그 금액”이라는 말은 모호합니다. 하나의 인보이스에는 소계, 세금, 배송비, 할인 전 합계, 최종 청구액이 함께 담기며 — 종종 서로 바로 옆에 나란히 놓여 있습니다. 어느 것인지 명시하지 않고 “그 금액”을 가져오라고 하면, 엔진이 추측한 값이 그대로 나옵니다.
• 항목 내역은 값이 아니라 목록입니다. 인보이스마다 인보이스 번호는 하나지만 항목 내역은 여러 개이며, 각각 고유한 설명, 수량, 단가, 항목 합계를 가집니다. 이를 잘못 펼치면 깔끔한 행을 원했던 자리에 뒤죽박죽 엉킨 결과가 나옵니다.
• PDF, 스캔본, 사진. PDF로 이메일로 받은 인보이스는 깔끔한 텍스트입니다. 같은 인보이스를 프런트에서 스캔하거나 휴대폰으로 찍으면 이미지가 되죠 — 이제는 무언가를 추출하기 전에 OCR이 필요하고, OCR은 그 나름의 오류를 동반합니다.

“인보이스를 그냥 추출해 준다”고 주장하는 어떤 도구든 이 모든 것에 대한 답을 가지고 있어야 합니다. 수작업의 괴로움은 단 하나의 인보이스가 아니라 바로 그 다양함 속에 있습니다.

흔히 쓰는 접근법, 그리고 각각이 한계에 부딪히는 지점

정답인 도구가 하나로 정해져 있지는 않습니다 — 결국 거래처가 얼마나 많은지, 그리고 그 레이아웃이 얼마나 일관적인지에 달려 있습니다.

손으로 직접 입력하기. 준비 과정이 전혀 없고, 신중하기만 하면 정확하지만, 확장성은 전혀 없습니다. 한 달에 몇 건이라면 괜찮지만, 여러 거래처에서 수십 건씩 처리하기 시작하면 애초에 불가능한 방식입니다.

템플릿 기반 파서. 각 필드가 페이지의 어디에 위치하는지 한 번 정의해 둡니다. 모든 인보이스가 똑같이 생겼다면 빠르고 저렴합니다. 하지만 거래처마다 다르기 때문에, 결국 거래처별로 템플릿을 만들고 유지하게 되고 — 거래처가 레이아웃을 손보는 날이면 다시 만들어야 합니다. 꾸준한 거래처가 서너 곳이라면 괜찮습니다. 하지만 길고 계속 바뀌는 거래처 목록 앞에서는 설정 비용이 절약한 시간을 다 잡아먹습니다.

자연어 추출. 위치를 표시하는 대신, 원하는 필드를 일상적인 언어로 설명하면 엔진이 각 레이아웃에 맞춰 적응합니다. 이 방식은 “거래처마다 다르다”는 문제를 정면으로 다루며, 스캔본이나 특이한 양식에도 훨씬 너그럽습니다. 절충점이 있다면, 출력 결과를 검증할 수 있게 해 주는 도구를 골라야 한다는 점입니다 — 고정된 좌표가 아니라 페이지를 읽어내는 모델을 신뢰하는 것이니까요.

Ztract는 바로 이 마지막 범주에 속하므로, 구체적으로 하나하나 살펴보겠습니다.

따라 하기: Ztract에서 인보이스를 Excel로

전체 흐름을 소개합니다 — 인보이스 한 장을 처리하든, 열두 곳의 거래처에서 온 쉰 장짜리 폴더를 처리하든 과정은 동일합니다.

1. 프로젝트를 만들고 원하는 것을 설명합니다

프로젝트는 관련 문서들과 거기에 적용할 스키마를 담는 컨테이너일 뿐입니다. 인보이스의 경우, 스키마를 정의하는 방법은 세 가지가 있습니다.

• 준비된 인보이스 스키마에서 시작해 조정하기. 가장 빠른 출발점입니다 — 인보이스 번호, 날짜, 거래처 정보, 합계, 항목 내역을 이미 알고 있습니다.

• 필드를 일상적인 언어로 설명하기. 예를 들면 다음과 같습니다.

  “각 인보이스에서 인보이스 번호, 발행일, 거래처 이름, 그리고 (세금과 할인을 반영한) 최종 청구액을 추출하세요. 그런 다음 각 항목 내역에 대해 설명, 수량, 단가, 항목 합계를 추출하세요. 어떤 필드가 없으면 추측하지 말고 비워 두세요.”

  여기서 두 가지를 눈여겨보세요. “(세금과 할인을 반영한) 최종 청구액” 이라는 표현은 여러 금액 중 어느 것을 말하는지 엔진에게 정확히 알려 줍니다. 그리고 “각 항목 내역에 대해” 라는 말은 항목 내역을 반복되는 목록으로 표시해, 모든 것이 한 셀에 뭉뚱그려지는 대신 깔끔한 행으로 돌아오게 합니다. 믿을 만한 인보이스 출력과 엉망인 출력을 가르는 것은 거의 이 두 가지 습관입니다.

• 샘플로부터 추론하기. 대표적인 인보이스 한 장을 넣으면 Ztract가 그로부터 스키마를 제안합니다. 새 거래처의 인보이스에 예상치 못한 필드가 있을 때 유용합니다.

핵심 이점은 이렇습니다. 동일한 스키마가 여러 거래처에 걸쳐 작동한다는 점이죠. 데이터가 놓인 위치가 아니라 원하는 데이터 자체를 설명하는 것이므로 — 한 번도 본 적 없는 레이아웃도 이미 본 레이아웃과 똑같이 처리됩니다. 거래처별 템플릿은 필요 없습니다.

2. 인보이스를 업로드합니다

파일을 끌어다 놓으세요 — PDF, Word, Excel, 스캔본, 휴대폰 사진까지, 파일당 500 MB까지 가능합니다. 텍스트 기반 PDF와 이미지 기반 스캔본 모두 작동하며, 스캔본은 먼저 OCR을 거칠 뿐입니다. 한 달 치 인보이스가 서로 다른 거래처에서 별개의 파일로 도착하더라도, 한꺼번에 업로드하면 같은 스키마가 모든 파일에 적용됩니다.

3. 검토하고 수정하기 — 실제로 시간을 아껴 주는 단계

사람들이 과소평가하는 점이 바로 이것입니다. 인보이스에서는 추출이 아니라 검토가 시간을 잡아먹습니다. 출력 결과를 믿을 수 없으면, 결국 모든 인보이스를 스프레드시트와 다시 대조하게 되고, 그러면 아낀 게 하나도 없게 됩니다.

Ztract는 바로 그 점을 중심으로 설계되었습니다. 추출된 모든 값은 원본 문서상의 정확한 위치에 연결되어 있습니다. 결과에서 숫자를 클릭하면 인보이스의 어느 위치에서 가져온 값인지 강조 표시됩니다. 검토를 빠르게 만들어 주는 것이 바로 그 나란히 보기 화면입니다. 모든 필드를 다시 확인하는 대신, 이상해 보이는 항목만 훑어보면 됩니다 — 소계를 잘못 가져온 합계, 두 행을 하나로 합쳐 버린 항목 내역 같은 것들 — 그리고 클릭 한 번으로 고치면 됩니다.

그리고 저희는 추출에 대해서만 요금을 부과하므로, 값을 수정하는 데는 비용이 전혀 들지 않습니다. 이후의 편집은 무료이며, 추출한 페이지만 패키지에서 차감될 뿐, 정리 작업은 차감되지 않습니다.

4. 내보내기

결과가 만족스러우면 Excel, CSV, JSON으로 내보내세요 — 인보이스 한 장이든 프로젝트 전체든 한 번에 가능합니다. 거기서부터 바로 매입 채무 워크플로, 회계 소프트웨어의 가져오기, 혹은 그 숫자들이 다음으로 가야 할 어디로든 곧장 들어갑니다.

여전히 사람의 눈이 필요한 경우들

까다로워지는 지점이 없는 척하기보다는, 어디서 까다로워지는지를 알려 드리는 편이 낫다고 생각합니다. 주의할 몇 가지 상황입니다.

• 대변표(크레딧 노트)와 환불. 대변표는 인보이스처럼 보이지만 금액이 반대 방향으로 흐릅니다. 음수 금액을 어떻게 처리할지 스키마에 명시하고, 검토 단계에서 부호를 다시 한번 확인하세요.
• 여러 통화를 쓰는 거래처. 서로 다른 통화로 거래하는 거래처에서 구매한다면, 배치 전체에 하나의 통화를 가정하지 말고 인보이스마다 통화를 별도 필드로 담으세요 — 그러지 않으면 “1,000”이라는 합계는 아무것도 말해 주지 않습니다.
• 심하게 손상된 스캔본. 팩스로 보낸 뒤 다시 스캔해 인쇄가 흐릿해진 인보이스는 OCR을 포함해 누구에게나 읽기 어렵습니다. 원본이 사람 눈에도 알아볼 수 없을 정도라면, 더 꼼꼼히 검증할 각오를 하세요 — 사후에 아무리 수정하는 것보다 깨끗한 스캔본 하나가 낫습니다.

마땅히 처리되어야 할 레이아웃인데 잘못된 결과가 나온다면, 저희는 정말로 그것을 보고 싶습니다 — 샘플(필요하면 익명 처리해서)을 support@ztract.com으로 보내 주시면 파고들겠습니다. 사람들이 보내 주는 문서들이야말로 엔진이 더 나아지는 방법입니다.

거래처 데이터에 대한 참고 사항

인보이스에는 민감한 상거래 정보가 담깁니다 — 누구에게서 구매하는지, 얼마를 지불하는지, 계좌번호는 무엇인지 — 그래서 분명히 짚고 넘어갈 가치가 있습니다. 저희는 여러분이 업로드한 문서로 모델을 학습시키지 않습니다. 저희 자체 엔진도, 저희가 거쳐 가는 제3자 LLM도 마찬가지입니다. 저희가 사용하는 상용 API들은 제출된 데이터로 학습하는 것을 금지하고 있으며, 저희는 그 약속에 의존합니다. 인보이스를 삭제하면 활성 저장소에서 즉시 사라지고, 백업에서는 14일 이내에 삭제됩니다. 전체 내용은 개인정보 처리방침과 데이터 처리 계약에 담겨 있습니다.

직접 가진 인보이스로 시험해 보세요

이 방식이 여러분의 워크플로에 맞는지 알아보는 가장 빠른 방법은, 어차피 손으로 입력했을 실제 인보이스 몇 장으로 직접 돌려 보는 것입니다 — 가급적 서로 다른 거래처에서 온 것으로요. 그래야 동일한 스키마가 서로 다른 레이아웃을 처리하는 모습을 볼 수 있습니다. 새 계정에는 무료 30페이지가 제공되며 신용카드도 필요 없습니다 — 한 묶음을 처음부터 끝까지 추출하고 합계를 직접 확인해 보기에 충분합니다.

그리고 인보이스를 대량으로 처리하시면서 무엇이 잘되고 무엇이 안됐는지 솔직한 피드백을 나눠 주실 수 있다면, 연락 주세요 — 저희는 초기 사용자들을 모시고 있으며, 사람들이 실제로 어려움을 겪는 문서들을 중심으로 다음에 무엇을 만들지 다듬어 가고 있습니다. 인보이스는 그 목록의 맨 위에 있습니다.

인보이스 데이터 추출에 대해 더 알아보려면 인보이스 데이터 추출 활용 사례 페이지를 확인해 보세요.