Seis Erros de Inserção de Dados do P45
Que Tributam em Excesso um Novo Funcionário — e o Custo para Corrigir

Por que um campo errado em um P45 nunca fica só um campo errado

Um erro em um P45 se propaga porque o PAYE é cumulativo por natureza. Diferente de um recibo ou nota fiscal — onde um número digitado errado está errado em exatamente um documento — um P45 alimenta a posição inicial de um cálculo contínuo que seu software de folha de pagamento repete a cada período de pagamento pelo resto do ano fiscal. Se você errar o código tributário, o valor pago até a data ou a base Semana 1/Mês 1 na configuração, o software não aplica esse erro uma vez; ele o carrega para cada Envio de Pagamento Integral (FPS) subsequente até que alguém perceba e corrija a base.

Essa é a diferença entre um erro de P45 e a maioria dos outros erros de digitação. O funcionário na linha de imposto de emergência não foi tributado a mais por um único número errado no mês um — ele foi tributado a mais no mês um, mês dois, mês três e mês quatro, porque o ponto de partida errado continuou gerando deduções erradas. E como a HMRC só reconcilia o quadro quando tem dados de renda completos, o reembolso geralmente não chega até que o código tributário seja corrigido no meio do ano ou, pior, até depois do fim do ano fiscal. A consequência de um erro de digitação de dois segundos é medida em meses do fluxo de caixa do funcionário.

Os seis erros abaixo são os que mais aparecem em fóruns de folha de pagamento e nos guias de correção da própria HMRC. Cada um é específico o suficiente para que você saiba se já o cometeu — e cada um tem uma causa raiz que não é "prestar mais atenção".

Erro 1: Trocar um dígito no código tributário

O erro mais comum em P45 é trocar um único dígito no código tributário — 1257L digitado como 1275L, ou 1250L como 1205L. Parece trivial porque é um caractere, mas o número em um código tributário é a isenção tributária do funcionário dividida por dez. 1257L concede £12.570 de renda isenta; 1275L concede £12.750; 1205L concede £12.050. Um código errado significa que o funcionário recebe uma isenção a que não tem direito (e terá que devolver) ou perde uma isenção a que tem direito (e paga a mais até que seja corrigido).

A causa raiz não é descuido — é que os códigos tributários são sequências de dígitos sem verificação interna, lidos de um layout e digitados em outro sob pressão de tempo. Não há nada em "1275L" que pareça errado. É um código de formato válido; só pertence a uma isenção diferente. E como o software de folha de pagamento aceita qualquer código bem formado sem questionar se corresponde ao P45, o erro passa silenciosamente para a primeira rodada de pagamento.

A correção, uma vez identificada, passa pela HMRC em vez de uma edição rápida: a HMRC emite um código revisado por meio de um aviso P6 ou P9, e seu software o aplica daqui para frente. Se o código era cumulativo, o próximo contracheque geralmente autocorrige a posição acumulada no ano. Se estava na base Semana 1/Mês 1, o pagamento a mais ou a menos fica sem solução até o fim do ano. De qualquer forma, a correção é mais lenta que o erro.

Erro 2: Inserir a data de saída errada — ou em branco

Uma data de saída errada corrompe a posição do funcionário na linha do tempo do ano fiscal, e uma data em branco que assume um valor padrão (sistemas de folha de pagamento às vezes forçam uma data vazia para 01/01/1900) pode criar um registro PAYE duplicado na HMRC. A data de saída no P45 informa ao seu software em qual semana ou mês fiscal o emprego anterior terminou, o que, por sua vez, define onde o novo emprego começa. Insira errado e o cálculo cumulativo será ancorado no ponto errado do ano.

