공공요금 청구서 데이터 추출,
인보이스 추출이 아닌

공공요금 청구서는 인보이스가 아닌 요금 항목의 집합체입니다

공공요금 청구서에는 네 가지 필드 그룹이 있으며, 그중 하나만 일반 인보이스와 겹칩니다. 첫 번째 그룹은 계정 및 서비스 데이터로, 계정 번호, 계정 소유자, 서비스 주소, 공급업체, 계량기 번호가 포함됩니다. 두 번째는 청구 기간으로, 청구일, 납부 기한, 서비스 기간(시작일~종료일), 그리고 종종 명세서 번호가 포함됩니다. 세 번째 그룹은 일반적인 인보이스 도구가 평면화하는 부분인 사용량과 요금입니다. 여기에는 현재 및 이전 검침값, 단위가 포함된 소비량, 상업용 전기 요금의 kW 단위 수요, 단가 또는 요율, 공급 및 배전 요금, 세금과 할증료, 크레딧이 포함됩니다. 네 번째는 결제 데이터로, 총 납부 금액, 이전 잔액, 결제 참조 번호가 포함됩니다.

이 문서를 읽는 사람은 업체 규모에 따라 다릅니다. 소규모 사업체에서는 경리 담당자가 청구서를 열어 총액을 확인하고 보관합니다. 부동산 관리 회사에서는 유틸리티 담당자가 계정 번호, 서비스 주소, 금액을 부동산 관리 시스템에 입력하여 각 요금이 올바른 부동산 원장에 기록되도록 합니다. 여러 채를 보유한 임대인은 같은 담당자가 하나의 주계량기를 여러 세대에 분배합니다. 그리고 기업이 에너지 사용량을 보고할 때, 시설 또는 지속가능성 분석가는 동일한 청구서에서 kWh와 therms를 다시 추출하여 벤치마킹 도구에 입력합니다.

이 모든 경우에 공통적으로 나타나는 점은 유틸리티 측이 분산되어 있다는 것입니다. 전기만 해도 미국에는 3,371개의 공급업체가 있으며, 여기에는 1,998개의 공영 전력 사업체와 859개의 협동조합이 포함됩니다(APPA, 2026). 수도는 더욱 분산되어 있습니다. 미국에는 약 51,000개의 지역 상수도 시스템이 있으며, 그중 92% 이상이 10,000명 미만의 고객에게 서비스를 제공합니다(AWWA). 세 개 주에 부동산을 보유한 포트폴리오는 매달 수십 가지의 서로 다른 청구서 레이아웃을 처리해야 할 수 있으며, 각 레이아웃은 사용량 수치를 페이지의 다른 위치에 배치합니다.

유틸리티 인보이스와 공공요금 청구서는 공급업체와 총액을 공유합니다. 청구서 추출을 가치 있게 만드는 모든 요소, 즉 계량기, 사용량, 요금 항목 내역은 인보이스 템플릿에 없던 필드입니다.

공공요금 청구서 추출이 실제로 실패하는 지점

공공요금 청구서 처리는 네 가지 예측 가능한 지점에서 실패하며, 그중 어느 것도 원시 문자 인식 문제가 아닙니다. 첫 번째는 측정 단위입니다. usage라는 동일한 단어가 전기 청구서에서는 킬로와트시(kWh)를, 가스 청구서에서는 therms 또는 CCF를, 수도 청구서에서는 세제곱미터 또는 갤런을 의미합니다. 이 모두를 하나의 열에 넣으면, 상품(에너지원)을 비교하는 순간 그 열은 더 이상 비교 가능하지 않게 됩니다. 두 번째는 요금 구조입니다. 전기 청구서에는 전기 자체에 대한 공급 요금과 전송에 대한 배전 요금이 있으며, 많은 주에서 배전 부분에는 자체적인 배전, 송전, 고객 요금이 포함됩니다(Eversource). 총액만 포착하면 요금 인상과 사용량 증가를 구분할 수 없습니다.

세 번째 실패 지점은 문서 자체의 데이터 품질입니다. 청구서에 실제 검침값 대신 추정 검침값이 표시될 수 있으며, 예산 청구제(budget billing) 플랜은 연말 정산(true-up)에서 그 차액을 정산합니다. 사용량 열이 검침이 추정되었는지 여부를 표시하지 않고 인쇄된 값을 그대로 기록한다면, 월별 시계열은 소비와 무관한 이유로 오르락내리락하게 됩니다. 네 번째 실패 지점은 배분(allocation)입니다. 하나의 공공요금 계정이 건물 전체에 서비스를 공급하는 반면 비용은 수십 개의 유닛에 귀속될 수 있으며, 청구서의 계정 번호가 해당 부동산과 계량기로 연결되는 유일한 신뢰할 수 있는 키입니다. 이 필드를 잃어버리면 배분을 수작업으로 재구성해야 합니다.

