P60 데이터 입력 실수 5가지:
급여 조정을 위험에 빠뜨리는 오류

P60 데이터 입력의 전사 사각지대

급여 업계는 수년간 P60 오류에 대해 논의해 왔지만, 거의 항상 소프트웨어 측면에 초점을 맞춰 왔습니다. 연중 잘못 적용된 세금 코드. 급여 시스템의 잘못된 NI 범주 문자. HMRC에 플래그 지정된 RTI 제출. 이는 처리 오류입니다. 급여 소프트웨어에 입력된 데이터가 잘못되었거나 구성 설정이 잘못되어 잘못된 증명서가 생성된 것입니다. 해결책은 급여 시스템에 있습니다.

그러나 급여 블로그, 회계사 안내서, HMRC 자문 페이지에서 거의 언급하지 않는 두 번째 유형의 P60 오류가 있습니다. 바로 P60이 올바르게 생성된 후, 사람이 증명서를 읽고 그 데이터를 조정 스프레드시트에 입력하는 순간에 발생하는 오류입니다. 급여 대행사가 연말 FPS 합계를 P60 출력과 대조하여 확인하는 것은 소프트웨어를 수정하는 것이 아니라 소프트웨어 출력이 HMRC 제출과 일치하는지 확인하는 것입니다. 원본 문서는 P60입니다. 전사 대상은 스프레드시트입니다. 전사되는 모든 필드는 급여 소프트웨어 감사 추적으로는 포착할 수 없는 오류가 발생할 기회이며, 그 이유는 급여 시스템이 전사 과정에 관여하지 않았기 때문입니다.

이러한 오류는 처리 오류와 구조적으로 다릅니다. 처리 오류는 급여 시스템이 유효성 검사 규칙(예: 잘못된 NI 형식, HMRC 기록과 일치하지 않는 세금 코드)에 플래그를 지정할 때 포착됩니다. 전사 오류는 누군가가 스프레드시트 셀을 P60 PDF와 수동으로 비교할 때 포착됩니다. 아무도 그 비교를 수행하지 않으면 오류는 스프레드시트에 남아 조정 보고서에 반영되며, 결국 직원이 자신의 세금 코드가 잘못되었음을 알게 되거나 주택 담보 대출 기관이 P60의 급여 수치가 고용주의 확인과 일치하지 않아 신청을 거부할 때 표면화됩니다.

아래의 다섯 가지 실수는 형식 유효성 검사를 통과하고 월말 점검을 통과하며 몇 달 후에 표면화되는 것들입니다. 이는 "작업을 더 주의 깊게 확인하라"는 문제가 아니라, 전사 단계 자체가 근본 원인인 워크플로의 증상입니다.

실수 #1: 국민보험번호 전위 오류 — 잘못된 직원을 찾아내는 오류

국민보험번호 형식(두 개의 접두 문자, 여섯 자리 숫자, 한 개의 접미 문자)은 전위 오류를 자동으로 잡아낼 수 있을 것처럼 보입니다. 모든 급여 소프트웨어, 모든 Excel 유효성 검사 수식, 모든 RTI 제출은 패턴과 일치하지 않는 문자열을 거부합니다. 하지만 형식 검사가 실제로 잡아내는 것은 다음과 같습니다: 잘못된 길이의 항목, 숫자가 있어야 할 자리의 문자, 유효하지 않은 접두 문자(첫 번째 문자로 D, F, I, Q, U, V; 두 번째 문자로 D, F, I, O, Q, U, V).

잡아내지 못하는 것은 여섯 자리 숫자 부분 내의 전위입니다. QQ 12 34 56 C를 QQ 12 43 56 C로 입력해도 현존하는 모든 형식 유효성 검사를 통과합니다 — 아홉 개 문자, 두 개의 유효한 접두 문자, 여섯 자리 숫자, 한 개의 유효한 접미 문자. 급여 소프트웨어가 수락합니다. HMRC의 RTI 시스템도 수락합니다. 그리고 직원의 세금 및 NI 데이터를 잘못된 HMRC 기록으로 보냅니다 — 완전히 다른 사람의 기록이거나, HMRC의 매칭 알고리즘이 결국 불일치를 표시할 때까지 아무도 없는 기록일 수도 있습니다.

