영국 P45 데이터 추출 완벽 가이드
급여팀을 위한 2026년판
영국에서 직원이 퇴사할 때마다 급여 시스템은 P45를 생성합니다. 이는 4부로 구성된 양식으로, 직원의 세금 코드, 연간 누적 급여, 공제 세금, 국민보험번호를 이전 고용주에서 다음 고용주로 전달합니다. 영국 노동 시장에서는 매년 약 250만 건의 P45가 발급됩니다. 수신 측에서는 새 고용주의 급여팀 담당자가 해당 PDF나 종이 사본을 열고 13개 데이터 필드를 각각 확인한 후 급여 소프트웨어의 신규 입사자 화면에 직접 입력합니다. 세금 코드 하나만 잘못 입력해도(예: 1257L을 1275L로 입력) 직원은 몇 주 동안 비상 세금 코드로 급여를 받으며, HMRC가 정정하기 전까지 수백 파운드를 초과 납부하게 됩니다. 문제는 P45가 복잡해서가 아닙니다. 수동 입력 오류를 없애기 위해 법적으로 마련된 데이터 전송 메커니즘이, 수십 년 동안 최종 단계에서 수동 입력이라는 병목 현상에 막혀 있었기 때문입니다.
핵심 요약
- 영국 P45는 고용주 간 수동 데이터 입력을 대체하기 위해 존재하지만, 최종 도착지에서는 매년 250만 건의 모든 15개 필드를 누군가가 직접 다시 입력합니다.
- P45와 급여 데이터베이스 사이에 검증 계층이 없기 때문에, 단순 계산상 30명 중 1명의 신규 입사자는 잘못된 세금 데이터로 입사하게 되며, 이 오류는 최대 11개월 동안 숨겨집니다.
- 다시 입력하는 것을 멈추고 검토를 시작하세요 — 13개 P45 필드를 10초 안에 추출한 후, 4월까지 모든 급여명세서를 결정하는 단 하나의 세금 코드만 확인하면 됩니다.
P45의 정체 — 존재 이유와 실체
P45의 공식 명칭은 '퇴직 근로자 상세 정보'입니다. 이는 급여 명세서 요약본이 아닌 세금 연속성 메커니즘입니다. 즉, 한 과세연도(4월 6일~다음 해 4월 5일) 내에서 근로자의 누적 PAYE 기록을 이전 고용주에서 새 고용주로 이전하는 법적 도구입니다. P45가 없으면 새 고용주는 근로자가 개인 면세 한도에서 어디에 해당하는지 계산할 수 없고, HMRC도 누적 소득 내역을 추적할 수 없습니다.
법적 의무는 2003년 소득세(PAYE) 규정 제36조에 명시되어 있습니다. "코드가 발급된 근로자의 고용이 종료되는 경우, 고용주는 P45 양식을 작성해야 한다"고 규정하며, 고용 종료 당일 작성하거나 불가능할 경우 부당한 지체 없이 작성해야 한다고 명시합니다. 제36조는 HMRC가 세금 코드를 발급한 모든 근로자(소득이 0인 경우 포함)에게 적용되며, 사직, 정리해고, 해고, 은퇴, 기간제 계약 만료 등 모든 고용 종료 유형을 포괄합니다.
이것이 P45가 단순한 서류가 아닌 이유입니다. P45는 고용주 A의 최종 급여 처리와 고용주 B의 첫 급여 처리를 연결하는 데이터 전달 고리이며, HMRC의 실시간 정보(RTI) 보고 체계 내에서 작동합니다. RTI에서는 매 급여일마다 근로자의 현재 세금 코드와 연간 누계를 참조하는 전자식 전액 급여 신고(FPS)를 제출해야 합니다. P45 데이터가 부정확하면 이 연결 고리가 끊어지고, 해당 과세연도 잔여 기간 동안 해당 근로자의 전체 PAYE 계산이 잘못된 입력값으로 진행됩니다.
대부분의 급여 가이드가 생략하는 점: P45가 존재하는 이유는 영국 세금 시스템이 누적식이지 거래식이 아니기 때문입니다. 매월 세금을 독립적으로 계산하는 일부 국가와 달리, 영국 PAYE 시스템은 단일 과세연도 내 모든 고용에서 £12,570의 개인 면세 한도가 얼마나 사용되었는지 추적합니다. 새 고용주는 단순히 0부터 시작할 수 없으며, 이전 내역을 반드시 알아야 합니다. P45는 그 인계를 위한 유일한 공식 메커니즘입니다.
P45의 4개 부문 — 각각의 용도와 전달처
P45는 한 사람에게 주어지는 단일 문서가 아닙니다. 동일한 핵심 세금 데이터를 HMRC, 퇴사 직원, 신규 고용주 등 세 당사자에게 각각의 법적 필요에 맞게 배포하기 위해 설계된 4부로 구성된 문서입니다.
| 부문 | 수령인 | 포함 내용 | 처리 방법 |
|---|---|---|---|
| 1부 | HMRC | 고용주 PAYE 참조번호, 직원 NI 번호, 퇴사일, 세금 코드, 연초 이후 급여 및 세금 | RTI 전체 급여 신고(FPS)를 통해 전자 제출. RTI 체계에서는 1부가 더 이상 물리적 제출물이 아니며, 퇴사 데이터는 해당 직원의 최종 FPS에 포함됩니다. HMRC PAYE 매뉴얼(PAYE5025)은 "직원이 RTI 고용에서 퇴사하는 경우, P45 양식을 HMRC에 제출하는 대신 퇴사 세부 정보가 FPS에 포함됩니다"라고 확인합니다. |
| 1A부 | 직원 (보관용) | 1부 데이터 전체 사본 + 직원 주소, 생년월일, 성별 | 직원이 개인 세금 기록으로 보관. 자진 신고 세금 신고, 세금 공제 청구 또는 유니버설 크레딧 신청 시 필요할 수 있음. 재발급 불가 — 분실 시 다음 고용주에서 HMRC 스타터 체크리스트를 사용해야 함. HMRC는 최소 22개월간 보관 권장. |
| 2부 | 신규 고용주 | 퇴사 시 세금 코드, 연초 이후 급여, 연초 이후 세금, NI 번호, 학자금 대출 표시, 주 1/월 1 플래그 | 신규 고용주의 급여 소프트웨어가 첫날부터 올바른 세금 공제액을 계산하는 데 사용. 고용주는 이를 HMRC에 전달하지 않으며, 규정 준수를 위해 기록에 보관(세금 연도 종료 후 최소 3년). |
| 3부 | 신규 고용주 (HMRC 등록용) | 2부의 사본 + 신규 고용주 필드(PAYE 참조번호, 시작일, 사원 번호) | 과거에는 신규 고용주가 새 고용을 등록하기 위해 HMRC에 전달. RTI 체계에서는 신규 고용주가 자체 FPS를 통해 스타터 세부 정보를 보고 — 3부는 해당 제출을 위한 내부 데이터 소스 역할. CIPP는 "RTI를 제출하는 고용주는 더 이상 P45(3부) 또는 P46 양식을 HMRC에 보내지 않아야 합니다"라고 조언. |
퇴사 고용주의 실제 작업 흐름: 최종 급여 실행(직원을 퇴사자로 표시하고 모든 P45 데이터를 HMRC에 전달하는 최종 FPS 트리거)을 처리한 후, 고용주는 P45를 인쇄하거나 이메일로 발송하여 1A부, 2부, 3부를 직원에게 전달합니다. P45가 전자적으로 생성된 경우, 2부와 3부는 일반적으로 단일 PDF로 결합됩니다. 직원은 1A부를 보관하고 2부와 3부를 첫 출근일 이전이나 당일에 신규 고용주에게 전달합니다.
숙련된 급여 관리자조차 혼동하는 한 가지 세부 사항: 미리 인쇄된 HMRC 용지가 아닌 일반 A4 용지에 인쇄하는 급여 소프트웨어에서 P45가 생성될 때, 양식이 시각적으로 4개의 명확한 섹션으로 나뉘지 않을 수 있습니다. 이러한 경우, 어떤 데이터가 어디에 속하는지는 페이지 레이아웃이 아닌 전적으로 상자 번호에 따라 결정됩니다. 상자 1(고용주 PAYE 참조번호)부터 상자 13(고용주 선언)까지가 어떤 부문을 보든 완전한 P45 데이터 세트를 구성합니다.
P45의 모든 항목: 박스 번호별 설명
각 필드가 무엇을 의미하는지 이해하는 것은 단순히 숫자를 기계적으로 복사하는 것과, P45가 올바르게 작성되었는지 확인한 후 급여 데이터에 입력하는 것의 차이를 만듭니다. 공식 HMRC P45 템플릿(버전 12/15)은 네 부분에 걸쳐 13개의 번호가 매겨진 박스를 매핑합니다:
| 박스 | 필드명 | 급여에서의 의미 |
|---|---|---|
| 1 | 고용주 PAYE 참조번호 | 고용주의 PAYE 제도를 식별하는 고유 번호입니다. 형식: 사무소 번호 / 참조 번호 (예: 123/AB45678). 회사의 PAYE 납부에 사용되는 Accounts Office 참조번호와는 다릅니다. PAYE 참조번호가 잘못되면 HMRC가 퇴사 데이터를 올바른 고용주 기록과 연결할 수 없습니다. |
| 2 | 직원의 국민보험번호 | 형식: QQ 12 34 56 C. NI 번호는 모든 HMRC 시스템에서 개인을 연결하는 기본 키입니다. 퇴사 고용주가 잘못 기록하면 신규 고용주의 FPS에서 불일치가 발생하여 HMRC가 중복 또는 알 수 없는 고용으로 플래그를 지정할 수 있습니다. |
| 3 | 직원 이름 (호칭, 성, 이름) | HMRC 기록과 정확히 일치해야 합니다. P45의 이름과 신규 고용주 급여 시스템의 이름이 일치하지 않으면(중간 이니셜 차이조차도) HMRC의 자동 매칭이 실패하여 세금 코드 업데이트가 지연될 수 있습니다. |
| 4 | 퇴사일 | 고용이 종료된 날짜로, DD/MM/YYYY 형식입니다. 이 날짜는 최종 급여 항목이 속하는 세금 월과 주를 결정합니다. 직원이 실제로 2026년 3월 15일에 퇴사했는데 퇴사일을 2026년 4월 15일로 입력하면 한 달 치 소득 전체가 잘못된 세금 기간에 포함됩니다. |
| 5 | 퇴사일 당시 세금 코드 | 퇴사 시점에 적용된 세금 코드입니다(예: 1257L, K475, BR, D0, NT). 접미사 의미: L=표준 개인공제, M=결혼공제 수혜자, N=결혼공제 양도자, T=HMRC 검토, K=마이너스 공제, BR=전체 소득에 기본세율, D0=고율, NT=비과세. 스코틀랜드 납세자는 접두사 S(예: S1257L)를 사용하며, 웨일스 납세자는 C 접두사를 사용합니다. |
| 6 | 주 1 / 월 1 지표 | 이 칸에 "X"가 있으면 세금 코드가 비누적(주 1/월 1) 기준으로 운영됨을 의미합니다. 각 급여 기간이 이전 소득과 납부 세금을 무시하고 독립적으로 계산됩니다. 이는 신규 고용주에서 긴급 세금 공제가 발생하는 가장 흔한 원인입니다. 직원의 기존 연간 누적 납부 세금이 계산에서 무시되기 때문입니다. |
| 7 | 총 급여 누계 / 총 세금 누계 | 현재 과세 연도 시작부터 퇴사일까지 모든 고용에서 발생한 직원의 누적 급여와 소득세 공제액입니다. 이 수치는 최종 급여명세서가 아닌 P11 공제 작업표에서 가져옵니다. 중요한 차이점: Box 7은 동일 과세 연도 내 이전 고용을 포함한 전체 누적 기록을 보여줍니다. Box 8은 이 고용의 부분만 표시합니다. Box 7과 Box 8의 금액이 동일하면 이 고용이 해당 과세 연도의 유일한 고용이었음을 의미합니다. |
| 8 | 이 고용의 총 급여 / 이 고용의 총 세금 | 이 고용에만 해당하는 급여와 세금입니다. 세금 코드가 누적이고 금액이 Box 7과 같으면 공란으로 둡니다. 이 필드는 직원이 한 과세 연도에 여러 직업을 가졌을 때 중요해집니다. 신규 고용주는 연간 누계 총액 중 직전 직무에서 발생한 금액을 이해해야 합니다. |
| 9 | 사번 / 급여 번호 | 퇴사 고용주의 내부 직원 식별자 및 부서/지점 참조번호입니다. 신규 고용주는 주로 기록 보관용으로 사용하며 세금 계산에는 사용하지 않습니다. |
| 10 | 성별 및 생년월일 | Part 1 및 Part 1A에만 표시됩니다. HMRC의 신원 확인용으로 사용됩니다. 신규 고용주는 PAYE 계산을 위해 이 데이터가 필요하지 않습니다. |
| 11 | 퇴직자의 개인 주소 및 우편번호 | 퇴직 당시 직원의 자택 주소입니다. CIPP는 HMRC가 우편번호를 사용하여 신원을 확인한다고 강조합니다. 우편번호가 잘못되면 HMRC 기록상 직원의 주소가 변경되어 향후 모든 서신이 잘못된 주소로 발송될 수 있습니다. |
| 12 | 고용주 이름, 주소 및 우편번호 | 퇴직하는 고용주의 세부 정보입니다. Part 3에는 추가 "P"란이 있습니다. 직원이 새 고용주로부터 시작일부터 다음 4월 5일까지 급여를 받지 않는 경우 "P"를 입력합니다. 연금 수급자 및 휴직 상태인 고용 관계에 사용됩니다. |
| 해당 없음 | 학자금 대출 공제 표시 | 학자금 대출 공제가 계속되는 경우 "Y"를 입력합니다. 이 란은 템플릿에 공식 번호가 없지만 Box 4(퇴직일)와 Box 5(세금 코드) 사이에 있습니다. CIPP는 P45가 늦게 도착하여 HMRC가 이미 새 세금 코드를 발급한 경우에도 고용주는 P45에서 학자금 대출 정보를 업데이트해야 한다고 지적합니다. 학자금 대출 공제 상태는 표준 HMRC 세금 코드 통지서에 포함되지 않기 때문입니다. |
이 전체 양식에서 직원에게 가장 중요한 필드는 박스 5 — 세금 코드입니다. 새 고용주에서 잘못된 세금 코드는 이후 모든 급여명세서에 영향을 미칩니다. 퇴사 고용주가 코드 1257L W1(비누적)이 표시된 P45를 발행한 경우, 새 고용주는 전체 기간 동안 W1을 적용합니다. 즉, 직원은 4월 이후 누적된 미사용 개인 공제 혜택을 받지 못합니다. 결과적으로 매월 세금은 해당 월이 단독으로 있는 것처럼 계산되어, 직원이 이전 달에 소득이 거의 또는 전혀 없었을 수 있다는 점을 무시합니다. Reddit 사용자는 이 경험을 새 직장에서 첫 급여명세서를 열었을 때 "비상세금으로 큰 금액이 사라진 것"을 발견한 것으로 설명합니다. 이는 매년 r/UKPersonalFinance에서 수백 개의 유사한 게시물에서 반복되는 불만으로, 대부분 누락되거나 잘못 처리된 P45로 인해 발생합니다.
P45의 맥락: 영국 급여 생태계에서의 위치
P45는 단독으로 존재하지 않습니다. 그 기능과 잘못 처리했을 때의 결과는 법정 급여 보고의 더 큰 프레임워크 내에서 그 위치를 파악할 때만 명확해집니다. 가장 중요한 세 가지 관계는 다음과 같습니다:
P45와 P60: 서로 대체 불가
P45와 P60은 가장 흔히 혼동되는 PAYE 서식이지만, 기능이 정반대입니다. P60은 연간 요약본으로, 4월 6일부터 다음 해 4월 5일까지의 전체 과세 연도에 대한 총 급여와 총 공제 세액을 보여줍니다(4월 5일 기준 재직 중인 직원 대상). P45는 연중 스냅샷으로, 4월 6일부터 특정 퇴사일까지를 다루며, 고용이 종료될 때만 발급됩니다. 실무적으로, 새 고용주에게 P60을 줄 일은 없습니다. 오직 P45만이 급여 시스템이 누적 계산을 이어갈 수 있도록 세금 코드를 제공합니다. P60을 P45 대신 새 고용주에게 주는 것은 통하지 않습니다. 급여 소프트웨어는 P60에서 세금 코드를 추출할 방법이 없기 때문입니다. P60은 원래 그런 용도로 설계되지 않았습니다.
P45와 스타터 체크리스트: 대체재가 아닌 차선책
직원이 P45 없이 새 일자리를 시작할 때(이전 고용주가 아직 발급하지 않았거나, 직원이 분실한 경우, P45는 재발급 불가), 새 고용주는 HMRC 스타터 체크리스트(구 P46)를 사용합니다. 체크리스트는 세 가지 질문을 합니다:
- 이번이 지난 4월 6일 이후 첫 직장인가요?
- 4월 6일 이후로 직장, 구직수당 또는 연금에서 지급을 받은 적이 있나요?
- 현재 다른 직장이나 연금에서 지급을 받고 있나요?
답변에 따라 HMRC가 초기 세금 코드를 부여합니다. 일반적으로 진술서 A(첫 직장)는 누적 기준 1257L, 진술서 B(다른 직장이 있었으나 종료됨)는 1257L W1/M1입니다. P45와의 결정적 차이점: 스타터 체크리스트는 연초 이후 급여나 세금 데이터를 전혀 제공하지 않아, 새 급여 시스템이 직원의 인적공제 한도 내 위치를 추정해야 합니다. 스타터 체크리스트는 없는 것보다 낫지만, 데이터 측면에서 동등한 대체재는 아닙니다. P45만이 제공할 수 있는 정확한 누적 수치가 없기 때문입니다. 이것이 스타터 체크리스트 기반 코드로 첫 급여명세서가 자주 틀리는 이유이며, HMRC가 체크리스트를 먼저 사용한 후에도 P45를 요청할 것을 권장하는 이유입니다. P45 데이터가 도착하면 급여 기록을 소급하여 수정할 수 있기 때문입니다.
RTI가 HMRC에 대한 종이 P45 제출을 대체한 방식
2013년 4월부터 영국은 실시간 정보(RTI) 보고 체제로 운영되고 있습니다. RTI 하에서 퇴사 고용주는 P45의 1부를 물리적으로 HMRC에 보내지 않습니다. 대신 퇴사일, 최종 세금 코드, 누적 급여/세금 수치 등 퇴사 정보가 마지막 급여 기간에 대한 전체 급여 신고(FPS)에 직접 포함됩니다. FPS는 급여일 당일 또는 그 이전에 제출되어야 합니다. HMRC 내부 시스템은 이 FPS 데이터를 사용하여 고용 기록을 종료하고 다음 고용주의 FPS를 받을 준비를 합니다.
시간 제약이 빡빡합니다. 최종 FPS에는 정확한 퇴사일과 모든 누적 수치가 포함되어야 합니다. 직원이 즉시 퇴사하는 경우처럼 퇴사일이 확인되기 전에 급여가 처리되는 일반적인 시나리오에서는 고용주가 수정된 FPS를 제출해야 할 수 있습니다. 그렇게 하지 않으면 직원의 HMRC 기록에 재직 중인 것으로 표시되어 새 고용주가 스타터를 등록하고 올바른 세금 코드를 적용하는 것이 지연될 수 있습니다.
지연 FPS 벌금은 PAYE 제도별로 월 £100~£400이며, 직원 수에 따라 다릅니다(1~9명: £100, 10~49명: £200, 50~249명: £300, 250명 이상: £400). HMRC는 실제로 3일의 유예 기간을 운영합니다. 급여일로부터 3일 이내에 접수된 FPS는 지속적인 지연 제출 패턴이 없는 한 벌금이 부과되지 않지만, 이는 법적 연장이 아닌 관용 조치입니다.
수동 P45 데이터 입력의 실제 비용
수동 P45 처리 비용은 주로 시간 문제가 아닙니다. P45 하나당 2분이 소요된다고 가정할 때, 한 달에 30명의 신규 스타터를 처리하는 급여 부서는 다른 사람의 급여 시스템이 이미 계산하고 인쇄한 데이터를 다시 입력하는 데 1시간을 소비합니다. 실제 비용은 오류 연쇄에 있습니다. 각 P45에는 새 고용주의 급여 소프트웨어에 입력해야 하는 약 15개의 개별 데이터 포인트가 있습니다. 각 필드의 정확도가 99.7%라고 가정하면(수동 입력 기준으로 낙관적임), 오류 없는 P45 전사 확률은 0.997^15, 즉 약 95.6%입니다. 한 달에 30개의 P45를 처리한다면, 평균적으로 한 달에 최소 한 명의 신규 스타터가 잘못된 세금 데이터로 급여에 입력된다는 의미입니다.
이 비용에 대해 영국 고용주의 수동 P45 처리 비용 분석에서 자세히 살펴보았으며, 퇴사자당 및 연간 비용 구조를 분석했습니다. 이 프레임워크는 직접 인건비, 오류 수정 시간(HMRC PAYE 헬프라인 대기 시간 포함, 세금 코드 오류 해결), 그리고 세금 코드 수정 지연이 직원 유지에 미치는 하류 비용을 다룹니다.
그러나 단위당 오류율을 넘어서는 더 깊은 구조적 문제가 있습니다. 급여 관리자가 P45 데이터를 다시 입력할 때, 시스템에는 원본 문서와 급여 데이터베이스 사이에 오류 감지 계층이 없습니다. 대부분의 비즈니스 프로세스(회계 이중 입력, 재고 바코드 스캔, 지불 조정)에는 확인 단계(체크섬, 알려진 기록과의 일치, 또는 두 번째 검토)가 있습니다. 수동 P45 전사에는 이러한 기능이 전혀 없습니다. 관리자가 새 스타터 양식에 "1257L"을 입력하면 급여 소프트웨어는 이를 그대로 받아들입니다. P45 이미지와의 교차 확인이 없습니다. 해당 우편번호나 급여 수준에 대한 일반적인 세금 코드 형식에 대한 검증도 없습니다. 오류는 직원이 급여명세서가 잘못되었음을 알아차리거나 HMRC의 연말 정산에서 불일치를 발견할 때까지 감지되지 않은 상태로 남아 있으며, 그 시점에는 이미 4~11개월 동안 잘못된 공제가 발생한 후입니다.
이러한 구조적 격차가 영국 급여팀 내에서 왜 존재하고 지속되는지 더 깊이 알아보려면, 영국 급여팀이 여전히 4부로 된 종이 P45 양식을 수동으로 처리하는 이유에 대한 분석을 참조하세요. 이 분석은 수동 입력 병목 현상의 구조적, 규제적, 기술적 원인을 추적합니다.
급여 소프트웨어가 P45를 처리하는 방식 — 그리고 하지 못하는 것
현대 영국 급여 소프트웨어는 P45를 생성하는 데 탁월합니다. Sage Payroll, BrightPay 또는 Xero에서 직원을 퇴사자로 표시하면 소프트웨어가 자동으로 최종 연도 누계(YTD) 수치를 계산하고, 13개 박스를 모두 채우며, 4부 PDF를 생성하고, HMRC에 FPS 제출에 퇴사 데이터를 포함시킵니다. 예를 들어 Sage의 프로세스는 직원 선택, 고용 탭으로 이동, '퇴사자' 선택, 퇴사일 입력, 일반 A4 용지에 P45 인쇄 순서로 진행되며, RTI 제출을 포함한 나머지 모든 작업은 소프트웨어가 처리합니다.
급여 소프트웨어가 하지 못하는 것: 이전 고용주의 P45를 읽어 새 직원 기록에 데이터 필드를 자동으로 입력하는 것입니다. 소프트웨어는 빈 필드가 있는 새 직원 등록 양식을 제공합니다. 급여 관리자가 직접 입력합니다. 데이터 경로는 다음과 같습니다:
이 격차 — P45의 구조화된 출력과 급여 소프트웨어의 구조화된 입력 사이 — 가 수동 입력 병목 현상이 발생하는 지점입니다. 영국 급여 소프트웨어 시장은 성숙하고 경쟁이 치열하며, HMRC의 무료 Basic PAYE Tools(직원 10명 미만 사업체용)부터 CIPP 골드 인증을 받은 IRIS와 같은 엔터프라이즈 플랫폼까지 다양한 제품이 있습니다. 그러나 전체 스펙트럼에 걸쳐 새 직원 데이터 수집 프로세스는 근본적으로 키보드에 의존하고 있습니다.
이는 급여 소프트웨어의 실패가 아닙니다. 실제 기술적 과제를 반영합니다. 유입되는 P45는 어떤 형식으로든 도착합니다 — 여전히 인쇄된 양식을 사용하는 이전 고용주의 스캔된 종이 사본, 이전 고용주의 급여 시스템에서 생성된 이메일 PDF, 새 직원이 출근 전에 찍은 Part 2의 스마트폰 사진 등. 급여 소프트웨어는 표준 디지털 입력 형식을 가정할 수 없습니다. 그런 형식이 없기 때문입니다.
AI 데이터 추출이 P45 워크플로우를 바꾸는 방법
수동 전사 병목 현상이 발생하는 이유는 기존 OCR(광학 문자 인식)이 P45와 같은 양식에 적용될 때 근본적인 한계가 있기 때문입니다. 문자를 읽을 수는 있지만 각 값이 어떤 상자에 속하는지는 이해하지 못합니다. 스캔된 P45에 기존 OCR 도구를 적용하면 평면 텍스트 출력("1257L £2,450.00 QQ123456C 15/03/2026"과 같은 단어 스트림)이 생성되며, 급여 관리자는 여전히 각 값을 새 입사자 양식의 올바른 필드에 수동으로 매핑해야 합니다. 읽기 단계는 자동화되지만, 이해 단계는 그렇지 않습니다.
이 방정식을 바꾸는 것은 의미론적 데이터 추출입니다. 이 접근 방식에서는 AI에 "세금 코드를 보려면 좌표 (x, y)를 보라"고 지시하는 대신 "이 문서에서 세금 코드를 찾아라"고 요청합니다. AI는 양식을 전체적으로 읽고 "퇴사일 기준 세금 코드"라는 레이블을 식별한 후 그 옆에 있는 값을 추출합니다. 양식이 깨끗한 PDF이든, 구겨진 스캔본이든, 비스듬히 찍은 사진이든 상관없습니다. 이는 위치 기반 추출(문서 레이아웃이 성공을 결정)에서 의미 기반 추출(AI가 각 필드의 위치뿐만 아니라 의미를 이해)로의 패러다임 전환입니다.
AI 데이터 추출 분야에서 이 접근 방식을 가리키는 용어는 사용자 정의 열 추출입니다. "세금 코드", "국민보험번호", "연말까지 총 급여", "퇴사일", "학자금 대출 표시" 등 원하는 출력 열을 정의하면 AI가 P45의 어디에 있든 각 필드의 의미를 이해하여 찾아냅니다. 이것이 P45에 특히 중요한 이유는 다음과 같습니다:
- P45 레이아웃은 표준화되어 있지만 디지털 표현은 그렇지 않습니다. BrightPay에서 생성되어 인쇄, 서명, 스캔, 이메일로 전송된 P45는 Sage에서 생성되어 기본 PDF로 렌더링된 P45와 (픽셀 좌표 측면에서) 다르게 보입니다. 의미론적 추출은 위치가 아닌 의미를 읽기 때문에 둘을 동일하게 처리합니다.
- 손으로 쓴 주석은 템플릿 기반 OCR을 무너뜨립니다. 이전 고용주가 인쇄된 P45의 상자 5 옆에 "수정된 코드 1257L"이라고 손으로 쓰면 템플릿 OCR 도구는 이를 완전히 놓치거나 왜곡된 출력을 생성합니다. 의미론적 AI는 인쇄된 양식 내용과 손으로 쓴 여백 메모를 구분할 수 있습니다.
- 다중 페이지 P45는 부분마다 필드 위치가 다릅니다. 1A부, 2부, 3부는 동일한 상자 번호를 공유하지만 서로 다른 페이지에 다른 형식으로 배치됩니다. 템플릿 OCR은 각 부분에 대해 별도의 템플릿이 필요합니다. 의미론적 추출은 추가 구성 없이 세 부분 모두에서 작동합니다.
파일은 안전하게 처리되며 저장되지 않습니다.
P45 데이터 추출 워크플로우 단계별 가이드
데이터 추출이 수동 입력을 대체할 때 전체 P45 처리 체인은 다음과 같습니다. 워크플로우는 한 가지 원칙을 중심으로 구축됩니다. 급여 관리자의 역할이 데이터 입력 담당자에서 데이터 검토자로 전환된다는 점입니다. 처음부터 필드를 생성하는 대신 추출된 필드를 검증합니다.
예를 들어 50개 고객사를 처리하고 월말에 모든 회사의 퇴사자를 처리하는 급여 위탁 회사와 같이 배치로 퇴사자를 처리하는 급여 팀의 경우, 이 워크플로는 관리자 수가 아닌 문서 수에 따라 선형적으로 확장됩니다. 월별 P45 퇴사자 양식을 직원 퇴사 데이터베이스로 일괄 처리하는 가이드에서는 특정 기간의 모든 P45를 단일 데이터베이스 테이블로 병합하는 다중 파일 처리 구성을 설명합니다.
P45 처리의 흔한 함정과 피하는 방법
CIPP 자문 서비스는 1년에 13,000건 이상의 급여 문의를 처리했습니다. P45 관련 문제는 가장 흔한 사례 중 하나로 꼽힙니다. 숙련된 급여 관리자조차 실수하는 상황은 다음과 같습니다:
P45 지연 수령: 첫 급여 지급 이후에 받은 경우
직원이 스타터 체크리스트 기반의 세금 코드(예: 1257L W1)로 시작합니다. 2주 후, 이전 고용주의 P45를 제출합니다. CIPP의 지침은 명확합니다: HMRC가 이미 스타터 체크리스트 데이터를 기반으로 새 세금 코드 통지(P6)를 발행했다면, HMRC가 발행한 코드를 사용하고 P45의 코드는 사용하지 마십시오. P45에서 학자금 대출 공제 상태만 업데이트하십시오. 학자금 대출 표시는 일반 P6 통지에 포함되지 않기 때문입니다. HMRC가 아직 코드를 발행하지 않은 경우, P45의 세금 코드와 연초 이후(YTD) 수치를 사용하여 급여 기록을 업데이트한 후, 이전 급여 기간에 대해 수정된 FPS를 제출하십시오.
한 과세 연도에 여러 개의 P45
4월 이후 세 개의 직장을 가진 직원은 세 개의 P45를 보유하게 됩니다. CIPP 규칙: 가장 최근 퇴사일이 있는 P45를 사용하십시오. 두 P45의 퇴사일이 같다면, 비과세 소득 공제액이 더 높은 P45를 사용하십시오(K 코드의 경우 추가 급여액이 더 적은 것). 여러 P45의 수치를 합산하지 마십시오. HMRC 시스템은 가장 최근 고용의 단일 누적 수치 세트를 예상합니다. 기본 논리: 각 P45는 이전 P45를 대체합니다. 가장 최근 고용주가 이전 연도의 모든 데이터를 누적 계산에 통합했어야 하기 때문입니다.
이전 과세 연도의 P45
2025/26 과세 연도(2026년 4월 6일 이전)에 발행된 P45는 2026/27년에 시작하는 고용에 유효하지 않습니다. 여기에 포함된 누적 수치는 마감된 과세 연도를 다루며, 현재 연도의 PAYE 계산과 무관합니다. 이 경우 HMRC 스타터 체크리스트를 사용하십시오. 이전 P45의 세금 코드는 여전히 유용합니다(전년도 직원의 가장 최근 코드를 알려줍니다). 그러나 YTD 수치는 새 연도의 급여 기록에 입력해서는 안 됩니다.
무소득 P45
휴면 이사나 장기 무급 휴직 중인 직원처럼 급여 명부에 있지만 급여를 받지 못한 경우, P45의 Box 7과 Box 8에 £0.00이 표시됩니다. 이는 유효한 P45이며, 고용주는 규정 36에 따라 이를 발급해야 합니다. 새 고용주는 Box 5의 세금 코드를 사용하되, 연초 이후 급여 및 세금은 0으로 입력합니다. 직원이 다음 4월 5일 이전에 새 고용주로부터 급여를 받지 않을 경우 Part 3(Box 12)에 "P" 표시를 사용해야 합니다.
계절적 성수기: 1월 P45 러시
영국에서 1월은 이직이 가장 많은 달입니다. 크리스마스 연휴 후 만료되는 근무 기간, 새해 경력 이동, Q4 보너스 지급으로 인한 퇴사가 겹칩니다. 급여 팀은 압축된 기간에 직면합니다. 12월 최종 급여 처리, RTI 연말 준비(마감 4월 19일), 신규 직원 P45 처리 급증이 모두 겹칩니다. 평소 주당 5개의 P45를 처리하던 관리자가 갑자기 같은 기간에 20개를 처리하게 되면서 수동 오류가 가장 많이 발생하는 시점입니다. 영국 급여 팀을 위한 1월 P45 러시 생존 가이드에서 정확성을 유지하면서 이 계절적 급증을 관리하는 전략을 다룹니다.
P45에서 P60으로: 연말 인계
P45는 연중 문서입니다. P60은 연말에 해당하는 문서입니다. 과세 연도 중 퇴사한 직원의 경우 P45가 P60과 동일한 역할을 합니다. 즉, 고용 기간 동안의 소득 및 납세 증명 기능을 수행합니다. 퇴사 처리한 고용주는 전 직원에게 P60을 발급하지 않습니다. P45를 받은 새 고용주의 경우 데이터 체인이 계속됩니다. P45의 연초 이후 금액은 새 급여 시스템에서 직원의 누적 기록 시작점이 되며, 최종적으로 연말에 다음 P60을 생성합니다(직원이 4월 5일에 여전히 급여 명부에 있는 경우).
P45(퇴사자)와 P60(현직 직원)을 모두 처리하는 급여 팀의 경우 데이터 추출 워크플로는 구조적으로 유사합니다. 두 양식 모두 표준화된 레이아웃에 고정 필드 세금 데이터를 포함하며, 급여 또는 보고 시스템에 동일한 전사 단계가 필요합니다. 영국 P60 연말 증명서 데이터를 Excel로 추출하는 방법 가이드에서는 P60 특정 필드 매핑을 다루며, 수동 P60 데이터 입력이 영국 고용주에게 과세 연도당 발생시키는 비용 분석에서는 P45의 비용 프레임워크를 연말 주기로 확장합니다.
자주 묻는 질문
HMRC에서 빈 P45 양식을 다운로드할 수 있나요?
아니요. HMRC는 온라인으로 신고하는 고용주를 위해 빈 P45 양식을 다운로드할 수 있도록 제공하지 않습니다. 급여 소프트웨어를 사용하는 경우, 퇴사자의 최종 급여 처리를 완료하면 P45가 자동으로 생성됩니다. 온라인 신고 면제 대상인 극소수 고용주에 해당하는 경우, HMRC 고용주 주문 라인을 통해 미리 인쇄된 P45 용지를 주문할 수 있습니다. 대부분의 급여 소프트웨어(HMRC의 무료 Basic PAYE Tools 포함)는 일반 A4 용지에 P45를 생성하므로 특별 용지가 필요하지 않습니다.
이전 고용주가 P45 발급을 거부하면 어떻게 되나요?
2003년 소득세(PAYE) 규정 제36조에 따라 P45 발급은 선택이 아닌 법적 의무입니다. 이전 고용주가 발급을 거부하거나 지연하는 경우, 근로자는 합리적인 기한을 명시한 공식 서면 요청을 해야 합니다. 그래도 고용주가 이행하지 않으면 근로자는 HMRC에 문제를 신고할 수 있으며, HMRC는 규정 준수 조사를 시작할 수 있습니다. 그동안 새 고용주는 HMRC 스타터 체크리스트를 사용해야 합니다. 근로자는 온라인 개인 세무 계정도 확인해야 합니다. 실제 P45가 제공되지 않았더라도 HMRC가 고용주의 최종 FPS를 통해 퇴사 데이터를 이미 수신했을 수 있습니다.
P45에 국민보험 기여금 납부 내역이 표시되나요?
아니요. P45에는 PAYE에 따라 원천징수된 소득세가 표시되며, 국민보험 기여금은 표시되지 않습니다. NI는 (소득세처럼 누적 방식이 아닌) 급여 지급 기간별로 계산되므로 P45에 연간 누계 NI 수치가 없습니다. 고용주의 최종 FPS는 HMRC에 NI 데이터를 보고하지만, 이는 근로자용 P45 사본에는 나타나지 않습니다. 납부한 NI 기여금 기록이 필요한 근로자는 개인 세무 계정을 확인하거나 HMRC에 국민보험 명세서를 요청해야 합니다.
AI 추출이 필기된 P45를 처리할 수 있나요?
네, 단 전제 조건이 있습니다. AI 의미 추출은 P45의 필기(예: Box 5 옆에 수기로 수정된 세금 코드나 필기된 퇴사일)를 읽을 수 있습니다. 표준 P45 양식의 인쇄된 텍스트 추출 정확도는 최대 99%입니다. 필기 정확도는 가독성에 따라 달라집니다. 명확한 블록 대문자는 안정적으로 추출되지만, 모호한 문자 형태의 흘림체는 수동 검토가 필요할 수 있습니다. 기존 OCR보다 주요 장점은 AI가 양식의 맥락을 이해한다는 점입니다. 즉, '퇴사일' 옆의 숫자가 임의의 숫자 문자열이 아닌 날짜임을 인식하여 문자 수준 인식이 완벽하지 않더라도 오분류를 줄입니다.
P45와 P46의 차이점은 무엇인가요?
P46은 더 이상 존재하지 않습니다. 2013년 RTI 도입과 함께 HMRC 스타터 체크리스트로 대체되었습니다. 스타터 체크리스트는 P45가 없을 때 신규 직원 정보를 수집하는 동일한 기능을 수행하지만 HMRC에 제출되지는 않습니다. 대신 고용주가 작성된 체크리스트를 보관하고 첫 번째 FPS를 통해 해당 스타터 신고 유형(A, B 또는 C)을 보고합니다.
유한회사 이사에게 P45가 필요한가요?
상황에 따라 다릅니다. 이사가 PAYE를 통해 급여를 받다가 해당 급여가 중단되면(예: 회사가 배당금 전용 보수로 전환), 회사는 P45를 발급해야 합니다. 이는 세금 코드가 발급되었고 PAYE 목적의 고용이 종료되었기 때문입니다. 이사가 급여를 줄여서 계속 급여 명단에 남아 있다면 P45는 필요하지 않습니다. 개인 사업자와 자영업자의 경우 P45가 전혀 발급되지 않습니다. 이들은 직원이 아니기 때문입니다. P45는 전적으로 PAYE 제도 하의 근로 소득자를 위한 문서입니다.