팀은 원인을 규명하기 훨씬 전에 문제의 누적을 느낍니다. r/PropertyManagement의 한 부동산 관리자는 그 규모를 직접 설명했습니다: "저희 회사는 매달 약 600~800장의 인보이스를 Yardi에 수작업으로 입력하고 있습니다" (r/PropertyManagement). 그 규모에서 작업은 어렵지 않지만 꾸준하며, 꾸준한 타이핑이 바로 전치된 계정 번호와 잘못 판독된 사용량 숫자가 발생하는 원인입니다.

kWh, Therms, CCF, m³가 하나의 열에 공존할 수 없는 이유

단위 함정은 공공요금 청구서 데이터에서 가장 비용이 많이 드는 실수입니다. 숫자는 유효하지만 의미가 잘못되기 때문입니다. 전기 사용량은 킬로와트시로 측정되며, 1kWh는 3,413 Btu의 에너지와 같습니다. 가스는 두 가지 계열로 제공됩니다. Therm은 100,000 Btu와 같은 에너지 단위이고, CCF와 MCF는 부피 단위로 각각 100입방피트와 1,000입방피트의 가스입니다. 단일 CCF는 대략 1 therm이지만, 이는 일반적인 열량 계수가 1.03 근처에 있기 때문이며, 이 계수는 매월 변동합니다(Owatonna Public Utilities). 수도에도 유사한 중복이 있습니다. 수도 계량기는 CCF로 판독되며, 1 CCF는 약 748갤런과 같습니다.

이 중복이 실제 오류가 숨어 있는 지점입니다. 두 청구서가 모두 2,400단위로 표시될 수 있지만, 하나는 입방피트, 다른 하나는 therms를 의미하거나, 하나는 CCF, 다른 하나는 MCF로 10배 차이가 날 수 있습니다. 단일 정규화된 사용량 숫자는 단위가 함께 기록된 경우에만 이를 구분할 수 있습니다. 공공요금 청구서 열 구성의 실용적인 규칙은 상품별 사용량 열 하나와 인쇄된 내용을 기록하는 단위 열 하나를 두는 것입니다. 따라서 전기 열에는 kWh만, 가스 열에는 therms 또는 CCF만 저장됩니다. 단일 비교 가능한 수치가 필요하다면, 추출 후 명시적 변환으로 계산해야 하며, 세 가지 상품이 하나의 헤더를 공유하도록 두어서는 안 됩니다.

배치의 모든 청구서가 동일해 보여도 단위 열을 유지하세요. 이 필드는 다음 달이나 다른 부동산에서 두 사용량 숫자가 실제로 비교 가능한지 알려주는 항목입니다.

유틸리티 청구서용 열 세트 — 공급업체 인보이스가 아님

공급업체별 파서를 만들지 않고 이러한 필드를 얻는 방법은 Custom Column Extraction입니다. ImageToTable.ai에서 원하는 열 이름을 입력하면 AI가 각 청구서를 읽고 필드 라벨의 의미를 파악하여 모든 열 아래에 값을 채웁니다. 페이지에서의 위치가 아니라 의미를 기준으로 합니다. 입력한 이름이 출력 스프레드시트의 헤더가 됩니다. 의미 기반 판독이므로 하나의 열 세트로 ConEd 전기 청구서, 지방 상수도 고지서, 협동조합 가스 청구서를 동일한 배치에서 처리할 수 있으며, 레이아웃이 변경되어도 만들거나 유지 관리할 템플릿이 없습니다.

유틸리티 청구서 열 세트는 네 가지 필드 그룹을 따르지만 인보이스에서 누락된 사용량 및 요금 세부 정보를 유지합니다:

두 가지 열 유형은 단순한 필드 목록으로는 할 수 없는 작업을 수행합니다. 계산 열은 추출 중에 도구가 실행하는 계산을 포함하므로, 청구서에 사용량이 명시되지 않은 경우에도 사용량 수치가 산출됩니다. 소비량(현재 검침값 − 이전 검침값)을 정의하면 결과가 별도의 열로 생성됩니다. 동일한 메커니즘이 요금 항목에도 적용됩니다. 계산 열은 섹션 내 라인 금액을 합산할 수 있으므로, 총 요금은 공급비, 배송비, 세금, 수수료를 한 번에 더합니다. 또한 조건부 검사도 지원합니다. 총 요금이 총 납부 금액과 일치하지 않으면 차액을 출력하는 열을 정의하면, 시트는 인쇄된 총액이 개별 라인 항목과 일치하지 않는 청구서에 플래그를 표시합니다. 추론 열은 분류를 처리하므로, 유틸리티 유형(옵션: 전기 / 가스 / 수도 / 하수 / 통신)은 헤더가 모호한 경우에도 청구서 내용을 기반으로 채워집니다.

