A Correria de P45 em Janeiro
Um Guia de Sobrevivência para Folha de Pagamento no Reino Unido

O Pico de Janeiro que Ninguém Programou

A rotatividade de funcionários no Reino Unido é de aproximadamente 34% ao ano, de acordo com a análise do CIPD da Pesquisa Anual da População — cerca de 27,4% dos trabalhadores mudam para um novo empregador e 6,6% deixam o mercado de trabalho a cada ano. Com aproximadamente 33 milhões de pessoas no regime PAYE, isso gera cerca de 9 milhões de P45s anualmente apenas para quem muda de emprego. Mas a rotatividade não é uniforme ao longo do calendário. Todo profissional de folha de pagamento sabe que ela se concentra, e janeiro é o período mais denso do ano.

A época não é aleatória. A maioria dos empregadores do Reino Unido opera com um período de aviso prévio de um mês, às vezes três meses para cargos seniores. Alguém que decide sair durante as férias de Natal — depois da festa da empresa, depois que o bônus cai, depois de duas semanas em família que esclareceram o que realmente querem da vida profissional — entrega o aviso na primeira semana de janeiro. Esse aviso vale durante janeiro, e o pagamento final e a data do P45 caem no final de janeiro ou início de fevereiro. Enquanto isso, os novos contratados que chegam para substituí-los trazem P45s de seus próprios empregadores anteriores — documentos produzidos por softwares de folha de pagamento diferentes, com layouts diferentes, com posicionamento de campos diferente — e cada um desses P45s precisa ser lido, transcrito para o sistema de folha de pagamento do novo empregador e verificado antes da primeira execução de pagamento. Uma construtora com 400 trabalhadores no canteiro e 35% de rotatividade anual processará cerca de 140 P45s em um ano, e um número desproporcional deles ocorre no primeiro trimestre. Um bureau de folha de pagamento que atende 30 clientes PME com um total de 450 funcionários enfrentará uma versão condensada do mesmo padrão em vários setores, várias exportações de software de folha de pagamento, vários formatos de P45 — nenhum deles padronizado.

O volume por si só não é o problema; as equipes de folha de pagamento lidam com volume o ano todo. O que torna janeiro diferente é que o volume colide com o trabalho acumulado do período de processamento comprimido de dezembro. Os dados do CIPP mostram que o mês mais curto de dezembro força os departamentos de folha de pagamento a adiantar tarefas e adiar outras. "A renovação dos anos de benefícios em janeiro também aumenta significativamente a carga de trabalho de dezembro", observou o CIPP em seu relatório de folha de pagamento de dezembro. Renovações de ano de benefícios, processamento de P11D e atualizações de código de imposto se acumulam sobre a execução padrão da folha de pagamento de janeiro. A onda de saídas de P45 chega no meio de um mês que já seria apertado — e chega em duas direções ao mesmo tempo.

O Problema da Dupla Direção: Quem Sai e Quem Entra, na Mesma Semana

O P45 é o único documento de folha de pagamento que um empregador no Reino Unido tanto produz quanto consome no mesmo fluxo de trabalho. Quando um funcionário sai, o empregador emite um P45 (formalmente "Detalhes do funcionário que está saindo do trabalho") sob o Regulamento 36 do Income Tax (PAYE) Regulations 2003. O software gera o certificado de quatro partes — a Parte 1 vai para o HMRC via RTI na Submissão Final de Pagamento, enquanto as Partes 1A, 2 e 3 vão para o funcionário. O lado da emissão é amplamente automatizado: Sage Payroll, BrightPay, Xero Payroll, Iris e Moorepay lidam com a geração do P45 como uma função padrão, calculando os valores acumulados no ano desde o início do ano fiscal (6 de abril) até a data de saída, aplicando a base de código tributário correta e preenchendo o certificado.

