신규 입사자에게 초과 과세를 유발하는
여섯 가지 P45 데이터 입력 오류 — 그리고 수정 비용

P45 한 필드 오류가 절대 한 필드에 그치지 않는 이유

P45 오류가 증폭되는 이유는 PAYE가 본질적으로 누적 계산 방식이기 때문입니다. 영수증이나 인보이스에서 잘못 입력된 숫자가 해당 문서 하나에만 영향을 미치는 것과 달리, P45는 회계연도 남은 기간 동안 급여 소프트웨어가 매 급여 주기마다 반복하는 연속 계산의 시작점을 설정합니다. 세금 코드, 당일까지의 급여, 또는 Week 1/Month 1 기준을 설정할 때 잘못 입력하면 소프트웨어는 그 오류를 한 번만 적용하는 것이 아니라, 누군가 발견하여 기준을 수정할 때까지 모든 후속 FPS(Full Payment Submission)에 계속 반영합니다.

이것이 P45 실수와 대부분의 다른 데이터 입력 실수의 차이점입니다. 비상 세금 코드로 처리된 직원은 첫 달에 단 한 번의 잘못된 숫자로 과세된 것이 아닙니다. 잘못된 시작점이 계속해서 잘못된 공제를 발생시켰기 때문에 1월, 2월, 3월, 4월 내내 과세되었습니다. 그리고 HMRC는 완전한 소득 데이터를 확보한 후에야 상황을 조정하기 때문에, 환급은 보통 세금 코드가 연도 중에 수정되거나, 더 나쁜 경우 회계연도가 끝날 때까지 이루어지지 않습니다. 2초짜리 오타의 결과는 직원의 수개월 현금 흐름에 영향을 미칩니다.

아래 여섯 가지 오류는 급여 포럼과 HMRC 자체 수정 지침에서 반복적으로 등장하는 것들입니다. 각각은 충분히 구체적이어서 자신이 실수했는지 여부를 알 수 있으며, 각각의 근본 원인은 "더 조심하라"가 아닙니다.

실수 1: 세금 코드 숫자 전위 오류

가장 흔한 P45 오류는 세금 코드에서 한 자리 숫자가 전위되는 것입니다. 1257L을 1275L로 입력하거나 1250L을 1205L로 입력하는 경우입니다. 한 글자 차이라 사소해 보이지만, 세금 코드의 숫자는 직원의 면세 소득 한도를 10으로 나눈 값입니다. 1257L은 £12,570의 면세 소득을 부여하고, 1275L은 £12,750, 1205L은 £12,050을 부여합니다. 잘못된 코드는 직원이 받을 자격이 없는 면세 한도를 받거나(추후 반납해야 함), 받을 자격이 있는 면세 한도를 박탈당하여(수정될 때까지 초과 납부) 결과를 초래합니다.

근본 원인은 부주의가 아닙니다. 세금 코드는 내부 검증 없이 숫자로만 구성된 문자열이며, 시간에 쫓겨 한 양식에서 읽어 다른 양식에 입력하기 때문입니다. "1275L"이 잘못된 것처럼 보이지 않습니다. 유효한 형식의 코드이며, 단지 다른 면세 한도에 속할 뿐입니다. 그리고 급여 소프트웨어는 P45와 일치하는지 확인하지 않고 형식에 맞는 코드를 모두 수용하기 때문에 오류는 첫 급여 실행에 조용히 반영됩니다.

일단 적용된 오류의 수정은 빠른 편집이 아닌 HMRC를 통해 이루어집니다. HMRC는 P6 또는 P9 통지를 통해 수정된 코드를 발행하고, 소프트웨어는 이를 향후 적용합니다. 코드가 누적 기준이었다면 다음 급여명세서는 일반적으로 연도 누계를 자동 수정합니다. Week 1/Month 1 기준이었다면 초과 또는 미달 납부는 연말까지 해결되지 않은 상태로 남습니다. 어느 쪽이든, 수정은 오류보다 느립니다.

실수 2: 퇴사일자를 잘못 입력하거나 비워두는 경우

퇴사일자가 잘못되면 과세 연도 타임라인에서 직원의 위치가 틀어지고, 비워두면 기본값(급여 시스템에서 빈 날짜를 1900-01-01로 강제 변환하는 경우 있음)으로 인해 HMRC에 중복 PAYE 기록이 생성될 수 있습니다. P45의 퇴사일자는 이전 고용이 종료된 과세 주 또는 월을 소프트웨어에 알려주며, 이에 따라 새 고용이 시작되는 시점이 결정됩니다. 잘못 입력하면 누적 계산이 연중 잘못된 시점에 고정됩니다.

