이번 달 퇴사자 15명, P45 15장
이중 입력 없이 퇴사자 데이터베이스 구축

월간 퇴사자와 단일 P45는 다른 문제입니다

연간 P60 작업은 한 번만 진행됩니다. 4월 5일 기준 모든 급여 대상 직원에게 발급됩니다. 급여팀은 5월 중 일주일을 할애해 일괄 처리하고, Full Payment Submission과 대사 작업을 할 수 있습니다. 반면, 월간 퇴사자 처리는 급여 일정에서 영구적인 업무입니다. 매달 2명에서 20명 사이의 직원이 퇴사합니다: 사직, 정리해고, 기간제 계약 만료, 은퇴 등. 모든 퇴사는 P45를 생성합니다. 그리고 모든 P45는 단순히 HMRC에 제출하고 퇴사자에게 전달하는 규정 준수 의무일 뿐만 아니라, HR이 전혀 다른 목적(누가, 왜, 얼마를 받고 떠났는지, 퇴사 패턴이 있는지)을 위해 필요한 데이터 포인트입니다.

단일 P45 처리는 간단합니다. 해당 필드를 스프레드시트로 추출하는 작업은 특별한 도구 없이 주의만 기울이면 됩니다. 대부분의 회사가 실제로 운영하는 월간 주기로 퇴사자를 처리하기 시작하면, 단일 퇴사자 규모에서는 존재하지 않는 세 가지 구조적 문제가 나타납니다.

월별 퇴사자 배치 처리는 연간 P60 작업의 축소판이 아닙니다. 이는 완전히 다른 문제입니다. P45는 동시에 발급해야 하는 규정 준수 문서이자, 보관해야 하는 급여 기록이며, 전혀 다른 목적을 위해 HR팀이 필요로 하는 퇴사 데이터 포인트입니다. 동일한 P45 PDF 하나가 이 세 가지 역할을 모두 수행할 수 있습니다. 단, 이를 인쇄해야 하는 양식이 아닌 구조화된 데이터 소스로 취급하기 시작한다면 말이죠.

대규모 P45 4부 구성: 어디로 가고 무엇이 잘못되는가

P45는 네 부분으로 구성됩니다. 배치 워크플로우에서 이 구분이 중요한 이유는, 대규모로 라우팅이 잘못되면 수동으로 하나씩 처리할 때는 드러나지 않던 수정 작업이 연쇄적으로 발생하기 때문입니다.

단일 퇴사자 워크플로우에서 4부 라우팅은 체크박스 하나로 끝납니다: 1부 제출, 1A/2/3부 전달. 그러나 15명의 배치에서는 라우팅이 추적 문제가 됩니다. FPS에서 어떤 퇴사자가 퇴사자로 표시되었습니까? 모든 2부와 3부가 올바른 직원에게 정확히 연결되었습니까? 아니면 누군가 김철수의 P45를 다른 김철수에게 건네준 것은 아닙니까? 퇴사자가 P45를 분실한 경우, 재발급이 불가능하며(HMRC에서 명시적으로 금지), 소득 명세서만 제공할 수 있습니다. 즉, 생성한 단일 P45 PDF가 유일한 공식 기록입니다. 이를 분실하거나 잘못 전달하는 것은 되돌릴 수 없는 오류입니다.

대규모 배치 처리에서 실질적인 안전장치는 모든 P45의 데이터를 생성 즉시 스프레드시트에 캡처하는 것입니다. 1A/2/3부가 여러분의 손을 떠나기 전에 말이죠. 이 스프레드시트는 내부 감사 기록이 됩니다: 각 P45에 포함된 내용, 발행일, 해당 퇴사자에 대한 증거입니다. 퇴사자가 6개월 후에 P45에 잘못된 세금 코드가 표시되었다고 연락해도, 급여 시스템 로그인과 인쇄했다고 생각하는 기억에 의존하는 대신 검증 가능한 행 데이터를 확보할 수 있습니다.

