결제 스크린샷 30장, 앱 5개,
Google Sheets 원장 하나

월말에 스크린샷이 쌓이는 이유

고객이 3일에 Venmo로 결제하면 확인 화면을 스크린샷으로 찍고 계속 업무를 진행합니다. 바쁘기 때문입니다 — 월 중간에 결제 한 건을 대사하는 것은 이미 완료된 거래에 대한 행정 업무처럼 느껴집니다. 그 스크린샷은 11일의 PayPal 알림, 18일의 Zelle 알림, 23일의 Cash App 알림과 함께 카메라 롤에 쌓입니다. 30일이 되면 네다섯 개의 다른 앱에서 찍은 스크린샷이 20~40장이 되지만 장부는 비어 있습니다.

이것은 미루기가 아닙니다. 구조적인 문제입니다: 은행 피드는 앱 내 잔액을 포착하지 못합니다. NFIB에 따르면 중소기업 사업주의 42%가 월간 세무 준수에 4시간 이상을 소비하며, 그 시간의 상당 부분은 세금 계획이 아니라 기기와 앱에 흩어진 스크린샷으로 한 달을 재구성하는 일입니다 (NFIB, 2025년 6월). 여러 플랫폼에서 결제를 받는 프리랜서와 중소기업 사업주에게 병목 현상은 수익 창출이 아닙니다. 기록하는 일입니다.

스프레드시트 자체가 문제는 아닙니다 — 이미 열려 있습니다. 부족한 것은 사진 앱, Venmo, PayPal, Sheets 사이를 오가며 화면에 이미 보이는 금액을 다시 입력하지 않고, 다섯 개 앱의 스크린샷 30장을 한 번에 스프레드시트에 넣을 방법입니다. 사이드바 애드온이 바로 그 공백을 채웁니다: Google Sheets 안에서 실행되며, 스크린샷 배치를 받아 각각을 장부의 행으로 추가합니다 — 열 정의 하나, 업로드 한 번, 병합된 테이블 하나. 지원되는 필드 유형, 형식, 플랜 세부 정보 등 전체 기능은 Google Sheets 사이드바 애드온을 참조하세요.

사이드바 일괄 워크플로우의 모습

Google Sheets 애드온은 스프레드시트의 확장 프로그램 메뉴에서 열리는 사이드바 패널입니다. 스크린샷을 별도로 처리한 후 CSV를 내보내 다시 Sheets에 업로드하는 별도의 웹 앱이 아닙니다. 추출 인터페이스 자체가 장부와 동일한 브라우저 탭에서 실행되며, 활성 시트가 직접 출력 대상이 됩니다.

월말 일괄 세션은 세 가지 작업으로 진행됩니다.

아키텍처 차이가 중요합니다. 메인 웹사이트의 웹 기반 일괄 워크플로우는 스크린샷을 다운로드 가능한 스프레드시트로 처리합니다. 효과적이지만 추출과 Google Sheets 장부 사이에 내보내기 및 재가져오기 단계가 추가됩니다. 사이드바는 이 단계를 제거합니다. 추출이 스프레드시트 내부에서 이루어지며 활성 시트가 직접 출력 대상이 됩니다. 대사 공식이 이미 있는 파일을 벗어날 필요가 없습니다.

결제 스크린샷을 시트로 변환하는 기본 파이프라인 개념(열 설정 전략 및 기존 장부 구조와의 통합 포함)은 파이프라인 가이드에서 자세히 다룹니다. 사이드바의 일괄 워크플로우는 이 파이프라인이 한 번에 하나가 아닌 30개의 스크린샷을 처리하는 방식입니다.

AI가 다섯 가지 앱 레이아웃 차이를 처리하는 방법

Venmo 확인 화면과 PayPal 거래 내역 페이지를 오가본 적이 있다면, 그 시각적 차이를 아실 것입니다. Venmo는 금액을 크고 중앙에 배치된 텍스트로 표시하고, 그 위에 송금인 이름, 아래에 메모를 표시합니다. PayPal은 합계를 헤더 블록에, 수수료를 그 아래 별도 줄에, 거래 ID를 바닥글에 표시합니다. Zelle은 표준 UI가 전혀 없습니다. 은행 모바일 앱에 내장되어 있어서 Chase Zelle 화면은 Wells Fargo 화면과 전혀 다르게 보입니다. Cash App은 녹색 테마 레이아웃을 사용하며 금액을 상단에, 송금인을 보조 정보 블록에 표시합니다. 각 앱은 동일한 데이터(송금인, 금액, 날짜)를 다르게 렌더링합니다.

