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

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

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

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

월간 퇴사자 배치는 연간 P60 작업의 축소판이 아닙니다. 그것은 다른 문제입니다. P45는 동시에 발급해야 하는 규정 준수 문서이자, 보관해야 하는 급여 기록이며, 전혀 관련 없는 목적으로 HR 팀이 필요로 하는 퇴사 데이터 포인트입니다. 동일한 P45 PDF가 세 가지 모두에 사용될 수 있습니다 — 인쇄할 양식으로 취급하는 것을 멈추고 구조화된 데이터 소스로 취급하기 시작한다면 말입니다.

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

P45는 네 부분으로 구성됩니다. 일괄 처리 워크플로우에서 이 구분이 중요한 이유는 대규모로 배송 경로를 잘못 지정하면 수동으로 하나씩 처리할 때는 가려졌던 수정 작업이 연쇄적으로 발생하기 때문입니다.

단일 퇴사자 워크플로우에서 4부 배송은 체크리스트에 불과합니다. 1부 제출, 1A/2/3부 전달. 그러나 15명 규모의 일괄 처리에서는 배송이 추적 문제가 됩니다. FPS에서 어떤 퇴사자가 퇴사자로 표시되었나요? 모든 2부와 3부가 올바른 직원에게 정확히 매칭되었나요, 아니면 누군가 John Smith의 P45를 다른 John Smith에게 건네주었나요? 퇴사자가 P45를 분실한 경우 재발급할 수 없습니다. 수입 증명서만 제공할 수 있습니다. 즉, 생성한 단일 P45 PDF가 유일한 공식 기록입니다. 분실하거나 잘못 배송하는 것은 복구할 수 없는 오류입니다.

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

P45 PDF에서 퇴사자 데이터베이스로: HMRC와 HR 모두를 위한 열 설계

P45 일괄 업로드 전에 정의하는 열 이름은 전체 워크플로에서 가장 중요한 결정입니다. 급여 컴플라이언스만을 위한 열 스키마는 총 급여, 총 세금, 세금 코드, 퇴사일 등 법정 필드만 담고 거기서 멈춥니다. 이는 FPS와 P45를 대조 검증하기에는 충분합니다. 그러나 HR의 퇴사 분석에는 부족합니다. HR이 묻는 질문은 다릅니다. 어느 부서에서 인력이 이탈하는지, 퇴사자들의 공통 세금 코드 패턴은 무엇인지, 고임금 퇴사자와 저임금 퇴사자의 이직 사유가 다른지 등입니다.

두 목적을 모두 충족하는 열 스키마는 세 개의 계층으로 구성됩니다. 첫 번째 계층은 컴플라이언스를 충족합니다. 두 번째 계층은 HR이 실제로 활용할 수 있는 데이터를 제공합니다. 세 번째 계층은 HMRC 문의가 되기 전에 이상치를 표면화합니다.

단일 P45에서 NI number, 세금 코드, 총 급여 및 세금 금액 등 법정 필드를 추출하는 구체적인 과정은 단일 P45 추출 가이드에서 각 필드를 자세히 다룹니다. 이 글은 그 가이드가 끝난 지점부터 시작합니다. 매달 15개의 P45를 동일한 열 스키마에 입력할 때 무엇이 달라지는지, 그리고 이를 통해 구축하는 장기 데이터베이스에 대해 설명합니다.

스키마는 P45 to Excel 설정을 매달 재사용 가능하게 만드는 핵심입니다. 열을 한 번 정의하면 이후의 모든 퇴사자는 동일한 헤더 아래 새 행으로 추가되며, 배치 간 재매핑이 필요 없습니다.

부서 간 협업: HR 통지와 P45 발급 사이의 격차 해소

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

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

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

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

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

HMRC는 단일 P45 레이아웃을 강제하지 않습니다. HMRC의 RTI 사양에 따라 급여 소프트웨어는 필수 항목을 포함해야 하지만, 시각적 배열은 각 공급업체에 맡겨집니다. 그 결과 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)에 인쇄한다는 사실을 알지 않고도 국민보험번호의 형태를 이해하여 Sage P45에서 NI 번호를 찾습니다. BrightPay P45, QuickBooks P45, Moorepay P45, 그리고 분실한 직원이 제출한 스캔된 종이 P45 모두 동일한 열 정의에 입력됩니다. 출력 열은 제공업체에 관계없이 동일하게 채워집니다.

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

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

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

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

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

월별 배치 주기는 연간 회고로는 놓치는 시기 패턴도 드러냅니다. 1월, 4월, 9월에 퇴사자 급증이 있는가? 단일 월 스냅샷으로는 답할 수 없지만, 6개월치 배치를 쌓으면 가능합니다. 패턴은 하나의 스프레드시트 분석이 아니라, 데이터베이스를 월별로 구축함으로써 드러납니다.

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