P45 PDF에서 퇴직 데이터베이스로: HMRC와 HR 모두를 위한 컬럼

P45 배치를 업로드하기 전에 정의하는 컬럼명은 워크플로에서 가장 중요한 결정입니다. 급여 준수만을 위해 설계된 컬럼 스키마는 총 급여, 총 세금, 세금 코드, 퇴사일 등 법정 필드만 캡처하고 거기서 멈춥니다. 이는 FPS에 대해 P45를 검증하기에 충분합니다. 그러나 HR의 퇴직 분석에는 부족합니다. HR이 묻는 질문은 다릅니다: 어떤 부서에서 인력이 이탈하는지, 퇴직자들 사이의 공통 세금 코드 패턴은 무엇인지, 고임금 퇴직자가 저임금 퇴직자와 다른 이유로 떠나는지 등입니다.

두 목적을 모두 충족하는 컬럼 스키마는 세 가지 계층으로 구성됩니다. 첫 번째 계층은 규정 준수를 보장합니다. 두 번째 계층은 HR이 실제로 사용할 수 있는 데이터를 제공합니다. 세 번째 계층은 HMRC 문의가 발생하기 전에 이상 징후를 표면화합니다.

단일 P45에서 법정 필드(NI 번호, 세금 코드, 총 급여 및 세금 수치)를 추출하는 구체적인 방법은 단일 P45 추출 가이드에서 각 필드를 자세히 다룹니다. 이 글은 그 가이드가 끝난 부분부터 시작합니다: 매월 15개의 P45를 동일한 컬럼 스키마에 입력할 때 무엇이 달라지고, 이를 통해 구축하는 장기 데이터베이스는 무엇인지 설명합니다.

부서 간 협업: HR 통보와 P45 발급 사이의 간극 해소

P45 규정은 "고용 종료일 당일 또는 부당한 지체 없이"라고 명시합니다. 실제로 이 문구는 협업 체인을 숨기고 있습니다. HR이 사직서를 접수합니다. 라인 매니저가 최종 근무일을 확인합니다 — 때로는 며칠 후에. 페이롤이 공식 퇴사 통보를 받습니다 — 라인 매니저 확인 후 또는 전, 회사 프로세스가 HR 주도인지 페이롤 주도인지에 따라 다릅니다. 페이롤은 최종 급여를 처리하고, Sage 또는 BrightPay에서 직원을 퇴사자로 표시하며, P45를 생성하고 FPS를 제출합니다. 그제야 P45가 존재하게 됩니다. "직원 사직"부터 "P45 생성"까지의 시간은 당일에서 2주까지 걸릴 수 있으며, 그 간극 동안 HR은 아직 P45 데이터가 없는 스프레드시트에 퇴사를 이미 기록해 놓았습니다.

이것이 수동 퇴사 데이터베이스의 숨은 비용입니다: 서로 다른 두 시스템에서 서로 다른 시간에 발생하는 중복 데이터 입력. HR은 사직이 확인될 때 퇴사자 이름, 부서, 퇴사 사유, 최종 날짜를 입력합니다. 페이롤은 P45가 생성될 때 — 일주일 후 — 동일한 이름, NI 번호, 총 급여, 총 세금, 세금 코드를 입력합니다. 두 데이터 세트는 거의 같은 스프레드시트에서 만나지 않습니다. 결과는 사람들이 왜 떠났는지는 알지만 무엇을 벌었는지는 모르는 HR 퇴사 추적기와, 사람들이 무엇을 벌었는지는 알지만 왜 떠났는지는 모르는 페이롤 아카이브입니다.

