PayPay 스크린샷에서 금액, 날짜, 가게 이름
추출하기

PayPay 거래 내역 항목에 실제로 표시되는 내용

PayPay 앱을 열고 홈 화면 상단의 내역 아이콘(取引履歴)을 탭한 다음 완료된 결제를 선택하세요. 이동한 항목에는 거래마다 일관된 필드 세트가 표시되며, 앱 업데이트 때마다 레이아웃이 미묘하게 새로고침되더라도 마찬가지입니다.

상단에는 금액이 ¥ 접두사와 함께 엔화로 표시됩니다. 그 아래 또는 화면 버전에 따라 인접한 위치에는 가게 이름(店舗名)이 표시되며, 가맹점이 PayPay에 등록한 로고가 함께 표시되는 경우가 많습니다. 그 아래에는 거래 날짜 및 시간이 일본 표준 형식인 YYYY/MM/DD HH:MM으로 표시되며, 항상 일본 표준시(JST, UTC+9)를 따릅니다.

그 다음에는 PayPay를 미국이나 유럽의 결제 앱과 차별화하는 두 가지 필드가 있습니다. 이 거래에서 적립된 포인트(ポイント) 수와 결제 수단(支払方法) — 즉 자금이 실제로 나온 자금 출처입니다. 그 아래에는 거래 ID(取引ID)와 초록색으로 표시된 "支払い完了"(결제 완료) 상태 태그가 있습니다.

이 필드는 모든 거래에서 화면의 동일한 영역에 나타나지만, 가맹점의 QR 코드를 스캔하여 결제했는지, 계산원이 바코드를 스캔하게 했는지, 아니면 PayPay 앱으로 리디렉션되는 온라인 결제를 통해 결제했는지에 따라 정확한 세로 순서가 약간 달라집니다. 금액과 가게 이름은 항상 상단 또는 그 근처에 있습니다. 포인트와 결제 수단은 중간 영역에 있습니다. 거래 ID는 가장 작은 글꼴로 하단에 있습니다.

금액, 날짜, 가게 이름: 필요한 세 가지

금액은 화면에서 가장 눈에 띄는 요소로, 가장 큰 숫자이며 정수 엔 결제의 경우 소수 자리 없이 ¥1,234 형식으로 표시됩니다. 세금 포함 ¥1,100 결제가 이루어진 경우 화면에는 ¥1,000이 아닌 ¥1,100이 표시됩니다. PayPay 거래 화면 자체에는 세금 내역이나 소계 줄이 없습니다. 표시된 숫자는 잔액에서 차감된 최종 금액입니다. 세전 금액이 필요한 후속 사용(세금 신고 범주, 세금 포함 금액과 세금 별도 금액을 구분하는 비용 보고서)의 경우 역산해야 합니다. 일본의 표준 소비세율은 10%이며, 식품(軽減税率)에는 인하된 8% 세율이 적용됩니다. 특정 거래가 인하된 세율 적용 대상이었는지 여부는 가게와 구매 품목에 따라 달라지며, PayPay 항목에는 세율이 표시되지 않습니다. 금액은 금액일 뿐입니다.

날짜 및 시간은 간단하지만 주목할 점이 두 가지 있습니다. 첫째, 형식은 항상 일본 시간입니다. 다른 시간대에서 세금 신고를 하는 주재원이나 원격 근무자라면 PayPay 스크린샷의 타임스탬프는 여행 중 구매 시점의 현지 시간이 아니라 도쿄에서 거래가 결제된 시간을 반영합니다. 둘째, 기록된 시간은 결제 완료 시간이지, 앱을 연 순간이나 계산원이 거래를 시작한 순간이 아닙니다. 마감일이 중요한 월말 회계의 경우 — 31일 23:58 거래 대 1일 00:02 거래 — PayPay 타임스탬프가 결정적입니다.

가게 이름은 변동성이 가장 큰 필드이며, 수십 개를 기록하기 전에 그 이유를 이해하는 것이 좋습니다. Seven-Eleven이나 Lawson 같은 편의점, Seiyu 같은 슈퍼마켓 체인, Matsumoto Kiyoshi 같은 드러그스토어 등 대형 체인의 경우 가게 이름은 결제 직후 표시되며, 종종 회사의 공식 로고와 함께 나타납니다. 소규모 독립 상점의 경우 표시되는 이름은 해당 상점이 계정을 만들 때 PayPay에 등록한 이름입니다. 이는 법인명, 상호, 또는 가게 전면의 한자와 완전히 일치하지 않는 로마자 표기일 수 있습니다. 특히 PayPay Card(신용카드) 거래의 경우 결제 상태가 "승인됨"(노란색 화면)에서 "결제 완료"(초록색 화면)로 바뀔 때까지 가게 이름이 표시되지 않는 경우도 있습니다. 이는 PayPay가 2024년 6월에 해결한 문제로, 대기 기간 동안 사용자가 가게 이름을 수동으로 등록할 수 있게 했습니다. 스크린샷에 일반 자리 표시자나 인식할 수 없는 이름이 표시되면 상단 바의 상태 색상을 확인하세요. 노란색이면 이름이 아직 표시될 수 있습니다.

