80개 P11D, 하나의 P11D(b):
직원 혜택 데이터 일괄 처리

P11D 80건 개별 생성이 아닌, 집계가 문제인 이유

급여 소프트웨어는 P11D 생성을 해결했습니다 — 단, 직원 1명씩만 처리할 수 있습니다. Sage, BrightPay, Xero, IRIS, Moorepay는 각각 과세 연도 전체에 걸쳐 직원 복리후생 기록을 유지하고, HMRC가 정한 평가 규칙에 따라 현금 등가액을 계산하며, 제출 가능한 P11D 양식을 생성합니다. 시간이 소요되는 단계는 생성이 아닙니다.

시간이 소요되는 단계는 모든 P11D(b)가 요구하는 집계 단계입니다. P11D(b)는 모든 직원에게 제공된 모든 복리후생에 대해 납부해야 할 총 Class 1A National Insurance를 신고하는 고용주 신고서입니다. HMRC의 CWG5 지침은 명확합니다: Class 1A가 적용되는 모든 복리후생의 현금 등가액을 — 전체 직원에 걸쳐 — 합산한 다음, 그 합계에 Class 1A 세율인 2025/26년 15%를 곱합니다. 이 산술에는 하나의 숫자가 필요합니다: 모든 P11D의 모든 섹션에서 1A로 표시된 모든 현금 등가액의 합계입니다. 그 숫자를 얻으려면 80개 개별 양식에서 값을 추출해야 합니다.

단일 급여 제공업체를 사용하는 회사의 경우, 해당 소프트웨어의 P11D 생성 도구가 80개 양식을 한 번에 일괄 인쇄할 수 있습니다. 그러나 직원별 한 행씩, 섹션별 현금 등가액이 구분된 구조화된 스프레드시트를 생성하지는 않습니다. P11D(b)에 입력되는 작업 파일인 그 스프레드시트는 수작업으로 만들어야 합니다. 직원당 약 2분씩 PDF를 열고, 관련 섹션 값을 찾아 행에 옮겨 적고, 양식의 14개 섹션에서 잘못 읽은 필드가 없는지 확인하는 작업을 80명 규모의 복리후생 포트폴리오에 적용하면, 마감 2주 전에 순수 데이터 입력만 2시간 30분 이상 소요됩니다. 그리고 이는 모든 초안이 동일한 소프트웨어에서 나왔고 모든 양식의 시각적 레이아웃이 동일하다는 가정하에 계산된 것입니다.

모든 P11D(b) 계산을 공급하는 단 하나의 스프레드시트

일괄 추출을 시작하기 전에 출력 스프레드시트에는 열 스키마가 필요합니다. 일반적인 스키마가 아니라 P11D(b)가 요구하는 사항에 직접 매핑되는 특정 스키마가 필요합니다. 영국 급여 전문가 협회(CIPP)는 연간 급여 연말 자료에서 P11D 작성에 대한 자세한 지침을 발행하며, 매년 일관된 메시지는 동일합니다. P11D(b)는 직원당 한 가지, 즉 1A 과세 혜택의 총 현금 등가액만을 중요하게 생각합니다. 개별 양식 섹션으로의 감사 추적을 구축하는 것은 급여 관리자가 HMRC가 해당 총액을 문의할 때 이를 방어할 수 있게 해줍니다.

실용적인 P11D(b) 준비 스프레드시트는 직원당 한 행이며, 두 가지 목적을 제공하는 열이 있습니다: 신원 일치와 혜택 합산입니다. 신원 열(직원 이름, NINO, 고용주 PAYE 참조 번호)은 모든 행이 올바른 HMRC 기록으로 추적되도록 보장합니다. 혜택 열은 P11D 섹션 문자를 P11D(b) 합계가 참조할 수 있는 스프레드시트 열에 매핑합니다:

