영국 P60 데이터 추출 완벽 가이드
급여팀을 위한

P60 데이터 추출이 실제로 의미하는 것

P60 데이터 추출은 연말 증명서(End of Year Certificate)에 있는 법정 필드(직원 NINO, 고용주 PAYE 참조번호, 해당 고용에서의 급여, 원천징수 세액, 국민보험 기여금, 최종 세금 코드)를 읽어 스프레드시트의 구조화된 열로 변환하는 과정입니다. 각 직원별, 과세 연도별로 한 행씩 기록됩니다. 증명서 자체는 HMRC 사양 RD1의 적용을 받으며, 이 사양은 대체 P60이 반드시 포함해야 하는 모든 필드를 규정하지만 시각적 레이아웃은 급여 소프트웨어 제공업체의 재량에 전적으로 맡깁니다.

이러한 구분(필수 데이터 vs. 자유 형식 레이아웃)이 바로 추출이 하나의 범주로 존재하는 이유입니다. 모든 P60이 동일하게 보인다면 템플릿 기반 OCR 도구로도 고정 좌표에서 Box 1부터 Box 6까지 읽을 수 있을 것입니다. 하지만 Sage 50cloud는 NINO를 오른쪽 상단에, PAYE 참조번호는 고용주 이름 아래 굵은 글씨로 왼쪽 하단에 인쇄할 수 있습니다. BrightPay는 테두리가 있는 섹션에 나란히 배치할 수도 있습니다. IRIS Staffology는 모든 것을 세로로 쌓을 수도 있습니다. 세 증명서 모두 HMRC 요구 사항을 동등하게 충족합니다. 세 증명서 모두 동일한 법정 필드를 포함합니다. 그리고 세 증명서 모두 그중 하나를 위해 만들어진 템플릿을 무력화합니다.

사용자 정의 열 추출 — 스프레드시트에 필요한 출력 열(“NINO,” “해당 고용 급여,” “원천징수 세액,” “NI 범주 문자”)을 정의하고 AI가 각 P60에서 필드 레이블의 위치가 아닌 의미를 이해하여 각 값을 찾아내는 방식 — 은 급여 제공업체별 설정 없이도 모든 제공업체에서 추출이 작동하도록 합니다. 동일한 열 정의가 Sage P60, Xero P60, BrightPay P60, 그리고 2023년에 관리 대상에 들어간 고용주의 스캔된 종이 P60까지 읽어냅니다. AI는 템플릿이 아닌 의미를 기준으로 읽습니다.

P60 데이터 추출이 중요한 이유

2003년 소득세(PAYE) 규정 제67조에 따라, 모든 영국 고용주는 4월 5일 기준 급여 명부에 있는 각 직원에게 P60을 제공해야 합니다. 법정 마감일은 5월 31일입니다. 증명서를 생성한 급여 소프트웨어의 경우, 여기서 워크플로가 종료됩니다. 급여 팀의 경우, 여기서 세 가지 다운스트림 워크플로가 시작되며, 그중 어느 것도 급여 소프트웨어의 P60 생성 기능으로 처리되지 않습니다.

연말 급여 대사 (FPS 기준)

여러 고용주 고객을 대상으로 연말 정산을 진행하는 급여 사무소는 모든 직원의 P60 수치가 HMRC에 실시간 정보(RTI) 시스템을 통해 제출된 연말 전액 급여 신고(FPS) 총액과 일치하는지 확인해야 합니다. 대사는 고용주별로 진행됩니다. 고용주 A의 모든 P60을 스프레드시트로 추출하고, 급여 및 세금 총액을 사무소 자체 FPS 추출 데이터와 비교하여 1파운드 단위로 일치하지 않는 행을 조사합니다. 5개 고용주 고객에 걸쳐 150명의 직원이 있는 경우, 이는 750건의 P60-FPS 비교에 해당하며, 단 한 행의 전사 오류가 불일치를 만들어 몇 달 후 HMRC 준수 점검에서 지적될 수 있습니다. 이 워크플로에 대한 자세한 내용은 급여 대사를 위해 영국 P60 데이터를 Excel로 추출하는 방법을 참조하십시오.

