5 Erros de Digitação no P60 que Colocam
a Conciliação da Folha de Pagamento em Risco

O Ponto Cego da Transcrição na Inserção de Dados do P60

A indústria de folha de pagamento passa anos discutindo erros no P60 — mas quase sempre pelo lado do software. Código tributário errado aplicado durante o ano. Letra de categoria NI incorreta no sistema de folha. Envio de RTI sinalizado pela HMRC. Esses são erros de processamento: o software de folha gerou um certificado errado porque os dados inseridos estavam errados, ou uma configuração estava desajustada. A correção está no sistema de folha.

Mas existe uma segunda categoria de erro no P60 que blogs de folha, guias de escritórios de contabilidade e páginas de orientação da HMRC mal mencionam: os erros introduzidos após o P60 ser gerado corretamente, no momento em que uma pessoa lê o certificado e digita seus dados em uma planilha de conciliação. Um bureau de folha verificando totais de FPS de fim de ano contra a saída do P60 não está corrigindo software — está verificando se a saída do software corresponde aos envios da HMRC. O documento de origem é o P60. O destino da transcrição é uma planilha. Cada campo transcrito é uma oportunidade para um erro que nenhuma trilha de auditoria do software de folha capturará, porque o sistema de folha nunca esteve envolvido na transcrição.

Esses erros são estruturalmente diferentes dos erros de processamento. Um erro de processamento é capturado quando o sistema de folha sinaliza uma regra de validação — um formato NI inválido, um código tributário que não corresponde aos registros da HMRC. Um erro de transcrição é capturado quando alguém compara manualmente a célula da planilha com o PDF do P60. Se ninguém fizer essa comparação, o erro permanece na planilha, alimenta o relatório de conciliação e eventualmente surge quando um funcionário percebe que seu código tributário está errado — ou um credor hipotecário rejeita um pedido porque o valor de pagamento no P60 não corresponde à verificação do empregador.

Os cinco erros abaixo são aqueles que sobrevivem à validação de formato, passam pelas verificações de fim de mês e surgem meses depois. Eles não são problemas de "revise seu trabalho com mais cuidado" — são sintomas de um fluxo de trabalho onde a própria etapa de transcrição é a causa raiz.

Erro #1: Transposição do Número de NI — O Erro que Encontra o Funcionário Errado

O formato do número de Seguro Nacional — duas letras de prefixo, seis dígitos, uma letra de sufixo — parece que deveria detectar automaticamente erros de transposição. Qualquer software de folha de pagamento, qualquer fórmula de validação no Excel, qualquer envio RTI rejeitará uma string que não corresponda ao padrão. Mas aqui está o que a verificação de formato realmente detecta: entradas de comprimento errado, caracteres onde deveriam estar dígitos, letras de prefixo inválidas (D, F, I, Q, U, V como primeiro caractere; D, F, I, O, Q, U, V como segundo).

O que ela não detecta é uma transposição dentro do segmento de seis dígitos. QQ 12 34 56 C digitado como QQ 12 43 56 C passa em toda validação de formato existente — nove caracteres, duas letras de prefixo válidas, seis dígitos, uma letra de sufixo válida. O software de folha de pagamento aceita. O sistema RTI da HMRC aceita. E ele direciona os dados fiscais e de NI do funcionário para o registro errado da HMRC — um registro que pode pertencer a uma pessoa completamente diferente, ou a ninguém, até que o algoritmo de correspondência da HMRC eventualmente sinalize a incompatibilidade.

Uma única transposição no segmento de seis dígitos cria um número de NI válido que pertence a um indivíduo diferente — ou cria uma combinação que não corresponde a nenhum número de NI emitido, mas passa na validação de formato. Em ambos os casos, o dano downstream não é um envio rejeitado — é um envio silenciosamente aceito com vínculo de identidade errado. Os dados do P60 do funcionário caem no registro de Seguro Nacional de outra pessoa. O cálculo do direito à Pensão Estatal dessa outra pessoa incorpora os ganhos de outra pessoa. O pré-preenchimento da Declaração de Imposto de Renda dessa outra pessoa mostra renda de um empregador para o qual ela nunca trabalhou.

A letra de sufixo é outra camada de complexidade oculta. As quatro letras válidas — A, B, C, D — correspondem ao trimestre civil em que o número de NI foi originalmente emitido. Administradores de folha de pagamento que trabalhavam antes do RTI sabem disso porque os cartões de NI costumavam chegar trimestralmente, e o sufixo era o marcador do trimestre. Alguém que entrou na profissão em 2020 pode nunca ter ouvido falar do sistema de sufixo trimestral. Então, quando transcrevem um P60 e veem QQ 12 34 56 C, não sabem que C significa "emitido no trimestre de outubro a dezembro" — e não sinalizariam se o sufixo estivesse errado, porque a validação de formato verifica apenas se o sufixo é A/B/C/D ou espaço, não se corresponde ao trimestre de emissão do número de NI.