이 스프레드시트의 대부분 행은 2~3개의 혜택 열만 채워집니다. 대부분의 직원은 회사가 제공하는 혜택 중 일부만 받기 때문입니다. 임원과 세 명의 고위 관리자는 회사 차량을 보유합니다. 직원의 절반은 개인 의료 보험에 가입되어 있습니다. 한 직원은 연중 이사했습니다. 200명 규모 회사의 혜택 포트폴리오에는 보고 가능한 혜택이 하나 이상 있는 직원이 80명일 수 있으며, 스프레드시트는 빈 섹션을 0으로 평가된 혜택과 혼동하지 않고 희소성을 처리해야 합니다.

다중 직원 규모에서만 드러나는 세 가지 구조적 문제

P11D 한 건을 처리하는 것과 80건을 처리하는 것은 다른 작업입니다. 규모의 변화는 일괄 인쇄 기능이 있는 급여 소프트웨어만으로는 해결되지 않는 세 가지 문제를 만들어냅니다.

지연 가산세 제도는 입력 오류의 비용을 구체적으로 보여줍니다: 단 한 건의 지연 또는 부정확한 P11D는 양식당 월 £300의 가산세가 부과되며, 지연이 지속되면 HMRC는 일일 £60의 추가 가산세를 부과할 수 있습니다. 이러한 가산세는 재량이 아닙니다 — 7월 6일 마감일 다음 날부터 적용됩니다. 제출 후 발견된 오류는 수정 신고를 유발하며, HMRC는 자체 일정에 따라 처리합니다.

하나의 열 정의로 모든 급여 시스템의 P11D 출력 처리

수동 입력을 대체하는 추출 방식은 맞춤 열 추출입니다. 스프레드시트 헤더로 사용할 필드 이름을 입력하면 — "Car Cash Equivalent," "Medical Insurance Cash Equivalent," "Loan Cash Equivalent," "Amount Made Good" — AI가 각 P11D 초안을 읽고 급여 시스템 종류와 관계없이 해당 섹션 값을 열에 매핑합니다. 이 방식은 양식의 각 필드 라벨 의미를 이해하는 방식으로 작동하며, 픽셀 좌표를 매칭하지 않습니다. 자동차 혜택 섹션을 "Cars and car fuel"로 표기하는 Sage P11D와 "Car benefit"으로 표기하는 BrightPay P11D 모두 "Car Cash Equivalent" 열에 매핑되는 이유는 AI가 둘 다 동일한 HMRC 정의 Section F 개념으로 인식하기 때문입니다.

이러한 전환 덕분에 일괄 P11D 처리가 양식별 재스캔 방식에서 단일 패스 작업으로 바뀝니다. 열 스키마를 한 번 정의하고 모든 P11D 초안을 하나의 배치로 업로드하면 — PDF, 스캔본, 인쇄된 양식의 휴대폰 사진 — 80개 행이 모두 하나의 병합된 스프레드시트에 채워집니다. 수집 링크는 초안이 팀원이나 외부 급여 대행 기관에 분산되어 있는 경우에 사용합니다.

여기에서 단일 P11D 초안으로 추출 원리를 직접 테스트할 수 있습니다 — 샘플 업로드 후 몇 개의 열 이름을 지정하면 섹션 값이 어떻게 매핑되는지 확인할 수 있습니다:

동일한 열 세트는 과세 연도와 급여 제공업체를 넘어 재사용할 수 있으며, 여러 회사의 P11D 신고를 처리하는 경우 고용주 간에도 재사용할 수 있습니다. HMRC 보고용 UK P11D 혜택 데이터를 Excel로 추출하는 방법에 대한 종합 가이드에서 양식별 추출 워크플로를 자세히 다룹니다. 일괄 규모에서 중요한 점은 동일한 열 이름이 어떤 소프트웨어로 생성되었든 폴더의 모든 초안에서 동일하게 작동한다는 것입니다.

스프레드시트 80개 행에서 P11D(b) 수치 하나로

