직원들은 경비 스크린샷을 보냅니다.
재무팀은 건당 20분씩 입력합니다.
월요일 오전 9시 17분입니다. 재무팀 받은편지함에는 읽지 않은 메시지가 37개 있습니다 — 모두 경비 제출 건입니다. 12개는 결제 앱 스크린샷입니다: Alipay 거래 확인, WeChat Pay 영수증, "Pending - $47.19"를 보여주는 Chase 모바일 뱅킹 스크린샷. 9개는 사무실 형광등 아래에서 팔을 뻗어 찍은 실제 영수증 사진입니다 — 하나는 거꾸로 되어 있습니다. 8개는 이메일 전달 첨부 파일입니다: 호텔 예약 확인서, 라이드셰어 여행 요약, 온라인 주문 확인서. 나머지 8개는 혼합입니다: 한 직원이 자신의 경비 추적기로 사용한 스프레드시트 스크린샷, 공급업체 PDF 인보이스 2개, 스크린샷으로 전달된 문자 메시지 스레드 3개. 각각에는 오늘 재무팀 누군가가 읽고 회사 경비 스프레드시트에 다시 입력할 데이터가 들어 있습니다. GBTA Foundation의 보고서당 20분 벤치마크에 따르면, 이 37건의 제출은 약 12시간의 수동 입력 작업에 해당합니다 — 누군가의 근무 주중 하루 반을 화면에 이미 보이는 이미지를 보며 숫자를 입력하는 데 쓰는 것입니다. 데이터는 거기 있습니다. 다만 스프레드시트가 필요로 하는 위치에 없을 뿐입니다.

경비 스크린샷이 종이 영수증보다 어려운 이유

종이 영수증은 예측 가능한 구조를 가집니다. 가맹점 이름은 상단 중앙에 위치합니다. 날짜, 시간, 거래 ID는 그 아래 한 개의 압축된 블록에 나타납니다. 품목, 소계, 세금, 합계는 전표 오른쪽에 세로 열을 이룹니다. 이 레이아웃은 30년 동안 거의 변하지 않았습니다 — 북미의 모든 POS 시스템은 대략 같은 템플릿을 따르는 영수증을 출력합니다.
휴대폰에서 찍은 경비 거래 스크린샷에는 이런 예측 가능성이 전혀 없습니다. Alipay 결제 확인 화면은 가맹점 이름을 상단 중앙에 굵게 표시하고, 금액은 그 아래 큰 컬러 숫자로, 결제 수단은 파란 태그로, 거래 시간은 하단에 작은 회색 텍스트로 표시합니다 — 이 모든 것이 내비게이션 바, 상태 표시줄 아이콘, 배경색이 있는 브랜드 앱 프레임 안에 들어 있습니다. Chase 모바일 뱅킹 스크린샷은 가맹점 이름을 거래 목록의 왼쪽 열에, 금액을 오른쪽에, 날짜를 그 위에 다른 글꼴로 배치합니다 — 완전히 다른 UI 레이아웃 안에서 말이죠. 스크린샷으로 전달된 이메일 확인서는 예약 세부 정보가 본문 텍스트에 포함되어 있고 답장 헤더와 서명 블록이 뒤섞여 있습니다.
같은 경비 데이터 — 날짜, 가맹점, 금액, 카테고리, 결제 수단 — 가 세 가지 스크린샷 소스에 걸쳐 완전히 다른 세 가지 시각적 레이아웃으로 배치되어 있습니다. 이것이 스크린샷 추출을 영수증 스캔보다 근본적으로 어렵게 만드는 이유입니다: 데이터가 같은 템플릿의 다른 위치에 있는 게 아닙니다. 서로 다른 정보 구조에 내재되어 있는 것입니다 — 거래 확인 UI는 은행 명세서 UI가 아니고, 은행 명세서 UI는 이메일 본문이 아닙니다. 사람이 읽는 경우에는 결제 앱에서 커피 아이콘 옆의 "$47.19"가 은행 거래 목록의 "Amount" 열에 있는 "47.19"와 같은 의미라는 것을 이해하기 때문에 어렵지 않게 파악합니다. 전통적인 OCR은 이것을 이해하지 못합니다. 문자를 위에서 아래로, 왼쪽에서 오른쪽으로 순서대로 읽을 뿐이며 — 스크린샷에서는 그 순서가 의미상 말이 안 되는 경우가 많습니다.
결제 앱 확인 화면, 은행 앱 거래 목록, 이메일 예약 확인서는 같은 경비를 설명하는 세 가지 다른 정보 구조입니다. 전통적인 OCR은 각각을 평면적인 문자 스트림으로 읽습니다. AI 시각 추출은 각각을 구조화된 데이터 소스로 읽습니다 — 스크린샷을 생성한 앱이 무엇이든 결제 확인 UI 중앙의 큰 숫자가 거래 금액이라는 것을 이해합니다.
스크린샷에서 데이터를 입력하는 실제 비용: 보고서당 $58이 최저선

