100장 이상의 영국 P60, 5월 31일까지
하나의 감사 스프레드시트, 수동 입력 불필요

P60 100장 이상이 1장과 근본적으로 다른 문제인 이유

P60 한 장을 처리하는 것은 이미 해결된 문제입니다. — 필드를 Excel로 추출하는 작업은 도구가 아니라 주의력이 필요합니다. PDF를 열고, 법정 항목을 찾아, 일곱에서 여덟 개의 숫자를 한 행에 입력하면 됩니다. 하지만 볼륨이 생기는 순간 — 직원 100명, 급여 제공업체 3곳, 종이 증명서를 가진 인수 회사 퇴사자 몇 명 — 문제는 속도가 아니라 구조에 관한 것이 됩니다.

단일 문서 규모에서는 존재하지 않는 세 가지 구조적 문제가 100장 이상 규모에서 나타납니다. 이 중 어느 것도 파일을 더 빨리 처리한다고 해결되지 않습니다.

이 각각의 문제에는 5월에 더 많은 데이터 입력 직원을 고용하는 것 외의 해결책이 있습니다. 핵심은 출력물이 스프레드시트가 아니라 6개월 후에 원본 데이터를 생성하지 않은 사람이 읽을 감사 기록이라고 생각하고 배치 워크플로우(파일 준비부터 열 스키마까지)를 설계하는 것입니다.

멀티 포맷 현실: 세이지도 브라이트페이도 150DPI 스캔본이 아니다

HMRC는 단일 P60 레이아웃을 강제하지 않는다. 내용을 강제할 뿐이다. 사양 RD1에 따라 대체 P60은 특정 항목(직원 이름, NI 번호, PAYE 참조번호, 연간 총 급여, 총 공제 세액, 학자금 대출 공제, 최종 세금 코드, 고용주 정보)을 표시해야 하지만, 시각적 배열은 각 급여 소프트웨어 공급업체에 맡겨진다. 그 결과, Sage 50cloud의 P60은 BrightPay의 P60과 구조적으로 다르고, QuickBooks Online Payroll P60, Moorepay P60, IRIS P60도 각각 다르다. 게다가 원본을 분실한 직원들이 제출한 스캔 종이 사본까지 더해진다.

전통적인 템플릿 기반 추출(샘플 P60의 필드 주위에 사각형을 그리는 방식)은 각 급여 공급업체별로 별도 템플릿을 요구함으로써 이 문제를 처리한다. 공급업체 5곳을 유지하면 템플릿 5개를 유지해야 한다. 공급업체가 새 과세 연도에 맞춰 P60 레이아웃을 업데이트하면(HMRC 지침 변경, 리브랜딩, 서식 변경) 템플릿은 조용히 정렬되지 않은 출력을 생성한다. 급여 관리자는 FPS 합계와 조정이 맞지 않을 때서야 이를 발견한다.

의미론적 추출은 위치가 아닌 의미를 위해 문서를 읽음으로써 공급업체별 템플릿 문제를 제거한다. "NI 번호", "연간 총 급여(£)", "공제 세액(£)", "PAYE 참조번호", "최종 세금 코드" 등 원하는 열을 한 번 정의하면 AI가 데이터가 페이지의 어디에 있는지가 아니라 무엇을 나타내는지 이해하여 모든 P60에서 각 값을 찾는다. Sage 50cloud P60, BrightPay P60, QuickBooks P60, 2023년 스캔 종이 P60 모두 동일한 열 정의에 입력된다. 영국 P60의 개별 필드와 추출 시 각 필드의 작동 방식에 대한 자세한 설명은 단일 P60 추출 가이드를 참조하라. 이 글은 그 가이드가 끝난 지점부터 시작한다: P60을 하나씩 생각하는 것을 멈추면 어떤 일이 일어나는가.

영국 급여 맥락에서 이것이 특히 가치 있는 이유는 PAYE 참조번호(123/AB456 형식)가 어떤 급여 소프트웨어로 생성되었든 동일 고용주의 모든 P60에서 일관되게 유지되기 때문이다. 정규 직원에게 Sage를, 계약직 직원에게 BrightPay를 사용하는 회사는 동일한 PAYE 참조번호를 가지지만 시각적으로 다른 두 형식의 P60을 발행한다. 의미론적 추출은 레이아웃이 아닌 값을 읽는다. 출력 스프레드시트의 "PAYE 참조번호" 열은 두 공급업체 모두에서 동일하게 채워져 다중 공급업체 배치를 위한 자연스러운 그룹화 키를 제공한다.