O lado do recebimento é onde a automação termina. Quando um novo contratado chega com um P45 do empregador anterior — ou envia um PDF gerado por um software de folha de pagamento totalmente diferente — alguém precisa abrir esse documento, localizar cinco campos e digitá-los no sistema de folha de pagamento do novo empregador. Esses cinco campos são: data de saída, total de pagamento até a data e total de imposto até a data para o ano fiscal atual, código tributário na saída, número do Seguro Nacional e status de dedução do empréstimo estudantil. Se algum deles for inserido incorretamente, o primeiro contracheque do novo contratado estará errado — e a correção recai sobre a equipe de folha de pagamento, não sobre o fornecedor do software. O HMRC exige que os registros de folha de pagamento sejam mantidos por pelo menos três anos e alerta que registros inadequados podem gerar uma conta de imposto estimada e uma multa de até £3.000.

Em janeiro, o lado do recebimento dessa equação se multiplica. Um administrador de folha de pagamento que normalmente lida com dois ou três P45s de novos contratados por semana pode enfrentar quinze na segunda semana de janeiro — os que saíram em dezembro e agora são os novos contratados de janeiro de outra pessoa. Cada um leva de dois a três minutos para transcrever e verificar. Considerando a mediana salarial de um administrador de folha de pagamento no Reino Unido de aproximadamente £29.750 brutos — o que se traduz em um custo total para o empregador de cerca de £21 por hora, uma vez que o Seguro Nacional Classe 1 do empregador a 15% acima do limite secundário de £5.000 e as contribuições para a pensão de inscrição automática são considerados — isso representa cerca de 70 pence de mão de obra por P45. O custo é pequeno o suficiente para que ninguém o orce, e é exatamente por isso que a entrada de dados do P45 nunca foi devidamente custeada na maioria das organizações. Mas com quinze P45s por semana ao longo de um janeiro que se estende por quatro ou cinco períodos de pagamento, o tempo está passando para uma tarefa que não tem nenhuma camada de automação entre o PDF na tela e o registro de folha de pagamento no sistema.

Os Cinco Campos Que Mantêm o P45 Manual

O RTI digitalizou a etapa empregador-para-HMRC do P45 em 2013. Hoje, todo software de folha de pagamento transmite dados de desligamento diretamente à HMRC por meio da Full Payment Submission — a Parte 1 do P45 é efetivamente redundante. Mas o RTI não fez nada pela etapa empregador-para-empregador. As Partes 2 e 3, que carregam os mesmos dados para o novo empregador, continuam sendo documentos físicos ou PDFs projetados para leitura humana. Nunca foram feitos para leitura por máquina. E como a HMRC especifica quais dados um P45 deve conter, mas não como devem ser dispostos, cada fornecedor de software de folha de pagamento cria seu próprio formato de P45.

Um P45 gerado pelo Sage 50 Payroll coloca o código de imposto em uma posição diferente de um gerado pelo BrightPay. O PDF do P45 do Xero é diferente do Iris. O layout do Moorepay difere do FreeAgent. Os cinco campos que importam — data de desligamento, remuneração até a data, imposto até a data, código de imposto, número do NI — aparecem em todos os certificados, mas suas coordenadas, tamanhos de fonte, rótulos e proximidade com outros campos variam conforme cada fornecedor de software, cada atualização de versão e, às vezes, cada preferência de modelo definida pelo empregador. Um escritório de folha de pagamento que recebe P45s de trinta empresas clientes diferentes pode encontrar trinta layouts distintos — e o único denominador comum garantido entre todos eles é que uma pessoa precisa encontrar os campos e digitá-los.

Essa variabilidade de layout é o motivo pelo qual o processamento de P45s resistiu à automação, mesmo enquanto todas as outras partes da folha de pagamento migraram para software. O OCR tradicional precisa saber onde cada campo está na página — uma abordagem baseada em posição que falha assim que chega um P45 de outro provedor. Ferramentas de extração baseadas em modelos exigem criar e manter uma regra de análise separada para cada variante de layout, o que adiciona uma carga administrativa que rivaliza com a digitação que deveria substituir. O gargalo é estrutural: os dados do P45 são padronizados no nível do campo — a HMRC define os campos — mas não no nível do layout, que fica a cargo do mercado de software.