자진 신고 준비 (1월 마감, 5월 수집 기간)

개인 고객을 대상으로 하는 회계 법인은 1월 31일 자진 신고 마감일을 앞두고 은행 거래 명세서, 배당 바우처, P11D 양식과 함께 P60을 받습니다. 동일 과세 연도에 두 개의 병행 고용 관계를 가진 고객은 각각 고유한 고용주 PAYE 참조 번호와 "해당 고용에서의 급여" 금액이 있는 두 개의 P60 행을 생성합니다. 이는 SA100 세금 신고서의 고용 페이지에 직접 매핑되며, 고용주 A의 급여 금액이 고용주 B의 항목에 잘못 기입되는 전사 오류는 SA302 조회의 가장 일반적인 원인 중 하나입니다. 영국 급여의 5월 문제는 이러한 전사 작업이 회계사들이 모든 고객의 연말 문서 작업으로 이미 분주한 시기에 최고조에 달한다는 점입니다.

소득 확인의 대규모 처리

주택담보대출 제공자, 임대 중개인, 고용 심사 기업, 이민 자문 기관은 전년도 소득 증명을 위해 P60을 정기적으로 요청합니다. 확인 작업은 대량으로 이루어지며 필드가 제한적입니다: 이름, 국민보험번호(NINO), 고용주 PAYE 참조번호, 연간 총 급여. 신청자의 고용주가 사용하는 급여 제공자는 확인자가 통제할 수 없기 때문에, 사전 설정 없이 모든 레이아웃을 처리할 수 있는 추출 도구의 능력이 확인 파이프라인의 자동화 여부를 결정합니다. 그렇지 않으면 누군가 각 PDF를 열고 수동으로 숫자를 입력해야 합니다.

P60 추출의 독특한 과제

P60은 급여명세서나 세금 양식과 일부 추출 과제를 공유합니다 — 형식 다양성, 일관되지 않은 라벨링, 스캔본 대 디지털 품질 — 하지만 거의 다른 문서 유형에서는 발생하지 않는 세 가지 구조적 문제도 있습니다. 추출 워크플로를 설정하기 전에 이를 이해해야 6월에 스프레드시트를 수동으로 다시 수정할 필요가 없습니다.

다양한 급여 제공자 형식, 하나의 법정 사양

HMRC의 RD1 사양은 대체 P60에 대해 "형식과 레이아웃의 변형"을 명시적으로 허용합니다. Sage는 법정 증명서 섹션을 왼쪽 정렬 블록으로 인쇄하며 PAYE 참조번호를 고용주 이름 아래에 굵게 표시합니다. BrightPay는 NI 세부정보를 테두리 표로 구분합니다. Xero는 NINO를 직원 주소 블록 위에 배치합니다. QuickBooks Online은 세금 코드와 NI 범주 문자를 상단 1/4에 가로 스트립으로 표시합니다. Moorepay는 3열 그리드를 사용합니다. 여섯 가지 레이아웃 모두 규정을 준수합니다. 그중 어느 것도 템플릿을 공유하지 않습니다.

이는 사양의 결함이 아닙니다. 영국 고용주가 수십 년 동안 각기 다른 인쇄 엔진을 가진 다양한 급여 소프트웨어를 사용해 왔고, HMRC의 규제 입장은 데이터 내용을 규정할 뿐 시각적 레이아웃을 규정하지 않기 때문입니다. 추출에 대한 실질적인 결과는 Sage 생성 P60에서 작동하는 템플릿 기반 접근 방식이 BrightPay P60에서는 쓰레기를 생성한다는 것입니다. 의미 기반 추출 접근 방식(픽셀 좌표가 아닌 필드 의미로 읽기)은 "이 고용에서의 급여"가 페이지의 어디에 나타나든 동일한 의미임을 이해하기 때문에 단일 열 정의로 모든 제공자를 처리합니다.

