영국 급여 부서의 5월 문제
P60 데이터 입력의 숨겨진 비용

아무도 예산에 반영하지 않는 5월의 문제

P60은 선택 사항이 아닙니다. 2003년 소득세(PAYE) 규정 제67조에 따라 모든 고용주는 4월 5일 기준 급여 명부에 있는 모든 직원에게 P60을 제공해야 합니다. 마감일은 5월 31일입니다. 이를 놓치면 HMRC는 초기 벌금 300파운드에 더해 P60이 미해결 상태로 남아 있는 매일 60파운드씩 추가 과태료를 부과할 수 있습니다. 이미 연말 신고 마감(최종 FPS, 최종 EPS, P32 조정)을 견뎌낸 급여 부서에게 5월은 회복의 달이 아닙니다. 두 번째 마감일입니다.

직원 100명 규모의 회사에서 P60 발급 자체는 최신 급여 소프트웨어에서 몇 분이면 끝납니다. "P60 생성"을 클릭하고, 다운로드하고, 배포하면 끝입니다. 인건비가 발생하는 지점은 누군가가 급여 소프트웨어가 애초에 수행하도록 설계되지 않은 작업에 P60 데이터를 사용해야 할 때입니다. 즉, 이사회를 위한 연간 보상 보고서 작성, 총 급여액을 총계정원장과 조정, 감사 데이터 준비, 또는 — 여기서 작업량이 폭발적으로 증가합니다 — 이전 고용주로부터 증명서를 가져온 직원들의 P60 정보를 통합하는 경우입니다.

평균 직원 15명 규모의 중소기업 고객 30곳을 관리하는 중간 규모의 급여 대행 업체는 매년 5월 450개의 P60을 처리합니다. 80명의 고객을 위해 개인 세금 신고를 처리하는 단일 회계사는 각 고객의 P60 수치가 필요합니다. 급여 벤치마킹을 계획하는 인사 부서는 전체 직원의 연말 급여 총액이 필요합니다. 여기에는 연중에 입사하여 현재 고용주에서 근무한 기간만 P60에 표시되는 직원도 포함되며, 이는 동일 과세 연도에 두 직장에서 번 총 소득이 아닙니다. 이러한 각 시나리오에서 P60은 존재합니다. 데이터는 페이지에 있습니다. 하지만 이를 스프레드시트에 옮기는 작업 — 행별로, 필드별로, 고용주별로 — 은 여전히 수동 작업입니다.

서류의 출처

모든 P60이 동일한 급여 시스템에서 깨끗하고 기계 판독 가능한 데이터 내보내기 형태로 도착한다면, 수동 입력 문제는 존재하지 않을 것입니다. 또한 다른 나라라면 그랬을 것입니다. 영국에서 P60 환경은 어떤 급여 소프트웨어 업체도 해결할 유인이 없는 구조적 요인으로 인해 분열되어 있습니다.

이전 고용주는 여전히 종이로 발행합니다. 2025/26 과세 연도 중에 이직한 직원은 이전 고용주에게 P45를 남겼지만, 4월 5일에는 이전 고용주가 해당 직원이 근무한 연도 부분에 대한 P60을 여전히 발행합니다. HMRC 규정에 따라 각 고용 관계는 자체 P60을 생성합니다. 이전 고용주가 종이 기반 신고를 사용하거나 온라인 신고 면제 대상인 경우 — 돌봄 및 지원 고용주, 일부 종교 단체, 예외적 상황 면제를 받은 고용주 — 해당 P60은 물리적 문서로 도착합니다. 직원은 이를 새 급여 부서에 제출합니다. 누군가가 수치를 입력합니다.

여러 직업은 여러 P60을 의미합니다. 두 개의 PAYE 직업(정규직과 주말 직업, 또는 본업과 부업의 이사 급여)을 가진 직원은 두 개의 별도 P60을 받습니다. 각각은 해당 특정 고용에서의 소득만 표시합니다. 주택 담보 대출 신청, 세액 공제 청구, 또는 자진 신고에 필요한 직원의 총 연간 소득을 집계하려면 누군가가 두 수치를 더한 후 결합된 데이터를 필요한 곳에 입력해야 합니다. 직업 A의 급여 시스템은 직업 B의 P60을 볼 수 없습니다. 직업 B의 급여 시스템은 직업 A를 볼 수 없습니다. 그 다리는 계산기와 키보드입니다.