A própria orientação da HMRC sobre como corrigir um FPS é explícita sobre o quão complicada fica a correção posterior: se uma data de pagamento ou data de saída for reportada errada e uma flag de "pagamento após saída" estiver envolvida, você não deve inserir os mesmos valores nos campos "pagamento no período" e "pagamento no acumulado do ano", ou criará um registro duplicado para o funcionário — você precisa colocar 0,00 no campo de pagamento no período e realinhar a folha de pagamento para o período fiscal correto. Isso é uma reconciliação de várias etapas desencadeada por uma única data digitada errada.

A causa raiz é que as datas de saída são fáceis de confundir: a data em que o emprego do funcionário terminou, a data do pagamento final e a data em que você recebeu o P45 são três coisas diferentes, e os layouts do P45 nem sempre tornam a distinção óbvia. Insira a data de pagamento onde a data de saída deveria estar e a linha do tempo se desloca.

Erro 3: Confundir "Total de Pagamento até a Data" com "Pagamento neste Emprego"

Quando um funcionário teve mais de um emprego, o P45 mostra dois valores de pagamento — "Total de Pagamento até a Data" (cumulativo em todos os empregos neste ano fiscal) e "Pagamento neste Emprego" (apenas o emprego de saída) — e inserir o errado no campo de acumulado do ano do seu software reporta incorretamente os ganhos cumulativos do funcionário para a HMRC. Os dois números são diferentes propositalmente, e apenas um deles pertence ao campo de acumulado do ano que orienta o cálculo cumulativo do imposto.

Coloque "Pagamento neste Emprego" onde "Total de Pagamento até a Data" deveria ir, e você subestima os ganhos do funcionário no ano. O software então pensa que o funcionário tem mais isenção fiscal pessoal não utilizada do que realmente tem, deduz menos imposto por vários meses, e a diferença surge como uma correção desagradável no código de imposto mais tarde — a HMRC recupera o imposto não pago reduzindo a isenção no código, então o funcionário de repente vê uma dedução muito maior para recuperar o que nunca foi retido.

Isso pega administradores experientes, não apenas novatos, porque um P45 de emprego único tem os dois valores idênticos — então o hábito de "pegar o número do pagamento" funciona até que silenciosamente falhe em um funcionário que sai com múltiplos empregos. A causa raiz é que a distinção só importa algumas vezes, que é exatamente quando uma etapa de cópia mecânica falha. A análise campo a campo do que cada caixa do P45 significa vale a pena ter à mão precisamente para esses casos de valores duplos.

Erro 4: Tratar um código da Semana 1/Mês 1 como cumulativo

Um código tributário com o sufixo "W1" ou "M1" — por exemplo, 1257L M1 — é não cumulativo. Ignorar esse sufixo (inserindo o código como 1257L simples) faz com que seu software distribua a isenção de forma cumulativa quando não deveria. Semana 1/Mês 1 significa que cada período de pagamento é tributado isoladamente, usando apenas o pagamento daquele período e ignorando tudo o que veio antes no ano. Remova o sufixo e a base de cálculo se inverte.

A consequência segue a direção para a qual a base ignorada empurrou. Se o funcionário realmente deve estar no M1 (a HMRC frequentemente aplica isso quando seus registros de anos anteriores estavam incompletos) e você insere um código cumulativo, o software pode devolver uma isenção que o funcionário já usou em outro lugar, resultando em retenção insuficiente agora e gerando uma conta futura. O erro inverso — deixar um código de emergência M1 ativo quando a HMRC já emitiu um cumulativo — mantém o funcionário com imposto retido a mais, porque a isenção nunca se acumula entre os períodos.

A causa raiz é que a flag W1/M1 é um sufixo de dois caracteres que parece um detalhe secundário, mas altera toda a aritmética. É fácil tratar "1257L M1" e "1257L" como o mesmo código com um rótulo extra. Eles não são o mesmo código. Um detalhe intencional: um código W1/M1 genuíno em um P45 é uma instrução oficial da HMRC para ser inserido como está — não um erro a ser "corrigido" fazendo os valores parecerem cumulativos.