이것이 바로 맞춤 열 이름 추출이 중요한 이유입니다. AI는 "화면 중앙의 숫자"나 "위에서 세 번째 줄의 텍스트"를 찾지 않습니다. 전체 스크린샷을 읽고 사용자가 정의한 각 열 이름과 의미상 일치하는 값을 찾습니다. "Amount"라는 열을 정의하면 AI는 Venmo의 72px 중앙 텍스트든, PayPal 요약 표의 라인 항목이든, Zelle의 다른 거래 세부 정보와 함께 포함된 은행 확인 금액이든 결제 합계를 찾습니다.

동일한 메커니즘이 전체 열 세트에 걸쳐 작동합니다. "Payer"는 Venmo의 @사용자 이름일 수도, PayPal의 송금인 전체 이름일 수도, Zelle의 전화번호나 이메일일 수도 있습니다. "Date"는 Cash App의 MM/DD 형식일 수도, 영국 PayPal 스크린샷의 DD/MM 형식일 수도 있습니다. AI는 맥락에 따라 출력을 일관된 형식으로 정규화합니다. "App"은 추론 열로 처리할 수 있습니다. App (options: Venmo/PayPal/Zelle/Cash App/Square/Other)로 정의하면 AI는 앱의 시각적 UI 시그니처(Venmo 파란색, PayPal 헤더 레이아웃, 녹색 Cash App 인터페이스)를 인식하여 각 스크린샷을 분류하므로 각 파일을 수동으로 태그할 필요가 없습니다.

결과: 다섯 개 앱에서 가져온 30개의 스크린샷이 어떤 앱이 어떤 스크린샷을 생성했는지와 관계없이 모든 행에 동일한 다섯 개의 열이 동일한 순서로 있는 하나의 시트를 생성합니다. 앱별 열 매핑도, 형식별 템플릿 구성도 필요 없습니다. 한 번 정의하고, 모두 업로드하고, 하나의 테이블을 얻으세요.

결제 스크린샷 30장 배치에서 주목할 세 가지 사항

배치 처리는 단일 스크린샷 워크플로우에는 없는 실패 모드를 도입합니다. 그중 어느 것도 치명적이지는 않지만, 사전에 인지하고 있으면 처음 경험할 수 있는 불만족스러운 상황을 예측 가능한 워크플로우로 바꿀 수 있습니다.

1. 동일 결제에 대한 중복 스크린샷

결제가 도착했을 때 PayPal 확인 화면을 촬영합니다. 사흘 후 PayPal을 다시 열고 활동 로그에서 동일한 거래를 스크린샷으로 캡처합니다. 이미지는 다르지만 결제는 동일합니다. 두 파일 모두 배치에 포함됩니다. 해결 방법은 빠릅니다. 추출 후 원장을 날짜와 금액 기준으로 정렬하세요. 날짜, 앱, 보낸 사람, 금액이 동일한 두 행은 거의 확실히 중복입니다. 하나를 삭제하세요. 이는 15초면 충분한 확인으로, 수익이 이중으로 계산되는 것을 방지합니다.

2. 앱별 스크린샷의 누락 필드

모든 결제 앱이 동일한 필드 세트를 표시하지는 않습니다. 일부 Zelle 구현(사용 중인 은행 앱에 따라 다름)은 전체 이름 대신 보낸 사람의 이름과 성의 이니셜만 표시합니다. 일부 Cash App 확인 화면은 타임스탬프를 생략하고 날짜만 표시합니다. AI가 정의한 열에 맞는 값을 찾지 못하면 해당 셀은 비어 있습니다. 검증 전략: 추출 후 원장에서 Payer, Date, Amount 열의 빈 셀을 필터링하세요. 30장 배치에서는 총 1~4개의 빈 필드가 예상됩니다(행당 1~4개가 아님). 이 스크린샷을 따로 분리해 수동으로 열고 채우면 됩니다. 나머지 26개 이상의 행은 완전합니다.

3. 스팟 체크 전략: 30개 행을 모두 검토하지 마세요