퇴직자 P60: 모든 연말정산에 숨겨진 예외 사례

2026년 2월에 퇴사한 직원이 올해 4월 5일 기준으로 급여 명부에 등재되어 있었습니다. 즉, 해당 직원이 연말 이전에 퇴사했더라도 이전 고용주는 해당 직원이 근무한 과세 연도 분량의 P60을 발급해야 합니다. 고용주가 Sage를 사용하는데 직원이 이직한 회사가 Xero를 사용하는 경우, 새 급여 부서는 해당 팀이 거의 접하지 못하는 형식의 P60을 보유하게 됩니다. 더 나아가, 이전 고용주가 여전히 종이 증명서를 발급하는 경우 — 돌봄 및 지원 고용주 및 특정 면제 기관에 대한 HMRC 규정에 따라 허용됨 — P60은 물리적 문서로 도착합니다. 누군가 이를 휴대폰으로 촬영하여 급여 부서에 이메일로 보냅니다. 그 사진은 자체 급여 시스템에서 생성된 깔끔한 디지털 P60과 함께 추출 입력 자료가 됩니다.

퇴직자 P60은 또한 연도 간 영향을 미칩니다. 2025년 4월부터 2026년 2월까지 고용주 A에서 근무한 후, 2026년 2월부터 4월까지 고용주 B에서 근무한 직원은 동일한 과세 연도에 해당하는 두 개의 P60을 보유합니다. 해당 연도의 총 과세 소득은 두 P60의 "이 고용에서의 급여" 금액을 합한 값입니다. 하지만 어느 P60에도 그 합계가 표시되지 않습니다. 계산은 추출 후 스프레드시트에서 이루어지며, 두 P60이 동일한 통합 문서에 정확하게 추출되어야 합니다. 두 행 중 하나라도 숫자가 하나 잘못 입력되면 총액이 잘못 계산되며, 이는 결국 종합소득세 신고 시 드러나게 됩니다.

연도 간 데이터: 국민보험 등급 문자 문제

직원의 국민보험 등급 문자가 연도 중간에 변경되는 경우 — 가장 일반적으로 국민연금 수급 연령 도달 시 A에서 C로 변경 — P60에는 두 개의 서로 다른 등급 문자 아래에 두 개의 별도 NI 행이 표시됩니다. 각 행에는 자체 소득 구간(LEL, LEL~PT, PT~UEL, UEL 초과)과 직원 부담금이 있습니다. Sage는 이를 왼쪽에 문자 레이블이 있는 두 개의 인접한 행으로 인쇄합니다. Xero는 문자를 섹션 헤더로 사용하여 별도의 테이블 섹션으로 인쇄합니다. 두 행을 단일 "총 NI" 수치로 통합하는 추출 시스템 — 일반적으로 급여 명세서용으로 설계되었다가 P60에 맞게 개조된 도구에서 흔함 — 은 고용주가 RTI 제출과 대조할 때 필요한 등급 문자별 분석을 잃게 됩니다.

NI 등급 문자 세트는 제한적입니다: A, B, C, F, H, I, J, L, M, S, V, X, Z. 추출된 스프레드시트에서 이 세트 외부의 값은 기재 오류 또는 추출 실패입니다. 대부분의 P60이 문자 A(표준 요율)를 사용하기 때문에 NI 등급 열에 잘못된 "D" 또는 "K"가 있는 경우 간단한 Excel 유효성 검사 규칙으로 감지할 수 있습니다. 하지만 이 감지는 추출 시 전용 열에 문자를 보존한 경우에만 작동하며, 두 NI 행을 기여금이 합산된 단일 행으로 병합한 경우에는 작동하지 않습니다.

수동 방식 vs AI 기반 P60 데이터 추출

