추출 후 데이터 오류가
대부분의 팀이 생각하는 것보다 더 심각한 이유

합계가 맞지 않는 경우: 아무도 확인하지 않는 오류

추출 후 가장 흔한 오류는 가장 눈에 띄지 않는 오류입니다. 배관 자재 공급업체에서 송장이 도착합니다 — 3페이지, 15개 라인 항목, 소계 $3,847.50, 세금 $307.80, 총액 $4,155.30. AI는 모든 라인을 정확히 읽습니다. 수량: 12. 단가: $47.25. 라인 합계: $567.00. 15개 라인 합계가 모두 정확히 추출되었습니다. 소계도 $3,847.50으로 정확히 추출되었습니다. 총액도 $4,155.30으로 정확히 추출되었습니다. 스프레드시트의 모든 개별 값은 정확해 보입니다. 하지만 아무도 15개 라인 합계가 실제로 $3,847.50이 되는지 확인하지 않았습니다. 이 경우, 합계는 $3,697.20입니다 — 정확히 한 라인 항목이 빠져 있습니다.

이것이 추출 후 오류의 특징입니다: 모든 셀이 개별적으로는 정확해 보이지만, 셀 간의 관계가 깨져 있습니다. AI는 각 필드를 독립적으로 추출했습니다 — "수량: 12", "단가: $47.25", "라인 합계: $567.00"을 페이지의 별도 사실로 읽었습니다. AI는 이들 사이의 관계를 계산하지 않았습니다. 이는 AI의 결함이 아닙니다. 의미론적 추출의 본질입니다: 모델은 적힌 내용을 읽을 뿐, 논리적으로 따라와야 할 내용은 읽지 않습니다.

합계에 포함되지 않은 라인 항목은 페이지 전환에 있었습니다 — 15개 중 11번째 행으로, 2페이지 맨 아래에 인쇄되었고 나머지 테이블은 3페이지에 이어졌습니다. AI는 11번째 행의 데이터를 정확히 읽었습니다. 12~15번째 행도 정확히 읽었습니다. 하지만 출력이 스프레드시트로 조합될 때, 소계 셀은 위 행을 참조하는 SUM 수식이 아닌 정적 추출 값이 되었습니다. $3,847.50과 $3,697.20 사이의 불일치는 AP 담당자가 공급업체 명세서의 잔액이 다르다는 것을 발견할 때까지 3주 동안 스프레드시트에 남아 있었습니다.

발생 이유. 추출 도구는 수식이 아닌 정적 값을 출력합니다. 송장의 소계 필드는 AI가 읽는 숫자이지, AI가 수행하는 계산이 아닙니다. 라인 항목이 잘못 추출되면 — 소수점 누락, 중복, 또는 완전히 누락 — 페이지에서 추출된 소계 값은 라인 항목이 실제로 합산되는 값과 일치하지 않습니다. 하지만 추출 프로세스에서 이 불일치를 표시하는 것은 없습니다. 도구는 성공적으로 완료되었습니다. 출력은 정상적으로 보입니다. 오류는 라인 항목의 합계와 총액 필드가 표시하는 값 사이의 간격에만 존재합니다 — 어떤 자동 검사도 채우지 못하는 간격입니다.

잡는 방법. 추출 후, 산술 폐쇄 검증을 위한 한 번의 검사 패스를 전담하세요: 모든 라인 합계를 합산하고 결과를 추출된 소계와 비교합니다. 세금에도 동일하게 적용하세요 — 소계에 명시된 세율을 곱하고 추출된 세금 금액과 비교합니다. 두 숫자가 반올림 허용 오차 이상으로 차이가 나면 문서에 플래그를 지정하세요. 이는 송장당 10초가 걸리는 검사로, AP 시스템에 들어가기 전에 가장 흔한 추출 후 오류 유형을 잡아냅니다. 추출된 문서 데이터 QA 체크리스트에서 이 검증 단계와 전체 검증 워크플로우를 자세히 다룹니다.

누락 행: 15가 14가 될 때, 그 차이는 공급업체 지급 한 건