결제 금액 30개를 수기로 옮겨 적어본 사람은 30개 숫자를 검토하는 인지적 비용을 알고 있습니다. 배치 워크플로우에서는 모든 행을 읽지 않습니다. 금액 기준 내림차순으로 정렬하고 상위 3개와 하위 3개를 확인하세요. 소수점 오류($14.00 vs $1,400.00)나 숫자 병합 오류(클라이언트가 실제로 $250.00을 지불했는데 $2,500으로 표시)는 극단값에서 즉시 드러납니다. 그런 다음 App 열을 필터링하고 앱별로 한 행씩 스팟 체크하여(Venmo, PayPal, Zelle, Cash App, Square) AI가 각 앱의 레이아웃을 올바르게 매핑했는지 확인하세요. 이 과정은 2분 미만이 소요되며 중요한 체계적 오류를 잡아냅니다.

이 검증 전략(극단값 정렬, 빈 셀 필터링, 앱별 스캔)은 실패 모드가 예측 가능하기 때문에 결제 스크린샷에 특화되어 있습니다. 영수증 배치 처리 가이드는 지출 영수증에 대한 다른 검증 패턴을 다루며, 배치 인보이스 워크플로우에는 자체적인 패턴이 있습니다. 결제 스크린샷은 인보이스나 영수증보다 문서당 필드 수가 적으며(일반적으로 지불자, 금액, 날짜, 참조 정보만 포함) 검증이 더 빠르지만, 단일 필드 누락이 해당 행의 유용성에 미치는 영향은 비례적으로 더 큽니다.

스크린샷 묘지에서 대사 검증 준비 원장으로

일괄 추출이 완료되고 검증 단계를 마치면 스프레드시트에는 Payer, Amount, Date, App, Note 열로 구성된 단일 연속 테이블에 결제 건별로 한 행씩 정리됩니다. 이후 진행되는 대사 검증 단계는 스프레드시트에 최적화된 작업으로 몇 분이면 끝납니다.

먼저 App별로 그룹화합니다. App으로 필터링한 SUMIFS 수식이나 피벗 테이블을 사용하면 Venmo를 통한 총 수령액, PayPal을 통한 총 수령액 등을 확인할 수 있습니다. 이 소계를 실제 은행 입금 내역과 비교합니다. 28일의 Venmo 일괄 이체 금액은 그 이전의 모든 Venmo 행의 합계와 대략 일치해야 합니다. 15일의 PayPal 자동 입금은 월 상반기 PayPal 스크린샷 합계와 일치해야 합니다. 이는 자동 매칭이 아니라 정합성 점검입니다. 하지만 스크린샷을 놓치거나 고객이 기록하지 않은 앱으로 결제한 경우를 발견하는 데 도움이 됩니다.

둘째, 결제자 이름을 고객 계정이나 송장 번호에 매핑합니다. 원장에 고객 열이 있다면 각 Payer 항목을 알려진 고객과 대사 검증할 수 있습니다. Venmo의 "Sarah Johnson"은 송장 시스템의 "Sarah Johnson LLC"와 동일한 고객이어야 합니다. AI는 스크린샷에 있는 내용을 추출하며, 이름 정규화는 사용자의 전문 지식이 필요한 영역입니다. 대부분의 프리랜서는 10~30명의 단골 고객을 두고 있고, 일괄 처리 첫 달 이후에는 결제자 이름 패턴이 안정되므로 이 작업량은 많지 않습니다.

월말 일괄 처리 이상으로 여러 결제 플랫폼의 수입을 장기간 추적하려면 다중 플랫폼 수입 추적 가이드에서 플랫폼 수수료 및 통화 변동 처리를 포함한 반복 대사 검증 패턴을 다룹니다. 여기서 설명하는 일괄 처리 워크플로는 입력 단계, 즉 스크린샷 30장을 원장 행으로 변환하는 작업을 처리합니다. 이후의 작업(SUMIFS, 피벗 테이블, 고객 이름 정규화)은 스크린샷이 도착하기 전과 마찬가지로 스프레드시트 안에서 이루어집니다.

자주 묻는 질문

Venmo, PayPal, Zelle, Cash App, Square, Stripe 스크린샷에서도 작동하나요?

네, 여섯 가지 모두 지원합니다. 이 추가 기능은 Venmo, PayPal, Zelle, Cash App, Square, Stripe의 결제 확인 스크린샷을 동일한 배치에서 처리합니다. Zelle은 가장 변동성이 큽니다 — UI가 사용 중인 은행 앱에 따라 다르기 때문입니다(Chase, Wells Fargo, Bank of America는 모두 Zelle 확인 화면을 다르게 표시합니다) — 하지만 열 이름 추출 메커니즘은 레이아웃과 무관합니다. AI는 "Amount"가 화면의 어디에 있는지가 아니라 의미가 무엇인지에 따라 찾습니다. 한 페이지에 여러 거래가 표시되는 Stripe 대시보드 스크린샷의 경우, 업로드 전에 이미지를 거래당 하나로 잘라내거나 Stripe 내보내기 CSV를 직접 사용하세요.

