1월 P45 대란
영국 급여 생존 가이드

아무도 예약하지 않은 1월 급증

영국 직원 이직률은 연간 약 34%로, CIPD의 연간 인구 조사 분석에 따르면 근로자의 약 27.4%가 새 고용주로 이동하고 6.6%가 매년 노동 시장을 떠납니다. PAYE 기준 약 3,300만 명을 고려하면, 직장을 옮기는 사람들만으로도 연간 약 900만 개의 P45가 발급됩니다. 하지만 이러한 변동은 연중 균일하지 않습니다. 모든 급여 실무자는 이것이 특정 시기에 집중된다는 것을 알고 있으며, 1월은 연중 가장 밀집된 시기입니다.

시기는 우연이 아닙니다. 대부분의 영국 고용주는 한 달, 고위 직급의 경우 세 달의 통지 기간을 운영합니다. 크리스마스 연휴 동안 — 회사 파티 후, 보너스가 입금된 후, 자신의 직장 생활에서 진정으로 원하는 것이 무엇인지 깨닫게 된 2주간의 가족 시간 후 — 떠나기로 결정한 사람은 1월 첫째 주에 사직서를 제출합니다. 이 통지 기간은 1월 내내 이어지며, 최종 급여와 P45 발급일은 1월 말이나 2월 초에 도래합니다. 한편, 그들을 대체하기 위해 도착하는 신규 직원들은 이전 고용주의 P45를 가져옵니다. 이 문서들은 각기 다른 급여 소프트웨어, 다른 레이아웃, 다른 필드 위치로 생성되며, 이 모든 P45는 첫 급여 실행 전에 읽고, 새 고용주의 급여 시스템에 입력하고, 확인해야 합니다. 현장 직원 400명과 연간 이직률 35%인 건설 회사는 1년에 약 140개의 P45를 처리해야 하며, 그중 상당수가 1분기에 집중됩니다. 총 450명의 직원을 둔 30개의 중소기업 고객을 운영하는 급여 대행사는 여러 업종, 여러 급여 소프트웨어 내보내기, 여러 P45 형식(표준화되지 않은)에 걸쳐 동일한 패턴의 축소된 버전에 직면합니다.

단순한 물량 자체가 문제는 아닙니다. 급여 팀은 연중 내내 물량을 처리합니다. 1월이 다른 점은 이 물량이 12월의 압축된 처리 기간에서 비롯된 미뤄진 작업과 충돌한다는 것입니다. CIPP의 데이터에 따르면, 12월이 짧아 급여 부서는 작업을 앞당기고 일부는 연기해야 합니다. "1월의 복리후생 연도 갱신은 12월 업무량을 크게 증가시킵니다."라고 CIPP는 12월 급여 보고서에서 밝혔습니다. 복리후생 연도 갱신, P11D 처리, 세금 코드 업데이트 모두 표준 1월 급여 실행 위에 쌓입니다. P45 퇴사자 물결은 이미 빡빡할 예정이었던 한 달의 한가운데에 도착하며, 두 방향에서 동시에 밀려듭니다.

양방향 문제: 같은 주에 퇴사자와 입사자

P45는 영국 고용주가 동일한 워크플로우에서 생산하고 소비하는 유일한 급여 문서입니다. 직원이 퇴사하면 고용주는 2003년 소득세(PAYE) 규정 제36조에 따라 P45(공식 명칭 "퇴직 근로자 상세 정보")를 발행합니다. 소프트웨어는 4부로 구성된 증명서를 생성합니다. 1부는 최종 전액 급여 신고 시 RTI를 통해 HMRC로 전송되고, 1A부, 2부, 3부는 직원에게 전달됩니다. 발행 측면은 대부분 자동화되어 있습니다. Sage Payroll, BrightPay, Xero Payroll, Iris, Moorepay 모두 표준 기능으로 P45 생성을 처리하며, 과세 연도 시작일(4월 6일)부터 퇴사일까지의 연간 누계를 계산하고, 올바른 세금 코드 기준을 적용하며, 증명서를 작성합니다.

