데이터 추출이
작업의 절반에 불과한 이유

문서 추출이 실제로 제공하는 것 — 그리고 제공하지 않는 것

요점은 간단합니다. 40줄짜리 청구서가 PDF로 도착합니다. 업로드하면 AI가 모든 청구 항목(설명, 수량, 단가, 행 합계)을 읽고 이미 열이 라벨링된 스프레드시트를 출력합니다. 마케팅 용어로는 "엔드투엔드 자동화"입니다. 회계 용어로는 출발 신호탄입니다.

추출 후 스프레드시트에 실제로 들어 있는 것은 페이지에 표시된 그대로의 원시 값이기 때문입니다. 수량 열에는 숫자가 있습니다. 단가 열에는 숫자가 있습니다. 행 합계 열에는 숫자가 있습니다. 하지만 아무도 — AI도, 추출 엔진도 — 수량 × 단가가 실제로 청구서에 인쇄된 행 합계와 일치하는지 검증하지 않았습니다. 아무도 20개 행 합계를 모두 합산하여 마지막 페이지의 소계와 비교하지 않았습니다. 아무도 소계에 적용된 세금 비율이 공급업체가 기재한 세금 금액을 산출하는지 확인하지 않았고, 숫자가 맞지 않을 때 "검토 필요"로 표시하지도 않았습니다.

추출 도구는 데이터를 제공했습니다. 검증된 데이터를 제공한 것은 아닙니다. 그리고 이 두 가지 사이의 간격 — "숫자가 Excel에 있다"와 "숫자가 정확하고 총계정원장에 반영할 준비가 되었다" 사이의 간격 — 에서 실제 시간이 사라집니다.

수동 데이터 입력보다 비용이 더 많이 드는 스프레드시트 수식

청구서 데이터 추출 도구는 "숫자 입력" 단계를 페이지당 3분에서 약 5~10초로 줄였습니다. 이는 확실한 개선입니다. 하지만 PDF 도착부터 "게시 준비 완료"까지 전체 워크플로우에 스톱워치를 대면, 대부분의 도구 비교가 포착하지 못하는 시간 분포의 변화가 나타납니다.

AI 추출 후의 일반적인 청구서 처리 워크플로우에는 최소 네 가지 유형의 수식 작업이 포함됩니다. 각각은 개별적으로 작습니다 — 여기 열 하나, 저기 SUM 하나 — 하지만 collectively 이들은 아무도 예산에 잡지 않는 반복적인 스프레드시트 조립 라인을 형성합니다:

• 행 합계 검증. 청구서의 각 행에 대해 E열에 =C2*D2가 필요합니다 — 수량 곱하기 단가 — 그리고 F열에 인쇄된 행 합계와 비교해야 합니다. 품목이 15개인 청구서 한 장은 곱셈 수식 15개와 비교 수식 15개를 의미합니다. 월 200장의 청구서라면, 드래그하고 표본 점검해야 할 수식 셀이 6,000개가 됩니다.
• 소계 대조. 개별 행을 검증한 후 계산된 행 합계를 합산하여 인쇄된 소계와 비교합니다. 그런 다음 세율을 적용하고(관할 구역이나 품목에 따라 다를 수 있음 — 일부 품목은 과세 대상이고 일부는 아님) 인쇄된 세금 금액과 비교합니다. 그런 다음 소계에 세금을 더해 청구서 총액과 비교합니다. 세율이 분리된 여러 페이지 청구서의 경우, 이는 단순한 SUM 수식이 아닙니다. 상위 값이 하나라도 틀리면 깨지는 상호 의존적인 계산 체인입니다.
• 조건부 플래그. 청구서 총액이 PO 금액을 초과합니까? 지급 기한이 7일 이내입니까(긴급 승인 플래그)? 공급업체가 선호 공급업체 목록에 있습니까? 이 각각은 조건부 수식입니다 — =IF(F2>G2,"OVER BUDGET","") — 누군가 작성하고 서식을 지정하고 모든 행에 드래그합니다.
• 표준화 수식. 날짜는 가능한 모든 형식으로 도착합니다: 06/15/2026, 15-Jun-2026, 20260615. 통화 금액은 공급업체 국가에 따라 소수점 쉼표와 마침표가 섞여 있습니다. 누군가 =DATEVALUE() 래퍼와 =SUBSTITUTE() 체인을 작성하여 회계 시스템에 들어가기 전에 모든 것을 정규화합니다.