HMRC의 FPS 수정 가이드라인은 후속 정리가 얼마나 복잡해지는지 명확히 설명합니다. 지급일 또는 퇴사일자를 잘못 신고하고 '퇴사 후 지급' 플래그가 관련된 경우, '기간 내 급여'와 '연간 누계 급여' 필드에 동일한 금액을 입력하면 직원의 중복 기록이 생성되므로, 기간 내 급여 필드에 0.00을 입력하고 올바른 과세 기간에 맞춰 급여를 재조정해야 합니다. 이는 한 번의 잘못된 날짜 입력으로 인해 발생하는 다단계 조정 과정입니다.

근본 원인은 퇴사일자가 혼동되기 쉽다는 점입니다. 직원의 고용 종료일, 최종 급여 지급일, P45 수령일은 서로 다른 세 가지이며, P45 양식이 항상 이를 명확히 구분해 주지는 않습니다. 지급일을 퇴사일자 필드에 입력하면 타임라인이 어긋납니다.

실수 3: '연간 총 급여'와 '해당 고용 급여' 혼동

직원이 두 개 이상의 일자리를 가진 경우, P45에는 '연간 총 급여'(해당 과세 연도 모든 고용의 누계)와 '해당 고용 급여'(퇴사한 일자리만 해당)라는 두 가지 급여 수치가 표시됩니다. 이 중 잘못된 값을 소프트웨어의 연간 누계 필드에 입력하면 HMRC에 직원의 누적 소득이 잘못 보고됩니다. 두 숫자는 의도적으로 다르며, 누적 세금 계산을 담당하는 연간 누계 필드에는 그중 하나만 입력해야 합니다.

'해당 고용 급여'를 '연간 총 급여' 자리에 입력하면 해당 연도 직원 소득이 과소 보고됩니다. 그러면 소프트웨어는 직원의 실제보다 더 많은 면세 한도가 남아 있다고 간주하여 수개월 동안 세금을 적게 공제하고, 이후 세금 코드 수정으로 그 차액이 드러납니다. HMRC는 코드에서 면세 한도를 줄여 미납 세금을 회수하므로, 직원은 갑자기 훨씬 큰 공제를 경험하게 됩니다.

이 실수는 신입뿐만 아니라 경험 많은 관리자도 자주 범합니다. 단일 고용 P45에서는 두 수치가 동일하기 때문에 '그냥 급여 숫자를 가져오는' 습관이 멀티잡 퇴사자의 경우 조용히 실패하기 때문입니다. 근본 원인은 이 구분이 항상 필요한 것이 아니라 특정 상황에서만 중요하다는 점이며, 바로 그때 기계적인 복사 단계가 실패합니다. 각 P45 항목의 의미를 필드별로 설명한 내용은 이러한 이중 수치 사례를 위해 항상 참고할 만한 가치가 있습니다.

실수 4: 주 1/월 1 코드를 누적 코드로 처리하는 경우

"W1" 또는 "M1" 접미사가 붙은 세금 코드(예: 1257L M1)는 비누적 코드입니다. 이 접미사를 무시하고 일반 1257L로 입력하면 소프트웨어가 공제액을 누적 방식으로 잘못 분배하게 됩니다. 주 1/월 1은 각 급여 기간이 독립적으로 과세되며, 해당 기간의 급여만 사용하고 연초 이후의 모든 것은 무시함을 의미합니다. 접미사를 빼면 계산 기준이 완전히 바뀝니다.

그 결과는 무시된 기준이 밀어낸 방향에 따라 달라집니다. 직원이 실제로 M1을 적용받아야 하는 경우(HMRC는 이전 연도 기록이 불완전할 때 자주 적용합니다) 누적 코드를 입력하면 소프트웨어가 직원이 이미 다른 곳에서 사용한 공제액을 되돌려주어 현재는 과소 공제되고 나중에 청구서가 발생할 수 있습니다. 반대 실수로, HMRC가 이후 누적 코드를 발급했는데도 비상 M1 코드를 계속 사용하면 공제액이 기간에 걸쳐 누적되지 않아 직원이 계속 과세됩니다.

근본 원인은 W1/M1 플래그가 두 글자 접미사로 부차적으로 보이지만 전체 산술을 변경한다는 점입니다. "1257L M1"과 "1257L"을 같은 코드에 레이블이 잘못 붙은 것으로 취급하기 쉽습니다. 그러나 이들은 같은 코드가 아닙니다. 한 가지 중요한 세부 사항: P45의 실제 W1/M1 코드는 HMRC의 권위 있는 지시이므로 그대로 입력해야 하며, 수치를 누적처럼 보이게 "정리"해야 할 오류가 아닙니다.