수신 측면에서 자동화는 끝납니다. 신규 입사자가 이전 고용주의 P45를 가지고 오거나, 전혀 다른 급여 소프트웨어로 생성된 PDF를 이메일로 보내면, 누군가는 해당 문서를 열고 5개 항목을 찾아 새 고용주의 급여 시스템에 입력해야 합니다. 그 5개 항목은: 퇴사일, 현 과세 연도의 총 급여 및 총 세금, 퇴사 시 세금 코드, 국민보험번호, 학자금 대출 공제 상태입니다. 이 중 하나라도 잘못 입력되면 신규 입사자의 첫 급여 명세서가 틀리게 되며, 수정 작업은 소프트웨어 공급업체가 아닌 급여 팀의 책상 위로 떨어집니다. HMRC는 급여 기록을 최소 3년간 보관할 것을 요구하며, 부적절한 기록은 추정 세금 청구서와 최대 £3,000의 벌금을 초래할 수 있다고 경고합니다.

1월에는 이 방정식의 수신 측면이 배가됩니다. 보통 주당 2~3건의 신규 입사자 P45를 처리하는 급여 관리자는 1월 둘째 주에 15건을 마주할 수 있습니다. 12월 퇴사자들이 이제 다른 회사의 1월 입사자가 된 것입니다. 각 건당 전사 및 확인에 2~3분이 소요됩니다. 영국 급여 관리자 중간값 약 £29,750 총급여를 기준으로, £5,000 2차 기준선 초과분에 대한 15%의 고용주 1급 국민보험과 자동 등록 연금 기여금을 고려한 고용주 부담 비용은 시간당 약 £21입니다. 이는 P45당 약 70펜스의 인건비에 해당합니다. 이 비용은 워낙 작아서 예산을 책정하는 곳이 없으며, 이것이 바로 대부분의 조직에서 P45 데이터 입력 비용이 제대로 산정된 적이 없는 이유입니다. 그러나 4~5개의 급여 기간에 걸친 1월 동안 주당 15건의 P45를 처리해야 한다면, 화면의 PDF와 시스템의 급여 기록 사이에 자동화 계층이 없는 작업에 시간이 촉박해집니다.

P45를 수동으로 유지하는 다섯 가지 필드

RTI는 2013년에 P45의 고용주-국세청 구간을 디지털화했습니다. 모든 급여 소프트웨어는 이제 Full Payment Submission을 통해 퇴사자 데이터를 HMRC에 직접 전송합니다. P45의 Part 1은 사실상 불필요해졌습니다. 그러나 RTI는 고용주-고용주 구간에는 아무런 조치를 취하지 않았습니다. 새 고용주에게 동일한 데이터를 전달하는 Part 2와 3은 여전히 사람이 읽도록 설계된 종이 또는 PDF 문서로 남아 있습니다. 이들은 기계 판독용으로 설계된 적이 없습니다. 그리고 HMRC는 P45에 포함되어야 할 데이터는 지정하지만 레이아웃은 지정하지 않기 때문에, 각 급여 소프트웨어 공급업체는 자체 P45 형식을 설계합니다.

Sage 50 Payroll에서 생성된 P45는 BrightPay의 것과 다른 위치에 세금 코드를 배치합니다. Xero의 P45 PDF는 Iris의 것과 다르게 보입니다. Moorepay의 레이아웃은 FreeAgent의 것과 다릅니다. 중요한 다섯 가지 필드(퇴사일, 현재까지 급여, 현재까지 세금, 세금 코드, 국민보험번호)는 모든 증명서에 나타나지만, 그 좌표, 글꼴 크기, 레이블 문구, 다른 데이터 필드와의 근접성은 소프트웨어 공급업체, 버전 업데이트, 때로는 고용주가 설정한 템플릿 기본 설정에 따라 다양합니다. 서로 다른 30개 고객사로부터 P45를 받는 급여 대행사는 30개의 다른 레이아웃을 접할 수 있으며, 모든 레이아웃에서 보장된 유일한 공통 분모는 사람이 필드를 찾아 입력해야 한다는 것입니다.