월 1회 업로드, 시트 1개, 숫자 1개당 확인 1회

공공요금 청구서는 한 번에 한 장이 아니라 매달 묶음으로 도착하므로 작업 흐름도 이에 맞춰야 합니다. 이번 주기에 도착한 모든 청구서를 공급업체와 상품 유형에 관계없이 단일 배치로 업로드하세요. 도구가 이를 함께 처리하고 결과를 청구서당 한 행씩 하나의 스프레드시트로 병합합니다. 계좌번호 확인은 각 행을 올바른 부동산에 매핑하고, 조건부 열의 플래그는 게시 전에 재검토가 필요한 청구서를 가리킵니다. 한 주에 걸쳐 타이핑으로 처리하던 포트폴리오가 이제 시트 하나와 짧은 예외 목록으로 줄어듭니다.

두 가지 기능이 추출 작업을 줄여줍니다. Email Inbox는 청구서를 전달하거나 유틸리티 포털 규칙이 자동으로 전달하도록 설정할 수 있는 전용 주소를 계정에 제공하므로 업로드 단계 없이 청구서가 대기열에 들어옵니다. 또한 많은 유틸리티 명세서가 도착하는 형태인 비밀번호 보호 PDF도 처리합니다. Review Mode와 Bbox 위치 확인은 중요한 숫자를 검사하는 기능입니다. 추출된 셀에 마우스를 올리면 도구가 청구서 이미지에서 해당 값이 나온 위치를 정확히 강조하고, 이미지의 영역을 클릭하면 해당 셀로 이동합니다. 계좌번호나 사용량 수치의 경우 전체 페이지를 다시 읽는 대신 한눈에 확인할 수 있습니다. 청구서가 사진이나 흐릿한 팩스로 도착하면 계정을 더 높은 Model Tier로 설정하여 더 정확하게 판독할 수 있습니다. 동일한 명세서가 여러 페이지에 걸쳐 스캔된 경우 Multi-Page Merge가 페이지를 단일 행으로 접어 계좌번호가 모든 줄에 적용되도록 합니다.

출력 형식은 Excel, CSV 또는 JSON입니다. 이 파일은 비용 배분, 예산 대비 실적 비교, ENERGY STAR Portfolio Manager와 같은 벤치마킹 도구, 또는 이미 사용 중인 부동산 관리 시스템의 유틸리티 모듈에 공급됩니다. 부동산 관리 플랫폼도 이 문제를 해결해 왔습니다. AppFolio의 Smart Bill Entry는 5,600만 건 이상의 인보이스를 처리했다고 보고하며, AppFolio 고객은 월 평균 3,000건 이상의 새 청구서를 입력합니다(AppFolio). 한편 Yardi는 2025년 말 Breeze Premier에 포함된 OCR 및 AI 인보이스 도구인 Smart AP를 출시했습니다(Yardi). 이러한 도구는 자체 플랫폼 내에서 인보이스 측면을 해결합니다. 이 워크플로우가 다루는 단계는 청구서가 플랫폼에 도달하기 전에 어떤 형식으로든 도착하는 청구서에서 사용량과 요금 항목을 추출하는 것입니다.

제공하지 않는 기능

유틸리티 청구서 파이프라인은 그 한계가 명확할 때만 신뢰할 가치가 있습니다. ImageToTable.ai는 문서를 추출하고 구조화합니다. 유틸리티 포털에 로그인하거나 청구서를 대신 다운로드하지 않으며, 청구서를 결제하거나 결제 일정을 잡지 않고, 청구서 감사나 청구 이상 징후 탐지를 자체적으로 수행하지 않으며, Yardi, AppFolio, QuickBooks 또는 ERP에 데이터를 직접 전송하지 않습니다. 구조화된 파일을 반환하며, 시스템에 기록하는 작업은 담당 팀이 수행합니다. 사람의 판단이 필요한 두 가지는 계정과 계량기 쌍이 올바른지 확인하는 것과 요금 항목이 타당한지 결정하는 것입니다. 이 도구가 제거하는 것은 처음부터 오류를 발생시킨 재판독과 재입력 작업입니다.

또한 혼동되기 쉬운 두 문서를 구분할 필요가 있습니다. 계량기 숫자를 읽는 것은 상류의 캡처 작업, 즉 계량기 사진을 판독값으로 변환하는 현장 작업으로, 이는 별도의 접근 방식이 필요한 다른 문제이며 계량기 판독 데이터 추출 전체 가이드와 계량기 판독 정확도 가이드에서 다룹니다. 유틸리티 청구서는 그 하류에 있습니다. 청구서에는 이미 판독값과 계정, 기간, 요금 항목, 납부 금액이 포함되어 있습니다. PDF나 스캔에서 청구서를 추출하는 것은 문서 측 작업이며, 계량기 숫자를 읽는 것과는 다른 필드 집합입니다. 현장 추출이 구조화된 출력에 어떻게 매핑되는지 더 폭넓게 보려면 문서 데이터 추출 설명에서 전사와 구조화 추출의 차이를 설명합니다.