이 작업 중 어느 것도 추출이 아닙니다. AI는 이미 올바른 숫자를 추출했습니다. 그러나 이러한 계산이 완료될 때까지 숫자는 사용할 수 없습니다 — 그리고 대부분의 조직에서 계산 작업량은 보이지 않습니다. 이는 회의 사이 15분 단위로 Excel에서 이루어지며, 직무 설명에 "스프레드시트 수식 기술자"가 포함되지 않은 사람들이 수행합니다. 작업은 완료되지만, 시간이 얼마나 걸리는지 추적하는 사람은 없습니다 — 그리고 그것이 필요한지 묻는 사람도 없습니다.

중견기업 AP(매입채무) 담당자가 월 200장의 청구서를 처리하고 청구서당 평균 8분을 추출 후 수식 작업(검증 열 작성, 수식 드래그, 소계 대조)에 사용한다면, 데이터를 추출하지만 아무것도 계산하지 않는 작업에 월 26시간을 소비하는 셈입니다. BLS 기준 부기 담당자 중간 임금 $23.33/시간으로 계산하면, 수식 작성 인건비만 월 $600 이상입니다. 담당자 3명으로 구성된 팀이라면 월 $1,800 — 연간 $21,600 — 을 추출 중에 계산이 이루어졌다면 불필요했을 Excel 수식에 지출하는 것입니다.

문서 추출 업계가 추출을 완료 지점으로 여기는 이유

시장을 지배하는 도구들 — 템플릿 기반 OCR, 머신러닝 분류기, 대형 비전 모델 — 은 모두 단일 엔지니어링 문제를 중심으로 구축되었습니다: "문서 이미지가 주어지면 구조화된 텍스트를 출력한다." 이는 수십 년이 걸려 제대로 해결한 어려운 문제입니다. 이러한 도구를 구축하는 팀은 당연히 해결 방법을 아는 문제를 중심으로 조직됩니다.

그러나 엔지니어의 "완료" 정의 — "텍스트가 데이터베이스 행에 있다" — 는 회계 담당자의 완료 정의 — "숫자가 검증되고 계산되어 총계정원장에 입력할 준비가 되었다" — 와 일치하지 않습니다. 추출 출력은 데이터 산출물입니다. 회계 출력은 재무 산출물입니다. 하나에서 다른 것으로의 변환에는 계산이 필요하며, 추출 업계는 그 계산을 대부분 사용자에게 맡겨 왔습니다.

이는 개별 도구의 실패가 아닙니다. 문제가 정의된 방식의 구조적 공백입니다. 소프트웨어 업계는 문서 처리를 보고 "OCR을 개선해야 한다"고 보았습니다. 더 나은 OCR을 구축했습니다. 그런 다음 "형식이 예측 불가능하다"는 것을 보고 레이아웃에 구애받지 않는 AI를 구축했습니다. 각 반복은 추출을 더 빠르고 정확하게 만들었지만, 각 반복은 또한 추출 후 수식 작업의 부재를 더욱 두드러지게 만들었습니다. 추출에 10초가 걸리고 수식 작업에 여전히 8분이 걸리면 추출 속도는 더 이상 핵심이 아닙니다. 수식 격차가 핵심이 됩니다.

이 격차에 대한 가장 설득력 있는 증거는 AP(매입채무) 팀이 실제로 추출 도구를 사용하는 방식입니다. 그들은 추출합니다. Excel로 내보냅니다. 그런 다음 열을 추가합니다 — 추출이 데이터를 놓쳤기 때문이 아니라 도구가 계산하지 않기 때문입니다. 수량 × 단가 열을 추가합니다. 차이 열을 추가합니다. 승인 플래그 열을 추가합니다. 표준화된 날짜 열을 추가합니다. 회계 시스템으로 보내는 스프레드시트에는 추출 도구가 생성한 것보다 두 배 많은 열이 있습니다. 절반은 추출 출력입니다. 나머지 절반은 화요일 오후 4시에 누군가가 작성한 수식입니다.