건축 자재 인보이스에는 두 페이지에 걸쳐 22개 항목이 나열되어 있습니다. AI는 21개 행을 추출합니다. 누락된 행은 1페이지의 마지막 줄로, AI의 레이아웃 분석이 데이터 행이 아닌 구조적 요소로 식별한 페이지 헤더 박스 바로 아래에 있습니다. 해당 행은 문서에 존재합니다. 해당 행의 값은 $182.40입니다. 행 번호는 22번입니다. 그러나 추출 결과에는 21개 행만 표시되고 $182.40은 스프레드시트 어디에도 나타나지 않습니다.

$4,200 인보이스에서 $182.40은 4.3%입니다. 월말 마감을 망가뜨리지는 않습니다. 그러나 6주 후 공급업체 조정 과정에서 표면화되며, 그 시점에 AP 담당자, 구매 관리자, 공급업체 AR 담당자 등 세 명이 합산 45분을 들여 추적하게 됩니다. 오류를 찾는 비용이 오류 자체의 비용을 초과합니다.

누락 행 오류는 세 가지 구조적 경계에서 집중적으로 발생합니다: 다중 페이지 PDF의 페이지 나눔, 두꺼운 구분선이나 박스형 헤더 영역이 앞에 있는 테이블 섹션, 그리고 테이블의 마지막 행이 페이지 맨 아래 여백에 위치한 페이지입니다. 각 경우에서 AI의 레이아웃 이해는 해당 경계를 구조적 구분자로 처리하며, 인접한 행이 여전히 데이터 영역에 속한다는 것을 인식하지 못합니다. 역설적이게도 AI는 해당 행에 데이터가 포함되어 있음을 올바르게 식별합니다. 단지 해당 데이터를 문서의 다른 영역에 속하는 것으로 분류할 뿐이며, 추출 스키마는 어떤 필드를 추출할지 정의할 뿐 몇 개의 행이 존재해야 하는지는 정의하지 않기 때문에 이를 잡아내지 못합니다.

탐지 방법은 간단하지만 추출 워크플로우에 거의 내장되어 있지 않습니다: 세는 것입니다. 출력의 행 수를 셉니다. 소스 문서를 빠르게 육안으로 스캔한 결과와 비교합니다 — 또는 대규모 처리 시 각 공급업체의 일반적인 인보이스 형식에 대한 알려진 행 수 범위와 비교합니다. 항상 12줄 인보이스를 보내는 공급업체가 갑자기 11줄 추출을 생성한다면, 추출된 모든 값이 정확해 보이더라도 조사할 가치가 있는 신호입니다.

잘못된 열 매핑: 날짜가 들어가야 할 자리에 송장 번호가 있는 경우

한 동료는 이 오류를 "자신의 눈을 의심하게 만드는 오류"라고 표현했습니다. "송장 번호"로 표시된 스프레드시트 열에는 "03/14/2026" 및 "11/02/2026"과 같은 값이 들어 있었습니다. "송장 날짜"로 표시된 열에는 "SI-2026-0482" 및 "SI-2026-0501"과 같은 값이 들어 있었습니다. 모든 셀에는 올바르게 형식화된 값이 있었습니다. 모든 값은 올바른 문서에서 추출되었습니다. 단지 잘못된 열에 있을 뿐이었습니다 — 의미론적 수준의 전치 오류였습니다.

이 유형의 오류는 모든 자동 검증 검사를 통과하기 때문에 특히 위험합니다. 송장 번호 열에는 문자열이 들어 있습니다. 날짜 열에는 날짜가 들어 있습니다. 데이터 유형 검증기는 아무 문제도 발견하지 못합니다. null 값 검사기는 빈 칸을 발견하지 못합니다. 형식 검증기는 모든 값이 해당 열의 예상 형식을 준수하는지 확인합니다. 스프레드시트는 오류 메시지 하나 없이 ERP로 가져와집니다. 피해는 3주 후에야 나타나며, AP 팀이 송장 번호 대신 날짜를 기준으로 지급 대사를 맞추고 있었다는 사실을 발견하게 됩니다.

열 매핑 오류는 추출 스키마에서 발생합니다. 열을 "송장 번호"와 "송장 날짜"로 정의하면 AI가 문서에서 두 값을 모두 찾아 각각의 열에 할당합니다. 대부분의 송장에서는 이 작업이 완벽하게 작동합니다 — 필드가 명확하게 표시되어 있고 의미론적 일치가 모호하지 않기 때문입니다. 그러나 송장 번호와 송장 날짜가 작고 레이블이 없는 헤더 블록에 인접해 있는 문서에서는 AI의 의미론적 할당이 전치될 수 있습니다. 모델은 밀집된 클러스터에서 두 값을 보고 식별자와 날짜를 나타낸다는 것을 알지만, 어느 것이 어느 것인지에 대한 명시적 레이아웃 신호는 없습니다. 크고 다양한 송장 말뭉치에서 1~3%의 경우, 모델이 잘못 추측합니다.