여섯 자리 숫자 부분의 한 번의 전위는 다른 개인에게 속한 유효한 NI 번호를 생성하거나, 발급된 NI 번호와 일치하지 않지만 형식 유효성 검사를 통과하는 조합을 만듭니다. 어느 경우든, 하류에서 발생하는 피해는 제출 거부가 아니라 조용히 수락된 잘못된 신원 바인딩이 있는 제출입니다. 직원의 P60 데이터가 다른 사람의 국민보험 기록에 들어갑니다. 그 다른 사람의 국민연금 수급권 계산에 다른 사람의 소득이 포함됩니다. 그 다른 사람의 자진 신고 사전 입력에 그들이 한 번도 일한 적 없는 고용주의 소득이 표시됩니다.

접미 문자는 또 다른 숨겨진 복잡성 계층입니다. 네 개의 유효한 문자(A, B, C, D)는 NI 번호가 원래 발급된 분기에 해당합니다. RTI 이전에 일했던 급여 관리자들은 NI 카드가 분기별로 도착했고 접미사가 분기 표시자였기 때문에 이를 알고 있습니다. 2020년에 업계에 입문한 사람은 분기별 접미사 시스템에 대해 들어본 적이 없을 수 있습니다. 따라서 P60을 필사할 때 QQ 12 34 56 C를 보고 C가 "10월-12월 분기에 발급됨"을 의미한다는 것을 알지 못합니다 — 그리고 접미사가 잘못된 경우에도 이를 표시하지 않을 것입니다. 형식 유효성 검사는 접미사가 A/B/C/D 또는 공백인지만 확인할 뿐 NI 번호의 발급 분기와 일치하는지는 확인하지 않기 때문입니다.

새로운 고객을 맡아 NI 번호가 "몇 년 동안" 잘못되었음을 발견한 회계 법인 — AccountingWEB에 문서화됨 — 은 예외적인 사례가 아닙니다. 전위 오류가 시스템에 들어가고 형식 유효성 검사가 "괜찮아 보이는데"라고 말할 때 일어나는 일입니다.

실수 #2: 세금 코드 입력 오류 — 직원의 실제 손실로 이어지는 실수

P60의 세금 코드는 단순히 1257L 같은 문자열이 아닙니다. 이는 해당 과세연도에 대한 직원의 PAYE 계산 최종 상태이며, 두 가지 중요한 정보를 담고 있습니다: 면세 한도를 결정하는 코드 번호 자체와, HMRC에 해당 코드가 누적 기준인지 긴급(비누적) 기준인지 알려주는 선택적 기준 표시자(W1 또는 M1)입니다.

세금 코드에서 가장 흔히 발생하는 전사 오류는 1257L을 1258L로 잘못 입력하는 것이 아닙니다. P60에 1257L W1이라고 표시되어 있는데 기준 표시자를 생략하는 것입니다. 스프레드시트 열이 코드만 캡처하고 W1/M1 접미사를 누락하면, 정산 보고서는 해당 직원이 연말에 긴급 세금 기준이었다는 정보를 잃게 됩니다. 이 데이터를 받은 다음 고용주나 이를 바탕으로 자진 신고서를 준비하는 회계사는 표준 누적 코드로 보고 W1/M1 문제가 없는 것처럼 적용합니다. 결국 직원의 세금은 이월되어서는 안 될 코드를 기준으로 다음 과세연도에 잘못 계산됩니다.

실제 영향은 가상의 이야기가 아닙니다. Audit Consulting Group의 P60 정정 사례집에는 맨체스터의 Emma라는 직원 사례가 있습니다. 그녀의 P60에 잘못된 세금 코드가 표시되어 £890 초과 납부가 발생했고, 이를 해결하기 위해 수정된 P60과 HMRC 환급 절차가 필요했습니다. 이는 한 증명서의 코드 하나가 잘못되어 직원의 돈 £890이 수개월 동안 HMRC에 묶여 있던 것입니다. 오류가 급여 시스템이 아닌 전사 과정에서 발생한 경우(급여 시스템은 올바른 코드를 생성했지만 P60을 전사하는 사람이 스프레드시트에 잘못 입력한 경우) 해결 경로는 더 깁니다. 고용주는 올바른 P60을 제시할 수 있습니다. 전사가 오류의 원인이지 원본 문서가 아닙니다. 하지만 6개월 전에 잘못 전사한 급여 담당자가 9월에 직원의 전화를 받는 사람이 아닐 수도 있습니다.