O que muda a equação é a extração semântica: ler um documento entendendo o que cada campo significa, em vez de onde ele está. Em vez de programar uma ferramenta para encontrar "Código de Imposto" na coluna A, linha 7 de um modelo específico de P45, um extrator semântico identifica o campo pelo seu rótulo — "Código de Imposto no Desligamento", "Código de imposto", "Código de Imposto (na data de desligamento)" — e extrai o valor adjacente, independentemente de sua posição. Essa abordagem, que o ImageToTable.ai chama de Extração de Colunas Personalizadas, é o primeiro método de extração que corresponde à forma como os P45s realmente funcionam no ecossistema de folha de pagamento do Reino Unido: mesmos dados, layouts diferentes, sem padronização. Você digita os nomes das colunas desejadas — Data de Desligamento, Remuneração até a Data, Código de Imposto, Número do NI, Status de Empréstimo Estudantil — e a IA localiza cada valor em qualquer lugar da página, entendendo o que o rótulo significa, não onde ele aparece.

O Custo Real de um Código Tributário Digitado Errado

Um código tributário 1257L significa que o funcionário tem direito à isenção total de £12.570 para o ano fiscal de 2025/26 — o código padrão para a maioria dos funcionários com um emprego e sem ajustes. O sufixo 'L' indica a isenção padrão, e o número 1257 é a isenção dividida por 10. Se um administrador de folha de pagamento digitar 1275L — dois dígitos trocados — o software interpreta isso como uma isenção de £12.750, e o funcionário recebe £180 a mais em sua isenção ao longo do ano. O sistema da HMRC eventualmente detecta a divergência e emite um código corrigido, mas até lá o funcionário pode estar pagando menos imposto há meses. O valor não pago é cobrado por meio de um código tributário futuro ajustado, que aparece no contracheque sem aviso — e o funcionário liga para o departamento de folha de pagamento querendo saber por que seu salário líquido caiu.

Isso não é hipotético. Os fóruns do AccountingWEB trazem casos reais de erros de digitação de dados do P45 que se propagam por vários períodos de pagamento. Um bureau de folha de pagamento relatou que inseriu valores acumulados do P45 de uma exportação CSV do Sage de um empregador anterior no BrightPay para uma transferência no meio do ano — e descobriu meses depois que o cliente havia sido cobrado £2.390 pela HMRC, exatamente o imposto acumulado dos valores do P45 que haviam sido contados em dobro. A resposta da HMRC: abra uma disputa, que pode levar "mais de um ano para ser resolvida". Os dois minutos de digitação que causaram o erro já haviam acontecido; a correção levou um ano.

A taxa de erro para entrada manual de dados fica entre 1% e 4% por campo, dependendo da qualidade do documento, da pressão de tempo e da familiaridade do operador com o layout. Em cinco campos do P45, uma taxa de erro de 1% por campo dá aproximadamente 5% de chance de que qualquer P45 específico contenha pelo menos um erro. Com quinze P45s por semana durante janeiro, é uma quase certeza estatística de pelo menos um erro por mês — e o erro que cai no campo do código tributário não se anunciará até que um contracheque esteja errado. O funcionário que percebe o erro liga para a folha de pagamento. A folha verifica o P45 original, encontra o erro de transcrição e inicia uma correção. A HMRC se envolve. Os dois minutos de digitação que custaram 70 centavos agora consumiram três mesas, vários e-mails e potencialmente semanas de acompanhamento — nada disso orçado, nada disso visível em um relatório de centro de custo, tudo isso rastreável a um único dígito digitado errado.

O custo total do processamento manual do P45 — mão de obra, correção de erros, exposição a conformidade e a multa de £3.000 por funcionário por manutenção de registros — foi detalhado. Para a equipe da folha de pagamento de janeiro, a parte relevante desse cenário é o recebimento: cada P45 que chega de um novo funcionário é uma tarefa de transcrição manual, cada transcrição carrega uma probabilidade de erro, e janeiro multiplica tanto o volume quanto a pressão de tempo que aumenta a taxa de erro.