P60 데이터를 스프레드시트로 가져오는 방법은 세 가지이며, 선택에 따라 5월 급여 기간이 타이핑 마라톤이 될지, 파일 업로드 후 내보내기로 끝날지가 결정됩니다.

템플릿 기반 OCR은 레거시 문서 처리 도구에서 사용하는 방식으로, 문서 이미지에 사각형 영역을 정의하고 각 영역 내에서 OCR을 실행합니다. Sage P60에서 직원 NINO가 A4 페이지 좌표 (530, 280, 700, 300)에 있는 경우, 템플릿은 해당 사각형 안의 텍스트를 읽습니다. NINO가 좌표 (400, 190, 600, 210)에 있는 BrightPay P60의 경우 빈 셀이나 잘못된 필드 값을 생성합니다. 영국 급여 제공자들은 근본적으로 다른 P60 레이아웃을 사용하기 때문에, 템플릿 시스템은 제공자별로 하나의 템플릿이 필요하고, 디지털 레이아웃과 일치하지 않는 스캔된 종이 P60을 위한 대비책도 필요합니다. 게다가 제공자가 인쇄 형식을 업데이트할 때마다 템플릿은 조용히 깨집니다.

AI 의미 기반 추출은 이 로직을 반전시킵니다. 데이터가 페이지의 어디에 있는지 정의하는 대신, 스프레드시트에 필요한 열 이름을 입력하여 무엇을 원하는지 정의합니다. AI는 전체 문서를 읽고, 세금 증명서 구조 내에서 각 필드의 의미적 역할을 식별하여 픽셀 위치와 관계없이 해당 열을 채웁니다. Sage P60, BrightPay P60, 그리고 퇴사자의 이전 고용주가 보낸 종이 P60을 핸드폰으로 찍은 사진까지 모두 동일한 스프레드시트에 데이터가 채워진 행을 생성합니다. AI가 좌표가 아닌 의미로 매칭하기 때문입니다. 이것이 위치 기반 추출에서 의미 기반 추출로의 근본적인 전환입니다.

효율성 차이는 규모가 커질수록 더 벌어집니다. P60 한 건당 2분씩 수동 입력하면 150명의 직원 데이터를 입력하는 데 5시간의 집중적인 타이핑 작업이 소요됩니다. 이는 급여팀이 최종 EPS를 처리하고, P32를 조정하고, 이사회가 월말까지 요구하는 보고서를 준비해야 하는 5월 기간 중에 발생합니다. AI 추출은 동일한 150개의 P60을 총 약 15~25분 만에 처리합니다. 수동 방식에 대한 더 자세한 비교는 P60 데이터 입력의 숨은 비용을 참조하십시오.

추출할 주요 P60 필드

P60에는 대부분의 추출 워크플로우에 필요한 것보다 더 많은 필드가 있습니다. 추출할 필드는 스프레드시트가 어떤 용도로 사용될지에 따라 달라지지만, 필드 자체는 HMRC의 RD1 사양에 정의되어 있습니다. 각 필드의 용도를 이해해야 출력 결과가 다운스트림 작업을 해결할지, 아니면 새로운 조정 문제를 만들지 결정됩니다.

스프레드시트 결과적으로, 150명의 직원에 대한 완전한 P60 추출은 모든 NI 구간 분석을 포함할 때 약 150행과 20~25열을 생성합니다. 열 정의는 과세 연도 간에 재사용 가능합니다. HMRC의 법정 필드 세트는 법률이 변경될 때만 변경되며, 변경 시(2025-26 사양에 법정 신생아 진료 급여 추가와 같이) 나머지를 재구축하지 않고 새 열을 추가합니다.

P60 대량 일괄 처리

P60 한 장을 처리하는 것은 문제가 아닙니다. P60 한 장의 필드를 Excel로 추출하는 것은 자동화가 아닌 주의가 필요한 작업입니다. 문제는 규모가 커질 때 발생합니다 — 직원 100명, 세 가지 급여 제공업체, 인수한 회사 퇴사자들의 스캔된 종이 P60 몇 장 — 이 규모에서는 구조적 과제가 "이 필드를 읽을 수 있는가"에서 "이 스프레드시트의 모든 행이 정확히 하나의 원본 문서와 하나의 과세 연도로 추적 가능한가"로 바뀝니다.