인수로 인해 급여가 다른 시스템에 남아 있습니다. 2024년에 자회사를 인수한 회사는 여전히 두 개의 급여 제공업체를 운영할 수 있습니다. 모회사는 Sage, 인수된 법인은 BrightPay를 사용합니다. 두 제공업체 모두 P60을 생성합니다. 두 제공업체 모두 자체 형식, 자체 필드 레이블, 자체 보고 대시보드에 맞게 구조화된 형식으로 생성합니다. 결합된 법인 전체의 총 인건비에 대한 단일 통합 보기가 필요한 재무 이사는 스프레드시트를 열고 두 개의 호환되지 않는 내보내기에서 데이터를 병합하기 시작합니다. 또는 더 일반적으로는 P60 PDF 자체에서 병합합니다. 내보내기 형식이 충분히 달라 자동 매칭을 위해서는 5월에 누구도 착수할 시간이 없는 IT 프로젝트가 필요하기 때문입니다.

뷰로 고객은 모든 형식의 파일을 가져옵니다. 급여 뷰로와 회계 법인은 이러한 모든 분열 요인의 교차점에 있습니다. 단일 뷰로는 4개의 다른 급여 시스템을 사용하여 40명의 고객을 위해 급여를 처리할 수 있습니다. 고객이 연도 중에 전환한 이전 급여 제공업체의 P60 데이터를 가져오거나, 뷰로 고객의 직원이 세금 신고를 위해 전년도 P60 수치가 필요할 때, 뷰로는 PDF, 스캔한 종이 사본, HMRC 개인 세금 계정의 스크린샷, 그리고 가끔은 누군가의 배우자가 서류 캐비닛에서 찾아 문자로 보낸 P60 사진을 받습니다. 뷰로의 임무는 이 모든 것을 정확한 숫자로 바꾸는 것입니다. 뷰로의 도구는 대부분의 경우 데이터 입력 담당자입니다.

수동 P60 입력의 실제 모습: 항목별, 분 단위로 살펴보기

"수동 데이터 입력"은 급여 소프트웨어 마케팅이 닳아빠질 때까지 사용해온 추상적인 표현입니다. 5월의 바쁜 시기에 직원이 책상에서 실제로 무엇을 하는지에 대해서는 아무것도 알려주지 않습니다. 실제 과정은 다음과 같습니다.

직원 120명 규모의 회사에서 급여 담당자가 5월 6일에 앉아 연말 보상 보고서를 작성합니다. 급여 시스템(예: Sage 50 Payroll)은 이미 모든 현재 직원에 대한 P60을 생성했습니다. 담당자는 PDF 번들을 다운로드합니다. 하지만 재무 이사가 원하는 보고서는 P60 자체가 아닙니다. 직원 이름, NI 번호, 세금 코드, 총 급여 총액, 총 공제 세금, 직원 NI 기여금, 고용주 NI 기여금 열이 포함된 스프레드시트입니다. 이러한 필드 중 일부는 P60에 있습니다. 고용주 NI는 그렇지 않습니다. 이는 급여 시스템의 P32 보고서에 있습니다. 직원 연금 기여금도 P60에 없습니다. 이는 최종 급여 명세서에 있습니다. 따라서 담당자는 이제 모든 직원에 대해 참조할 세 가지 원본 문서를 갖게 되었습니다.

120명의 직원 각각에 대해 담당자는 다음을 수행해야 합니다. PDF 번들에서 직원을 찾고, 총 급여 수치를 읽고 급여 시스템의 내부 보고서와 대조하여 확인하고, 스프레드시트에 입력하고, 공제된 세금을 읽고 입력하고, NI 기여금을 읽고 입력한 다음, 고용주 NI를 위해 P32 보고서로 전환하고, 연금 기여금을 위해 급여 명세서 PDF로 전환합니다. 각 필드는 대략 6~8초가 걸립니다. 화면에서 숫자를 찾고, 올바른 숫자인지 확인하고, 입력하고, 다시 확인합니다. 직원 120명, 직원당 7개 필드이면 840개 필드입니다. 각각 7초씩이면 순수한 필사 작업에 98분이 걸립니다. 실제로는 이전 고용주의 P60이 두 개 있는 직원, 스캔된 템플릿에서 생성되어 제대로 검색되지 않는 PDF, 오후 2시 이사회 회의에 보고서가 준비될 것인지 묻는 전무 이사의 방해를 고려하면 약 3시간에 가깝습니다.