이러한 레이아웃 가변성은 급여의 다른 모든 부분이 소프트웨어로 전환되었음에도 P45 처리가 자동화를 거부하는 이유입니다. 기존 OCR은 각 필드가 페이지의 어디에 있는지 알아야 합니다. 즉, 다른 급여 제공업체의 P45가 도착하면 깨지는 위치 기반 접근 방식입니다. 템플릿 기반 추출 도구는 각 레이아웃 변형에 대해 별도의 구문 분석 규칙을 구축하고 유지 관리해야 하므로, 대체하려고 했던 타이핑에 버금가는 관리 부담이 추가됩니다. 병목 현상은 구조적입니다. P45 데이터는 필드 수준에서 표준화되어 있지만(HMRC가 필드를 정의함) 레이아웃 수준에서는 표준화되어 있지 않으며, 이는 소프트웨어 시장에 맡겨져 있습니다.

방정식을 바꾸는 것은 의미론적 추출입니다. 각 필드가 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 문서를 읽는 것입니다. 특정 P45 템플릿의 A열, 7행에서 "Tax Code"를 찾도록 도구를 프로그래밍하는 대신, 의미론적 추출기는 레이블("Tax Code at Leaving", "Tax code", "Tax Code (at date of leaving)")로 필드를 식별하고 위치에 관계없이 인접한 값을 추출합니다. ImageToTable.ai가 Custom Column Extraction이라고 부르는 이 접근 방식은 영국 급여 생태계에서 P45가 실제로 작동하는 방식과 일치하는 최초의 추출 방법입니다. 동일한 데이터, 다른 레이아웃, 표준화 없음. 원하는 열 이름(퇴사일, 현재까지 급여, 세금 코드, 국민보험번호, 학자금 대출 상태)을 입력하면 AI가 레이블의 의미를 이해하여 페이지 어디에서나 각 값을 찾습니다.

잘못 입력된 세금 코드가 실제로 초래하는 비용

1257L 세금 코드는 직원이 2025/26 과세 연도에 대해 전액 £12,570의 개인 면제 한도를 받을 자격이 있음을 의미합니다. 이는 대부분의 단일 직업 및 조정 사항이 없는 직원에게 적용되는 표준 코드입니다. 'L' 접미사는 표준 면세 개인 면제 한도를 나타내며, 숫자 1257은 면제 한도를 10으로 나눈 값입니다. 급여 관리자가 실수로 1275L을 입력하면(두 자리 숫자가 뒤바뀜) 급여 소프트웨어는 이를 £12,750의 개인 면제 한도로 해석하여 직원이 연간 £180의 추가 면세 한도를 받게 됩니다. HMRC 시스템은 결국 불일치를 감지하고 수정된 코드를 발행하지만, 그때까지 직원은 수개월 동안 세금을 덜 납부하고 있을 수 있습니다. 미납분은 조정된 미래 세금 코드를 통해 징수되며, 이는 경고 없이 직원의 급여 명세서에 나타납니다. 그러면 직원은 급여 부서에 전화를 걸어 실수령액이 왜 줄었는지 묻게 됩니다.

이는 가상의 이야기가 아닙니다. AccountingWEB 포럼에는 P45 데이터 입력 오류가 여러 급여 기간에 걸쳐 연쇄적으로 발생한 실제 사례가 있습니다. 한 급여 사무소는 이전 고용주의 Sage CSV 내보내기 파일에서 P45 연도 누계 데이터를 BrightPay에 수동으로 입력하여 중간 연도 이전을 처리했는데, 몇 달 후에야 해당 고객이 HMRC에 £2,390을 청구받았다는 사실을 발견했습니다. 이 금액은 P45 데이터가 이중으로 계산되어 발생한 누적 세금이었습니다. HMRC의 답변은 이의 제기를 제출하라는 것이었고, 이는 "해결되기까지 1년 이상 걸릴 수 있습니다." 오류를 일으킨 2분의 입력은 이미 발생했고, 수정에는 1년이 걸렸습니다.