Quebrando o Ciclo do P45 em Janeiro

A correção estrutural para o acúmulo de P45s em janeiro não é mais funcionários ou mais horas extras — equipes de folha de pagamento já sobrecarregadas em dezembro não têm capacidade ociosa para absorver um pico em janeiro trabalhando mais. A correção é eliminar completamente a etapa de transcrição. Os dados em um P45 — data de saída, pagamento até a data, imposto até a data, código de imposto, número NI, status de empréstimo estudantil — já estão impressos no certificado. O papel do administrador da folha de pagamento deve ser verificação, não criação. Olhe os dados extraídos, confirme se correspondem à fonte, importe para o sistema de folha de pagamento. Uma etapa em vez de duas, e a etapa que carrega o risco de erro — a digitação — é eliminada.

É aqui que a extração de IA sem modelos altera o fluxo de trabalho para processamento de P45. Diferente do OCR baseado em posição que precisa saber onde cada campo está em um layout específico de P45, a extração semântica lê o documento entendendo o que cada rótulo de campo significa. Um P45 gerado pelo Sage coloca o código de imposto em um local; um P45 gerado pelo BrightPay o coloca em outro. Um leitor humano navega por ambos instintivamente — eles procuram por "Código de Imposto" ou "Código de Imposto na Saída" e leem o valor adjacente. A extração semântica faz o mesmo: localiza o campo pelo seu significado, não por suas coordenadas. Este é o mecanismo central que torna viável processar em lote P45s de múltiplas fontes em uma única operação — você não está construindo modelos para o formato de saída de cada software de folha de pagamento. Você está dizendo ao sistema quais colunas deseja, e ele encontra os dados correspondentes em cada documento, independentemente do layout.

A dimensão do lote é crítica especificamente para janeiro. Com quinze, vinte ou trinta P45s chegando em uma única semana — uma mistura de funcionários saindo cujos formulários precisam ser emitidos e funcionários entrando cujos formulários precisam ser inseridos — processá-los um por um não resolve o problema da pressão de tempo. Extrair todos eles em uma única operação em lote, com resultados mesclados em uma planilha onde cada linha é um registro de dados de P45 completo, transforma uma semana de digitação distribuída em uma tarde de revisão. O fluxo de trabalho de processamento de P45 em lote — construindo um banco de dados de funcionários que saem a partir de múltiplos formulários simultaneamente — aplica-se igualmente ao lado dos funcionários que entram. A mesma execução de extração que preenche um banco de dados de funcionários que saem para funcionários que estão saindo pode preencher uma planilha de configuração de novos funcionários para os que estão entrando, porque os cinco campos principais são idênticos em ambas as direções.

Um Fluxo de Trabalho de Folha de Pagamento de Janeiro que Não Depende de Digitação

Em vez de abrir cada PDF de P45 individualmente, ler cinco campos, alternar para o software de folha de pagamento, digitar cinco campos e repetir trinta vezes, um administrador de folha de pagamento com ferramentas de extração pode reestruturar a carga de trabalho de janeiro em três blocos:

A aritmética de tempo é direta. A dois minutos por P45 para entrada manual, trinta P45s de novos funcionários consomem uma hora de digitação — e isso antes de corrigir quaisquer erros descobertos posteriormente. Com a extração em lote, os mesmos trinta P45s são carregados, extraídos e compilados em uma planilha em minutos. A hora restante se torna verificação e importação — trabalho que sempre foi necessário e que o administrador de folha de pagamento agora pode fazer adequadamente, em vez de encaixá-lo nas lacunas entre as sessões de digitação.