잡는 방법. 추출 후 교차 열 형식 검사를 실행하세요. 값의 5% 이상이 날짜 패턴과 일치하는 "송장 번호" 열은 검토 플래그를 트리거해야 합니다. 마찬가지로 송장 번호 규칙과 일치하는 영숫자 패턴이 포함된 "날짜" 열도 다시 확인할 가치가 있습니다. 이는 모든 행에 대해 실행하는 검사가 아니라 새 배치 출력에 대한 15초면 충분한 온전성 검사로, 자동 검증이 놓치도록 설계된 조용한 오류 유형을 잡아냅니다.

통화 및 소수점 오류: 세 자릿수를 좌우하는 쉼표

유럽과 라틴 아메리카의 인보이스 형식은 소수 구분 기호로 쉼표를, 천 단위 구분 기호로 마침표를 사용합니다. 이는 미국과 영국의 관례와 반대입니다. 독일 공급업체의 인보이스에 "1.250,00"이라고 적혀 있다면 이는 1,250유로와 0센트를 의미합니다. 이를 "$1,250.00"으로 추출하면 올바른 값입니다. 천 단위 구분 기호를 잃고 "$1250.00"으로 추출해도 여전히 올바른 숫자 값입니다. 그러나 쉼표를 소수점으로 잘못 해석하여 "$12.50"으로 추출하면 추출 값이 두 자릿수만큼 벗어나게 됩니다.

이 오류는 형식 검증으로는 포착되지 않습니다. "$12.50"은 완벽하게 유효한 통화 금액이기 때문입니다. 공급업체별로 명시적 범위를 설정하지 않는 한 범위 검사도 작동하지 않습니다. ERP에도 문제없이 가져와집니다. 그리고 실제 피해는 공급업체가 €1,250.00 인보이스에 대해 $12.50만 지급된 이유를 묻기 위해 전화할 때까지 표면화되지 않습니다.

소수점 이동은 여러 형태로 나타납니다. 가장 유명한 사례인 유럽식 쉼표-마침표 반전은 국제 인보이스 처리에서 발생하는 숫자 추출 후 오류의 약 3분의 1을 차지합니다. 또 다른 3분의 1은 AI가 끝자리 0을 누락하는 경우입니다. 모델이 "1250"을 올바르게 파싱했지만 소수점을 잘못된 위치에 배치하여 $1,250.00이 $125.00이 되는 것입니다. 나머지 3분의 1에는 OCR 아티팩트가 포함됩니다. 소수점을 가리는 얼룩이나 접힘으로 인해 $1,250.00이 $125000 또는 $12.5000으로 읽히는 경우로, 둘 다 표준 통화 형식에 깔끔하게 매핑되지 않습니다.

포착 방법. 통화 관례가 알려진 문서의 경우 소수점 위치 검증 규칙을 추가하세요. 추출된 금액이 해당 공급업체의 예상 범위와 한 자릿수 이상 차이가 나면 플래그를 지정합니다. 일괄 처리의 경우 각 금액의 자릿수를 공급업체의 과거 분포와 비교하세요. 지난 50개 인보이스가 €800~€3,200 범위인 공급업체의 단일 €1,250 인보이스는 문제없습니다. 같은 공급업체의 €12.50 인보이스는 지급 실행에 도달하기 전에 확인할 가치가 있습니다. 문서 추출 정확도 가이드에서는 필드 수준 정확도 지표가 실제 금융 데이터와 어떻게 상호작용하는지 설명합니다. 여기에는 일반적인 정확도 비율이 숨기는 특정 실패 모드가 포함됩니다.

날짜 형식 혼란: 한 열에 MM/DD와 DD/MM 혼재

