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부로 구성된 증명서를 생성합니다 — Part 1은 최종 Full Payment Submission의 RTI를 통해 HMRC로 전송되고, Part 1A, 2, 3은 직원에게 전달됩니다. 발급 측은 대부분 자동화되어 있습니다: Sage Payroll, BrightPay, Xero Payroll, Iris, Moorepay 모두 표준 기능으로 P45 생성을 처리하며, 과세 연도 시작일부터 퇴사일까지의 연초 이후 누계 금액을 계산하고 올바른 세금 코드 기준을 적용하여 증명서를 작성합니다.

수령 측에서 자동화는 끝납니다. 새 신규 입사자가 이전 고용주의 P45를 들고 오거나 — 완전히 다른 급여 소프트웨어로 생성된 PDF를 이메일로 보내오면 — 누군가 그 문서를 열고 다섯 개의 필드를 찾아 새 고용주의 급여 시스템에 입력해야 합니다. 그 다섯 개의 필드는: 퇴사일, 현재 과세 연도의 총 급여 및 총 세금, 퇴사 시 세금 코드, National Insurance 번호, 학자금 대출 공제 여부입니다. 이 중 하나라도 잘못 입력되면 새 신규 입사자의 첫 급여 명세서가 잘못됩니다 — 그리고 수정 작업은 소프트웨어 공급업체가 아닌 급여 팀의 책상으로 넘어옵니다. HMRC는 급여 기록을 최소 3년간 보관할 것을 요구하며 부적절한 기록은 추정 세금 고지서와 최대 £3,000의 벌금으로 이어질 수 있다고 경고합니다.

1월에는 이 방정식의 수령 측이 배가됩니다. 평소에 주당 2~3건의 신규 입사자 P45를 처리하는 급여 관리자가 1월 둘째 주에는 15건을 처리해야 할 수도 있습니다 — 12월의 퇴사자들이 이제 다른 회사의 1월 신규 입사자가 된 것입니다. 각 건당 입력 및 확인에 2~3분이 소요됩니다. 영국 급여 관리자 중위 연봉 약 £29,750 기준 — £5,000 2차 기준선을 초과하는 금액에 대한 15% 고용주 Class 1 National Insurance와 자동 가입 연금 기여금을 반영한 고용주 실부담 비용은 시간당 약 £21 — P45 1건당 약 70펜스의 인건비가 발생합니다. 이 비용은 너무 작아서 예산에 편성하는 곳이 없으며, 이것이 바로 대부분의 조직에서 P45 데이터 입력 비용이 제대로 산정된 적이 없는 이유입니다. 그러나 4~5개의 급여 기간에 걸친 1월 동안 주당 15건의 P45를 처리해야 한다면, 화면의 PDF와 시스템의 급여 기록 사이에 자동화 계층이 없는 이 작업에 촉박한 시간이 흐르고 있습니다.

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

RTI는 2013년에 P45의 고용주-에서-HMRC 구간을 디지털화했습니다. 이제 모든 급여 소프트웨어는 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 데이터는 필드 수준에서 표준화되어 있습니다 — 그러나 레이아웃 수준에서는 표준화되어 있지 않으며, 이는 소프트웨어 시장에 맡겨져 있습니다.

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

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

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

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

수동 데이터 입력의 오류율은 문서 품질, 시간 압박, 작업자의 레이아웃 숙지도에 따라 필드당 1%~4%입니다. P45 필드 5개에 걸쳐 필드당 1% 오류율은 주어진 P45 하나에 최소 한 개의 오류가 있을 확률이 약 5%임을 의미합니다. 1월에 주당 P45 15건을 처리한다면, 통계적으로 매월 최소 한 건의 오류가 발생할 가능성은 거의 확실합니다. 그리고 세금 코드 필드에 발생한 오류는 급여명세서가 잘못될 때까지 드러나지 않습니다. 오류를 발견한 직원은 급여 부서에 전화합니다. 급여 부서는 원본 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를 개별적으로 열고, 다섯 개 필드를 읽고, 급여 소프트웨어로 전환하고, 다섯 개 필드를 입력하고, 이 과정을 서른 번 반복하는 대신, 추출 도구를 갖춘 급여 관리자는 1월 워크로드를 세 개 블록으로 재구성할 수 있습니다:

시간 계산은 간단합니다. P45 한 건당 수동 입력 2분 기준, 신규 입사자 P45 서른 건은 한 시간의 타이핑을 소비합니다 — 이후 발견되는 오류를 수정하는 시간은 제외입니다. 배치 추출을 사용하면 동일한 서른 건의 P45가 업로드되고, 추출되어, 몇 분 안에 하나의 스프레드시트로 정리됩니다. 남은 한 시간은 검증과 가져오기에 사용됩니다 — 항상 필요했던 작업이며, 급여 관리자는 이제 타이핑 사이의 틈새에 끼워 넣는 대신 제대로 수행할 수 있습니다.

퇴사자 측면에서는 동일한 추출 워크플로우가 다른 목적을 제공합니다: 생성된 P45의 수치가 직원과 HMRC에 전달되기 전에 올바른지 확인하는 것입니다. 급여 시스템 자체 기록과 대조한 퇴사자 P45 PDF의 배치 추출은 자동 교차 검증을 만듭니다 — P45의 퇴사일이 시스템과 일치합니까? 연간 누계 급여와 세금 수치가 조정됩니까? RTI 제출 전에 이 검사를 실행하면 급여 소프트웨어가 말하는 것과 증명서가 보여주는 것 사이의 간극을 좁혀, 불일치가 HMRC의 FPS 처리에 도달하기 전에 잡아냅니다. P45 퇴사자 데이터를 Excel로 추출하는 단계별 가이드는 이 워크플로우를 자세히 설명하며, 특정 필드 매핑과 Week 1/Month 1 기준 표시 및 학자금 대출 플랜 유형과 같은 일반적인 엣지 케이스를 다룹니다.

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

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

더 근본적인 문제는 영국 급여팀이 여전히 P45를 수동으로 처리하는 이유가 기술이나 도구 부족 때문이 아니라, 최근까지 사용 가능했던 도구가 서식별 설정을 너무 많이 요구하여 자동화가 대체하려던 수동 프로세스보다 더 느렸기 때문입니다. 급여 대행사가 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 레이아웃에 대해 별도의 구문 분석 규칙이 필요합니다. 의미론적 추출은 필드 레이블의 위치가 아닌 의미를 이해하여 각 P45를 읽습니다. 즉, 여러 급여 제공업체의 P45가 혼합된 배치를 업로드하고 단일 열 정의 집합에 대해 모두 추출할 수 있습니다. 출력은 P45당 한 행씩 구성된 하나의 스프레드시트입니다.

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

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

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

둘 다 근로자가 과세 연도에 번 소득과 납부한 세금을 보여주지만, 발생하는 상황이 다릅니다. P45는 근로자가 직장을 그만둘 때 발급되며, 과세 연도 시작일부터 퇴사일까지의 기간을 다룹니다. 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나 직접 구문 분석할 수 없는 형식의 첨부 파일로 도착하는 P45에 특히 유용합니다. 추출 도구는 PDF, JPG, PNG, WebP 및 AVIF 입력을 지원합니다.

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

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