대량 파일 명명: 모든 행을 원본까지 추적 가능하게

일괄 P60 작업에서 가장 중요한 결정은 파일 하나를 업로드하기 전에 이루어집니다: 바로 원본 문서의 이름을 어떻게 지을지입니다. 출력 스프레드시트에 100개의 행이 있고, 3개월 후 HMRC 규정 준수 담당자가 "47번 행의 기반이 된 P60을 보여주세요"라고 요청했을 때, "스프레드시트와 다운로드 폴더를 대조해 봐야 합니다"라고 답해서는 안 됩니다. 즉시 찾을 수 있는 파일명이어야 합니다.

감사 추적성을 갖춘 명명 규칙은 세 가지 구성 요소를 포함합니다:

결과 파일명 패턴인 AB123456C_2025-26_sage.pdf은 감사 추적을 파일명 자체에 내장합니다. 추출 도구가 출력에 파일명을 보존할 때(ImageToTable.ai는 일괄 내보내기에서 기본적으로 "파일 이름" 열을 포함), 스프레드시트의 모든 행은 자체 출처를 갖게 됩니다. 외부 참조가 필요 없습니다.

여러 PAYE 제도에 걸쳐 직원을 관리하는 급여 팀(20개 고객 법인의 급여를 관리하는 인력 공급 회사, 또는 각 자회사가 자체 PAYE 참조 번호를 가진 그룹 구조)의 경우, PAYE 참조 형식 123/AB456이 자연스러운 일괄 그룹화 키가 됩니다. 123/AB456이 있는 모든 P60을 한 배치로 처리하고, 456/CD789가 있는 모든 P60을 다른 배치로 처리하세요. 각 배치 출력의 PAYE 참조 열은 나중에 두 스프레드시트를 병합할 때 피벗 포인트 역할을 합니다. 어떤 행이 어떤 고용주에 속하는지 추측할 필요가 없습니다.

퇴사자, 전직원, 그리고 법적으로 P60이 필요한 사람

HMRC 규정은 명확합니다: 과세연도 4월 5일 기준 급여 명부에 있는 모든 직원은 5월 31일까지 P60을 받아야 합니다. 여기에는 과세연도 중 퇴사했지만 4월 5일 현재 재직 중인 직원도 포함됩니다. 3월 30일에 사직하고 4월 4일까지 근무한 직원은 P60을 받습니다. 3월 31일에 퇴사한 직원은 받지 못합니다. 이 차이가 중요한 이유는 어느 쪽이든 실수하면 감사 노출 위험이 생기기 때문입니다.

P60 100건 배치에서 퇴사자 예외 사례는 네 가지 범주로 나뉘며, 각 범주에 따라 배치에 포함할 내용과 이후 확인 사항이 달라집니다:

감사 함정은 P60을 누락하는 것이 아닙니다. P60이 없어야 할 사람에게 발급하거나, 있어야 할 사람에게 발급하지 않는 것입니다. 어느 쪽이든 오류는 FPS 조정으로 이어지며, 준수 핸드북 CH40000에 따른 HMRC 준수 점검 시 급여 소프트웨어보다 더 빨리 불일치가 드러납니다.

실질적인 안전장치는 AI가 각 문서의 내용을 기반으로 분류하는 'P60 상태'라는 추론 열을 추가하는 것입니다. '4월 5일 재직', '4월 5일 이후 퇴사', '전년도 중복', 'P60 아님'과 같은 값으로 조정 전 출력을 정렬하여 검토나 제외가 필요한 행을 표시할 수 있습니다. 추출 과정의 한 열이 그렇지 않으면 따라올 수동 교차 확인 시간을 절약해 줍니다.

100행 스프레드시트를 위한 감사 대비 열 설계

배치 업로드 전에 정의하는 열 이름은 전체 워크플로에서 가장 중요한 결정입니다. 5명 직원 테스트 배치용으로 설계된 열 스키마는 100행에서는 종종 실패합니다. 그 이유는 데이터 양으로 인한 예외 상황(PAYE 제도 간 중복 NI 번호, 연중 변경된 세금 코드, 플랜별로 분할된 학자금 대출 공제)을 고려하지 않았기 때문입니다.

100행 감사를 견디는 열 스키마는 세 가지 유형의 열로 구성되며, 각각 출력에서 고유한 기능을 수행합니다:

여러 고용주에 걸쳐 P60을 관리하는 급여 팀의 경우 "PAYE 참조" 열은 배치 그룹화 키이자 조정 피벗 역할을 합니다. PAYE 참조별로 출력을 필터링하고 총 급여 및 총 공제 세금 열을 합산한 다음 각 고용주의 P35(고용주 연간 신고서) 합계와 비교합니다. AI는 PAYE 참조 형식을 이해할 필요가 없습니다. 표시된 대로 문자열을 읽고, 영국 PAYE 참조는 일관된 NNN/XXNNNNN 패턴(PAYE20005)을 사용하므로 출력은 자연스럽게 정렬 및 필터링 가능합니다.

세금 코드 처리는 대량 규모에서 특히 주의가 필요합니다. 2025-26년의 표준 누진 세금 코드는 1257L(개인 공제액 £12,570 반영)이지만, 대량 처리를 하면 100명의 직원 중 표준에서 벗어난 사례가 얼마나 많은지 드러납니다. K 코드(총 공제액이 공제 한도를 초과)를 가진 직원은 1257L을 가진 직원과 근본적으로 다른 세금 처리를 받습니다. P60에 BR(기본 세율) 코드가 표시된 직원은 두 번째 소득원에 대해 과세되었을 가능성이 높습니다. NT(비과세) 코드를 가진 직원은 HMRC에 비거주 확인을 위해 P85를 제출했을 수 있습니다. "X" 접미사가 붙은 1257L 코드를 가진 다섯 명의 직원은 비누진(1개월 기준) 방식으로 배정되었습니다. 즉, 연간 누계 수치가 전체 연도 계산을 반영하지 않을 수 있습니다. "최종 세금 코드"라는 열이 이 모든 정보를 보여줍니다. 두 번째로 AI가 각 코드를 "누진", "비누진", "BR/D0/D1", 또는 "K 코드"로 분류하는 "세금 코드 유형"이라는 계산된 열은 코드 스프레드시트를 세금 상황 스프레드시트로 바꿔 한 번의 클릭으로 필터링할 수 있게 합니다.

여러 고용주 및 과세 연도에 걸친 P60 데이터 병합

대량 추출은 배치당 하나의 스프레드시트를 생성합니다. 각각 고유한 123/AB456 형식의 참조 번호를 가진 세 개의 PAYE 제도에서 P60을 관리하는 급여 팀은 결국 세 개의 스프레드시트를 갖게 됩니다. 병합 단계는 추출 열의 구조적 설계가 빛을 발하거나 무너지는 지점입니다.

모든 배치가 동일한 열 이름("NI 번호", "직원 이름", "PAYE 참조", "과세 연도", "연간 총 급여(£)", "연간 총 공제 세금(£)")을 사용했다면, 세 개의 스프레드시트는 열 재매핑 없이 수직으로 쌓을 수 있습니다. 각 시트의 "PAYE 참조" 열은 각 행이 어떤 고용주에 속하는지 식별하므로, 병합된 스프레드시트는 PAYE 참조를 기준으로 피벗하여 고용주별 합계를 생성할 수 있습니다. 이것이 배치 간 열 이름을 표준화하는 전체 목적입니다. 병합은 열 매핑 작업이 아닌 추가 작업이 됩니다.

파일 구성, 배치 접근 방식 선택, 다운스트림 사용을 위한 출력 구조화 등 더 광범위한 워크플로 질문에 대해서는 전체 배치 OCR 워크플로 가이드에서 여러 문서 유형에 걸친 파일 준비, 도구 선택 및 출력 구조화를 다룹니다. 여기서 설명된 P60별 열 스키마는 해당 일반 프레임워크에 연결됩니다.

병합 관련 특수 사례 하나: 동일한 NI 번호지만 다른 PAYE 참조를 가진 두 배치에 나타나는 직원입니다. 이는 오류가 아니라 동일 과세 연도에 두 개의 일자리를 가진 직원입니다. 고용주 A의 P60은 한 고용주의 소득과 세금을 보여주고, 고용주 B의 P60은 다른 고용주의 소득과 세금을 보여줍니다. 하나의 스프레드시트로 병합된 이 두 행은 합산되어서는 안 됩니다. "PAYE 참조" 열이 별개의 고용을 나타내는 두 P60을 합산하는 것을 방지합니다. 이 열이 없으면 "연간 총 공제 세금(£)"을 단순히 SUM한 값은 어느 고용주의 P35와도 일치하지 않으며, HMRC 조정도 맞지 않게 됩니다.

자주 묻는 질문: 영국 P60 일괄 처리