A firma de contabilidade que assumiu um novo cliente e descobriu que o número de NI estava errado "por alguns anos" — documentada no AccountingWEB — não é uma exceção. É o que acontece quando um erro de transposição entra no sistema e a validação de formato diz "parece certo para mim."

Erro #2: Inserção Incorreta do Código Tributário — O Erro que Custa Dinheiro Real aos Funcionários

Um código tributário em um P60 não é apenas uma sequência como 1257L. Ele representa o estado final do cálculo PAYE do funcionário para o ano fiscal e carrega duas informações críticas: o próprio número do código, que determina a isenção fiscal, e um indicador opcional de base — W1 ou M1 — que informa à HMRC se o código foi aplicado de forma cumulativa ou emergencial (não cumulativa).

O erro de transcrição mais comum com códigos tributários não é digitar 1257L como 1258L. É omitir o indicador de base quando o P60 mostra 1257L W1. Se a coluna da planilha captura apenas o código e descarta o sufixo W1/M1, o relatório de reconciliação perde a informação de que este funcionário estava em base tributária emergencial no fim do ano. O próximo empregador que receber esses dados — ou o contador que preparar a declaração de Imposto de Renda a partir deles — vê um código cumulativo padrão e o aplica como se não houvesse problema com W1/M1. O imposto do funcionário é calculado incorretamente para o próximo ano fiscal, com base em um código que nunca deveria ser transportado.

O impacto real não é hipotético. O arquivo de correções de P60 da Audit Consulting Group inclui uma funcionária chamada Emma, em Manchester, cujo P60 exibia o código tributário errado — o resultado foi um pagamento a maior de £890, que exigiu um P60 corrigido e um processo de reembolso da HMRC para ser resolvido. Isso são £890 do dinheiro de uma funcionária retidos pela HMRC por meses, porque um código em um certificado estava errado. Quando o erro é de transcrição, e não do sistema de folha de pagamento — o sistema gerou o código correto, mas a pessoa que transcreveu o P60 o digitou incorretamente na planilha — o caminho para a resolução é mais longo. O empregador pode apontar para o P60 correto. A transcrição é o erro, não o documento original. Mas o operador de folha de pagamento que o transcreveu errado há seis meses pode não ser a pessoa que atende a ligação do funcionário em setembro.

A inserção incorreta do código tributário também se propaga pelo pipeline da declaração de Imposto de Renda. Se um escritório de contabilidade usa dados do P60 — transcritos de documentos de clientes — para preencher as páginas de Emprego da declaração SA100, um código errado na declaração cria uma incompatibilidade com os dados RTI da HMRC. A HMRC pode sinalizar a declaração para investigação, e a próxima comunicação do contador com o cliente começa explicando por que um erro de digitação em maio gerou uma carta da HMRC em novembro.

Erro #3: Remuneração Total e Imposto Descontado — Uma Troca de Coluna que Desanda Tudo

Um P60 de um funcionário que teve dois empregos no mesmo ano fiscal mostra dois conjuntos de valores facilmente confundíveis sob pressão de tempo. "Remuneração neste Emprego" é o salário bruto deste empregador específico. "Remuneração Total do Ano" inclui salários de empregos anteriores, transportados do P45. "Imposto Descontado" neste emprego é o PAYE que este empregador reteve. "Imposto Total do Ano" agrega o imposto de todos os empregos.

Num P60 impresso pelo Sage, esses quatro valores podem aparecer em duas colunas adjacentes. Num P60 impresso pelo Xero, podem aparecer empilhados verticalmente. Num P60 em papel trazido por um funcionário de um empregador anterior há cinco anos, podem aparecer num layout completamente diferente. Um operador de folha de pagamento transcrevendo 80 P60s por dia, alternando entre diferentes formatos de layout a cada poucos certificados, digita "Remuneração neste Emprego" na coluna "Imposto Descontado" uma vez. Uma linha. Uma troca. E essa linha agora mostra £31.200 de imposto sobre £4.870 de remuneração — ou o inverso, £4.870 de imposto sobre £31.200 de remuneração.

O primeiro número dispara uma verificação automática — proporção imposto/remuneração. Qualquer um que veja uma linha de planilha com £31.200 de imposto sobre £4.870 de remuneração notará. Mas o inverso — £4.870 de imposto sobre £31.200 de remuneração — é uma alíquota efetiva plausível de 15,6%. Passa na verificação de proporcionalidade. Passa na verificação de formato. Alimenta o relatório de conciliação como uma linha válida, e a conciliação total das linhas com os dados do FPS sai ligeiramente desviada — perto o bastante para atribuir a arredondamento ou pequena diferença de timing do RTI, não longe o bastante para acionar uma reauditoria completa de cada linha.