월말 AP 처리를 위해 200개 송장 배치가 처리됩니다. 추출 결과 "Invoice Date" 열에 일부 행은 "03/05/2026"으로, 다른 행은 "05/08/2026"으로 표시됩니다. 첫 번째 값은 2026년 3월 5일을 나타냅니다. 두 번째 값은 2026년 5월 8일을 나타냅니다. 그러나 스프레드시트만으로는 어느 것이 어느 것인지 알 수 없습니다. 두 형식 모두 유효한 날짜이고, 둘 다 ERP에 문제없이 가져와지며, 빠르게 훑어보는 검토자에게는 둘 다 정상으로 보입니다. AI는 각 문서에 표시된 대로 날짜 문자열을 추출했으며, 배치 전체에 걸쳐 정규화를 적용하지 않았습니다.

단일 열에 혼합된 날짜 형식은 똑딱거리는 시계와 같은 데이터 품질 문제입니다. 열이 잘못 정렬됩니다. MM/DD/YYYY 체계에서는 03/05/2026이 05/08/2026보다 먼저 정렬되지만, DD/MM/YYYY에서는 그 반대입니다. 이 데이터로 작성된 에이징 리포트는 잘못된 결과를 생성합니다. 송장 날짜에서 계산된 지급 조건은 수식이 가정하는 관례에 따라 며칠 또는 몇 주씩 달라집니다. 그리고 이러한 오류는 잘못된 추출이 아니라 추출과 ERP 가져오기 사이의 정규화 단계 부재에서 발생합니다. 이 단계는 너무 단순해서 공식화되는 경우가 드뭅니다.

최악의 시나리오: 서로 다른 공급업체의 미국식 및 비미국식 날짜 형식이 섞인 열로, 어떤 출처가 어떤 관례를 따르는지에 대한 메타데이터가 없는 경우입니다. 단일 문서를 읽는 AI는 공급업체의 로케일을 알 수 없습니다. 단지 문자열을 있는 그대로 추출할 수만 있습니다. 정규화는 의식적인 추출 후 단계로 수행되어야 합니다. 공급업체별 날짜 관례를 식별하고, 모든 날짜를 ISO 형식(YYYY-MM-DD)으로 변환하고, 해당 문서 유형에 대해 합리적인 범위를 벗어나는 날짜가 없는지 검증해야 합니다.

이를 포착하는 방법. 추출 후 날짜 열에서 첫 번째 세그먼트가 12를 초과하는 값을 스캔합니다. 이는 DD/MM 날짜입니다. 모호한 값의 경우 공급업체의 알려진 로케일 또는 문서의 언어 메타데이터와 교차 참조합니다. 규칙을 설정합니다. 배치가 ERP 가져오기 승인 전에 출력의 모든 날짜가 단일 선언된 형식을 준수해야 합니다. 이것은 AI 문제가 아닙니다. 결정적 해결책이 있는 워크플로 문제입니다.

중복 행: 동일한 데이터가 두 번 추출됨

케이터링 공급업체 인보이스에는 두 페이지에 걸쳐 있는 라인 항목 테이블이 있습니다. 페이지 나눔이 18개 행 중 9번째 행을 가로지릅니다. 1페이지에서 AI는 1~9행을 추출합니다. 2페이지에서 AI의 레이아웃 분석은 새 테이블로 해석되는 것을 만납니다 — 동일한 열 구조, 페이지 연속 부분 상단에 나타나는 동일한 헤더 레이블 — 그리고 9~18행을 다시 추출합니다. 이제 9행이 출력에 두 번 나타납니다: 1페이지 테이블에서 한 번, 2페이지 연속 부분에서 한 번.

중복 행은 일반적으로 3자 매칭 중에 발견됩니다. 인보이스의 합산 수량이 PO 수량을 정확히 중복 행의 수량만큼 초과할 때입니다. 그러나 발견하려면 누군가 3자 매칭을 수행해야 합니다. 자동화된 PO 조정 없이 AP가 인보이스를 처리하는 조직에서는 중복이 지급까지 통과됩니다. $5,000 인보이스에서 $340 라인 항목이 두 번 지급되면 6.8% 초과 지급이며, 공급업체가 이를 크레딧으로 돌려줄 수도 있고 아닐 수도 있습니다.

중복 행 오류는 기계적으로 감지하기 쉽습니다: 각 행의 내용을 해시하고 동일한 문서 출력 내에서 동일한 해시를 찾으면 됩니다. 그러나 대부분의 추출 워크플로우에는 중복 제거 검사가 포함되어 있지 않습니다. AI 추출이 소스 행당 하나의 행을 생성한다는 가정 때문입니다 — 이 가정은 98%의 경우 성립하며, 테이블이 페이지 나눔을 가로지를 때 정확히 실패합니다. 해결책은 출력에 적용되는 중복 제거 규칙이지, 추출 모델의 변경이 아닙니다.