세금 코드 입력 오류는 자진 신고 파이프라인을 통해서도 이어집니다. 회계 법인이 클라이언트 문서에서 전사한 P60 데이터를 사용하여 SA100 세금 신고서의 고용 페이지를 작성하는 경우, 신고서의 잘못된 코드는 HMRC의 RTI 데이터와 불일치를 만듭니다. HMRC는 해당 신고서를 조사 대상으로 표시할 수 있으며, 회계사가 클라이언트에게 보내는 다음 연락은 5월의 입력 오류가 11월에 HMRC 서한을 초래한 이유를 설명하는 것으로 시작됩니다.

실수 #3: 총 급여와 원천징수 세금 — 한 열만 바꿔도 모든 것이 무너집니다

동일 과세연도에 두 직장을 가진 직원의 P60에는 시간에 쫓기면 쉽게 혼동되는 두 세트의 숫자가 표시됩니다. "이 고용에서의 급여"는 이 특정 고용주로부터의 총 급여입니다. "연간 총 급여"는 P45에서 이월된 이전 고용주의 급여를 포함합니다. "이 고용에서 원천징수된 세금"은 이 고용주가 원천징수한 PAYE 세금입니다. "연간 총 세금"은 모든 고용에서의 세금을 합산합니다.

Sage에서 인쇄된 P60에서는 이 네 숫자가 인접한 두 열에 나타날 수 있습니다. Xero에서 인쇄된 P60에서는 세로로 쌓여 나타날 수 있습니다. 5년 전 이전 고용주가 직원이 가져온 종이 P60에서는 완전히 다른 레이아웃으로 나타날 수 있습니다. 하루에 80개의 P60을 입력하며 매 서류마다 다른 레이아웃 형식을 오가는 급여 담당자는 "이 고용에서의 급여"를 "원천징수된 세금" 열에 한 번 잘못 입력합니다. 한 행. 한 번의 바꿔치기. 그러면 그 행은 이제 £4,870의 급여에 £31,200의 세금을 보여주거나 — 그 반대로 £31,200의 급여에 £4,870의 세금을 보여줍니다.

첫 번째 숫자는 자동 점검(세금 대 급여 비율)을 촉발합니다. £4,870의 급여에 £31,200의 세금이 있는 스프레드시트 행을 보는 사람은 누구나 알아차릴 것입니다. 그러나 그 반대인 £31,200의 급여에 £4,870의 세금은 15.6%라는 그럴듯한 실효 세율입니다. 비례성 점검을 통과합니다. 형식 점검을 통과합니다. 유효한 행으로 조정 보고서에 입력되며, FPS 데이터에 대한 총 행 조정이 약간 어긋납니다 — 반올림이나 작은 RTI 타이밍 차이로 돌리기에 충분히 가깝고, 모든 행의 전체 재감사를 촉발할 만큼 차이가 크지 않습니다.

이 특정 오류는 HMRC 자체 소프트웨어에서도 문서화된 유사 사례가 있습니다. 한 과세연도에 HMRC의 Basic PAYE Tools(BPT) 소프트웨어는 NI 소득 구간이 뒤바뀐 P60 PDF를 생성했습니다 — PDF에는 RTI 제출과 일치하지 않는 잘못된 숫자가 표시되었습니다. AccountingWEB에서 논의하는 급여 관리자들은 자신의 잘못이 아닌 오류를 진단하는 데 "청구 불가능한 시간"을 소비했다고 설명했습니다. HMRC의 답변은 오류가 기여 기관 데이터가 아닌 PDF에만 나타난다는 것이었습니다 — 이는 급여 담당자가 읽고 입력하는 PDF에 소프트웨어 제공업체조차 발견하지 못한 레이아웃 오류가 포함될 수 있음을 의미합니다.

인간의 전사 오류가 모호한 원본 문서 레이아웃(유사한 숫자 값이 있는 두 열, 시각적 구분선 없음)과 결합하면, 개별 행을 원본 P60 PDF와 대조하는 사람이 있기 전까지는 오류를 사실상 감지할 수 없게 됩니다. 하루 80행을 처리할 때, 모든 행을 원본 PDF와 대조하는 사람은 없습니다.

실수 #4: 퇴사일 불일치 — P45와 P60이 서로 다른 정보를 알려줄 때

이 실수는 단일 문서에서 발생하지 않습니다. 동일한 직원을 참조하는 두 문서 사이의 간극에서 발생합니다. 3월에 A사를 퇴사하고 4월에 B사에 입사한 직원은 두 세트의 P60 데이터에 나타납니다. A사의 P60은 3월 퇴사일까지의 급여를 보여줍니다. B사의 P60은 4월 입사일부터의 급여를 보여줍니다. 각 증명서는 개별적으로 정확합니다. 그러나 직원의 스프레드시트 행에 전사될 때 두 증명서의 합계는 아무도 확인하지 않는 제약 조건을 준수해야 합니다. 즉, P45의 퇴사일은 다음 고용의 시작일보다 앞서야 하며, 두 P60의 총 급여는 연간 수치와 일치해야 합니다.