Erro 5: Digitar incorretamente o número do Seguro Nacional

Um número do Seguro Nacional errado significa que a HMRC não consegue associar o novo contratado ao seu registro existente, então o primeiro FPS pode ser rejeitado ou, pior, ser atribuído à conta de outra pessoa. O NINO é a chave de identidade que a HMRC usa para reconciliar um indivíduo em todos os empregos que já teve. Seu formato é rígido — duas letras, seis dígitos, uma letra sufixo (ex.: QQ 12 34 56 C) — mas o formato rígido não impede um dígito trocado, e um NINO bem formado, porém errado, parece completamente válido.

Quando o número não corresponde, as contribuições ao Seguro Nacional e o PAYE que você reporta podem ser creditados no registro errado. Para o funcionário, isso pode significar lacunas no histórico de contribuições — o tipo que mais tarde prejudica os anos de qualificação para a Pensão Estatal ou o direito a benefícios baseados em contribuições — e o problema é invisível até que ele verifique um extrato anos depois. Certos prefixos nunca são emitidos (as letras D, F, I, Q, U e V nunca são usadas como primeira letra; O nunca é a segunda), então esses sinalizam um erro óbvio, mas um número plausível e errado passa direto.

A causa raiz é que um NINO tem nove caracteres de identificador puro, sem significado para verificação de sanidade — você não pode olhar para ele e saber que está errado, como questionaria um salário implausível. Ou ele corresponde ao registro da HMRC ou não, e você descobre depois.

Erro 6: Omitir o indicador de empréstimo estudantil — ou adivinhar o plano

O P45 sinaliza empréstimos estudantis com um único "Y" na caixa 5 e nada mais — não informa qual plano — portanto, tanto omitir o indicador quanto adivinhar o plano geram deduções mensais incorretas. De acordo com o Chartered Institute of Payroll Professionals (CIPP), quando um P45 mostra "Y" na caixa de empréstimo estudantil, as deduções devem começar no próximo dia de pagamento disponível, mas como o formulário não distingue Plano 1, Plano 2, Plano 4 ou Plano 5, o funcionário precisa informar qual se aplica.

Dois erros distintos ocorrem aqui. O primeiro é ignorar o indicador completamente — a caixa de seleção é pequena e, se for negligenciada, os pagamentos do funcionário param no momento em que ele muda de emprego, acumulando silenciosamente um saldo devedor que a Student Loans Company recupera depois. O segundo é adivinhar o plano. O guia do HMRC para empregadores diz que, se o funcionário não puder informar seu plano, você deve usar o Plano 5 como padrão no software de folha de pagamento até que um aviso de início SL1 chegue — você não inventa um plano e não deduz atrasados referentes ao período anterior ao recebimento do P45. Escolha o plano errado e o limite estará errado, então a porcentagem incidirá sobre a parcela errada do salário todos os meses até que um SL1 corrija.

A causa raiz é uma lacuna estrutural que o CIPP consultou abertamente com seus membros: o P45 simplesmente não informa o tipo de plano, então o formulário em si não fornece informações suficientes para acertar a dedução. Isso torna o problema menos um erro de digitação e mais um ponto cego conhecido — que você fecha capturando o indicador com precisão e depois confirmando o plano com o funcionário ou por meio do aviso SL1, em vez de presumir.

O que realmente é necessário para corrigir um erro de P45 após o processamento da folha

Corrigir um erro de P45 nunca é tão rápido quanto o erro que o causou e, em circunstâncias desfavoráveis, expõe o empregador a uma multa. A primeira coisa a saber é que você não pode simplesmente reemitir um P45 corrigido — o HMRC proíbe alterar ou gerar um novo, pois um segundo P45 criaria registros duplicados de PAYE. Qualquer correção deve ser feita por meio do Real Time Information.