추출된 스프레드시트가 채워지면 — 직원당 한 행, 신원 열이 채워지고, 복리후생 섹션은 해당 항목이 있으면 채워지고 없으면 비어 있는 상태 — P11D(b)는 계산기 작업이 아닌 하나의 수식이 됩니다. HMRC의 CWG5 실무 예제는 산술 과정을 명확히 보여줍니다: Class 1A 과세 대상 모든 복리후생의 현금 등가액을 합산한 뒤 15%를 곱합니다. 데이터가 열로 구조화되어 있으면, 1A 과세 대상 복리후생 열에 걸친 SUMIF 하나와 곱셈 한 번이면 됩니다.

하지만 이 도구는 한 단계 더 나아갈 수 있습니다. 계산 열을 사용하면 AI가 추출 후가 아닌 추출 중에 합산을 수행할 수 있습니다. Total 1A-Liable (sum of Car, Medical, Loan, Van, Accommodation cash equivalents minus Amount Made Good)이라는 열을 지정하면 각 초안을 읽을 때 직원별 순 1A 과세 대상 수치가 자동으로 채워집니다. 그런 다음 P11D(b)를 위해 80개 행 전체를 합산하는 열은 이미 직원 기여금을 차감한 값을 합산하게 되어, 수동 집계에서 가장 흔한 실수 중 하나를 제거합니다.

일괄 추출이 하지 않는 것 — 여전히 사람의 검토가 필요한 부분

정직한 일괄 워크플로우에는 검증 단계가 포함됩니다. 추출은 원본에 기재된 내용을 그대로 읽어옵니다. 급여 시스템이 복리후생 가치를 잘못 계산했다면, 그 오류가 그대로 스프레드시트로 전달됩니다. 추출 과정에서는 차량 가격과 CO2 등급으로 자동차 복리후생을 재계산하거나, 혜택성 대출이 연간 £10,000 집계 기준을 초과했는지 확인하거나, 복리후생이 1A 과세 대상으로 올바르게 분류되었는지 검증하지 않습니다. 이러한 판단에는 HMRC 평가 규칙에 대한 급여 전문가의 지식이 필요합니다.

추출 후 실행할 가치가 있는 검증 확인은 데이터가 열로 구조화되어 있기 때문에 빠르게 수행할 수 있습니다:

추출된 각 행에는 원본 파일 참조가 포함되어 있어, 문제가 있는 행은 원본 P11D 초안에서 한 번의 클릭으로 확인할 수 있습니다. 이러한 추적 가능성 덕분에 80명의 직원 규모에서도 열 수준 검증이 현실적입니다. 수동 필사 워크플로우로는 체계적인 검증이 불가능했습니다. 필사 단계 자체가 가용 시간을 모두 소모했기 때문입니다.

P11D, P60, P45 일괄 처리: 동일한 워크플로, 다른 열 세트

영국 급여팀은 세 가지 법정 직원 양식을 처리하며, 각각 HMRC에 다른 데이터를 보고하지만 일괄 처리 문제는 세 양식 모두 구조적으로 동일합니다. 개별 PDF 생성은 해결되었지만, 이를 요약 스프레드시트로 통합하는 작업은 아직 해결되지 않았습니다. 열 이름은 바뀌지만 일괄 워크플로는 동일합니다.

차이는 필드 세트에 있습니다. P60 일괄 처리(급여 감사를 위한 P60 일괄 처리 가이드 참조)는 연말 증명서에서 급여, 세금, NI 수치를 추출합니다. P45 일괄 처리(퇴사자 양식 P45 일괄 처리 가이드 참조)는 퇴사하는 직원의 퇴사일과 지급액을 추출합니다. SA100 일괄 처리(SA100 세금 신고 일괄 처리 가이드 참조)는 자진 신고 수치를 추출합니다. 팀에서 네 가지 양식 유형을 모두 처리하는 경우, 각각에 대해 별도의 저장된 열 정의를 유지하고 재사용하세요. 일괄 워크플로는 동일하며, 열 이름만 양식에 따라 다릅니다.

자주 묻는 질문