급여 대행사의 경우 규모로 인해 숫자가 더욱 뚜렷해집니다. 30개 고객사에 걸쳐 450명의 직원이 있고, 동일한 직원당 7개 필드와 동일한 속도를 가정하면, 원시 필사 작업은 약 6시간이 소요됩니다. 이는 중단 없는 타이핑으로 하루 근무 시간 전체보다 더 깁니다. 그러나 대행사는 중단 없는 시간 블록을 얻지 못합니다. 그들은 P60, P32, P11D 및 2026년 4월 6일부터 시행된 새로운 의무적 급여 포함 혜택에 대해 문의하는 고객의 전화 사이에 클라이언트 파일이 도착하는 대로 일괄 처리합니다. 단편화된 주의가 흩어진 일주일 동안, 6시간의 데이터 입력은 중단과 재개가 반복되는 이틀 분량의 작업이 되며, 상황 전환 시마다 오류율이 높아집니다.

수동 데이터 입력 오류율에 대한 연구는 숙련된 작업자의 경우 1%에서 4% 범위로 수렴됩니다. 영국 급여 맥락에서 업계 설문 조사에 따르면 약 20%의 급여에 최소 하나의 오류가 포함되어 있습니다. 이는 데이터 필드의 20%가 아니라 전체 급여 실행의 20%입니다. 450명 직원 규모의 대행사의 경우, 필드 수준 오류율 1%는 P60 시즌당 4~5개의 잘못 입력된 수치를 의미합니다. 각각은 씨앗입니다.

영국 급여 환경에서의 오류 연쇄

P60 숫자를 잘못 입력하면 스프레드시트에만 머물지 않습니다. 퍼져나갑니다.

가장 짧은 경로는 직원의 자진 신고 세금 신고서로 이어집니다. 회계사가 P60의 총 급여를 잘못 입력하여 고객의 SA100에 기재하면 세금 계산이 틀어집니다. HMRC 시스템은 제출된 신고서를 고용주가 제출한 RTI 데이터와 비교합니다. 불일치가 발생하면 준수 점검이 시작됩니다. 회계사는 원본 P60을 찾아 입력 오류를 확인하고, 신고서를 수정한 후 고객에게 수정 사항을 설명해야 합니다. 각 단계는 청구할 수 없는 시간입니다.

다음 경로는 HMRC의 준수 체계 자체로 이어집니다. HMRC의 기록 보관 요구 사항에 따라 고용주는 관련 과세 연도 종료 후 최소 3년간 급여 기록을 보관해야 합니다. HMRC가 해당 기록을 조사하여 직원에게 발급된 P60 수치와 보고에 사용된 내부 기록 간에 불일치를 발견하면, 고용주는 부실 기록으로 인해 최대 £3,000의 벌금에 처해질 수 있으며, 정확한 수치를 재구성해야 하는 의무도 따릅니다. 감사 추적이 없는 수동 입력 스프레드시트의 경우, 이는 원본 문서에서 모든 것을 다시 입력해야 함을 의미합니다. 벌금은 계산을 잘못했기 때문이 아닙니다. 계산이 정확했다는 것을 증명할 수 없기 때문입니다. 잘못 입력된 키 하나가 있는 스프레드시트는 증거가 될 수 없습니다.

그리고 직원에게 직접 영향을 미치는 연쇄도 있습니다. P60은 영국 직원이 주택 담보 대출 신청, 세액 공제 청구, 비자 갱신 시 소득을 증명하는 데 사용하는 주요 문서입니다. 잘못된 숫자가 기재된 P60을 받은 직원(또는 두 P60의 총 급여를 누군가가 더할 때 잘못 계산된 경우)은 대출 기관이나 홈 오피스가 확인을 요청하는 최악의 순간에 오류를 발견합니다. P60을 발급한 급여 부서는 법적으로 "사본"이라고 표시된 수정 버전을 발행해야 합니다. 수동 입력 오류로 인해 발급된 모든 중복 P60은 급여 팀이 예산에 포함하지 않았고, 필요하지 않았어야 할 수정에 소요된 시간을 의미합니다.

