영국 급여의 5월 문제
P60 데이터 입력의 숨은 비용

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

P60은 선택 사항이 아닙니다. 2003년 소득세(PAYE) 규정 제67조에 따라 모든 고용주는 4월 5일 기준 급여 명부에 있는 모든 직원에게 P60을 제공해야 합니다. 마감일은 5월 31일입니다. 이를 놓치면 HMRC는 초기 벌금 300파운드에 더해 P60이 미해결 상태로 남아 있는 매일 60파운드씩 추가 과태료를 부과할 수 있습니다. 이미 연말 신고 마감을 견뎌낸 급여 부서에게 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일에 연말 보상 보고서를 작성하기 위해 자리에 앉습니다. 급여 시스템은 이미 모든 현직 직원의 P60을 생성했습니다. 관리자는 PDF 번들을 다운로드합니다. 하지만 재무 이사가 원하는 보고서는 P60 자체가 아닙니다. 원하는 것은 직원 이름, NI 번호, 세금 코드, 총 급여, 총 공제 세액, 직원 NI 기여금, 고용주 NI 기여금이라는 열로 구성된 스프레드시트입니다. 이러한 필드 중 일부는 P60에 있습니다. 고용주 NI는 P60에 없으며 급여 시스템의 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을 생성하도록 설계되었기 때문입니다. P60을 소비하도록 설계된 것이 아닙니다. Sage Payroll은 법정 서식에 맞는 P60을 생성하고, 자체 데이터베이스에서 총 급여, 공제 세금, NI 기여금, 세금 코드 등 필드를 채운 다음 증명서를 배포합니다. 이 작업은 안정적으로 수행됩니다. 하지만 이 시스템이 하지 않는 일 — 어떤 급여 플랫폼도 설계상 수행하지 못하는 일 — 은 외부에서 P60 데이터를 가져와 다운스트림에서 사용할 수 있도록 구조화하는 것입니다. 급여 전문가가 다른 고용주, 다른 급여 제공업체 또는 종이 증명서의 P60 데이터를 자체 보고 환경으로 가져와야 할 때, 급여 소프트웨어는 제공할 수 있는 것이 없습니다. 데이터는 PDF나 종이에 있습니다. 시스템은 이를 읽을 수 없습니다. "데이터가 존재한다"와 "데이터가 내 스프레드시트에 있다" 사이의 간극은 여전히 키보드 앞의 사람입니다.

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

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

읽는 대신 직접 실행해 보시려면 P60 to 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의 "Total Pay for the Year"와 BrightPay에서 생성된 P60의 "Pay for the Year"가 동일한 데이터 포인트를 의미한다는 것을 이해합니다. 그렇다고 해도, 심하게 훼손된 복사본, 수기 수정, 비표준 종이 템플릿은 정확도를 떨어뜨릴 수 있습니다. 일반적인 P60 배치 — 알려진 급여 소프트웨어의 디지털 PDF와 소수의 스캔된 종이 사본이 섞인 경우 — 추출 정확도는 수작업 입력 작업의 대부분을 제거하지만 모든 예외 사례를 제거하지는 않습니다.

확인하지 않을 때의 비용

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

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

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