문서에 데이터가 있는데 빈 셀

의료 보험 EOB에는 행당 8개의 클레임 데이터 열이 나열됩니다: 서비스 날짜, 시술 코드, 청구 금액, 허용 금액, 플랜 지급액, 환자 부담금, 공제 적용액, 비고. 추출 후 "환자 부담금" 열은 페이지의 12개 클레임 중 4개에 대해 빈 셀을 보여줍니다. AI는 다른 7개 열을 올바르게 읽었습니다. 단지 환자 부담금 값을 식별하지 못했습니다 — 아마도 이 특정 EOB 형식에서 필드가 "환자 부담금"이 아닌 "본인 부담"으로 표시되어, 문서의 레이블과 추출 스키마의 열 이름 간 의미적 일치가 너무 약했기 때문일 수 있습니다.

빈 셀은 오류처럼 보이지 않기 때문에 추출 후 데이터 품질의 조용한 킬러입니다. 8개 열이 채워지고 1개가 비어 있는 행은 정상적으로 보입니다 — 특히 0 값이 실제로 흔한 "환자 부담금" 같은 열에서는 더욱 그렇습니다. 행당 2초 속도로 출력을 검토하는 검토자는 "빈 셀"을 보고 "$0"으로 가정합니다 — 그럴듯하지만 틀린 추론입니다. 실제 값은 $47.30이었습니다. 크지 않습니다. 그러나 배치의 42개 클레임에서 4개의 빈 환자 부담금 셀은 다음 청구 주기까지 눈에 띄지 않는 $189.20의 누락된 환자 청구를 의미합니다.

잡는 방법. 추출 후 각 행을 검사하여 필수 열에 빈 값이 있는지 확인합니다. 특정 문서 유형에 대해 절대 비어 있으면 안 되는 열 — 인보이스 합계, 날짜, 공급업체 ID — 을 정의하고 해당 열이 비어 있는 행에 플래그를 지정합니다. 합법적으로 0 값을 포함하는 열의 경우 AI가 셀을 비워 두지 않고 명시적 "N/A" 또는 "$0"을 출력하도록 요구하여, 누락된 데이터가 항상 0 값 데이터("$0")와 구별되도록 합니다. 이는 모델 개선이 아닌 필드 정의 규율입니다. 잘못 추출된 숫자 수정 가이드에서는 열 이름 지정과 필드 정의가 AI가 값을 찾는지 아니면 아무것도 반환하지 않는지를 직접 결정하는 방식을 설명합니다.

이 오류들이 조용히 누적되는 이유 — 그리고 오류 발생과 발견 사이의 지연이 실제 비용인 이유

전통적인 수동 데이터 입력 워크플로우에서 종이 인보이스를 ERP 화면에 입력하는 사람은 시각적 참조 자료를 가지고 있습니다. 라인 합계 열이 채워지지 않는 것을 볼 수 있습니다. 테이블의 마지막 행이 페이지 바닥글에 잘리는 것을 알아차립니다. 피드백 루프는 즉각적입니다. 데이터 입력이 발생하는 순간 오류가 표면화되는데, 입력을 수행하는 사람이 지속적이고 무의식적인 검증도 동시에 수행하기 때문입니다.

자동화된 추출은 그 피드백 루프를 끊습니다. AI가 문서를 읽고, 출력을 조합하고, 중간 결과에 사람의 눈이 닿지 않은 채 ERP로 전달합니다. 피드백 루프는 "즉시"에서 "다음 대사 시점"으로 줄어듭니다. 그리고 대사는 주간, 월간, 분기별로 이루어지며, 그 기간 동안 오류는 감지되지 않은 채 누적됩니다.

단일 인보이스의 행 하나 누락은 $200 문제입니다. 한 달 동안 20개 인보이스에서 20개 행이 누락되면 $4,000 문제입니다. 그러나 20개 누락 행을 진단하는 비용 — 각각을 원본 문서로 추적하고, 공급업체를 식별하고, 정확한 금액을 확인하고, 수정 지불을 발행하고, 원장을 업데이트하는 것 — 은 $4,000를 훨씬 초과합니다. 추출 후 오류를 찾는 인건비는 일반적으로 오류 자체 가치의 3-5배입니다. 이것이 가장 효과적인 검증 전략이 "오류를 더 빨리 찾는 것"이 아니라 "오류가 시스템에 들어가기 전에 잡는 것"인 이유입니다. 누락된 행을 잡는 30초의 가져오기 전 검사는 25분의 대사 조사를 2분의 재추출로 전환합니다.