배치 워크플로는 누구의 프로세스도 변경하지 않고 데이터 캡처 시점을 변경함으로써 이 간극을 없앱니다. 페이롤이 P45를 생성하고 HR이 별도로 퇴사 추적기를 유지하는 대신, P45 PDF가 두 부서의 단일 소스가 됩니다. 급여 실행 후 — 모든 퇴사자가 처리되고 모든 P45가 생성된 후 — 해당 월의 P45 배치를 업로드하고, 법정 페이롤 필드(P45 자체에서)와 HR 컨텍스트 필드(추론된 열에서)를 모두 포함하는 스프레드시트로 추출합니다. 한 번의 추출 패스. 두 팀 모두 데이터를 얻습니다. HR 팀은 이미 보유한 사직서를 기반으로 퇴사 사유 열을 추가합니다. 페이롤 팀은 FPS에 대해 세금 수치를 확인합니다. 두 팀 모두 동일한 NI 번호, 동일한 퇴사 날짜, 동일한 행에서 작업합니다.

이미 유사한 접근 방식으로 연말에 P60을 처리하는 회사의 경우, 월별 P45 워크플로는 동일한 패턴을 따릅니다: 열 이름 표준화, 월별 배치, FPS에 대한 확인. P60 배치 감사 워크플로는 파일 명명, 열 설계, 다중 고용주 병합을 자세히 다룹니다 — 열 스키마는 문서별로 다르지만 배치 접근 방식은 동일합니다.

크로스 프로바이더 현실: Sage, BrightPay, QuickBooks, 그리고 연도 중간에 부서를 옮긴 퇴사자

HMRC는 단일 P45 레이아웃을 강제하지 않습니다. HMRC의 RTI 사양에 따라 급여 소프트웨어는 필수 항목(고용주 PAYE 참조번호, 직원 NI 번호, 이름, 퇴사일, 세금 코드, 총 급여, 총 세금)을 포함해야 하지만, 시각적 배열은 각 공급업체에 맡겨집니다. 그 결과 Sage 50cloud Payroll의 P45는 BrightPay의 P45와 다르게 보이고, QuickBooks Online Payroll의 P45와도 다르며, Moorepay의 P45와도 다릅니다. 직원의 NI 번호는 한쪽에서는 오른쪽 상단 상자에, 다른 쪽에서는 직원 이름 아래에 있을 수 있습니다. 세금 코드는 한쪽에서는 PAYE 참조번호 옆에 인쇄되고, 다른 쪽에서는 별도의 테두리 상자 안에 인쇄될 수 있습니다.

이러한 레이아웃 차이는 수동 배치 작업에서 미묘하지만 상당한 비용을 발생시킵니다. 급여 관리자가 Sage P45를 읽다가 BrightPay P45를 읽을 때마다 각 필드를 찾기 위해 시각적으로 다시 스캔합니다. 회사가 다른 법인을 인수하고 전환 기간 동안 해당 급여 소프트웨어를 그대로 사용하는 경우 자연스럽게 발생하는, 세 개의 급여 제공업체에 분산된 15개의 P45를 처리할 때 이러한 시각적 재스캔은 문서당 약 10초가 추가됩니다. 한 달 치 퇴사자를 처리할 때, 이는 타이핑 한 번 하기 전에 낭비되는 몇 분의 스캔 시간입니다.

의미 기반 추출은 위치가 아닌 의미를 기준으로 문서를 읽음으로써 공급업체별 재스캔을 제거합니다. "NI 번호"와 같이 원하는 열을 한 번만 정의하면 됩니다. AI는 Sage가 그리드 좌표(x=72mm, y=38mm)에 인쇄한다는 사실을 알지 않고도 국민보험번호의 형태(두 글자, 여섯 숫자, 한 글자: AB123456C)를 이해하여 Sage P45에서 NI 번호를 찾습니다. BrightPay P45, QuickBooks P45, Moorepay P45, 그리고 분실한 직원이 제출한 스캔된 종이 P45 모두 동일한 열 정의에 입력됩니다. 출력 열은 제공업체에 관계없이 동일하게 채워집니다.