수동 데이터 입력의 오류율은 문서 품질, 시간 압박, 작업자의 레이아웃 숙련도에 따라 필드당 1%~4%입니다. 5개의 P45 필드에서 필드당 1%의 오류율은 특정 P45에 최소 하나의 오류가 있을 확률이 약 5%임을 의미합니다. 1월 동안 주당 15개의 P45를 처리한다면, 통계적으로 매달 최소 하나의 오류가 발생할 것이 거의 확실합니다. 그리고 세금 코드 필드에 발생한 오류는 급여 명세서가 잘못될 때까지 드러나지 않습니다. 오류를 발견한 직원이 급여 부서에 전화를 겁니다. 급여 부서는 원본 P45를 확인하고, 필사 오류를 발견한 후 수정 절차를 시작합니다. HMRC가 개입합니다. 70펜스의 비용이 들었던 2분의 데이터 입력이 이제 세 개의 책상, 여러 통의 이메일, 그리고 잠재적으로 수 주간의 후속 작업을 소모했습니다. 이 중 어느 것도 예산에 포함되지 않았고, 비용 센터 보고서에 표시되지 않았으며, 모두 단 하나의 잘못 입력된 숫자에서 비롯되었습니다.

수동 P45 처리의 전체 비용 — 인건비, 오류 수정, 규정 준수 위험, 직원당 3,000파운드의 기록 보관 패널티 — 이 자세히 분석되었습니다. 1월 급여팀에게 이 프레임워크에서 관련된 부분은 수신 측입니다: 신규 입사자로부터 도착하는 모든 P45는 수동 입력 작업이며, 모든 입력 작업에는 오류 가능성이 따르고, 1월은 오류율을 높이는 볼륨과 시간 압박을 모두 배가시킵니다.

1월 P45 악순환 끊기

1월 P45 적체 현상에 대한 구조적 해결책은 더 많은 인력이나 초과 근무가 아닙니다 — 이미 12월에 한계까지 일하고 있는 급여팀이 1월 급증을 더 열심히 일해서 흡수할 여유가 없습니다. 해결책은 입력 단계를 완전히 제거하는 것입니다. P45의 데이터 — 퇴사일, 연말까지 급여, 연말까지 세금, 세금 코드, 국민보험번호, 학자금 대출 상태 — 는 이미 증명서에 인쇄되어 있습니다. 급여 관리자의 역할은 생성이 아닌 확인이어야 합니다. 추출된 데이터를 보고, 원본과 일치하는지 확인한 후, 급여 시스템에 가져오십시오. 두 단계 대신 한 단계, 그리고 오류 위험이 있는 단계인 입력이 제거됩니다.

이것이 템플릿 없는 AI 추출이 P45 처리 워크플로를 변경하는 지점입니다. 특정 P45 레이아웃에서 각 필드의 위치를 알아야 하는 위치 기반 OCR과 달리, 의미 기반 추출은 각 필드 레이블의 의미를 이해하여 문서를 읽습니다. Sage에서 생성된 P45는 세금 코드를 한 위치에 배치하고, BrightPay에서 생성된 P45는 다른 위치에 배치합니다. 인간 독자는 두 가지 모두를 본능적으로 탐색합니다 — "세금 코드" 또는 "퇴사 시 세금 코드"를 찾아 인접한 값을 읽습니다. 의미 기반 추출도 동일한 작업을 수행합니다: 좌표가 아닌 의미로 필드를 찾습니다. 이것이 여러 출처의 P45를 단일 작업으로 일괄 처리할 수 있게 만드는 핵심 메커니즘입니다 — 각 급여 소프트웨어의 출력 형식에 대한 템플릿을 만들 필요가 없습니다. 원하는 열을 시스템에 알려주기만 하면, 레이아웃에 관계없이 각 문서에서 일치하는 데이터를 찾습니다.

