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

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

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

단일 증명서의 경우, 일회성 P60 to Excel 실행으로 충분합니다. 아래 문제들은 폴더가 커져서 아무도 행을 육안으로 확인할 수 없게 될 때만 나타납니다.

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

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

다중 형식의 현실: Sage도 BrightPay도 150DPI 스캔도 아니다

HMRC는 단일 P60 레이아웃을 요구하지 않습니다. 콘텐츠를 요구합니다. specification RD1에 따라 대체 P60에는 특정 항목이 표시되어야 하지만, 시각적 배열은 각 급여 소프트웨어 공급업체에 달려 있습니다. 그 결과 Sage 50cloud의 P60은 BrightPay의 P60과 구조적으로 다르고, QuickBooks Online Payroll의 P60, Moorepay의 P60, IRIS의 P60도 각각 다릅니다. 게다가 원본을 분실한 직원들이 제공한 스캔된 종이 사본까지 고려해야 합니다.

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

의미론적 추출은 위치가 아닌 의미를 위해 문서를 읽음으로써 공급업체별 템플릿 문제를 제거합니다. "NI Number", "Total Pay for Year (£)", "Tax Deducted (£)", "PAYE Reference", "Final Tax Code"와 같은 원하는 열을 한 번 정의하면 AI는 데이터가 페이지에서 어디에 있는지가 아니라 무엇을 나타내는지 이해하여 각 P60에서 각 값을 찾습니다. Sage 50cloud P60, BrightPay P60, QuickBooks P60, 2023년 스캔 종이 P60 모두 동일한 열 정의로 처리됩니다. 영국 P60의 개별 필드와 추출 중 각 필드의 동작에 대한 자세한 설명은 단일 P60 추출 가이드에서 시작하세요. 이 문서는 그 가이드가 끝난 지점부터 시작합니다. P60을 하나씩 생각하는 것을 멈추면 어떤 일이 일어나는지에 관한 것입니다.

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

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

대량 P60 작업에서 가장 효과가 큰 결정은 파일을 업로드하기 전에 내리는 것입니다: 바로 원본 문서의 이름을 어떻게 짓느냐입니다. 출력 스프레드시트에 100개의 행이 있고, 3개월 후 HMRC 담당자가 "47번 행의 기반이 되는 P60"을 요청했을 때, "다운로드 폴더와 스프레드시트를 대조해 봐야 합니다"라고 답해서는 안 됩니다. 즉시 찾을 수 있는 파일 이름이 필요합니다.

감사 추적성을 지원하는 명명 규칙에는 세 가지 구성 요소가 포함됩니다:

결과 파일 이름 패턴 — AB123456C_2025-26_sage.pdf — 은 감사 추적을 파일 이름 자체에 내장합니다. 추출 도구가 출력에서 파일 이름을 보존할 때, 스프레드시트의 모든 행은 자체 출처 정보를 담게 됩니다. 외부 참조가 필요 없습니다.

여러 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행에서는 종종 실패합니다. 그 이유는 데이터 양으로 인한 예외 상황을 고려하지 않았기 때문입니다.

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 코드 5건은 비누적 기준으로 설정된 것으로, 해당 직원의 연초 이후 수치가 연간 전체 계산을 반영하지 않을 수 있음을 의미합니다. "최종 세금 코드"라는 이름의 열 하나가 이 모든 정보를 표면화합니다. 두 번째로, AI가 각 코드를 "누적", "비누적", "BR/D0/D1", "K 코드"로 분류하는 "세금 코드 유형"이라는 계산 열은 코드 스프레드시트를 세금 상황 스프레드시트로 바꿔 한 번의 클릭으로 필터링할 수 있게 합니다.

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

일괄 추출은 배치당 하나의 스프레드시트를 생성합니다. 각각 고유한 123/AB456 형식의 참조 번호를 가진 3개의 PAYE 제도에 걸쳐 P60을 관리하는 급여 팀은 결국 스프레드시트 3개를 갖게 됩니다. 병합 단계에서 추출 열의 구조적 설계가 효과를 발휘하거나 붕괴됩니다.

모든 배치에서 동일한 열 이름("NI Number", "Employee Name", "PAYE Reference", "Tax Year", "Total Pay for Year (£)", "Total Tax Deducted (£)")을 사용했다면, 세 개의 스프레드시트는 열 재매핑 없이 세로로 쌓입니다. 각 시트의 "PAYE Reference" 열은 각 행이 어떤 고용주에 속하는지 식별하므로, 병합된 스프레드시트는 PAYE 참조 번호를 기준으로 피벗하여 고용주별 합계를 산출할 수 있습니다. 이것이 배치 간 열 이름 표준화의 전부입니다. 병합이 열 매핑 작업이 아닌 추가 작업이 되는 것입니다.

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

병합 관련 특수 사례 하나: 동일한 NI number를 가졌지만 PAYE 참조 번호가 다른 직원이 두 배치에 나타나는 경우입니다. 이것은 오류가 아니라 같은 과세 연도에 두 개의 일자리를 가진 직원입니다. 고용주 A의 P60은 한 고용의 소득과 세금을 보여주고, 고용주 B의 P60은 다른 고용의 소득과 세금을 보여줍니다. 하나의 스프레드시트로 병합된 이 두 행은 합산하면 안 됩니다. "PAYE Reference" 열이 별개의 고용을 나타내는 두 P60을 합산하지 못하게 막는 역할을 합니다. 이 열이 없으면 "Total Tax Deducted (£)"를 단순히 SUM하면 어느 고용주의 P35와도 일치하지 않는 수치가 나오고, HMRC 조정이 균형을 이루지 못하게 됩니다.

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