O software de folha de pagamento torna a mecânica possível, mas não indolor. O BrightPay, por exemplo, exige que você reabra os contracheques afetados antes de alterá-los e oferece um seletor de plano de empréstimo estudantil dedicado para essa correção específica; o IRIS Staffology expõe uma função "Earlier Year FPS" por funcionário para correções de anos encerrados. As ferramentas existem justamente porque essas correções são comuns — mas cada uma é uma reconciliação manual, não um desfazer com um clique.

O risco mais grave é a multa. Erros nas declarações RTI se enquadram no Schedule 24 do Finance Act 2007 e, conforme resume o CIPP, quando uma declaração imprecisa subestima o imposto devido, a HMRC pode cobrar 30% da receita perdida por imprecisão por descuido, 70% por imprecisão deliberada e até 100% quando for deliberada e oculta. Um valor digitado incorretamente de um P45 dificilmente será julgado como deliberado — mas "descuido" é exatamente a categoria em que um erro de transcrição se enquadra, e a defesa contra isso é conseguir demonstrar que você tomou o devido cuidado. A HMRC só cobrará uma multa "se você não tomou o devido cuidado ou agiu deliberadamente", o que torna a presença ou ausência de um processo controlado e verificável de entrada de dados a diferença entre uma correção e uma multa.

De onde vêm esses erros — e a correção que elimina a etapa de transcrição

Cada um desses seis erros compartilha uma única causa raiz: um humano lê um valor de um layout de documento e o redigita em outro, sem nenhuma camada de correção de erros entre eles. O código tributário não está errado no P45; ele se torna errado na redigitação. A correção, então, não é "verifique com mais cuidado" — é eliminar a redigitação.

Isso é mais difícil do que parece especificamente com P45s, porque não existe um layout padrão de P45. A HMRC determina quais dados um P45 deve conter, mas não como ele se parece. Portanto, um P45 gerado pelo Sage 50 Payroll coloca o código tributário em um lugar diferente daquele do BrightPay, Xero ou QuickBooks UK. O OCR baseado em modelo — que depende de saber onde cada campo está na página — falha no momento em que um P45 chega de um provedor de folha de pagamento para o qual não foi construído. É por isso que o "denominador comum" sempre foi uma pessoa lendo o PDF.

O ImageToTable.ai elimina a redigitação sem precisar de um modelo para cada provedor. Ele usa a Extração de Colunas Personalizadas: em vez de informar à ferramenta onde o código tributário está em cada layout, você digita os nomes dos campos que sua configuração de folha de pagamento precisa — "Tax Code at Leaving", "Total Pay to Date", "Pay in This Employment", "Leaving Date", "NINO", "Student Loan Indicator", "Week1/Month1 Basis" — e a IA lê cada P45 entendendo o que esses campos rotulados significam, onde quer que apareçam, em qualquer layout do provedor. A definição da coluna é escrita uma vez e reutilizada para cada novo funcionário ao longo do ano fiscal. Como a ferramenta captura tanto "Total Pay to Date" quanto "Pay in This Employment" como colunas separadas e preserva o sufixo W1/M1 conforme impresso, os dois erros que dependem da confusão de campos (Erros 3 e 4) não surgem na etapa de extração.

A extração não é uma garantia de precisão absoluta — é a eliminação do modo de falha específico de onde vêm esses seis erros. Você ainda deve à execução da folha de pagamento uma validação: uma verificação rápida de formato no Excel que sinaliza um NINO que não tem nove caracteres, um código tributário que não termina em uma letra válida ou um valor de imposto que não é uma proporção plausível do salário. Mas você está verificando algumas linhas sinalizadas contra a fonte, não transcrevendo manualmente cada campo de cada P45 e torcendo para não ter trocado um dígito. Para equipes que desejam o contexto mais amplo — processamento em lote, fórmulas de validação e o conjunto completo de campos — o guia completo para extração de P45 do Reino Unido e a decomposição de custos do processamento manual de P45 continuam de onde este artigo termina.

Perguntas Frequentes