Global Business Travel Association의 벤치마크 — 경비 보고서당 $58, 보고서당 20분의 처리 시간 — 는 2015년에 측정되었으며 여전히 가장 널리 인용되는 업계 수치입니다. SAP Concur도 이를 인용하고, Ramp도 이를 인용합니다. 모든 경비 관리 업체가 이를 기준선으로 사용합니다. 하지만 GBTA 연구는 직원 제출부터 관리자 승인, 재무 검토 및 상환까지 이어지는 광범위한 경비 보고 워크플로를 측정한 것입니다. 경비 증빙이 스크린샷이나 사진으로 도착하면, 비용은 한 단계에 집중됩니다. 바로 보이는 데이터를 스프레드시트로 수동 입력하는 것입니다.
같은 GBTA 연구의 세부 분석은 여러 페인 포인트에 걸쳐 재분석되었습니다. 서드파티 경비 소프트웨어가 없는 기업의 출장 구매 담당자 중 54%가 "데이터 입력"을 주요 페인 포인트로 꼽았습니다. 55%는 "영수증 첨부"를 꼽았습니다. 경비 보고서 설정(49%)이 그다음으로 많이 언급되었습니다. 이 세 단계 — 경비 보고 프로세스의 앞단 — 가 20분의 대부분을 차지합니다. 특히 증빙이 기계 판독 가능한 데이터가 전혀 없는 스크린샷일 때, "데이터 입력" 단계만으로도 보고서당 20분 중 약 12-15분이 소요됩니다.
오류율은 여기에 더해 문제를 키웁니다. GBTA 연구에 따르면 경비 보고서의 19%에 오류가 포함되어 있으며, 각 수정에는 추가로 $52와 18분이 듭니다. 스크린샷 수동 입력은 특히 오류가 나기 쉽습니다. $47.19에 대한 결제 앱 확인 내역은, 재무 담당자의 시선이 한 화면의 스크린샷과 다른 화면의 스프레드시트 사이를 오가면서 $47.91이 됩니다. 가맹점 이름 "Guangzhou Hengtong Logistics Co."는 잘린 필드에서 "Guangzhou Hengtong Logist"가 됩니다. 날짜 "06/15/2026"은 스크린샷 UI의 타임스탬프 형식을 읽는 사람이 너무 빠르게 해석해서 "05/15/2026"이 됩니다.
Aberdeen Group은 별도의 분석을 발표하며 소규모 기업의 수동 경비 보고서 처리를 보고서당 $35.02로 추산했습니다. 이는 더 낮은 임금 수준과 더 단순한 승인 절차를 반영한 수치입니다. GBTA 데이터와 결합하면 수동 처리 비용은 보고서당 $35-$58 범위이며, 스크린샷만 사용하는 워크플로는 파이프라인 어디에도 기계 판독 가능한 데이터가 없기 때문에 이 범위의 상단에 위치합니다. 모든 숫자를 이미지에서 입력해야 하기 때문입니다.
월평균 1.2건의 경비 항목을 제출하는 직원 30명이 있는 회사(자주 출장하는 직원과 가끔 제출하는 직원이 섞여 있음)라면, 월 36건의 제출입니다. 보고서당 $58이면 월 수동 입력 비용은 $2,088입니다. 연간으로 환산하면 $25,056을, 시각 AI 모델이 스크린샷당 몇 초 만에 처리할 수 있는 작업에 쓰는 셈입니다. 게다가 $58이라는 수치는 2015년 기준입니다. 임금 상승을 반영하면 오늘날 환산 금액은 보고서당 $70에 더 가깝습니다.
기존 OCR과 경비 앱이 스크린샷에서 놓치는 것