이러한 제공업체 중립적 동작은 연도 중간에 퇴사한 직원이 현재와 다른 급여 시스템을 사용했던 일반적인 시나리오에서 특히 유용합니다. 9월에 Sage에서 BrightPay로 전환한 회사의 경우, 퇴사자 중에는 Sage에서 생성된 P45(9월 이전 퇴사)와 BrightPay에서 생성된 P45(9월 이후 퇴사)가 섞여 있습니다. 수동 작업에서는 두 P45 레이아웃이 서로 다른 시각적 접근 방식을 요구하기 때문에 급여 관리자가 각 배치를 별도로 처리합니다. 의미 기반 추출 배치는 동일한 업로드에서 둘 다 처리할 수 있습니다. AI는 레이아웃이 아닌 값을 읽습니다. "PAYE 참조번호" 열은 어떤 소프트웨어가 P45를 생성했는지에 관계없이 동일한 고용주의 모든 퇴사자에 대해 동일하게 채워집니다.

월별 P45 배치를 퇴사 분석 피드로 전환하기

대부분의 회사는 HR이 수동으로 업데이트하는 스프레드시트로 퇴사자를 추적합니다. 이름, 부서, 퇴사일, 사유가 기록되어 "이번 달에 누가 떠났는지"는 알 수 있지만, "엔지니어링 부서 퇴사자의 평균 총 급여는 잔류자와 비교해 어떠한지", "비누적 세금 코드를 가진 퇴사자의 비율이 더 높은지", "3분기 퇴사자의 세금 코드 구성이 2분기와 다른지"는 알 수 없습니다. 이러한 질문에 답하려면 급여 부서만 보유한 급여 및 세금 데이터(P45 데이터)와 HR만 보유한 부서 및 사유 데이터를 결합해야 합니다.

월별 P45 배치 추출은 정확히 그 결합 데이터셋을 생성합니다. 매달 동일한 열 스키마로 P45 배치를 스프레드시트에 추출합니다. 6개월이 지나면 6개의 스프레드시트가 쌓입니다. 열 이름이 월별로 동일하므로 연간 데이터셋으로 적재하는 것은 추가 작업일 뿐입니다. 열 재매핑이나 필드 정렬이 필요 없습니다. 각 배치에 "월" 열을 고정값으로 추가하면, 급여, 세금, 세금 코드, 국민보험번호, 퇴사일이 포함된 6개월치 퇴사자 데이터가 생성됩니다. 월별, 세금 코드 유형별, 총 급여 구간별로 조회할 수 있습니다.

급여 데이터만으로도 퇴사 면접 기록으로는 알 수 없는 사실을 드러냅니다. BR(기본 세율) 세금 코드를 가진 퇴사자 집단은 두 번째 직업을 가졌을 가능성을 시사하며, 이는 이미 조직에 경제적으로 덜 몰입했던 직원들을 나타냅니다. K 코드(공제액이 면제액을 초과)를 가진 퇴사자 집단은 복잡한 세무 관계(회사 차량, 현물 급여)를 가진 직원으로, 퇴사 결정이 급여 불만보다는 복리후생 구조와 연관될 수 있습니다. 이는 퇴사 면접에서는 전혀 드러나지 않지만, P45 데이터를 포착하면 확인할 수 있습니다.

월별 배치 주기는 연간 회고로는 놓치는 시기 패턴도 드러냅니다. 1월(보너스 후 퇴사), 4월(세금 연도 종료 후 P60을 기다렸다 퇴사), 9월(여름 후 신규 졸업생 채용으로 기존 직원 밀려남)에 퇴사자 급증이 있는가? 단일 월 스냅샷으로는 답할 수 없지만, 6개월치 배치를 쌓으면 가능합니다. 패턴은 하나의 스프레드시트 분석이 아니라, 데이터베이스를 월별로 구축함으로써 드러납니다.

FAQ: 영국 P45 퇴직자 양식 일괄 처리