Ardent Partners 2025 AP 지표 보고서에 따르면 평균 조직은 단일 인보이스를 처음부터 끝까지 처리하는 데 $9.40를 지출하며, 인보이스의 14%에는 수동 개입이 필요한 예외가 포함되어 있습니다. 이 보고서는 "추출 오류"를 "정책 예외"나 "승인 라우팅 문제"와 구분하지 않지만, 중첩은 큽니다. 수동 개입의 상당 부분은 ERP에 제대로 입력되지 않은 데이터로 인해 발생하며, 이는 이 문서에서 설명하는 오류와 동일한 유형입니다. ERP에 입력되는 모든 추출 후 오류는 기계 속도의 입력을 인간 속도의 예외로 전환하며, 그 예외의 비용은 기술이 아닌 인건비로 지불됩니다.

검증 습관: 30초면 충분한 다섯 가지 검사

추출 워크플로우에 검증 단계를 구축하는 데 데이터 품질 플랫폼이나 전담 검증 팀이 필요하지 않습니다. 다섯 가지 기계적 검사를 일관되게 적용하면 위에서 설명한 일곱 가지 오류 유형이 ERP에 도달하기 전에 잡아낼 수 있습니다:

이 다섯 가지 검사의 핵심 통찰은 문서를 다시 읽거나 출력을 소스와 수동으로 비교할 필요가 없다는 점입니다. 통계적이고 기계적인 검사로, 어떤 크기의 배치든 30초면 완료되며, 사람의 눈에 올바르게 보이는 데이터 속에 숨어 있어 육안 검토를 통과하는 오류를 잡아냅니다.

검증 워크플로우에 대한 더 깊은 내용 — 반복 QA 프로세스 구성 방법, 스팟 체크를 위한 샘플 크기, 검증을 한 사람의 게이트가 아닌 팀 워크플로우에 통합하는 방법 — 은 AI 추출 데이터 검증을 위한 QA 체크리스트에서 완전한 운영 프레임워크를 제공합니다. 이 다섯 가지 검사는 시작점입니다. QA 체크리스트는 지속적인 프로세스입니다.

추출 정확도 논의에는 대부분의 벤치마크가 포착하지 못하는 중요한 차원이 있습니다. 문서 추출 도구의 실용적 정확도 비교에서 자세히 다루는 내용인데, 필드 정확도와 직통 처리율은 같은 도구에 대해 근본적으로 다른 이야기를 전합니다. 이 둘 사이의 차이를 이해하는 것은 올바른 오류로부터 보호하는 검증 워크플로우를 구축하는 데 필수적입니다.

FAQ

추출 후 오류는 AI의 실패가 아닙니다. 이는 추출과 ERP 사이의 프로세스에서 발생하는 공백입니다. 추출 도구가 데이터를 생성하도록 설계되었지 감사하도록 설계되지 않았기 때문에 존재하는 공백입니다. 여기서 설명하는 일곱 가지 오류는 단일한 근본 원인을 공유합니다. 검사가 잘못된 대상을 확인하고 있기 때문에 모든 자동 검사를 통과하는 것입니다. 형식 검증은 잘못된 형식을 잡아냅니다. 산술 검증은 잘못된 계산을 잡아냅니다. 그 사이에 공백이 존재하며, 이를 메우는 데는 배치당 30초가 소요됩니다. 새 도구나 더 큰 팀이 필요하지 않습니다.

문서 데이터를 처리하고 추출 워크플로우에 검증을 직접 구축하려면 ImageToTable.ai가 검증 중심의 추출 파이프라인을 실행합니다. 이 도구는 템플릿 좌표가 아닌 필드 의미론으로 추출하며, 라인 합계를 조정하고 세금 산술을 확인하며 추출 후가 아닌 추출 중에 범위 이상 징후를 플래그하는 계산 열을 지원합니다. 전체 QA 검증 워크플로우는 위의 다섯 가지 검사를 지속 가능한 팀 프로세스로 운영하는 방법을 다룹니다.