Esse erro específico tem um paralelo documentado no próprio software da HMRC. Em um ano fiscal, o software Basic PAYE Tools (BPT) da HMRC produziu PDFs de P60 onde as faixas de ganhos de NI estavam trocadas — o PDF mostrava valores errados que não correspondiam à submissão do RTI. Administradores de folha de pagamento discutindo no AccountingWEB descreveram gastar "tempo não cobrável" diagnosticando um erro que não era deles. A resposta da HMRC foi que o erro aparecia apenas no PDF, não nos dados da agência de contribuições — o que significa que o PDF que o operador de folha está lendo e transcrevendo pode conter erros de layout que nem o provedor do software detectou.

Quando um erro humano de transposição se combina com um layout de documento fonte que é em si ambíguo — duas colunas com valores numéricos semelhantes, sem separador visual — o erro se torna virtualmente indetectável até que alguém reconcilie a linha individual contra o PDF original do P60. A 80 linhas por dia, ninguém reconcilia cada linha contra o PDF original.

Erro #4: Divergência na Data de Saída — Quando o P45 e o P60 Contam Histórias Diferentes

Esse erro não ocorre em um único documento. Ele acontece na lacuna entre dois documentos que se referem ao mesmo funcionário. Um funcionário que saiu do Empregador A em março e começou no Empregador B em abril aparece em dois conjuntos de dados do P60. O P60 do Empregador A mostra o pagamento até a data de saída em março. O P60 do Empregador B mostra o pagamento a partir da data de início em abril. Ambos os certificados estão individualmente corretos. Mas a soma dos dois — quando transcrita em uma linha de planilha para o funcionário — precisa respeitar uma restrição que ninguém está verificando: a data de saída no P45 deve ser anterior à data de início do próximo emprego, e o pagamento total em ambos os P60s deve corresponder aos valores do ano completo.

Quando a data de saída no P45 é transcrita incorretamente — digitada como 31/03 em vez de 28/02, por exemplo — o novo empregador aplica o código tributário errado porque o P45 é o documento que o novo empregador usa para determinar a posição tributária acumulada do funcionário. Se o P45 mostrar uma data de saída duas semanas depois da real, o software de folha de pagamento do novo empregador aplica um código cumulativo que assume duas semanas extras de isenção fiscal do emprego anterior — isenção que o funcionário já usou. O funcionário acaba sub-tributado pelo restante do ano e recebe uma carta de Avaliação Simplificada da HMRC no outono seguinte exigindo o pagamento da diferença.

A orientação da HMRC sobre corrigir uma data de saída errada diz: atualize seus registros de folha de pagamento com a data correta e não reporte a alteração no seu próximo FPS — porque fazer isso pode criar um registro de emprego duplicado. Mas essa orientação se aplica ao empregador que fez a submissão original do FPS. Se o erro de transcrição acontecer na planilha de reconciliação de um bureau de folha de pagamento — a data de saída foi digitada errada durante a entrada de dados, não durante o FPS original — o bureau não tem um FPS para alterar. O erro existe apenas na planilha. E a planilha alimenta o relatório de reconciliação do bureau, que alimenta a aprovação do empregador, o que pode levar o empregador a emitir um P60 corrigido que conserta um problema que não existia no P60 original — criando um ciclo de correção que perde o tempo de todos.

A lacuna estrutural é a validação entre documentos. O software de folha de pagamento valida dentro de um único documento — formato NI no P60, formato de código tributário no P45. Nenhum sistema valida entre documentos — ou seja, nenhum sistema verifica se a data de saída do P45 e o valor "Pagamento Neste Emprego" do P60 são consistentes com a trajetória total de pagamento do funcionário. Essa verificação entre documentos é o que o operador de folha de pagamento deve fazer manualmente ao transcrever. E é a primeira verificação descartada quando o volume excede o tempo disponível.

Erro #5: Confusão sobre o Plano de Empréstimo Estudantil — Plano 1, 2, 4, 5 ou Pós-Graduação?

Dos cinco erros deste artigo, este é o que menos culpa os administradores de folha de pagamento — e o que gera mais reclamações de funcionários meses após a emissão do P60. O sistema de reembolso de empréstimos estudantis do Reino Unido agora tem cinco tipos de plano, cada um com um limite de reembolso diferente, e o plano de um funcionário é determinado por onde estudou, quando se formou e que tipo de curso fez.

A matriz é a seguinte:

O guia do empregador da HMRC diz: se seu funcionário não souber em qual plano está, use o Plano 5 no software de folha de pagamento até receber um Aviso de Início de Empréstimo Estudantil (SL1). Usar o Plano 5 como padrão é uma medida administrativa sensata — mas significa que todo funcionário que está no Plano 1, 2 ou 4, mas não informou o empregador, terá deduções calculadas com o limite errado. Um mutuário do Plano 1 (limite £26.900) tratado como Plano 5 (limite £25.000) começa a reembolsar £1.900 de renda antes do previsto — o que, a 9%, representa cerca de £171 por ano em deduções a mais. Um mutuário do Plano 4 (limite £33.795) tratado como Plano 5 (£25.000) paga a mais sobre £8.795 de renda — cerca de £792 por ano.

A dimensão de transcrição deste erro é mais sutil. Quando um operador de folha de pagamento transcreve dados do P60 para uma planilha de reconciliação, o P60 mostra um valor de dedução de empréstimo estudantil — um único número em libras inteiras. Ele não mostra qual plano gerou essa dedução. O operador digita £1.200 na coluna da planilha rotulada "Deduções de Empréstimo Estudantil". O número está correto. O plano é invisível. Dois funcionários com o mesmo salário e a mesma dedução de £1.200 podem estar em planos diferentes — um Plano 1, outro Plano 2 — e a planilha os trata de forma idêntica. O relatório de reconciliação que compara o total de deduções do P60 com os totais do FPS será compatível, porque os valores das deduções estão corretos. O erro não está no valor — está no tipo de plano registrado no sistema de folha de pagamento, que o P60 resume sem nomear.

Quando o HMRC eventualmente cruza os tipos de plano dos funcionários — o que faz, e pode levar meses porque os dados do SLC fluem de forma assíncrona pelo HMRC até os empregadores — o empregador recebe uma notificação de que um funcionário estava no plano errado. O empregador então precisa corrigir deduções passadas, o que pode envolver o funcionário solicitar reembolso ao SLC. Martin Lewis, do MoneySavingExpert, documentou o congelamento da faixa de pagamento do Plano 2 e o problema mais amplo de deduções excessivas: funcionários com renda variável, funcionários que começaram a pagar cedo demais e funcionários no plano errado por padrão. O processo de reembolso passa pelo SLC, não pela folha de pagamento — mas o erro original está no registro da folha que o P60 resume, e a planilha de conciliação que não captura o tipo de plano amplifica a invisibilidade do erro.

Por que a Extração por IA Muda o Perfil de Erro — Não Apenas a Velocidade

Cada erro descrito acima compartilha uma causa raiz que treinamento, listas de verificação e revisões duplas abordam apenas superficialmente. A causa raiz é a própria etapa de transcrição — o momento em que uma pessoa lê um PDF e digita seus dados em uma célula. Remover essa etapa elimina toda uma categoria de erros que nenhuma fórmula de validação captura.

Quando os dados do P60 são extraídos por IA em vez de digitados manualmente, o perfil de erro muda. O número do NI é lido diretamente do certificado — sem oportunidade de transposição entre página e célula. O código de imposto chega completo com seu indicador W1/M1 porque a extração preserva a string completa, não o que uma pessoa lembra de digitar. Os valores de pagamento e imposto são mapeados para suas colunas corretas por significado semântico — "Pagamento neste Emprego" vs "Pagamento Total do Ano" — em vez da navegação espacial do operador por um layout que ele viu pela primeira vez dez segundos atrás. A dedução do empréstimo estudantil é extraída como o valor impresso, e a questão do tipo de plano se torna um problema de configuração do sistema de folha de pagamento, não um problema de transcrição.

Isso não significa que a extração elimina todos os erros. Ela muda quais erros permanecem. Em vez de erros de transposição — dígito errado, coluna errada, sufixo omitido — os erros restantes são erros de verificação: a IA leu incorretamente um caractere mal impresso? Ela mapeou a letra da categoria NI da linha errada quando um funcionário teve uma mudança de categoria no meio do ano? Esses erros de verificação são mais rápidos de detectar porque o operador revisa os dados extraídos contra o documento original, em vez de digitar e revisar simultaneamente. O operador se torna um revisor, não um transcritor — e revisores capturam erros que transcritores criam.

Para o fluxo de trabalho completo — de PDFs de P60 a planilha pronta para conciliação, incluindo definições de coluna que funcionam em Sage, Xero, BrightPay e qualquer layout de P60 de provedor de folha de pagamento — veja nosso guia para extrair dados de P60 do Reino Unido para Excel. Para o problema mais amplo da entrada manual de dados de P60 como um gargalo estrutural no fechamento do ano fiscal da folha de pagamento, veja o custo oculto da entrada de dados de P60.