유틸리티 청구서 데이터 추출: 자주 묻는 질문

한 번도 본 적 없는 공급업체의 유틸리티 청구서도 읽을 수 있나요?

네. Custom Column Extraction은 필드 라벨의 의미를 기준으로 각 값을 찾으므로, 하나의 열 집합으로 투자자 소유 유틸리티 청구서, 지방 자치 단체 유틸리티 명세서, 농촌 협동조합 청구서에서 동일한 필드를 단일 배치로 추출할 수 있습니다. 공급업체별 템플릿을 만들 필요가 없으며, 이는 미국에만 수천 개의 전기 및 수도 공급업체가 있기 때문에 중요합니다. 특정 청구서에서 매핑할 항목이 없는 열은 오류를 발생시키지 않고 비어 있는 상태로 반환되므로, 필드를 생략한 공급업체가 있어도 실행이 중단되지 않습니다.

사용량 열에 kWh와 therms가 한 청구서에 섞여도 되나요?

인쇄된 내용 그대로 추출하므로 단위는 숫자와 함께 이동합니다. 여러 에너지원을 포괄하는 포트폴리오의 경우, 에너지원별 사용량 열 하나와 단위 열을 두는 것이 더 안전한 설계입니다. 전기 사용량에는 kWh만, 가스 사용량에는 therms 또는 CCF만 들어가게 되어 서로 다른 단위의 두 숫자가 동일한 수량으로 비교되는 일을 방지합니다. 이는 가스 청구서에서 10배 오차를 발생시키는 흔한 실수입니다.

유틸리티 포털에 로그인하거나 청구서를 다운로드하나요?

아닙니다. 포털 로그인은 없으며 추출 단계에도 필요하지 않습니다. 이미 보유한 청구서를 PDF, 스캔, 사진 형태로 가져오거나, 계정의 받은 편지함 주소로 전달하면 자동으로 대기열에 들어갑니다. 비밀번호로 보호된 명세서의 경우 저장된 비밀번호가 암호화된 첨부 파일에 시도되어 동일한 워크플로우로 진행될 수 있습니다.

예상 검침값과 정산 청구서도 처리할 수 있나요?

청구서에 명시된 내용을 추출하며, 예상 또는 예산 청구 명세서의 사용량과 요금, 인쇄된 이전 잔액 및 정산 금액도 포함됩니다. 예상치를 수정하거나 실제 사용량을 계산하지는 않습니다. 깨끗한 월별 사용량 시계열이 중요하다면 검침이 예상치였는지 여부를 별도 열로 캡처하여 해당 기간을 분리해 처리할 수 있습니다.

Yardi, AppFolio, QuickBooks로 데이터를 전송하나요?

아닙니다. 출력물은 Excel, CSV 또는 JSON 형식의 구조화된 파일이며, 팀이 이를 시스템 오브 레코드로 가져옵니다. 이렇게 하면 추출 도구가 사용 중인 플랫폼과 독립적으로 유지되고, 동일한 청구서 배치가 하나의 구조화된 시트에서 자산 원장과 에너지 벤치마크 등 두 곳으로 전달될 수 있습니다.

사진이나 스캔한 청구서에서 정확도는 어느 정도인가요?

선명하게 인쇄된 유틸리티 청구서의 정확도는 최대 99%에 달하며, 제공업체에서 직접 받은 평면 PDF가 가장 쉬운 입력입니다. 사진, 흐린 팩스, 회전된 스캔은 더 어려우며, 이러한 문서의 경우 계정을 더 높은 처리 티어로 설정할 수 있습니다. 계정 번호나 사용량 수치처럼 한 자리 오류가 중요한 필드의 경우 Bbox 보기에서 각 값을 읽은 정확한 위치를 표시하여 빠르게 확인할 수 있습니다.

유틸리티 청구서 처리의 핵심은 입력 작업 자체가 아니라, 청구서가 인보이스가 버리는 필드를 유지한다는 점입니다: 계량기, 사용량과 함께 이동하는 단위, 총액 뒤의 요금 항목. 이러한 필드를 한 번 열 집합으로 구조화하면 월간 작업이 데이터 입력이 아닌 검토용 시트가 됩니다. 인보이스 데이터 추출 가이드는 문서가 실제로 인보이스인 경우를 다루며, 은행 명세서 추출 워크플로우는 동일한 패턴을 다른 정기 금융 문서에 적용한 사례를 보여줍니다.