Para o lado dos funcionários que saem, o mesmo fluxo de extração serve a um propósito diferente: verificar se os valores nos P45 gerados estão corretos antes de serem enviados ao funcionário e à HMRC. Uma extração em lote dos PDFs de P45 de saída contra os próprios registros do sistema de folha de pagamento cria uma verificação cruzada automatizada — a data de saída no P45 corresponde ao sistema? Os valores de pagamento e imposto acumulados no ano se reconciliam? Executar essa verificação antes do envio do RTI fecha o ciclo entre o que o software de folha de pagamento informa e o que o certificado mostra, detectando discrepâncias antes que cheguem ao processamento FPS da HMRC. O guia passo a passo para extrair dados de P45 de funcionários que saem para o Excel detalha esse fluxo de trabalho, incluindo os mapeamentos de campo específicos e casos extremos comuns, como indicadores de base Semana 1/Mês 1 e tipos de plano de empréstimo estudantil.

Por que Janeiro é o Mês que Revela o Problema

Durante onze meses do ano, o processamento manual de P45s é um atrito administrativo de baixo grau — alguns minutos aqui, alguns formulários ali, o erro ocasional que é detectado antes de causar danos. Em janeiro, ele deixa de ser atrito e se torna um gargalo. O volume dispara, a pressão de tempo se intensifica, a taxa de erros aumenta, e a carga de trabalho corretiva — e-mails para a HMRC, envios de FPS corrigidos, consultas de funcionários sobre contracheques — consome fevereiro e março. O problema sempre foi estrutural: os dados do P45 são padronizados no nível do campo, mas não no nível do layout, e a transferência de empregador para empregador continua sendo uma cadeia de transcrição humana em um ecossistema de folha de pagamento, de outra forma automatizado. Janeiro apenas expõe a fratura no pior momento possível.

A questão mais profunda é que as equipes de folha de pagamento do Reino Unido ainda processam P45s manualmente, não por falta de habilidades ou ferramentas para fazer o contrário, mas porque as ferramentas disponíveis até recentemente — OCR baseado em modelos, extração zonal — exigiam um nível de configuração por formato que tornava a automação mais lenta do que o processo manual que deveria substituir. Quando um bureau de folha de pagamento recebe P45s de trinta empresas clientes diferentes usando cinco pacotes de folha de pagamento distintos, construir e manter trinta modelos de extração é um trabalho de tempo integral por si só. A extração semântica remove essa barreira: uma definição de coluna, aplicada a cada P45 no lote, porque a IA entende o que "Código Tributário na Saída" significa, independentemente de qual software o imprimiu.

Para as equipes de folha de pagamento se preparando para o próximo janeiro, a questão não é se a entrada manual de dados de P45 é sustentável — os números de volume já responderam isso. A questão é em que ponto o custo cumulativo de erros de transcrição, ciclos de correção e o arrasto administrativo de digitar os mesmos cinco campos repetidamente excede o custo de migrar para um fluxo de trabalho sem digitação. A estrutura de custos já está disponível. As ferramentas existem. A única variável restante é a decisão de parar de digitar e começar a revisar — e janeiro, mais do que qualquer outro mês, defende a tomada dessa decisão antes que a próxima onda de desligamentos chegue.

Perguntas Frequentes

Com que rapidez um empregador do Reino Unido deve emitir um P45 após a saída de um funcionário?

De acordo com o Regulamento 36 do Income Tax (PAYE) Regulations 2003, o P45 deve ser preenchido no dia em que o emprego termina ou, se isso não for possível, sem demora injustificada. Na prática, o HMRC espera que o P45 seja emitido com o pagamento final do funcionário ou dentro do mesmo ciclo de folha de pagamento. A maioria dos softwares de folha de pagamento — Sage, BrightPay, Xero Payroll, Iris, Moorepay — gera o P45 automaticamente quando o funcionário é marcado como desligado e a execução final da folha é processada. A Parte 1 é enviada ao HMRC por meio da Full Payment Submission (FPS) no dia do último pagamento do funcionário ou antes dele.

Posso processar P45s de diferentes softwares de folha de pagamento em lote?

Sim, com extração semântica por IA, em vez de OCR baseado em modelos. Ferramentas baseadas em modelos exigem uma regra de análise separada para cada layout de P45 de software de folha de pagamento — Sage, BrightPay, Xero, Iris, Moorepay e FreeAgent produzem certificados formatados de forma diferente. A extração semântica lê cada P45 entendendo o significado dos rótulos dos campos (como "Tax Code at Leaving" ou "Total Pay to Date") em vez de sua posição na página. Isso significa que você pode enviar um lote misto contendo P45s de vários provedores de folha de pagamento e extrair todos eles com base em um único conjunto de definições de colunas. A saída é uma planilha com uma linha por P45.