계산 공백의 실제 사례: 청구서 합계가 일치하지 않을 때

추출 후 수식이 단지 번거로울 뿐만 아니라 구조적으로 위험한 이유를 이해하려면, AP(매입채무)에서 가장 흔한 대조 실패 사례인 청구서 합계 불일치를 생각해 보십시오.

공급업체가 12개 품목이 포함된 청구서를 보냅니다. 추출 도구는 모든 필드를 정확하게 캡처합니다: 12개의 설명, 12개의 수량, 12개의 단가, 12개의 행 합계, 1개의 소계, 1개의 세금 금액, 1개의 청구서 합계. 모든 숫자는 원본 문서와 정확히 일치합니다. 그러나 추출된 12개의 행 합계를 합산하면 $3,847이 됩니다. 청구서에 인쇄된 소계는 $3,812입니다. 차이는 $35입니다.

오류는 추출 과정에 있는 것이 아닙니다. 공급업체의 청구서에 있는 것입니다 — 품목 가격이 잘못 책정되었거나, 할인이 일관되지 않게 적용되었거나, 반올림 결정으로 인해 불일치가 발생한 것입니다. 그러나 추출 도구에는 이를 감지할 메커니즘이 없습니다. 공급업체의 숫자를 검증 없이 충실히 재현했을 뿐입니다. 감지는 Excel에서 누군가 =SUM(F2:F13)을 작성하고 이를 F15 셀과 비교할 때 이루어집니다. 아무도 그 수식을 작성하지 않거나 — 수식이 올바르게 작성되었지만 여러 페이지로 구성된 청구서의 첫 페이지에만 적용된 경우 — $35의 차이는 그대로 남습니다. 이 차이는 총계정원장에 입력됩니다. 3개월 후 대조 항목이 되며, 그 시점에 원본 청구서를 찾아 행 산술을 검증하는 데 드는 인건비는 $35 자체보다 더 큽니다.

이 시나리오는 드문 경우가 아닙니다. 계산을 포함하지 않는 모든 추출 워크플로우의 기본 조건입니다. 모든 청구서는 누군가가 스프레드시트에서 수동으로 설정하고 해결해야 하는 수학 문제가 됩니다. 물량이 적을 때는 수학이 관리 가능합니다. 월 200건의 청구서에서는 수학이 공식적으로 할당된 사람이 없는 전일제 작업이 됩니다. 월 500건의 청구서에서는 수학이 위험이 됩니다 — 95%의 시간 동안 잡히는 오류가 나머지 5%에서는 잡히지 않기 때문이며, 통과하는 5%가 중요한 것들이기 때문입니다.

계산 단계를 Excel에서 추출 단계로 이동

문제가 추출이 원시 값을 생성하고 계산이 별도 도구에서 나중에 이루어지는 것이라면, 논리적 해결책은 두 단계를 하나로 통합하는 것입니다. "먼저 추출하고, 나중에 Excel에서 계산"하는 대신, 계산은 추출 순간 — AI가 문서를 읽고 출력 테이블을 작성하는 동안 — 실행됩니다.

이것이 ImageToTable.ai가 계산 열이라고 부르는 기능의 메커니즘입니다. 문서에서 추출하려는 열을 정의할 때 페이지에 존재하는 필드로만 제한할 필요가 없습니다. 계산을 통해 다른 추출 필드에서 파생된 값을 갖는 열을 정의할 수 있습니다. AI가 문서를 읽고, 원본 값을 추출하고, 계산을 수행하고, 결과를 출력에 직접 기록합니다 — 모두 단일 패스로 처리됩니다. 별도의 스프레드시트도, 수식 입력줄도, 셀 끌기도 필요 없습니다.

청구서의 경우 실질적인 적용 사례는 즉각적입니다:

• 행 합계 검증. 계산 열 Computed Line Total (Qty × Unit Price)을 정의합니다. 청구서의 각 품목에 대해 AI가 수량에 단가를 곱하고 결과를 출력합니다. 인쇄된 행 합계 열과 비교하면 — 불일치 사항은 작성하지 않은 수식이 아닌 출력에서 확인할 수 있습니다.
• 소계 대조. 추출된 모든 행 합계를 합산하고 인쇄된 소계와 비교하는 계산 열을 정의합니다. 출력은 원시 숫자가 아니라 대조 결과입니다: "행 합계: $3,847. 인쇄된 소계: $3,812. 차이: $35." 이전에 일련의 Excel 수식이 필요했던 계산이 추출 자체에 내장됩니다.
• 세금 검증. 고정 세율 매개변수를 사용하여 계산 열 Expected Tax (Subtotal × 0.0825)을 정의합니다. 인쇄된 세금 금액과 비교합니다. 공급업체가 잘못된 세율을 적용한 경우, 데이터가 Excel에 도달하기 전에 차이가 표시됩니다.
• 예산 플래그. 청구서 총액이 기준 값을 초과하는지 확인하는 계산 열을 정의합니다: Budget Check (Invoice Total > PO Amount). 출력은 "예산 초과" 또는 "OK"입니다 — 추출 중에 생성된 조건부 플래그로, 이후에 추가되는 것이 아닙니다.

계산 열이 검증의 필요성을 없애는 것은 아닙니다. 검증을 위해 계산할 필요성을 없애는 것입니다. AI가 산술을 수행하고, AP(매입채무) 담당자가 결과를 검토합니다. 이 구분이 중요한 이유는 계산은 기계적인 작업 — 대규모로 수동 수행 시 오류가 발생하기 쉬운 — 이고 검토는 판단 작업으로 인간이 더 잘하기 때문입니다. 계산을 상류로 이동하면 인간은 청구서당 8분을 기계가 할 수 없는 부분에 사용합니다: 차이가 의미하는 바와 취할 조치를 결정하는 일입니다.

이 기능은 두 가지 형태로 제공됩니다. 빠른 사용을 위해 열 이름에 계산식을 직접 작성할 수 있습니다 — Line Total (Qty × Unit Price) — 그러면 AI가 자연어에서 로직을 파싱합니다. 더 복잡한 다단계 파생의 경우, 로그인한 사용자는 구조화된 JSON 규칙 형식으로 계산을 정의하여 열 이름을 깔끔하게 유지하면서 계산 로직을 정확하게 표현할 수 있습니다. 두 접근 방식 모두 동일한 결과를 생성합니다: 추출 중에 계산된 값이 있는 출력 테이블의 열로, 이후에 추가되는 것이 아닙니다. 대량으로 청구서를 처리하는 팀의 경우, 계산 열을 사용한 일괄 청구서 데이터 추출은 이전에 몇 시간의 사후 처리 수식 작업이 필요했던 작업을 업로드가 완료되기 전에 끝나는 작업으로 바꿔줍니다.

자주 묻는 질문

추출 후 수식 작업은 실제로 얼마나 많은 시간이 소요되나요?

월 200건의 청구서를 처리하는 중견기업 AP(매입채무) 팀의 경우, 추출 후 계산(행 합계 검증, 소계 대조, 조건부 플래그, 날짜 표준화)은 청구서당 평균 8분의 수식 작업을 기준으로 월 약 25~30시간이 소요됩니다. 이는 추출 도구가 이미 작업을 완료한 이후에 존재하는 수식 작업입니다. 추출 자체는 페이지당 몇 초가 걸립니다. 수식은 청구서당 몇 분이 걸립니다. 추출 속도가 향상될수록 수식 격차는 비례적으로 더 커지지 작아지지 않습니다.

Excel 템플릿으로 이 수식들을 자동화하면 안 되나요?