수정 기간은 이 문제를 더 악화시킵니다. HMRC는 원래 제출 시점으로부터 6개 과세 연도까지의 급여 수정을 허용합니다. 2020/21 과세 연도의 P60 숫자를 2021년 5월에 잘못 입력하고 2026년에 수정했다면, 해당 숫자는 5년 동안 회사 기록에 남아 있었습니다. 그 기간 동안 해당 수치에 의존한 모든 보고서, 모든 감사, 모든 주택 담보 대출 신청은 잘못된 숫자를 기반으로 구축되었습니다. 단일 오류의 비용은 시간이 지남에 따라 줄어들지 않고 커집니다.

급여 소프트웨어가 이 문제를 해결하지 못한 이유

Sage는 1981년에 설립되어 영국 기업의 약 절반에 대해 급여를 처리합니다. Xero는 통합 급여 기능을 갖춘 부기 플랫폼에서 5,200명 이상의 영국 고객을 보유하고 있습니다. BrightPay는 뷰로 시장을 장악하고 있습니다. ADP는 영국에 사업장을 둔 다국적 기업의 급여를 운영합니다. 영국 급여 소프트웨어 산업은 성숙하고 자본이 풍부하며 HMRC의 RTI 시스템과 깊이 통합되어 있습니다. 그런데 왜 2026년에도 급여 전문가들이 여전히 P60 데이터를 수동으로 다시 입력하고 있을까요?

급여 소프트웨어는 P60을 생성하도록 설계되었기 때문이지, 소비하도록 설계되지 않았기 때문입니다. Sage Payroll은 법정 서식에 맞는 P60을 생성하고, 자체 데이터베이스에서 총 급여, 공제 세금, 국민보험 기여금, 세금 코드 등의 필드를 채운 후 증명서를 배포합니다. 이 작업은 안정적으로 수행됩니다. 하지만 어떤 급여 플랫폼도 외부 시스템의 P60 데이터를 가져와서 다운스트림에서 사용할 수 있도록 구조화하도록 설계되지 않았습니다. 급여 전문가가 다른 고용주, 다른 급여 제공업체 또는 종이 증명서의 P60 데이터를 자신의 보고 환경으로 가져와야 할 때, 급여 소프트웨어는 아무것도 제공할 수 없습니다. 데이터는 PDF나 종이에 있습니다. 시스템이 이를 읽을 수 없습니다. "데이터가 존재한다"와 "데이터가 내 스프레드시트에 있다" 사이의 간극은 여전히 키보드 앞에 앉은 사람입니다.

이는 시장 전반의 급여 명세서 처리에 영향을 미치는 동일한 구조적 문제입니다. 회계 법인을 위한 W-2 및 1099 추출에 관한 기사에서 살펴본 미국의 사례도 동일한 패턴을 따릅니다: 표준화된 서식, 호환되지 않는 시스템, 수동 재입력. 영국 상황에서의 차이점은 P60 표준화로 인해 수동 입력이 오히려 더 합리적으로 느껴진다는 점입니다. 필드는 항상 동일하고 레이아웃이 정해져 있으므로 입력하는 것이 작은 작업처럼 느껴집니다. 하지만 그 작은 작업을 직원 수, 출처 시스템 수, 잘못 입력했을 때의 다운스트림 영향으로 곱해야만 문제의 규모가 비로소 드러납니다.

이때 생성이 아닌 추출을 위해 설계된 다른 범주의 도구가 방정식을 바꿉니다. 모든 P60이 급여 시스템의 입력 채널을 통해 들어오도록 요구하는 대신, 의미론적 문서 추출은 각 필드가 의미하는 바를 읽습니다. 필요한 열을 한 번만 정의하십시오: "총 급여", "공제 세금", "국민보험 기여금", "세금 코드", "PAYE 참조번호". AI는 배치 내 모든 P60에서 각 값을 찾습니다. Sage에서 왔든, Xero에서 왔든, HMRC가 지정한 종이 템플릿에 손으로 작성했든, 직원이 서랍에서 찾은 2019년 증명서의 스캔본이든 상관없습니다. 정의한 열 이름은 그대로 유지됩니다. 출처 형식은 중요하지 않습니다. 템플릿도, 고용주별 구성도 필요 없습니다. 파일을 업로드하고 스프레드시트를 받으십시오. 단계별 워크플로는 급여 조정을 위한 영국 P60 데이터를 Excel로 추출하는 가이드를 참조하십시오.

규정 준수 시계는 똑딱거리고 있습니다