일괄 처리 차원은 특히 1월에 중요합니다. 단일 주에 15개, 20개 또는 30개의 P45가 도착하는 상황에서 — 양식을 발행해야 하는 퇴사자와 양식을 입력해야 하는 신규 입사자가 섞여 있음 — 하나씩 처리하는 것은 시간 압박 문제를 해결하지 못합니다. 모든 양식을 단일 일괄 작업으로 추출하고, 각 행이 완성된 P45 데이터 레코드인 하나의 스프레드시트에 결과를 병합하면, 일주일 분량의 분산된 입력 작업이 오후 분량의 검토 작업으로 바뀝니다. 일괄 P45 처리 워크플로 — 여러 양식에서 동시에 퇴사자 데이터베이스를 구축 — 는 신규 입사자 측에도 동일하게 적용됩니다. 퇴사 직원을 위한 퇴사자 데이터베이스를 채우는 동일한 추출 실행은 신규 입사자를 위한 신규 직원 설정 시트를 채울 수 있습니다. 두 방향 모두에서 5개의 핵심 필드가 동일하기 때문입니다.

타이핑에 의존하지 않는 1월 급여 워크플로우

각 P45 PDF를 개별적으로 열고, 5개 필드를 읽고, 급여 소프트웨어로 전환해 5개 필드를 입력하고, 이 과정을 30번 반복하는 대신, 추출 도구를 사용하는 급여 관리자는 1월 업무를 세 가지 블록으로 재구성할 수 있습니다.

시간 계산은 간단합니다. 수동 입력 시 P45당 2분씩, 신규 입사자 P45 30개는 1시간의 타이핑이 소요되며, 이후 발견되는 오류 수정 시간은 제외입니다. 배치 추출을 사용하면 동일한 30개 P45를 업로드, 추출, 하나의 스프레드시트로 만드는 데 몇 분이면 됩니다. 남은 1시간은 확인 및 가져오기 작업에 사용됩니다. 이는 항상 필요했던 작업이며, 급여 관리자는 이제 타이핑 사이의 틈새 시간이 아닌 제대로 된 시간을 할애할 수 있습니다.

퇴사자 측면에서는 동일한 추출 워크플로우가 다른 목적을 제공합니다. 생성된 P45의 수치가 직원과 HMRC에 전달되기 전에 정확한지 확인하는 것입니다. 퇴사자 P45 PDF를 급여 시스템 자체 기록과 배치 추출하면 자동 교차 검증이 생성됩니다. P45의 퇴사일이 시스템과 일치하는가? 연간 누계 급여 및 세금 수치가 일치하는가? RTI 제출 전에 이 검사를 실행하면 급여 소프트웨어가 표시하는 내용과 증명서가 일치하는지 확인하여 HMRC의 FPS 처리 전에 불일치를 잡아냅니다. P45 퇴사자 데이터를 Excel로 추출하는 단계별 가이드에서 이 워크플로우를 Week 1/Month 1 기준 표시기 및 학자금 대출 계획 유형과 같은 일반적인 예외 사항을 포함한 구체적인 필드 매핑과 함께 자세히 설명합니다.

1월이 문제를 드러내는 이유

11개월 동안 수동 P45 처리는 미미한 행정적 마찰에 불과합니다. 여기서 몇 분, 저기서 몇 장의 서식, 가끔 발생하는 오류는 피해가 커지기 전에 잡힙니다. 그러나 1월이 되면 마찰이 병목 현상으로 변합니다. 물량이 급증하고, 시간 압박이 심해지며, 오류율이 높아지고, 시정 작업(HMRC 이메일, 수정된 FPS 제출, 직원 급여 명세서 문의)이 2월과 3월까지 이어집니다. 문제는 항상 구조적이었습니다. P45 데이터는 필드 수준에서는 표준화되어 있지만 레이아웃 수준에서는 그렇지 않으며, 고용주 간 인계는 자동화된 급여 생태계에서 여전히 사람이 수동으로 입력하는 체인에 의존합니다. 1월은 최악의 순간에 이 균열을 그대로 드러냅니다.