Quais informações de um P45 devem ser inseridas no sistema de folha de pagamento do novo empregador?

Cinco campos principais das Partes 2 e 3 do P45: a data de saída do funcionário do emprego anterior, o pagamento total até a data e o imposto total até a data para o ano fiscal atual (de 6 de abril a 5 de abril), o código de imposto na saída (incluindo qualquer indicador de base Semana 1/Mês 1), o número do National Insurance e o status de dedução do empréstimo estudantil. Se algum desses itens for inserido incorretamente, o novo contratado pode ser colocado em um código de imposto de emergência e seu primeiro contracheque ficará errado. Os valores do ano fiscal são cumulativos — são os totais acumulados que o novo empregador precisa para dar continuidade à situação fiscal do funcionário sem uma redefinição.

Qual é a diferença entre um P45 e um P60?

Ambos mostram o que um funcionário ganhou e o imposto pago em um ano fiscal, mas são gerados por eventos diferentes. Um P45 é emitido quando um funcionário sai de um emprego — ele cobre o período do início do ano fiscal (6 de abril) até a data de saída. Um P60 é emitido no final de cada ano fiscal para funcionários que ainda trabalham para o empregador naquele momento — ele cobre os 12 meses completos até 5 de abril. Os empregadores devem fornecer P60s a todos os funcionários atuais até 31 de maio de cada ano. Para mais informações sobre o processamento de P60, veja o guia sobre extração de dados de P60 do Reino Unido para Excel para conciliação da folha de pagamento.

O que acontece se um código de imposto do P45 for inserido incorretamente?

Um código de imposto incorreto altera imediatamente o cálculo da isenção fiscal do funcionário. Por exemplo, inserir 1275L em vez de 1257L concede uma isenção de £12.750 em vez de £12.570 — o funcionário paga menos imposto em £180 ao longo do ano. A HMRC geralmente detecta a discrepância por meio da correspondência de dados do RTI e emite um código de imposto corrigido. O imposto pago a menos é recuperado por meio de um ajuste futuro no código de imposto, o que reduz o salário líquido do funcionário em um mês subsequente. O funcionário frequentemente entrará em contato com a folha de pagamento para perguntar por que seu pagamento mudou, e a folha de pagamento deve rastrear até o registro original do P45 para explicar a correção. Se o erro não for detectado, ele pode persistir entre anos fiscais e se acumular em um pagamento a menor maior que a HMRC cobrará diretamente.

Os formulários de P45 em papel podem ser processados com a mesma ferramenta de extração?

Sim. Uma imagem digitalizada ou uma foto de um P45 em papel funciona da mesma forma que um PDF — a IA lê o documento visualmente, não a partir de camadas de texto incorporadas. Isso é particularmente útil para os P45s em papel que ainda circulam em empresas menores, ou para P45s que chegam como anexos em formatos que não podem ser analisados diretamente (PDFs digitalizados, fotos JPEG, capturas de tela de um portal de folha de pagamento). A ferramenta de extração suporta entradas nos formatos PDF, JPG, PNG, WebP e AVIF.

A extração em lote de P45 funciona para escritórios de contabilidade que gerenciam múltiplas empresas clientes?

Sim — escritórios são o caso de uso mais forte, pois enfrentam a máxima diversidade de layouts. Um escritório que gerencia a folha de pagamento de trinta PMEs em cinco pacotes de software diferentes encontra P45s em dezenas de formatos distintos todo mês. Com a extração semântica, o escritório define um conjunto de nomes de colunas e o aplica a cada P45 no lote, independentemente do software que o produziu. A saída é uma planilha consolidada por cliente ou por execução de processamento. O guia de processamento em lote de P45 aborda fluxos de trabalho de escritórios com múltiplos clientes em detalhes.