5월의 압박만이 유일한 마감일은 아닙니다. P60 데이터를 수동으로 스프레드시트에 입력할 때, HMRC의 3년 기록 보관 의무는 모든 키 입력이 적어도 2029년 4월까지 회사의 규정 준수 기록에 남아있음을 의미합니다. 6년의 수정 기간은 2031년에 발견된 오류라도 원본 P60까지 추적 가능해야 함을 의미합니다. 출처에서 셀까지의 감사 추적이 없는 수동 입력 스프레드시트는 그런 수준의 조사를 견딜 수 없습니다.

벌금 구조는 이분법적이며 무자비합니다. HMRC가 기록을 요청했는데 고용주가 제시할 수 없는 경우, HMRC는 세금 부채를 추정할 수 있으며, 고용주는 자신이 없다고 이미 인정한 기록을 사용하여 그 추정이 틀렸음을 증명해야 합니다. 기록은 존재하지만 오류가 있는 경우, 고용주는 부적절한 기록에 대해 £3,000의 벌금에 직면합니다. 오류가 HMRC에 보고된 세금에 영향을 미치는 경우, 추가 연체 벌금이 적용됩니다 — 30일째 미납액의 1%에서 시작하여 6개월 및 12개월째 5%로 증가합니다. 한 P60의 총 급여 수치를 잘못 입력한 단일 오타가, 회계 사무소의 고객 기반을 통해 여러 과세 연도로 이월되면, 키 입력 오류에서 다섯 자리 수의 부채로 증폭될 수 있습니다.

그럼에도 불구하고, 대부분의 급여 팀에게 이러한 위험 중 어느 것도 P60 데이터를 수동으로 입력하는 결정에 가격이 책정되지 않습니다. 위험이 측정된 적이 없기 때문입니다. 데이터 입력 자체의 비용은 보이지 않습니다: "급여 처리"에 묻혀, 급여 담당자 역할에 흡수되어, 예산 항목으로 나타나지 않습니다. 수정 비용도 같은 방식으로 흡수됩니다. 감사가 그 격차를 드러낼 때 — HMRC가 "이 수치를 증명하라"고 요구하고 증명이 추적 불가능한 스프레드시트일 때 — 비용이 현실화됩니다. 그 시점에서 수동 입력이 거짓된 경제성이었다고 판단하기에는 너무 늦습니다.

여러 출처(다른 급여 시스템을 사용하는 직원, 회계 사무소의 고객, 수정 신고를 위한 전년도 증명서)에서 P60을 수집해야 하는 조직의 경우, 수집 링크를 통해 추출 전 문서 수집을 중앙화하여 "직원에게 종이 사본을 요청하는" 단계를 워크플로에서 완전히 제거할 수 있습니다.

자주 묻는 질문

급여 소프트웨어의 내보내기 기능으로 P60 데이터를 가져오면 안 되는 이유는 무엇인가요?

급여 소프트웨어는 자사가 급여를 지급하는 직원의 P60 데이터만 내보낼 수 있습니다. 다른 고용주, 이전 급여 제공업체 또는 수기 시스템에서 급여를 지급한 직원의 P60 데이터는 내보낼 수 없습니다. 또한 자사 급여 내에서도 내보내기 형식이 다운스트림 보고서에 필요한 구조와 일치하는 경우는 드뭅니다. 필드 이름이 다르고, 열 레이아웃이 맞지 않으며, 별도 모듈에 있는 고용주 NI 또는 연금 기여금이 포함되지 않을 수 있습니다. 내보내기는 사용 가능한 데이터를 의미하지 않습니다.

P60을 늦게 발급하면 어떤 과태료가 부과되나요?

HMRC는 초기 과태료 £300에 더해 P60이 미해결 상태로 남아 있는 매일 £60씩을 부과할 수 있습니다. 과태료 부과 가능성은 지연 사유와 시정 속도에 따라 달라집니다. 신속하게 수정된 진정한 오류는 반복적인 지연이나 조직적인 실패보다 과태료가 부과될 가능성이 낮습니다.

고용주는 P60 기록을 얼마나 오래 보관해야 하나요?

HMRC의 기록 보관 요건에 따라, 해당 과세 연도 종료일로부터 3년간 보관해야 합니다. 즉, 2025/26 과세 연도의 P60은 최소 2029년 4월까지 보관해야 합니다. HMRC는 최대 6개 과세 연도 전의 정정도 수용할 수 있으므로, 수정 가능성이 조금이라도 있다면 실질적인 보관 기간은 더 길어집니다.