일괄 처리는 여러 파일 작업을 단일 업로드 및 내보내기 시퀀스로 축소합니다: Sage 출력, Xero 출력, 스캔된 종이, 휴대폰 사진 등 모든 P60 PDF를 하나의 배치에 드롭하고, 열 이름을 한 번 정의한 후, 각 행이 하나의 P60인 통합 스프레드시트를 받습니다. 5월 31일 마감 전에 100개 이상의 P60을 일괄 처리하는 것이 추출을 문서별 편의에서 급여팀 워크플로로 전환시킵니다.

150개의 P60을 한 번에 처리하기 전에 세 가지 일괄 처리 관련 고려 사항을 다루는 것이 좋습니다:

P60 데이터 내보내기 및 활용

추출된 데이터는 다운스트림 워크플로우가 있는 곳에 전달되어야 합니다. P60 데이터는 각각 형식 요구사항이 다른 세 가지 주요 대상으로 전송됩니다:

• Excel (XLSX) — 급여 조정을 위한 기본 형식입니다. 추출된 데이터는 적절한 열 헤더, 표준화된 날짜 형식(과세 연도는 "2025-26"으로 표시), 숫자로 서식이 지정된 숫자 필드와 함께 제공됩니다. 즉, 통화 값이 텍스트로 저장되거나 NINO가 병합된 셀에 분할되어 있는 경우를 다시 포맷할 필요 없이 P60 추출 방법 가이드에 설명된 검증 수식을 즉시 적용할 수 있습니다.
• CSV — 급여 소프트웨어, 회계 시스템 또는 자체 조정 도구로 대량 가져오기 위한 형식입니다. 대부분의 급여 플랫폼은 보상 데이터에 대해 CSV 가져오기를 지원하며, 추출 과정에서 깨끗한 CSV를 얻으면 가져오기 전에 수동으로 스프레드시트 서식을 지정하는 중간 단계를 건너뛸 수 있습니다.
• JSON — 맞춤형 통합, API 기반 검증 파이프라인 또는 RTI 제출 데이터 추출과의 자동 교차 확인을 위한 형식입니다.

Google Sheets에서 조정 작업을 수행하는 팀의 경우, Google Sheets 사이드바 애드온을 사용하면 내보내기 및 재가져오기 과정 없이 추출된 P60 필드를 활성 시트에 직접 기록할 수 있습니다. Sheets 내에서 P60 PDF를 업로드하고 열 이름을 정의하면 데이터가 다음 빈 행에 자동으로 입력됩니다.

P60 데이터 추출 방식 선택

P60 추출에 중요한 기능은 송장 추출이나 영수증 스캔에 중요한 기능과 다릅니다. 한 달에 10,000장의 송장을 처리하는 도구가 150개의 P60에는 전혀 적합하지 않을 수 있습니다. P60의 구조(법정 필드, NI 카테고리 문자 분할, 퇴사자 예외 사례, 연도 간 데이터)는 일반 추출 도구가 처리하도록 설계되지 않은 요구 사항을 만들기 때문입니다. 평가해야 할 기준은 다음과 같습니다:

이러한 항목들은 P60 추출에 특화된 기준입니다. 송장 처리에 뛰어난 도구가 NI 등급 문자 테스트에서 실패할 수 있습니다. 급여 명세서를 잘 처리하는 도구가 퇴사자 P60의 예외 상황에서 어려움을 겪을 수 있습니다. 실제 문서(지저분한 문서 포함)로 테스트한 후에야 해당 도구가 이상적인 버전이 아닌, 팀이 실제로 받는 P60 업무를 처리할 수 있는지 확인할 수 있습니다.

자주 묻는 질문