P45의 퇴사일이 잘못 전사된 경우(예: 28/02 대신 31/03으로 입력), 새 고용주는 잘못된 세금 코드를 적용합니다. P45는 새 고용주가 직원의 누적 세금 상태를 결정하는 데 사용하는 문서이기 때문입니다. P45에 실제보다 2주 늦은 퇴사일이 표시되면, 새 고용주의 급여 소프트웨어는 이전 고용에서 2주 추가 면세 허용액을 가정하는 누적 코드를 적용합니다. 이는 직원이 이미 사용한 허용액입니다. 직원은 해당 연도의 남은 기간 동안 과소 과세되며, 다음 해 가을에 HMRC Simple Assessment 서신을 받아 부족분 납부를 요구받습니다.

HMRC의 지침에 따르면 잘못된 퇴사일을 수정하려면 급여 기록을 올바른 날짜로 업데이트하고 다음 FPS에 수정 사항을 보고하지 말라고 합니다. 그렇게 하면 중복 고용 기록이 생성될 수 있기 때문입니다. 그러나 이 지침은 원래 FPS를 제출한 고용주에게 적용됩니다. 전사 오류가 급여 부서의 조정 스프레드시트에서 발생한 경우(퇴사일이 원래 FPS 중이 아닌 데이터 입력 중에 잘못 입력됨), 부서는 수정할 FPS가 없습니다. 오류는 스프레드시트에만 존재합니다. 그리고 스프레드시트는 부서의 조정 보고서에 입력되고, 이는 고용주의 승인에 영향을 미치며, 결과적으로 고용주가 원래 P60에 존재하지 않았던 문제를 해결하기 위해 수정된 P60을 발행하게 되어 모두의 시간을 낭비하는 수정 루프를 만듭니다.

구조적 간극은 문서 간 검증입니다. 급여 소프트웨어는 단일 문서 내에서 검증합니다(P60의 NI 형식, P45의 세금 코드 형식). 문서 간 검증을 수행하는 시스템은 없습니다. 즉, P45 퇴사일과 P60의 "이 고용에서의 급여" 수치가 직원의 총 급여 추이와 일치하는지 확인하는 시스템은 없습니다. 이러한 문서 간 확인은 급여 담당자가 전사 시 수동으로 수행해야 하는 작업입니다. 그리고 업무량이 가용 시간을 초과할 때 가장 먼저 생략되는 확인 사항입니다.

실수 #5: 학자금 대출 플랜 혼동 — 플랜 1, 2, 4, 5 또는 대학원?

이 글에서 다루는 다섯 가지 실수 중 급여 담당자의 책임이 가장 적으면서도, P60 발급 후 수개월이 지나도 직원 불만이 가장 많이 발생하는 부분입니다. 영국 학자금 대출 상환 시스템은 현재 다섯 가지 플랜 유형으로 운영되며, 각각 상환 기준액이 다릅니다. 직원의 플랜은 수학 지역, 졸업 시기, 그리고 이수한 과정 유형에 따라 결정됩니다.

플랜 구성은 다음과 같습니다:

HMRC 고용주 지침에 따르면, 직원이 자신의 플랜을 모를 경우 학자금 대출 개시 통지서(SL1)를 받을 때까지 급여 소프트웨어에서 플랜 5를 사용하라고 안내합니다. 플랜 5를 기본값으로 설정하는 것은 합리적인 행정적 대비책이지만, 실제로 플랜 1, 2, 4에 해당하는 직원이 고용주에게 알리지 않으면 잘못된 기준액으로 공제가 계산됩니다. 플랜 1 대출자(기준액 £26,900)를 플랜 5(기준액 £25,000)로 처리하면 £1,900의 소득에 대해 예상보다 일찍 상환이 시작되며, 9% 기준으로 연간 약 £171이 초과 공제됩니다. 플랜 4 대출자(기준액 £33,795)를 플랜 5(£25,000)로 처리하면 £8,795의 소득에 대해 초과 납부가 발생하며, 연간 약 £792에 달합니다.