포인트(ポイント) 및 결제 수단(支払方法): PayPay에만 있는 두 필드

일본 외의 어떤 결제 앱도 특정 거래에서 적립된 로열티 포인트 수를 같은 화면에 보여주지 않습니다. PayPay는 보여줍니다.

거래 상세 화면의 포인트(ポイント) 줄에는 해당 결제로 적립된 정확한 포인트 수가 표시됩니다. QR 거래의 기본 적립률은 결제 금액의 0.5%이지만, 월간 활동 기반 부스트 프로그램인 PayPay STEP을 이용하면 적립률이 1.0%로 올라가고, PayPay Card를 보유하고 지출 기준을 충족하는 사용자는 1.5%까지 도달할 수 있습니다. Sukiya에서의 ¥2,000 점심은 기본 적립률로 10포인트, STEP 활성 시 20포인트를 적립할 수 있습니다. 포인트는 각각 1엔의 가치가 있으며 만료일(期限なし)이 없습니다. 이는 포인트가 일반적으로 몇 달 안에 만료되는 일본의 거의 모든 다른 포인트 시스템과 PayPay를 구별하는 정책입니다.

각 거래 화면의 포인트 수치는 단순한 누계가 아닙니다. 해당 특정 결제에 연결되어 있습니다. 캐시백 조정을 위해 한 달 동안 적립된 총 포인트를 추적하거나, 결제의 순 비용과 생성된 포인트 가치를 분리해야 하는 경우, 이 필드가 이를 가능하게 하는 데이터 포인트입니다. 그리고 이 필드는 다른 어떤 플랫폼의 결제 스크린샷에도 존재하지 않습니다.

결제 수단(支払方法) 필드는 사용된 자금 출처를 알려줍니다: PayPay 잔액(PayPay残高), 연결된 은행 계좌, PayPay Credit, PayPay Card 또는 조합입니다. 이는 단일 PayPay 계정이 여러 거래에서 여러 출처를 사용할 때 중요합니다. 일본에서 사용자가 일상 지출을 위해 소액의 PayPay 잔액을 유지하고 더 큰 구매를 위해 신용카드를 연결하는 일반적인 설정입니다. 스크린샷 묶음에는 세 가지 다른 방식으로 자금 조달된 거래가 포함될 수 있으며, 예산 편성이나 세금 목적으로 결제 수단별 비용 분류를 하는 경우 支払方法 줄이 이를 구별하는 방법입니다. 다른 어떤 결제 앱 스크린샷에도 포함되지 않는 이 필드가 없으면 각 거래를 별도의 은행 거래 내역서나 카드 명세서와 교차 참조해야 합니다.

이 두 필드는 앱 화면에서 시각적으로만 표시됩니다. PayPay가 2025년 2월에 다운로드용으로 도입한 거래 CSV에는 포함되지 않습니다 — CSV에는 거래 날짜, 설명, 거래 상대방, 금액이 포함되지만 거래당 적립 포인트나 결제 수단 내역은 포함되지 않습니다. 이 두 값을 필요로 한다면 스크린샷이 유일한 출처입니다.

이 구분 — 스크린샷이 공식 CSV에는 없는 필드를 캡처한다는 점 — 은 PayPay에 특히 스크린샷 추출이 중요한 실용적인 이유입니다. 동일한 접근 방식은 모든 결제 앱에서 작동합니다: WeChat Pay, Alipay, Venmo, PayPal. 단일 열 정의 세트 — Amount, Date, Store, Points, Pay Method — 는 모든 앱의 스크린샷에서 데이터를 가져옵니다. 추출은 데이터가 의미하는 바를 읽기 때문이며, 어떤 앱의 템플릿에서 왔는지는 중요하지 않습니다. 일본의 또 다른 지배적인 모바일 결제 앱인 LINE Pay는 유사한 거래 내역 디자인을 사용하며 동일한 스크린샷-스프레드시트 격차에 직면하고, Mercari의 Merpay 거래 스크린샷도 동일한 열 세트에 맞습니다.

PayPay 스크린샷이 영수증으로 인정되는 경우