미리 만들어진 Excel 템플릿은 배치별 설정 시간을 줄여주지만 수동 단계를 없애지는 않습니다. 템플릿은 여전히 각 추출 결과에 적용해야 합니다 — 데이터 가져오기, 열 정렬이 어긋나지 않았는지 확인, 수식이 올바른 행을 참조하는지 검증 등이 필요합니다. 템플릿은 수식 작성에는 도움이 되지만 검증에는 도움이 되지 않습니다. 2행부터 13행까지를 포함하는 SUM 수식은 청구서에 14개의 품목이 있을 때까지는 완벽하게 작동하다가 14행이 조용히 제외됩니다. 템플릿은 수식 작업을 줄여주지만 수식 검토의 필요성을 없애지는 않으며 — 실제로 시간이 많이 소요되는 것은 바로 검토입니다.

ImageToTable.ai의 계산 열은 손으로 쓴 청구서에서도 작동하나요?

네 — 계산 열은 AI가 문서에서 추출한 모든 값에 대해 작동하며, 원본이 인쇄된 문서든 손으로 쓴 문서든 관계없습니다. AI가 손으로 쓴 청구서에서 수량과 단가를 읽을 수 있다면, 인쇄된 청구서와 마찬가지로 추출 중에 두 값을 곱할 수 있습니다. 계산의 정확성은 기본 추출의 정확성에 달려 있습니다. 손으로 쓴 숫자를 잘못 읽으면 계산 결과에도 그 오류가 전달됩니다. AI의 필기 인식 정확도는 가독성에 따라 달라집니다 — 표준 양식에 또렷하게 적힌 숫자는 안정적으로 추출되지만, 구조화되지 않은 레이아웃에 빽빽하게 휘갈겨 쓴 글씨는 검토가 필요할 수 있습니다.

계산 열은 어떤 종류의 계산을 처리할 수 있나요?

계산 열은 행 수준 산술(같은 행의 필드 간 곱하기, 나누기, 더하기, 빼기), 문서 내 교차 행 집계(문서 내 모든 행 합계 합산), 조건부 논리(청구서 합계가 기준을 초과하면 "예산 초과" 출력, 그렇지 않으면 "정상" 출력), 고정 매개변수 참조(문서에 포함할 필요 없이 세율이나 참조 값을 계산 규칙에 포함), 다단계 파생(품목에서 소계 계산 후 세금 적용 후 인쇄된 합계와 비교)을 지원합니다. 간단한 계산은 열 이름에 직접 로직을 작성하세요. 복잡한 다단계 계산은 로그인 사용자에게 제공되는 JSON 규칙 형식을 사용하세요.

인간의 청구서 검토 필요성을 대체하나요?

아닙니다. 그리고 그것이 목표도 아닙니다. 계산 열은 계산 단계를 대체하지, 검토 단계를 대체하지 않습니다. 인간은 여전히 출력 결과를 살펴보고 차이가 무엇을 의미하는지 결정해야 합니다. $35 차이가 허용 가능한 반올림 오류인지, 아니면 대변 메모가 필요한 청구 오류인지 말입니다. 계산 열의 가치는 인간이 산술이 이미 완료되었기 때문에 더 빨리 결정에 도달한다는 점입니다. $35 차이를 발견하기 위해 수식을 설정하는 데 5분을 소비하는 대신, 검토자는 출력에서 즉시 그 차이를 보고 5분을 그것에 대해 무엇을 할지 결정하는 데 사용합니다.

계산 열이 지원하지 않는 계산이 필요하면 어떻게 하나요?

계산 열은 추출 후 가장 일반적인 계산(산술, 합산, 비교, 조건부 논리)을 다룹니다. 고도로 전문화된 계산(보험계리 수식, 실시간 환율의 다중 통화 외환 변환, 감가상각 일정)의 경우 Excel 또는 전용 금융 시스템이 적절한 도구로 남아 있습니다. 계산 열은 반복적이고 공식적인 추출 후 작업의 90%를 처리하도록 설계되었으며, 존재하는 모든 스프레드시트 기능을 대체하기 위한 것이 아닙니다. 대부분의 청구서 처리 워크플로우에서 그 90%는 소요 시간의 대부분을 차지합니다.