경비 관리 소프트웨어 업계는 지난 20년간 경비 데이터가 시스템에 들어온 이후의 처리 과정을 최적화하는 데 집중해 왔습니다. 승인 라우팅은 자동화되어 있고, 정책 위반은 표시되며, 환급은 배치로 처리됩니다. 남아 있는 병목은 그 소프트웨어가 데이터를 건드리기 직전의 순간, 즉 경비 증빙이 직원의 휴대폰에 스크린샷으로 존재하고 그 안의 데이터가 기계가 읽을 수 있는 형태로 표현되지 않은 상태입니다.
법인 카드 프로그램은 카드 네트워크 피드에서 가맹점명, 날짜, 금액을 자동으로 채워 넣어 이 문제의 일부를 해결합니다. 하지만 그 자체로 새로운 공백을 만듭니다. 카드 피드는 거래를 포착할 뿐, 영수증 세부 내역은 담지 않습니다. 함께 먹은 식사를 포함한 식당 청구서 항목, 객실 요금에 세금과 주차비와 미니바 요금이 더해진 호텔 청구서, 여러 GL 코드로 나뉜 공급업체 결제 — 이 모든 것은 실제 문서에만 담긴 항목별 세부 내역을 필요로 합니다. 카드 네트워크는 $187.40이 청구되었다는 사실은 알지만, $120이 객실 요금이고 $18이 주차비이며 $11.40이 세금이고 $38이 별도의 경비 카테고리가 필요한 미니바 요금이라는 사실은 모릅니다.
모바일 영수증 스캔 앱 — Expensify, Concur 등에 있는 "영수증 사진 찍기" 기능 — 은 종이 영수증을 위해 만들어졌습니다. 종이 영수증은 일관된 물리적 형태를 가집니다. 보통 3-4인치 너비의 감열지 조각에 텍스트가 한두 열로 인쇄되어 있죠. 스캔 엔진은 이 형식을 기대합니다. 결제 앱 확인 화면의 스크린샷 — 상단에 내비게이션 바, 중간에 색상 배너, 하단에 공유 버튼이 있는 9×19.5 화면 비율의 직사각형 — 을 넣으면 엔진은 UI 요소를 어떻게 처리해야 할지 모릅니다. 텍스트를 파싱하려고 시도하지만 UI 레이아웃에서 영수증 패턴을 찾기 때문에 가맹점, 금액, 날짜를 잘못 배정합니다.
이것이 근본적인 불일치입니다. 기존 OCR과 모바일 영수증 스캐너는 문서 레이아웃을 위해 만들어졌습니다. 경비 스크린샷은 애플리케이션 UI 레이아웃입니다. 둘 다 같은 데이터를 담고 있습니다 — 이 가맹점에서 이 날짜에 이 금액의 거래가 있었다는 것 — 하지만 시각적 문법은 완전히 다릅니다. 시각 AI 모델이 둘 다 읽을 수 있는 이유는 인간이 둘 다 읽을 수 있는 이유와 같습니다. 즉, 학습된 템플릿에서 데이터가 어디에 위치하는지 대조하는 것이 아니라 각 데이터가 무엇을 의미하는지 이해하는 능력입니다.
시각적 AI가 OCR과 다르게 스크린샷을 읽는 방식
기존 OCR은 유사한 픽셀 패턴의 연속 블록("이건 텍스트처럼 보인다")을 감지하고 각 블록에 문자 인식을 실행하여 이미지를 처리합니다. 출력은 경계 상자 좌표가 있는 평면적인 텍스트 세그먼트 스트림입니다: (x:120, y:45): "Starbucks", (x:300, y:87): "$12.45", (x:120, y:120): "03/15/2026". 여기서 누락된 것은 이러한 텍스트 조각들 간의 관계입니다. OCR은 좌표 (300, 87)의 "$12.45"가 거래 금액이고, (120, 45)의 "Starbucks"가 가맹점이며, 둘 다 동일한 거래 이벤트에 속한다는 것을 알지 못합니다.
맞춤 열 추출에 사용되는 시각적 AI 모델은 사람이 보는 방식으로 스크린샷을 읽습니다. "날짜", "가맹점", "금액", "카테고리", "결제 수단"과 같은 열 이름을 정의하면 AI는 픽셀 좌표를 검색하지 않습니다. 탐색 모음, 컬러 배너, 상태 아이콘, 텍스트 블록, 구분선, 여백 등 전체 이미지를 전체적으로 읽고 의미론적 이해를 구성합니다: 이것은 Alipay의 결제 확인 화면이다. 중앙 카드에 통화 기호가 있는 큰 숫자는 거래 금액이다. 그 위의 굵은 텍스트는 가맹점이다. 하단의 타임스탬프는 날짜다. 금액 옆의 파란색 태그는 "신용카드"라고 표시되어 있다 — 그것이 결제 수단이다.
이것은 제품 설명에서의 패러다임 전환입니다 — 위치 기반 추출에서 의미 기반 추출로. 기존 OCR과 템플릿 도구는 "이 페이지에서 데이터가 어디에 있는가?"라고 묻습니다. 금액 필드 주위에 상자를 그리고, 날짜 필드 주위에 또 다른 상자를, 가맹점 필드 주위에 세 번째 상자를 그려야 합니다 — 앱마다 템플릿 하나씩. 시각적 AI는 "이 페이지에서 데이터가 무엇을 의미하는가?"라고 묻습니다. 특정 앱, 레이아웃, 화면 크기와 관계없이 화면의 결제 세부 정보 섹션에서 통화 표시기가 있는 눈에 띄는 숫자처럼 금액이 맥락에서 어떻게 보이는지 인식하여 금액을 식별합니다.
1 열을 한 번만 정의하세요
도구를 열고 열 이름을 입력하세요: 날짜, 가맹점, 금액, 카테고리, 결제 수단. 이것들은 출력 스프레드시트에 원하는 필드입니다. 열 이름이 사양이 되며 AI는 모든 스크린샷을 읽어 이러한 의미론적 설명과 일치하는 데이터를 찾습니다.
2 스크린샷을 한 번에 일괄 업로드하세요
37개의 스크린샷과 영수증 사진을 모두 업로드 영역으로 한 번에 끌어다 놓으세요. Alipay 확인 화면, Chase 모바일 캡처, 전달된 이메일 스크린샷, 식당 영수증 사진 — 혼합된 형식, 혼합된 레이아웃, 다양한 화면 비율, 다양한 앱 UI 규칙. 도구는 이를 단일 일괄 처리로 처리합니다.
3 AI는 위치가 아닌 의미로 데이터를 추출합니다
각 스크린샷에 대해 시각적 AI는 이미지를 읽고 정보 구조를 이해합니다 — 결제 확인인가? 은행 거래 내역인가? 영수증 사진인가? 전달된 이메일인가? — 그리고 열 이름과 일치하는 값을 찾습니다. Alipay 화면의 "날짜"는 하단에 작은 텍스트로 된 타임스탬프이고, 은행 명세서 스크린샷에서는 거래 내역의 열 머리글이며, 영수증 사진에서는 상단 근처에 인쇄된 텍스트입니다. AI는 각 맥락에서 날짜 필드가 어떻게 보이는지 이해하기 때문에 모두 찾아냅니다.
4 Excel 파일 하나에, 모든 스크린샷이 각각 한 행으로
결과물은 단일 Excel 스프레드시트입니다. 각 행은 스크린샷 하나에서 추출한 경비 데이터입니다 — 날짜 열, 가맹점 열, 금액 열, 카테고리 열, 결제 수단 열. 원본 파일명이 참조 열로 포함되어, 스프레드시트의 모든 행이 감사 목적으로 원본 스크린샷까지 추적됩니다. 내보내고 Excel에서 열면, 37개의 서로 다른 앱 레이아웃에 흩어져 있던 데이터가 이제 정렬 및 필터 가능한 하나의 테이블에 담깁니다.
이 단계에서의 시간 단축이 핵심 지표입니다. 스크린샷당 12~15분이 걸리던 작업 — 이미지 열기, 필드 읽기, 스프레드시트 행에 입력하기, 숫자 확인하기, 다음 이미지로 이동하기 — 이제 스크린샷당 AI 처리 시간 5~10초에 배치 업로드에 몇 분이 추가될 뿐입니다. 37건의 제출물 기준, 수동 입력 12시간 대신 도구 사용 시간은 약 4분입니다. 20분이라는 GBTA 벤치마크가 무너진 이유는 경비 프로세스의 어떤 부분이 바뀌었기 때문이 아니라, 그 20분의 대부분을 차지하던 수동 입력 단계가 자동화로 완전히 제거되었기 때문입니다.
IRS 규정 준수: 스크린샷으로 경비 입증 요건을 충족할 수 있나요?
짧게 답하면: 그렇습니다 — 단, 필요한 데이터 요소를 포함하고 있어야 합니다. IRS Publication 463 및 Internal Revenue Code §274(d)에 따라, 사업 경비 공제는 적절한 기록 또는 충분한 증거로 입증되어야 합니다. 각 경비에 대해 문서는 금액, 날짜, 장소, 업무 목적을 명시해야 합니다. 식사 및 접대의 경우 관련자의 업무 관계도 문서화해야 합니다.
결제 확인 내역의 디지털 스크린샷은 종이 영수증과 동일하게 이러한 요건을 충족합니다 — IRS는 Revenue Ruling 2003-106 이후 전자 영수증과 경비 보고서를 포함한 디지털 기록을 승인해 왔으며, 해당 규정은 책임 회계 제도(accountable plan) 상환 약정에 대해 전자 영수증과 경비 보고서를 명시적으로 허용했습니다. $75 영수증 규칙(IRC §274(d))에 따르면 $75 미만 경비는 영수증이 필요하지 않지만, 금액, 날짜, 장소, 업무 목적은 여전히 기록해야 합니다. $75 이상 경비는 영수증 또는 이에 상응하는 문서 증거가 필수입니다.
이는 업무 흐름에 다음과 같은 의미를 줍니다: $47.19 식사의 스크린샷은 법적으로 원본 종이 영수증 보관이 필요하지 않지만, 날짜, 가맹점, 금액, 업무 목적을 어딘가에서 찾을 수 있게 기록해야 합니다. $312 호텔 폴리오의 스크린샷은 보관이 필요합니다 — 그리고 호텔 결제 확인 스크린샷과 폴리오의 항목별 세부 내역 스크린샷은 데이터가 읽기 쉽고 완전하다면 문서 증거 요건을 충족합니다.
스크린샷 데이터를 구조화된 스프레드시트로 추출하는 실질적인 규정 준수 가치는 IRS 요구 사항을 충족하는 것 이상입니다. 스프레드시트의 모든 경비 행이 원본 파일 이름 — alipay_starbucks_march15.png, chase_hotel_marriott_march17.png — 을 참조하면 데이터와 증빙 간의 연결은 향후 어떤 감사나 내부 검토에서도 유지됩니다. 3년 후(경비 기록에 대해 IRS가 권장하는 보관 기간) 스프레드시트를 여는 사람은 모든 이미지를 다시 읽을 필요 없이 파일 이름만으로 원본 스크린샷을 찾을 수 있습니다. 경비 증빙이 완전히 디지털일 때 이것이 바로 감사 추적 무결성의 모습입니다.
월말 일괄 처리는 실제로 어떤 모습인가
실제 시나리오를 생각해 보겠습니다. 법인카드 제도도, 경비 관리 소프트웨어도 없는 40인 규모의 컨설팅 회사입니다. 직원들은 세 가지 채널을 통해 경비 증빙을 제출합니다: 회사 Slack 채널(#expenses), 이메일 첨부 파일, 그리고 현장 컨설턴트의 경우 재무 담당자에게 직접 보내는 WeChat 메시지입니다. 3월 말, 재무 담당자는 모든 파일을 한 폴더에 다운로드합니다.
폴더에는 다음이 들어 있습니다: Alipay/WeChat Pay 결제 확인 스크린샷 14장, 휴대폰으로 촬영한 종이 영수증 이미지 9장, 항공사 및 호텔 예약 이메일 확인서를 스크린샷으로 전달한 것 6장, 은행 앱 거래 내역 스크린샷 4장, 공급업체 PDF 인보이스 3장, 수기 작성 마일리지 기록 사진 2장. 총 38개 파일, 최소 5가지 서로 다른 시각적 형식으로, 동일한 핵심 데이터 — 날짜, 판매처/공급업체, 금액, 카테고리, 결제 수단 — 가 5가지 완전히 다른 레이아웃으로 배열되어 있습니다.
이 배치를 수동 입력으로 처리하는 경우: 재무 담당자가 각 파일을 열고, 필드를 읽고, 마스터 스프레드시트에 입력합니다. 형식 전환은 숨은 비용입니다. Alipay 확인서를 읽을 때 — 상단 중앙의 굵은 판매처 이름, 큰 컬러 텍스트의 금액 — 눈은 특정 레이아웃을 훑는 데 적응합니다. 그런데 다음 파일은 금액이 열로, 판매처가 다른 열로, 날짜가 위에 있는 은행 거래 내역입니다 — 완전히 다른 훑는 패턴입니다. 눈은 다시 적응해야 합니다. 파일 20번째에 이르면 오류가 늘어납니다. 파일 30번째에 이르면 재무 담당자는 파일 5번째에서는 하지 않았을 실수를 저지릅니다. GBTA의 19% 오류율은 고르게 분포하지 않습니다 — 형식 전환 피로로 인해 일괄 처리 세션의 후반부에 집중됩니다.
동일한 배치를 AI 추출로 처리하는 경우: 38개 파일을 한 번에 업로드합니다. 열을 정의합니다 — 날짜, 판매처, 금액, 카테고리, 결제 수단, 업무 목적. AI는 각 파일의 데이터 의미를 이해하여 5가지 다른 시각적 레이아웃에서 일치하는 값을 찾고, 38개 행이 있는 스프레드시트 하나를 출력합니다. 재무 담당자의 남은 업무는 검토와 승인입니다 — 판단과 정책 지식이 필요한 작업 — 수동 입력은 그 어느 것도 필요로 하지 않습니다.
이 규모에서의 비용 차이: 스크린샷 38장 × 수동 20분 = 760분(12.7시간). 재무 담당자의 완전 부담 시간당 요금 약 $30 기준, 한 달 수동 입력 인건비는 $381입니다. 12개월로 환산하면: $4,572 — AI 도구가 월간 활성 도구 상호작용 5분 미만으로 수행하는 작업에 지출되는 금액입니다.
스크린샷에서만 발생하는 세 가지 전사 오류
모든 경비 보고서 오류가 동일한 것은 아닙니다. 스크린샷 전사는 종이 영수증이나 법인 카드 피드에서는 발생하지 않는 세 가지 특정 오류 유형을 만들어냅니다:
1. UI 요소 오염
결제 앱 스크린샷에는 거래 데이터가 포함되어 있지만 — 앱의 탐색 바("뒤로", "공유", "세부 정보"), 시간과 배터리 잔량이 표시된 상태 바, 때로는 떠다니는 "성공" 애니메이션, 그리고 스크린샷을 빠르게 찍었을 경우 휴대폰의 알림 트레이도 포함됩니다. 기존 OCR은 이 모든 것을 텍스트로 읽습니다. "뒤로" 버튼 라벨이 필드로 추출됩니다. 배터리 잔량 "73%"가 금액으로 읽힙니다. 상태 바의 시간 — "14:31" — 이 거래 시간으로 잘못 식별됩니다.
비주얼 AI는 화면의 시각적 문법을 이해하기 때문에 애플리케이션 크롬과 애플리케이션 콘텐츠를 구분합니다: 탐색 바는 일관된 스타일로 상단과 하단 가장자리에 있고, 상태 아이콘은 특정 모서리에 있으며, 거래 데이터는 다른 타이포그래피와 간격을 가진 중앙 콘텐츠 영역에 있습니다. 인간에게 명백한 구분 — "이것은 앱의 일부이고, 이것은 내가 원하는 데이터다" — 은 AI 모델이 분리하는 법을 배우는 부분입니다.
2. 통화 기호 및 형식 모호성
글로벌 기업은 여러 통화로 된 경비 스크린샷을 받습니다. 한국 직원이 "₩47,000"이 표시된 KakaoPay 스크린샷을 제출합니다 — ₩47,000 KRW, $47,000 USD가 아닙니다(약 $32). 일본 직원이 "¥1,280"이 표시된 PayPay 스크린샷을 제출합니다 — ¥1,280 JPY, 대략 $8. 독일 직원이 "1.280,50 €"에서 유럽식 천 단위/소수 표기법을 사용하는 은행 스크린샷을 제출합니다 — 미국식 형식을 기본값으로 사용하는 미국 OCR 엔진이 $1.28로 잘못 읽을 가능성이 있습니다.
비주얼 AI가 이러한 필드를 추출할 때, 앱에 대한 맥락적 이해 — KakaoPay는 한국 결제 앱이고, PayPay는 일본 앱이며, 독일 Sparkasse 은행 앱은 독일 로케일을 사용합니다 — 해석에 정보를 제공합니다. AI는 "1280"을 숫자 값으로 추출하고 통화 맥락을 보존하여 출력 스프레드시트가 후처리 단계에서 통화 간 정규화를 할 수 있게 합니다. 기존 OCR은 "1.280,50" 또는 "¥1,280"을 원시 텍스트 문자열로 출력하며, 누군가가 수동으로 정규화해야 합니다 — 그 자체로 오류가 발생하기 쉬운 수동 단계입니다.
3. 카테고리 분류를 별도의 수동 단계로 처리
경비 보고서에는 거래 데이터만 필요한 것이 아니라 경비 카테고리도 필요합니다. 식비 및 접대, 여행, 사무용품, 전문 서비스 또는 회사의 특정 GL 코드가 여기에 해당합니다. 수동 입력을 사용하면 재무 담당자가 각 항목에 대해 판단을 내려야 합니다. "스타벅스 — 식비. 오피스디포 — 사무용품. 우버 — 여행." 항목마다 5~10초의 인지 부담이 추가되고, 리뷰어마다 같은 가맹점을 다르게 분류하면 일관성이 떨어집니다.
AI 추출은 추론 열이라는 메커니즘을 통해 동일한 처리 과정에서 이 작업을 처리할 수 있습니다. 열을 카테고리(옵션: 식비/교통/사무/기타)로 정의하면 AI가 가맹점 이름, 거래 맥락, 문서 유형을 읽고 제공한 옵션에서 가장 가능성 높은 카테고리를 추론합니다. 별도의 분류 단계가 필요 없습니다. 추론은 사용자가 정의한 규칙(지정한 옵션 집합으로 제한)에 따라 작동하므로 전체 배치에서 일관된 결과를 얻을 수 있습니다. 동일한 기본 기능으로 결제 수단, GL 코드, 부서 또는 문서 내용에 따른 모든 업무별 분류를 추론할 수 있습니다.
수집 링크: 이메일과 Slack에서 스크린샷을 받는 일을 중단하세요
더 깊은 구조적 문제는 수동 입력이 아니라 제출 채널입니다. 직원들이 이메일, Slack, WeChat, SMS를 통해 경비 스크린샷을 제출하면 재무팀의 업무는 회계와 무관한 다운로드 및 정리 단계에서 시작됩니다. 네 개의 서로 다른 플랫폼에서 파일을 수집하고, 추적 가능하도록 이름을 바꾸고, 직원별로 그룹화하고, 어떤 제출이 완료되었고 어떤 것이 누락되었는지 확인해야 합니다.
수집 링크는 단일 제출 엔드포인트를 제공하여 이 문제를 해결합니다. 재무 담당자가 링크(고유 URL)를 생성하여 직원에게 보냅니다. 직원이 휴대폰 브라우저에서 링크를 열면 짧은 인증 코드를 입력하고 브라우저에서 직접 경비 스크린샷을 업로드합니다. 파일은 업로드 시간과 파일명으로 표시되어 재무 담당자의 계정 처리 대기열에 단일 보기로 정리됩니다. 다운로드할 이메일 첨부 파일도, 스크롤해야 할 Slack 스레드도, 문자 메시지 체인의 전달 스크린샷도 없습니다.
회사 이메일 계정이 없는 현장 팀과 외부 계약자의 경우, 이 방식은 가장 흔한 제출 실패 유형인 "보냈는데 받으셨나요?"를 제거합니다. 수집 링크는 고정된 목적지입니다. 업로드는 화면에서 확인됩니다. 재무 담당자는 처리가 시작되기 전에도 어떤 직원이 제출했고 어떤 직원이 제출하지 않았는지 정확히 확인할 수 있습니다.
Google Sheets 애드온: 경비 스프레드시트로 바로 추출
Google Sheets에서 업무를 처리하는 재무팀 — 저희가 중소기업 및 중견기업에서 흔히 확인한 가장 일반적인 경비 워크플로 패턴에 따르면, 이는 월 200건 미만의 보고서를 처리하는 상당수의 팀에 해당합니다 — Google Sheets 애드온은 내보내기 및 가져오기 단계를 완전히 제거합니다. 애드온은 모든 Google Sheet 내부에 사이드바로 열립니다. 경비 스크린샷을 사이드바에 직접 업로드하고, 열을 정의하고, 배치를 처리하면 추출된 데이터가 활성 시트에 직접 추가됩니다 — 파일 다운로드 불필요, Excel-to-Sheets 변환 불필요, 창 간 복사-붙여넣기 불필요.
애드온은 API 키에 연결되면 계정 모드로 작동합니다: 템플릿, 매칭 규칙, 처리 이력이 웹 앱과 동기화됩니다. 스프레드시트에 편집 권한이 있는 팀원은 개별 플랜 할당량 내에서 업로드 및 처리를 진행할 수 있습니다. 그 결과 재무팀 전체가 공유하는 단일 스프레드시트에 누구도 필드를 직접 입력하지 않고도 경비 데이터가 스크린샷과 영수증 사진에서 도착합니다.
실제 경비 스크린샷으로 체험하기
AI 추출이 여러분의 특정 경비 스크린샷 조합에서 제대로 작동하는지 평가하는 가장 좋은 방법은 실제 파일로 테스트하는 것입니다. 아래 데모는 expense-report 프리셋 — 날짜, 가맹점, 금액, 카테고리 열이 사전 구성됨 — 으로 실행되지만, 여러분의 경비 스프레드시트에 맞게 열을 추가, 제거 또는 이름을 바꿀 수 있습니다. 가입 불필요, 신용카드 불필요. 파일은 몇 초 안에 처리되며 세션 이후에는 저장되지 않습니다.
비용 안내
ImageToTable.ai는 4가지 플랜을 제공합니다. Free 플랜은 월 50크레딧을 포함하며, 소규모 팀이 몇 건의 경비 스크린샷을 처리하고 추출 품질이 요구 사항을 충족하는지 평가하기에 충분합니다. 월 $9의 Basic 플랜은 월 500크레딧을 제공하며, 월 100~200건의 경비 제출을 처리하는 팀에 적합합니다. 월 $19의 Pro 플랜은 2,000크레딧을 제공하며, 문서당 더 많은 크레딧이 필요한 다중 페이지 PDF 호텔 폴리오 및 공급업체 인보이스를 포함한 대용량 배치 처리를 지원합니다. 월 $59의 Max 플랜은 대용량 재무팀을 위한 10,000크레딧을 제공하며 우선 처리를 포함합니다. 모든 유료 플랜에는 Google Sheets 애드온, 템플릿 관리, 배치 내보내기 기능이 포함됩니다.
건당 $35~$58의 수동 처리 비용과 비교하면, 구독은 월 초 경비 제출 5~10건 이내에 비용을 충당합니다. 월 $19의 Pro 플랜은 Aberdeen 중소기업 요율 기준으로 재무팀이 수동 입력 노동에 약 $1,260을 지출해야 하는 동일한 분량의 경비 데이터를 처리합니다. 계산에 스프레드시트가 필요하지 않습니다 — 머릿속으로 계산할 수 있습니다.
```자주 묻는 질문
AI 추출 기능이 중국어, 일본어, 한국어 또는 기타 비영어권 언어로 된 스크린샷을 읽을 수 있나요?
네. 시각 AI 모델은 중국어(간체 및 번체), 일본어, 한국어, 아랍어, 태국어, 베트남어 및 모든 유럽 언어를 포함한 주요 언어의 텍스트를 처리합니다. Alipay, WeChat Pay, KakaoPay, PayPay 및 이와 유사한 지역별 앱의 결제 앱 스크린샷이 지원됩니다. 이 모델은 원본 언어로 데이터를 추출하고 원본 텍스트를 보존할 수 있습니다. 따라서 Alipay 스크린샷의 중국어 가맹점 이름은 음역이 아닌 중국어 텍스트로 출력 스프레드시트에 표시됩니다.
Microsoft Excel의 "Get Data from Picture" 기능과 무엇이 다른가요?
Excel의 "Get Data from Picture"는 이미지에서 보이는 모든 텍스트를 구조화되지 않은 그리드로 추출합니다. OCR 엔진이 읽을 수 있는 모든 것을 캡처하여 원본 이미지와 대략 동일한 공간 배열로 셀에 배치합니다. "이것이 내가 관심 있는 금액이다"와 "이것은 탐색 모음 텍스트다"를 구분하지 않습니다. 보이는 텍스트가 15개인 스크린샷의 경우 15개의 셀이 생성됩니다. 그런 다음 필요한 특정 데이터 포인트를 찾아 추출하고 재구성해야 합니다. 맞춤 열이 있는 AI 추출은 지정한 필드(날짜, 금액, 가맹점, 카테고리)만 추출하여 정의한 열 구조에 바로 정리해 주므로 바로 사용할 수 있습니다.
메신저 앱을 통해 전달된 압축 이미지처럼 저품질 스크린샷에서도 작동하나요?
메신저 앱(WeChat, WhatsApp, Slack 모두 이미지를 재압축함)의 압축 아티팩트는 이미지 품질을 저하시키며, 심한 압축 수준에서는 작은 텍스트를 읽을 수 없게 될 수 있습니다. AI 모델은 직원이 휴대폰에서 직접 스크린샷을 찍어 채팅 앱을 통해 전달하지 않고 업로드할 때 얻을 수 있는 선명하고 원본 해상도의 스크린샷에서 가장 잘 작동합니다. 압축된 이미지에서 텍스트가 사람의 눈으로 읽을 수 있다면 AI는 일반적으로 추출할 수 있습니다. 압축으로 인해 텍스트가 읽을 수 없는 픽셀 덩어리로 변한 경우 추출 품질이 저하됩니다.
종이 영수증과 스크린샷을 같은 도구로 처리할 수 있나요?
네, 가능합니다. 이 도구는 스크린샷, 영수증 사진, PDF 명세서, 스캔 문서를 동일한 배치에서 처리합니다 — 입력 유형이 다르다고 해서 별도의 도구를 사용할 필요가 없습니다. Alipay 스크린샷, 촬영한 종이 영수증, PDF 호텔 숙박 명세서를 함께 업로드하세요. 열을 한 번만 정의하면 됩니다 — 날짜, 거래처, 금액, 카테고리 — 출력 스프레드시트의 각 행은 소스가 디지털 스크린샷, 영수증 사진, PDF 중 무엇이든 관계없이 처리된 문서 하나를 나타냅니다.
QuickBooks, Xero 또는 ERP와 어떻게 연동되나요?
이 도구는 Excel(XLSX) 및 CSV 형식으로 출력하며, 모든 주요 회계 시스템에서 가져올 수 있습니다. QuickBooks Online과 Xero는 모두 비용 거래에 대해 CSV 및 Excel 가져오기를 지원합니다. 맞춤 가져오기 형식을 사용하는 ERP 시스템의 경우, 추출된 데이터는 기존 가져오기 파이프라인에 공급되는 정리되고 구조화된 소스 역할을 할 수 있습니다. 이 도구는 워크플로에서 회계 시스템 앞에 위치합니다 — 구조화되지 않은 스크린샷에서 구조화된 데이터를 생성하고, 그 구조화된 데이터는 일반적인 가져오기 및 대사 프로세스를 통해 이동합니다.
처리 후 스크린샷 파일은 어떻게 되나요?
업로드된 파일은 메모리에서 처리되며 활성 처리 세션 외에는 서버에 저장되지 않습니다. 계정 대시보드에서 처리된 작업을 언제든지 삭제할 수 있으며, 그러면 추출된 데이터와 소스 파일이 모두 서버에서 제거됩니다. 지속적인 규정 준수를 위해 소스 스크린샷을 자체 스토리지(Google Drive 폴더, SharePoint 문서 라이브러리 또는 파일 서버)에 보관하고, 출력 스프레드시트의 파일 이름 참조 열이 각 소스 파일로 연결되는 감사 추적 링크를 제공하는 것을 권장합니다.
결론
경비 스크린샷은 사라지지 않습니다. 직원들은 휴대폰이 자연스럽게 만들어내는 방식으로 경비 증빙을 계속 제출할 것입니다 — 결제 앱 확인 화면, 은행 거래 스크린샷, 영수증 사진, 전달된 이메일. 이러한 각 스크린샷에는 현재 재무팀 누군가가 읽고 스프레드시트에 입력하고 있는 데이터가 포함되어 있으며, 보고서당 약 $35~$58의 비용이 발생합니다. 이 비용은 급여에 포함되어 있어 눈에 보이지 않습니다 — 누군가 이 작업을 수행하고, 작업이 완료되며, 비용이 재무팀 급여에 흡수됩니다. 그러나 비용은 실제이며, 소규모 팀의 연간 비용도 다섯 자릿수에 달합니다.
시각 AI 추출은 경비 보고 워크플로를 변경하지 않습니다. 워크플로 내에서 시간의 60~70%를 소비하던 단계, 즉 이미지에서 보이는 데이터를 스프레드시트의 행으로 수동 입력하던 단계를 변경합니다. 그 단계가 15분에서 10초로 줄어들면 기준점이 이동합니다. 그리고 한 달에 12시간을 스크린샷을 읽는 데 보내던 재무팀은 그 시간을 실제로 재무 판단이 필요한 작업에 사용하기 시작합니다.