더 근본적인 문제는 영국 급여팀이 여전히 P45를 수동으로 처리하는 이유가 기술이나 도구 부족 때문이 아니라, 최근까지 사용 가능했던 도구(템플릿 기반 OCR, 영역 추출)가 서식별 설정을 너무 많이 요구하여 자동화가 대체하려던 수동 프로세스보다 더 느렸기 때문입니다. 급여 대행사가 5가지 다른 급여 패키지를 사용하는 30개 고객사로부터 P45를 받을 때, 30개의 추출 템플릿을 만들고 유지하는 것 자체가 풀타임 업무입니다. 의미론적 추출은 이 장벽을 제거합니다. AI가 어떤 소프트웨어에서 인쇄되었든 "퇴사 시 과세 코드"의 의미를 이해하기 때문에, 배치 내 모든 P45에 하나의 열 정의만 적용하면 됩니다.

다음 1월을 준비하는 급여팀에게 질문은 수동 P45 데이터 입력이 지속 가능한지가 아닙니다. 물량 수치가 이미 답을 줬습니다. 질문은 입력 오류, 시정 주기, 동일한 5개 필드를 반복해서 입력하는 행정적 부담의 누적 비용이 언제 비입력 워크플로로 전환하는 비용을 초과하는지입니다. 비용 프레임워크는 이미 마련되어 있습니다. 도구도 존재합니다. 남은 유일한 변수는 입력을 중단하고 검토를 시작하기로 결정하는 것이며, 1월은 그 어느 달보다 내년 퇴사자 물결이 오기 전에 이 결정을 내려야 하는 이유를 보여줍니다.

자주 묻는 질문

영국 고용주는 직원 퇴사 후 P45를 얼마나 빨리 발급해야 하나요?

2003년 소득세(PAYE) 규정 제36조에 따라 P45는 고용 종료일에 작성해야 하며, 불가능한 경우 부당한 지체 없이 작성해야 합니다. 실제로 HMRC는 P45를 직원의 최종 급여와 함께 또는 동일 급여 주기 내에 발급할 것을 기대합니다. 대부분의 급여 소프트웨어(Sage, BrightPay, Xero Payroll, Iris, Moorepay)는 직원을 퇴사자로 표시하고 최종 급여 처리가 완료되면 자동으로 P45를 생성합니다. 1부는 직원의 마지막 급여일 또는 그 이전에 FPS(Full Payment Submission)를 통해 HMRC에 제출됩니다.

서로 다른 급여 소프트웨어의 P45를 일괄 처리할 수 있나요?

네, 템플릿 기반 OCR이 아닌 의미론적 AI 추출을 사용하면 가능합니다. 템플릿 기반 도구는 각 급여 소프트웨어의 P45 레이아웃(Sage, BrightPay, Xero, Iris, Moorepay, FreeAgent 모두 서로 다른 형식의 증명서를 생성함)에 대해 별도의 구문 분석 규칙이 필요합니다. 의미론적 추출은 필드 레이블(예: "퇴사 시 세금 코드" 또는 "현재까지 총 급여")의 위치가 아닌 의미를 이해하여 각 P45를 읽습니다. 즉, 여러 급여 제공업체의 P45가 혼합된 배치를 업로드하고 단일 열 정의 집합에 대해 모두 추출할 수 있습니다. 출력은 P45당 한 행씩 구성된 하나의 스프레드시트입니다.

P45의 어떤 정보를 새 고용주의 급여 시스템에 입력해야 하나요?