일본에서 PayPay 거래 스크린샷은 세금 신고 시 유효한 증빙 문서로 인정됩니다. 단, 한 가지 조건이 있습니다. 금액, 날짜, 거래 상대방(가게 이름)이 표시되어야 한다는 것입니다. 일본 세무사가 Zeiri4.com에서 "PayPay 거래 내역 스크린샷은 세금 신고(確定申告) 시 영수증 대체로 사용할 수 있다"고 확인했습니다. 단, 이 세 가지 데이터 포인트가 표시되어야 합니다. 동일한 포럼 스레드와 Freee의 세무 상담 Q&A에서의 별도 논의에서도 청색 신고(青色申告)를 제출하는 개인 사업자(個人事業主)가 PayPay 스크린샷을 経費(사업 비용) 증빙으로 정기적으로 사용한다고 확인했습니다.

전자 장부 보존법(電子帳簿保存法)은 2022년에 개정되어 전자적으로 생성된 거래 기록의 전자 보관을 요구합니다. 이는 PayPay 스크린샷을 파일로 저장하는 것이 단지 허용되는 것만이 아니라, 디지털 기록만 생성되는 거래의 경우 법적으로 적합한 보관 방식임을 의미합니다.

추출된 PayPay 행이 수동 입력을 대체하는 세 가지 일반적인 후속 경로:

세금 신고(確定申告): 일본의 세 가지 지배적인 클라우드 회계 플랫폼 — freee, MoneyForward Cloud, Yayoi (弥生) — 은 CSV 거래 데이터를 가져올 수 있지만, PayPay의 은행 연동은 기존 은행 계좌 및 신용카드에 비해 제한적입니다. 많은 사용자가 PayPay 거래를 하나씩 수동으로 입력합니다. 스크린샷에서 필드(금액, 날짜, 가게 이름, 선택적으로 포인트 및 결제 수단)를 추출하여 CSV로 만든 다음 회계 소프트웨어로 가져오면 매년 2월 일요일 오후를 채우는 수동 타이핑 단계를 제거합니다.

비용 청구(経費精算): 비용 관리에 Concur를 사용하는 일본 기업은 PayPay 계정을 직접 연결할 수 있습니다. PayPay는 공식 Concur 통합을 추가하여 직원이 거래 내역 화면에서 영수증 사진을 첨부하여 비용을 제출할 수 있게 했습니다. 그러나 다른 시스템을 사용하는 기업이나 회사가 Concur-PayPay 연결을 설정하지 않은 직원의 경우 워크플로우는 여전히 동일합니다. 거래를 스크린샷으로 찍고, 비용 양식에 값을 입력하고, 스크린샷을 증빙으로 첨부합니다. 스크린샷에서 행을 추출하면 비용 양식 필드가 이미 이미지에 있는 데이터로 채워집니다.

가계부(家計簿): 일본에서 가장 인기 있는 개인 금융 앱 — Zaim(OCR을 사용하여 영수증 사진을 자동 분류) 및 MoneyForward ME (マネーフォワードME, 은행 계좌와 신용카드에 연결됨) — 은 동일한 PayPay 격차에 직면합니다. PayPay가 개인용 API 액세스를 제공하지 않기 때문에 PayPay 앱에서 거래 데이터를 직접 가져올 수 없습니다. 예산 편성 포럼과 Reddit의 r/japanlife에서 널리 논의되는 해결 방법은 PayPay 내역을 스크린샷으로 찍어 앱의 영수증 스캔 기능에 제공하거나 각 거래를 수동으로 기록하는 것입니다. Zaim의 영수증 OCR은 종이 영수증을 읽지 PayPay 화면을 읽지 않습니다. 레이아웃이 다르고, 포인트 줄이 표준 감열지 영수증 형식을 기대하는 기존 OCR 엔진을 혼란스럽게 합니다.

스크린샷 하나에서 거래 내역 스프레드시트로

PayPay 결제 한 건은 간단합니다. 앱을 열고 금액을 확인하면 끝입니다. 하지만 PayPay는 모든 것에 사용됩니다 — 7-Eleven 방문, 라멘 가게, 택시, 종이 청구서의 바코드를 스캔하여 납부하는 공과금까지. 한 달이 끝나면 앱의 거래 내역은 개별 항목의 긴 목록이 되며, 각 항목은 탭하여 세부 정보를 열어야 합니다. 그 목록을 필터링하고 합산할 수 있는 열로 변환하려면 각 항목에서 데이터를 한 번에 하나씩 추출해야 합니다 — 스크린샷 방법을 사용하지 않는 한 말이죠.

기존 OCR — 영수증 사진을 읽고 숫자를 추출하는 방식 — 은 PayPay 화면에는 잘 맞지 않습니다. 종이 영수증은 예측 가능한 구조를 가집니다: 항목, 소계, 세금, 합계가 거의 동일한 세로 순서로 나열됩니다. PayPay 거래 항목은 파싱이 아닌 한눈에 보기 위해 설계된 모바일 UI입니다. 금액은 큰 글꼴로 상단에 있지만 라벨이 없습니다. 포인트 숫자는 중간에 "P" 아이콘과 함께 있는 독립된 숫자로, OCR 엔진은 이를 또 다른 통화 금액으로 보고 실제로는 20포인트인데 ¥20으로 기록할 수 있습니다. 가게 이름은 텍스트 라벨 없이 로고 아이콘 옆에 나타날 수 있으며, OCR은 아이콘을 노이즈로 처리합니다.