실수 5: 국민보험번호 오입력

잘못된 국민보험번호는 HMRC가 신규 직원을 기존 기록과 연결하지 못하게 하여 첫 FPS가 거부되거나, 더 나쁜 경우 다른 사람의 계정에 기록될 수 있습니다. NINO는 HMRC가 개인의 모든 고용 기록을 조정하는 데 사용하는 신원 키입니다. 그 형식은 엄격합니다(두 글자, 여섯 자리, 하나의 접미사 문자, 예: QQ 12 34 56 C). 그러나 엄격한 형식이 숫자 전치를 막지는 못하며, 형식은 맞지만 잘못된 NINO는 완전히 유효해 보입니다.

번호가 일치하지 않으면 보고된 국민보험 기여금과 PAYE가 잘못된 기록에 적립될 수 있습니다. 직원의 경우 기여 내역에 공백이 생길 수 있으며, 이는 나중에 국민연금 자격 연도나 기여 기반 혜택 수급권에 영향을 미칠 수 있습니다. 이 문제는 몇 년 후 명세서를 확인할 때까지 드러나지 않습니다. 특정 접두사는 절대 발급되지 않으므로(문자 D, F, I, Q, U, V는 첫 글자로 사용되지 않으며, O는 두 번째 글자로 사용되지 않음) 명백한 오류를 표시할 수 있지만, 그럴듯한 잘못된 번호는 그냥 통과됩니다.

근본 원인은 NINO가 9자리 순수 식별자로, 타당성을 검증할 의미가 없어서 터무니없는 급여를 의심하는 것처럼 잘못되었는지 알 수 없다는 점입니다. HMRC 기록과 일치하거나 일치하지 않을 뿐이며, 결과는 나중에 알게 됩니다.

실수 6: 학자금 대출 표시 누락 또는 플랜 추측

P45는 5번란에 'Y' 하나만으로 학자금 대출을 표시할 뿐, 어떤 플랜인지는 알려주지 않습니다. 따라서 표시를 누락하거나 플랜을 추측하면 월별 공제액이 모두 잘못됩니다. 공인급여전문가협회(CIPP)에 따르면, P45의 학자금 대출란에 'Y'가 표시되면 다음 급여일부터 공제를 시작해야 하지만, 서식에는 플랜 1, 2, 4, 5를 구분하는 정보가 없으므로 직원이 어떤 플랜에 해당하는지 알려줘야 합니다.

여기에는 두 가지 오류가 있습니다. 첫째는 표시 자체를 놓치는 것입니다. 체크박스가 작아서 간과하면 직원이 이직하는 순간 상환금이 중단되고, 나중에 학자금 대출 회사가 추심할 연체액이 조용히 쌓입니다. 둘째는 플랜을 추측하는 것입니다. HMRC의 고용주 지침에 따르면, 직원이 자신의 플랜을 알려줄 수 없으면 SL1 개시 통지서가 도착할 때까지 급여 소프트웨어에서 플랜 5를 기본값으로 사용해야 합니다. 플랜을 임의로 정하거나 P45를 받기 전 기간의 연체액을 공제해서는 안 됩니다. 플랜을 잘못 선택하면 기준액이 틀려져 SL1로 정정될 때까지 매달 잘못된 소득 구간에서 비율이 적용됩니다.

근본 원인은 CIPP가 회원들을 대상으로 공개 설문조사한 구조적 결함입니다. P45에 플랜 유형이 포함되어 있지 않아 서식 자체만으로는 올바른 공제액을 알 수 없습니다. 따라서 이는 단순한 전사 실수라기보다 알려진 사각지대에 가깝습니다. 표시를 정확히 포착한 후 직원이나 SL1 통지서를 통해 플랜을 확인함으로써 이 문제를 해결할 수 있습니다. 추측해서는 안 됩니다.

급여 실행 후 P45 오류를 수정하는 실제 방법

P45 오류 수정은 오류를 일으킨 시간보다 결코 빠르지 않으며, 상황에 따라 고용주에게 과태료가 부과될 수 있습니다. 가장 먼저 알아야 할 점은 수정된 P45를 단순히 재발행할 수 없다는 것입니다. HMRC는 P45 수정이나 재생성을 금지합니다. 두 번째 P45가 중복 PAYE 기록을 만들기 때문입니다. 모든 수정은 실시간 정보(RTI)를 통해 이루어져야 합니다.