P60에 연금 기여금이 표시되나요?

아니요. P60에는 총 급여, 총 공제 세액, 국민보험 기여금, 그리고 직원의 최종 세금 코드가 표시됩니다. 연금 기여금은 과세 연도의 마지막 급여 명세서에 표시되며 P60에는 표시되지 않습니다. 이것이 수동 입력이 만연한 구조적 이유 중 하나입니다. 급여 전문가가 실제로 필요로 하는 모든 필드를 포함하는 단일 보고서는 존재하지 않습니다. 데이터는 P60, P32 및 최종 급여 명세서에 분산되어 있습니다.

직원이 동일 과세 연도에 두 개의 일자리를 가진 경우, P60을 하나 받나요, 아니면 두 개 받나요?

두 개입니다. 각 고용주로부터 하나씩 받습니다. 각 P60은 해당 고용 관계의 급여와 공제액만 보고합니다. 직원은 종합소득세 신고나 기타 목적을 위해 이 수치를 직접 합산해야 합니다. 현재 연도 데이터를 처리하는 급여 전문가의 경우, 현재 고용주의 P60은 해당 연도의 일부만 포함하므로 전체 상황을 파악하려면 이전 고용주의 P60 또는 P45 수치와 수동으로 통합해야 합니다.

AI가 다양한 급여 시스템의 P60 형식을 실제로 처리할 수 있나요?

P60은 HMRC가 정한 양식을 따르므로 대부분의 문서 유형보다 표준화되어 있습니다. 차이는 급여 소프트웨어 렌더링 방식(서로 다른 글꼴, 약간씩 다른 필드 위치, 고용주 로고 유무 등)에서 발생하며, 구조적 차이에서 오는 것은 아닙니다. 최신 AI 추출은 필드 레이블을 의미적으로 읽습니다. Sage에서 생성된 P60의 "연간 총 급여"와 BrightPay에서 생성된 P60의 "연간 급여"가 동일한 데이터 항목을 가리킨다는 것을 이해합니다. 다만, 심하게 손상된 복사본, 수기 수정 사항, 비표준 종이 양식의 경우 정확도가 떨어질 수 있습니다. 일반적인 P60 배치(알려진 급여 소프트웨어의 디지털 PDF와 소수의 스캔 종이 사본 혼합)의 경우 추출 정확도로 인해 수동 입력 작업의 대부분이 제거되지만, 모든 예외 사례까지 해결되지는 않습니다.

간과하는 비용

영국 급여 업계는 PAYE 계산, RTI 제출 처리, P60 적시 생성을 위한 정교한 인프라를 구축했습니다. 그러나 구축하지 못한 것은 P60과 데이터가 실제로 사용되는 스프레드시트(보상 분석, 감사 준비, 자진 신고, 주택 담보 대출 신청 등 연말 급여 수치가 구조화된 형식으로 필요한 모든 하위 프로세스) 사이의 연결 다리입니다.

이 격차는 매년 5월, 급여 전문가들의 수동 입력으로 채워집니다. 필드당 6~8초면 입력 자체는 충분히 빨라 아무도 의문을 제기하지 않습니다. 1%~4%의 오류율은 오류가 충분히 드물어 각각이 시스템적 비용이 아닌 고립된 실수처럼 느껴집니다. 수정, 정정, 중복 P60, 재발급 증명서 등의 보고는 '일상 업무'에 흡수됩니다. 3천만 개의 P60과 수천 개의 급여 부서에 걸친 누적 비용은 측정된 적이 없습니다. 측정하려면 격차가 존재한다는 것을 인정해야 하기 때문입니다.

첫 번째 단계는 소프트웨어를 구매하는 것이 아닙니다. 시간을 계산하고, 오류를 계산하고, 5월 문제에 숫자를 매기는 것입니다. 급여 관리자 한 명. 3일간의 분산된 데이터 입력. 잘못된 수치가 기재된 직원들의 수정 이메일 5통. 재발급된 중복 P60 2건. 오후 내내 해결해야 하는 HMRC 문의 1건. 한 번 합산해 보십시오. 그런 다음 격차의 비용이 이를 해소하는 비용보다 낮은지 결정하십시오.