템플릿 기반 추출 — "금액은 여기, 날짜는 여기"에 경계 상자를 그리는 방식 — 은 PayPay가 필드 위치를 8픽셀 이동시키는 UI 업데이트를 출시하는 순간 깨집니다. 또는 가게 이름이 평소보다 길어서 두 줄로 넘어가는 경우에도 마찬가지입니다. 각 변형은 깨진 템플릿입니다.

대안은 의미 기반 추출입니다: 도구에 어디를 볼지 알려주는 대신, 어떤 개념을 찾을지 알려줍니다 — "엔화 결제 금액," "거래가 완료된 날짜," "등록된 가게 이름," "적립 포인트 수." 추출 엔진은 사람이 읽는 방식으로 화면을 읽습니다: 두 값이 세 줄 또는 다섯 줄로 분리되어 있든, 어떤 앱 버전이 스크린샷을 생성했든 관계없이 ¥2,480을 거래 금액으로, 12P를 적립 포인트로 인식합니다. 동일한 열 정의는 보유한 모든 PayPay 스크린샷에서 작동하며, 중요하게도 다른 결제 앱의 스크린샷에서도 작동합니다. PayPay ¥1,200 점심 결제와 Line Pay ¥800 편의점 결제는 동일한 스프레드시트의 동일한 Amount 및 Date 열에 들어갑니다. 두 경우 모두 동일한 의미 기반 쿼리로 추출이 실행되기 때문입니다.

반복되는 시나리오 — 월말에 폴더 정리 컬렉션으로 모인 PayPay 스크린샷을 하나의 정렬 가능한 표로 변환해야 하는 경우 — 병목 현상은 결코 데이터가 아닙니다. 데이터가 하나의 파일에 30개의 행이 아닌 30개의 개별 이미지로 존재한다는 점이 문제입니다. 행을 꺼내는 것은 입력의 문제가 아니라 추출의 문제입니다.

FAQ

스크린샷 대신 PayPay 거래 데이터를 내보낼 수 없나요?

PayPay는 2025년 2월에 거래 내역 CSV 다운로드를 도입했으며, 지난 2년간의 데이터를 포함합니다. CSV에는 거래 날짜, 설명, 거래 상대방, 금액이 포함되지만, 거래당 적립 포인트나 사용된 결제 수단은 포함되지 않습니다. 이 두 필드가 필요하다면 스크린샷이 유일한 출처입니다. 핵심 세 가지 필드(금액, 날짜, 가게)만 필요한 사용자에게는 CSV 내보내기가 작동하지만, 앱에 로그인하고 내보내기 메뉴로 이동하여 다운로드를 기다려야 하는 다단계 프로세스가 필요합니다. 결제 시점에 캡처된 스크린샷은 이 과정을 완전히 우회합니다.

PayPay 스크린샷이 다른 앱 버전 및 UI 언어에서도 작동하나요?

네. 거래 상세 화면의 필드(금액, 가게 이름, 날짜, 포인트, 결제 수단)는 앱 UI가 일본어 또는 영어로 설정되어 있어도 동일한 세트입니다. 주변 라벨이 "支払い金額" 또는 "Payment Amount"로 표시되어도 ¥ 기호는 동일한 의미입니다. 추출은 이미지에서 숫자, 가게 이름 텍스트, 날짜 문자열을 읽습니다. 주변의 UI 언어는 결과에 영향을 미치지 않습니다.

가게 이름이 누락되었거나 일반적인 경우 거래를 어떻게 식별하나요?

일반적이거나 누락된 가게 이름(소규모 상점이 PayPay에 공식 상호를 등록하지 않았거나 PayPay Card 거래가 아직 "승인됨"(노란색) 상태인 경우 흔함)은 금액, 날짜, 시간의 조합으로 식별할 수 있습니다. 평일 12:35에 인식되지 않는 가맹점 이름으로 결제된 ¥980 결제는 일부 거래 항목에 카테고리 태그(예: "コンビニ" 또는 "飲食")로 표시되는 위치 컨텍스트와 결합하면 어느 가게인지 확인하기에 충분합니다. 일괄 추출 중 가게 이름 열에 자리 표시자가 표시되면 날짜 및 금액 열이 나중에 이름을 수동으로 채우기에 충분한 교차 참조 자료를 제공합니다. 스프레드시트에 하나의 모호한 가게 이름이 있는 것은 30건의 거래를 처음부터 입력하는 것보다 여전히 빠릅니다.