급여 소프트웨어는 작업 자체를 가능하게 하지만, 번거로움을 없애주지는 않습니다. 예를 들어 BrightPay는 수정하려는 급여 명세서를 다시 열어야 수정할 수 있으며, 해당 문제를 해결하기 위한 전용 학자금 대출 플랜 선택기를 제공합니다. IRIS Staffology는 마감된 연도의 수정을 위해 직원별로 "Earlier Year FPS" 기능을 제공합니다. 이러한 도구가 존재하는 이유는 바로 이런 수정 작업이 흔하기 때문이지만, 각각의 수정은 원클릭 실행취소가 아닌 수동 조정 작업입니다.

더 큰 위험은 벌금입니다. RTI 신고서 오류는 2007년 재정법 스케줄 24의 적용을 받으며, CIPP 요약에 따르면 부정확한 신고로 인해 납부해야 할 세금이 과소계상된 경우, HMRC는 부주의로 인한 부정확성에 대해 잠재적 손실 세수의 30%, 고의적인 경우 70%, 고의적이고 은폐된 경우 최대 100%의 벌금을 부과할 수 있습니다. P45 금액 입력 오류가 고의적인 것으로 판단될 가능성은 낮지만, '부주의'는 바로 전사 오류가 해당되는 범주이며, 이에 대한 방어는 합리적인 주의를 기울였음을 입증하는 것입니다. HMRC는 "합리적인 주의를 기울이지 않았거나 고의로 그렇게 한 경우"에만 벌금을 부과하므로, 통제 가능하고 확인 가능한 데이터 입력 프로세스의 유무가 수정과 벌금을 가르는 기준이 됩니다.

오류의 원인과 전사 단계를 제거하는 해결책

이 여섯 가지 오류는 모두 하나의 근본 원인을 공유합니다. 사람이 한 문서 양식의 값을 읽고 다른 양식에 다시 입력하는 과정에 오류 수정 계층이 없다는 점입니다. P45의 세금 코드가 잘못된 것이 아니라, 다시 입력하는 과정에서 잘못된 것입니다. 따라서 해결책은 "더 주의 깊게 확인하라"가 아니라 "재입력을 없애는 것"입니다.

특히 P45의 경우 표준 양식이 없기 때문에 이는 말처럼 쉽지 않습니다. HMRC는 P45가 포함해야 하는 데이터는 규정하지만 모양은 규정하지 않으므로, Sage 50 Payroll에서 생성된 P45는 BrightPay, Xero 또는 QuickBooks UK에서 생성된 것과 세금 코드 위치가 다릅니다. 각 필드의 페이지 내 위치를 알아야 하는 템플릿 기반 OCR은, 구축되지 않은 레이아웃의 급여 제공업체에서 P45가 도착하는 순간 작동이 중단됩니다. 이것이 바로 사람이 PDF를 읽는 것이 항상 "공통 분모"였던 이유입니다.

ImageToTable.ai는 각 제공업체별 템플릿 없이 재입력을 제거합니다. 사용자 정의 열 추출을 사용합니다. 즉, 각 레이아웃에서 세금 코드가 어디에 있는지 도구에 알려주는 대신, 급여 설정에 필요한 필드 이름("퇴직 시 세금 코드", "총 지급액", "본 고용에서의 급여", "퇴직일", "국민보험번호", "학자금 대출 표시", "주1/월1 기준")을 입력하면 AI가 각 P45를 읽고, 해당 레이블이 지정된 필드의 의미를 이해하여 제공업체의 레이아웃에 관계없이 해당 필드가 나타나는 모든 위치에서 데이터를 추출합니다. 열 정의는 한 번 작성하면 과세 연도 전체에 걸쳐 모든 신규 직원에 대해 재사용됩니다. 이 도구는 "총 지급액"과 "본 고용에서의 급여"를 별도의 열로 캡처하고 W1/M1 접미사를 인쇄된 그대로 보존하기 때문에, 필드 혼동에 의존하는 두 가지 오류(오류 3 및 4)는 추출 단계에서 발생하지 않습니다.

抽出は完全な正確性を主張するものではありません — これら6つのエラーの原因となる特定の障害モードを取り除くものです。それでも給与計算実行には検証パスが必要です。Excelで素早く形状チェックを行い、9文字でないNINO、有効な文字で終わらない税コード、給与に対して妥当な割合でない税額を特定します。しかし、チェックするのはソースに対してフラグが立った数行のみであり、すべてのP45のすべてのフィールドを手動で転記し、数字を入れ替えていないことを願う必要はありません。より広いコンテキスト（バッチ処理、検証式、完全なフィールドセット）を求めるチームのために、英国P45抽出の完全ガイドと手動P45処理のコスト内訳がこの記事の続きを提供します。

よくある質問