이 오류의 전사(transcription) 측면은 더 미묘합니다. 급여 담당자가 P60 데이터를 조정 스프레드시트에 전사할 때, P60에는 학자금 대출 공제액이 정수 파운드 단위로 하나만 표시됩니다. 해당 공제가 어떤 플랜에서 발생했는지는 표시되지 않습니다. 담당자가 스프레드시트의 '학자금 대출 공제' 열에 £1,200을 입력합니다. 숫자는 정확합니다. 플랜은 보이지 않습니다. 동일한 급여와 동일한 £1,200 공제를 받는 두 직원이 각각 플랜 1과 플랜 2에 속할 수 있지만, 스프레드시트는 이들을 동일하게 처리합니다. P60 총 공제액과 FPS 총액을 비교하는 조정 보고서는 공제 금액이 정확하므로 일치합니다. 오류는 금액이 아니라 P60에 이름이 명시되지 않은 급여 시스템에 기록된 플랜 유형에 있습니다.

HMRC가 직원의 상환 계획 유형을 교차 확인할 때 — 실제로 그렇게 하며, SLC 데이터가 HMRC를 거쳐 고용주에게 비동기적으로 전달되기 때문에 몇 달이 걸릴 수 있음 — 고용주는 직원이 잘못된 계획에 있었다는 통지를 받습니다. 그러면 고용주는 과거 공제액을 정정해야 하며, 직원이 SLC에 환급을 신청해야 할 수도 있습니다. MoneySavingExpert의 Martin Lewis는 플랜 2 상환 기준선 동결과 초과 공제의 광범위한 문제(변동 소득 직원, 너무 일찍 상환을 시작한 직원, 기본적으로 잘못된 계획에 있는 직원)를 문서화했습니다. 환급 절차는 급여가 아닌 SLC를 통해 진행되지만, 원래 오류는 P60이 요약하는 급여 기록과, 계획 유형을 포착하지 못해 오류의 가시성을 증폭시키는 조정 스프레드시트에 남아 있습니다.

AI 추출이 오류 프로필을 바꾸는 이유 — 속도만이 아님

위에서 설명한 모든 실수는 교육, 체크리스트, 2차 검토가 표면적으로만 해결하는 근본 원인을 공유합니다. 그 근본 원인은 바로 기록 단계 자체, 즉 사람이 PDF를 읽고 그 데이터를 셀에 입력하는 순간입니다. 이 단계를 제거하면 어떤 검증 공식도 잡아내지 못하는 오류 범주 전체가 사라집니다.

P60 데이터를 수동 입력 대신 AI로 추출하면 오류 프로필이 바뀝니다. 국민보험번호는 증명서에서 직접 읽히므로 페이지와 셀 사이에 전위(transposition) 기회가 없습니다. 세금 코드는 W1/M1 표시기를 포함한 전체 문자열이 추출되어 보존되므로, 사람이 기억나는 대로 입력하는 것이 아닙니다. 급여 및 세금 수치는 "이 고용에서의 급여" 대 "연간 총 급여"와 같이 운영자의 공간 탐색(10초 전에 처음 본 레이아웃)이 아닌 의미론적 의미에 따라 올바른 열에 매핑됩니다. 학자금 대출 공제는 인쇄된 값으로 추출되며, 계획 유형 문제는 기록 문제가 아닌 급여 시스템 구성 문제가 됩니다.

추출이 모든 오류를 없앤다는 의미는 아닙니다. 남는 오류의 종류가 바뀝니다. 전위 오류(잘못된 숫자, 잘못된 열, 접미사 누락) 대신 남는 오류는 검증 오류입니다. AI가 인쇄가 불량한 문자를 잘못 읽었는가? 연도 중간에 등급이 변경된 직원의 경우 잘못된 행에서 NI 등급 문자를 매핑했는가? 이러한 검증 오류는 운영자가 입력과 동시에 검토하는 대신 추출된 데이터를 원본 문서와 대조하여 검토하기 때문에 더 빨리 발견됩니다. 운영자는 기록자가 아닌 검토자가 되며, 검토자는 기록자가 만드는 오류를 잡아냅니다.

P60 PDF에서 조정 준비가 된 스프레드시트까지의 전체 워크플로우(Sage, Xero, BrightPay 및 모든 급여 제공자의 P60 레이아웃에서 작동하는 열 정의 포함)는 영국 P60 데이터를 Excel로 추출하는 가이드를 참조하세요. 급여 연말 결산의 구조적 병목 현상으로서 수동 P60 데이터 입력의 광범위한 문제는 P60 데이터 입력의 숨겨진 비용을 참조하세요.