P45의 2부와 3부에서 다섯 가지 핵심 필드: 이전 고용에서의 퇴사일, 현재 과세 연도(4월 6일부터 4월 5일까지)의 현재까지 총 급여 및 현재까지 총 세금, 퇴사 시 세금 코드(주 1/월 1 기준 표시 포함), 국민보험번호, 학자금 대출 공제 상태입니다. 이 중 하나라도 잘못 입력되면 신규 입사자에게 비상 세금 코드가 적용되어 첫 급여명세서가 잘못될 수 있습니다. 과세 연도 수치는 누적됩니다. 이는 새 고용주가 직원의 세금 상태를 초기화 없이 계속 유지하는 데 필요한 누적 총액입니다.

P45와 P60의 차이점은 무엇인가요?

둘 다 근로자가 과세 연도에 번 소득과 납부한 세금을 보여주지만, 발생하는 상황이 다릅니다. P45는 근로자가 직장을 그만둘 때 발급되며, 과세 연도 시작일(4월 6일)부터 퇴사일까지의 기간을 다룹니다. P60은 매 과세 연도 말에 해당 시점까지 계속 고용 중인 근로자에게 발급되며, 4월 5일까지의 전체 12개월을 다룹니다. 고용주는 매년 5월 31일까지 모든 현재 근로자에게 P60을 제공해야 합니다. P60 처리에 대한 자세한 내용은 급여 조정을 위한 영국 P60 데이터를 Excel로 추출하는 방법 가이드를 참조하세요.

P45 세금 코드가 잘못 입력되면 어떻게 되나요?

잘못된 세금 코드는 즉시 근로자의 면세 소득 계산을 변경합니다. 예를 들어, 1257L 대신 1275L을 입력하면 £12,570 대신 £12,750의 면세 한도가 적용되어 근로자는 연간 £180만큼 덜 세금을 납부하게 됩니다. HMRC는 일반적으로 RTI 데이터 매칭을 통해 불일치를 감지하고 수정된 세금 코드를 발행합니다. 미납 세금은 향후 세금 코드 조정을 통해 회수되며, 이는 다음 달 근로자의 실수령액을 줄입니다. 근로자는 종종 급여 부서에 급여가 변경된 이유를 문의하며, 급여 부서는 원래 P45 입력으로 거슬러 올라가 수정 사항을 설명해야 합니다. 오류가 발견되지 않으면 여러 과세 연도에 걸쳐 지속되어 더 큰 미납으로 이어질 수 있으며, HMRC가 직접 추적합니다.

종이 P45 양식도 동일한 추출 도구로 처리할 수 있나요?

네. 종이 P45의 스캔 이미지나 사진은 PDF와 동일하게 작동합니다. AI는 포함된 텍스트 레이어가 아닌 문서를 시각적으로 읽습니다. 이는 소규모 사업장에서 여전히 유통되는 종이 P45나 직접 구문 분석할 수 없는 형식(스캔 PDF, JPEG 사진, 급여 포털 스크린샷)의 첨부 파일로 도착하는 P45에 특히 유용합니다. 추출 도구는 PDF, JPG, PNG, WebP 및 AVIF 입력을 지원합니다.

여러 고객사를 관리하는 급여 대행사에서도 일괄 P45 추출이 가능한가요?

네 — 급여 대행사는 가장 다양한 레이아웃을 처리해야 하므로 이 기능의 최적 사용 사례입니다. 서로 다른 5가지 급여 소프트웨어를 사용하는 30개 중소기업의 급여를 관리하는 대행사는 매달 수십 가지 형식의 P45를 접하게 됩니다. 의미론적 추출을 사용하면 대행사가 한 세트의 열 이름을 정의하고, 해당 소프트웨어가 무엇이든 관계없이 배치의 모든 P45에 적용할 수 있습니다. 출력 결과는 고객사별 또는 처리 실행별로 하나의 통합 스프레드시트입니다. 일괄 P45 처리 가이드에서 다중 고객사 대행사 워크플로를 자세히 다루고 있습니다.