두 스크린샷이 같은 결제를 보여주면 어떻게 하나요?

두 스크린샷 모두 장부에 행을 생성합니다 — Amount, Date, Payer 값이 동일하거나 거의 동일할 가능성이 높습니다. 추출 후 Date와 App으로 정렬한 다음, 금액이 일치하는 연속된 행을 찾아 중복을 삭제하세요. 이 추가 기능은 자동으로 중복을 제거하지 않습니다. 같은 날짜에 다른 송금자가 동일한 금액을 보내는 것은 정상적인 경우이기 때문입니다 — 같은 날짜에 같은 앱을 통해 두 고객이 같은 금액을 지불하는 일은 생각보다 자주 발생합니다. 중복 판단은 자동 중복 제거보다 사람의 판단이 더 신뢰할 수 있습니다.

서로 다른 앱의 스크린샷을 한 번에 업로드할 수 있나요?

네, 그것이 핵심 사용 사례입니다. 단일 배치에 Venmo 확인 화면, PayPal 거래 스크린샷, 은행 앱의 Zelle 알림, Cash App 알림을 모두 포함할 수 있으며 — 동일한 열 정의로 처리되어 일관된 열 순서로 같은 시트에 행이 생성됩니다. 업로드 전에 앱별로 스크린샷을 그룹화할 필요가 없습니다.

스크린샷이 흐릿하거나 각도가 좋지 않으면 어떻게 하나요?

AI의 정확도는 가독성에 따라 달라집니다. 자연스럽게 촬영한 선명하고 조명이 밝은 결제 확인 스크린샷은 안정적인 추출 결과를 제공합니다. 과도하게 압축되었거나, 극단적인 각도로 촬영되었거나, 눈부심이 있는 화면에서 캡처한 스크린샷은 부분적이거나 부정확한 결과를 초래할 수 있습니다. 인쇄된 영수증 유형 문서의 경우, 이 추가 기능은 선명하게 촬영된 자료에서 최대 99%의 정확도를 달성합니다. 결제 스크린샷 — 종이 사진이 아닌 디지털 화면 캡처 — 은 본질적으로 촬영된 영수증보다 깨끗하므로 정확도가 일반적으로 더 높습니다. 특정 스크린샷이 지속적으로 좋지 않은 결과를 생성하는 경우, 앱에서 다시 캡처하여 해당 파일 하나만 다시 업로드하세요.

애드온이 세션 간에 열 구성을 유지하나요?

네, API 키를 통해 ImageToTable.ai 계정에 연결된 경우 유지됩니다. 열 이름(Payer, Amount, Date, App, Note 또는 직접 정의한 이름)은 세션 간에 유지됩니다. 다음 달에 사이드바를 열면 결제 원장 열이 이미 구성되어 있습니다. 사이드바는 여러 열 사전 설정을 지원하므로 결제 조정용 열 세트와 비용 영수증용 열 세트를 매번 필드를 다시 정의하지 않고 전환할 수 있습니다. 각 세션 후 업로드된 파일은 처리 후 삭제되며, 결제 데이터는 서버에 저장되지 않습니다.

"Payment Method"와 같은 추론 열을 추가하여 각 스크린샷을 자동 분류할 수 있나요?

네. 열을 Payment Method (options: Venmo/PayPal/Zelle/Cash App/Square/Stripe/Other)로 정의하면 AI가 앱의 시각적 UI를 기반으로 각 스크린샷을 해당 카테고리 중 하나로 분류합니다. 이는 추론 열입니다. AI는 스크린샷에 명시적으로 적혀 있지 않은 값을 시각적 패턴(예: Venmo 파란색 인터페이스, PayPal 헤더 레이아웃, Cash App 녹색 구성)을 인식하여 추론합니다. 추론 열은 직접 추출 열과 동일한 일괄 처리에서 처리되므로 분류와 추출이 동시에 이루어집니다. 동일한 방식이 원장에서 결제 유형을 추적하는 경우 "Client Category" 열에도 적용됩니다(예: Client Category (options: Hourly/Retainer/Project/Product)). 다만 해당 분류는 결제 스크린샷만으로는 AI가 갖지 못할 도메인 지식이 필요할 수 있으므로, 특정 사용 사례에 대한 정확성을 확인하려면 먼저 소규모 배치로 테스트하세요.