Mais de 100 P60s do Reino Unido até 31 de maio
Uma Planilha de Auditoria, Sem Digitação Manual
De acordo com o Regulamento 67 do Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682), todo empregador no Reino Unido deve fornecer um P60 a cada funcionário na folha de pagamento em 5 de abril — e o prazo de 31 de maio é definido em lei, não no software de folha. O P60 em si não é o gargalo. Sage 50cloud, BrightPay, QuickBooks Online, Moorepay e IRIS geram certificados em segundos. O gargalo é o que vem depois: alguém precisa consolidar mais de 100 desses PDFs — além de cópias impressas digitalizadas de funcionários que perderam os seus, mais capturas de tela do portal da HMRC — em uma planilha que reconcilie com as Full Payment Submissions do ano antes do fim do mês. A dois minutos por certificado no fluxo manual — abrir PDF, localizar Caixa 1 a Caixa 6, transcrever para uma linha da planilha — uma empresa com 150 funcionários queima cinco horas da janela de folha de maio apenas com copiar e colar. E isso supondo que ninguém mudou de software de folha no meio do ano, nenhum funcionário saiu em março e nenhum P60 digitalizado chegou impresso a 150 DPI.
Principais Conclusões
- Pela lei do Reino Unido, todo empregador deve emitir um P60 para cada funcionário até 31 de maio — e para uma empresa de 150 funcionários com vários provedores de folha, "apenas abrir os PDFs e copiá-los para o Excel" significa cinco horas de pura transcrição no mês mais movimentado do calendário de folha.
- O verdadeiro gargalo na escala de 100 documentos não é a velocidade de processamento de arquivos — é o design das colunas: um conjunto de colunas de identidade (Número NI + Referência PAYE), um conjunto de colunas financeiras (salário, imposto, contribuições), e um conjunto de colunas de verificação (tipo de código de imposto, verificação de categoria NI) que juntos tornam cada linha auditável e cada mesclagem de planilha uma simples anexação.
- Defina esse esquema de colunas uma vez, aplique os mesmos nomes a cada lote, independentemente do provedor de folha ou ano fiscal, e mesclar 100 linhas do Sage com 50 do BrightPay se torna uma operação empilhável verticalmente — sem remapeamento de colunas, sem modelos por provedor, sem adivinhação sobre qual linha pertence a qual empregador.
Por que 100+ P60s é um Problema Fundamentalmente Diferente de Apenas Um
Processar um único P60 é um problema resolvido — extrair seus campos para o Excel exige atenção, não ferramentas. Você abre o PDF, localiza as caixas estatutárias, digita sete ou oito números em uma linha e segue em frente. No momento em que você introduz volume — 100 funcionários, três provedores de folha de pagamento, alguns ex-funcionários de empresas adquiridas com certificados em papel — o problema deixa de ser sobre velocidade e passa a ser sobre estrutura.
Três problemas estruturais surgem na escala de 100+ que não existem na escala de um único documento. Nenhum deles é resolvido processando arquivos mais rápido.
1. Divergência de layout entre provedores
Um P60 do Sage 50cloud formata os dados do funcionário alinhados à esquerda, com a referência PAYE em negrito abaixo do nome do empregador. Um P60 do BrightPay separa a seção de certificados estatutários com uma caixa com borda. Um P60 do QuickBooks Online imprime o número do NI acima do bloco de endereço do funcionário, em vez de adjacente ao nome. Para um administrador de folha de pagamento transcrevendo manualmente, cada layout exige uma re-varredura visual — localizar onde cada caixa está na renderização específica deste provedor antes de digitar qualquer coisa. Em 100 P60s divididos entre três provedores, apenas o custo dessa re-varredura visual — cerca de 10 segundos por documento para reorientação — consome 15 minutos de tempo morto antes de uma única tecla de transcrição.
2. Proveniência de linhas em escala de auditoria
Ao extrair 100 P60s em 100 linhas de planilha, cada linha deve ser rastreável de volta a exatamente um documento de origem e exatamente um ano fiscal. Se a planilha de saída tiver uma coluna para "Remuneração Total" com £38.450, mas nenhuma coluna identificando qual P60 de funcionário produziu esse valor, a planilha é um passivo de auditoria — não um ativo de auditoria. Sob verificações de conformidade da HMRC, um inspetor pode solicitar o P60 subjacente a qualquer valor em sua reconciliação. Sem rastreabilidade de origem por linha incorporada na própria extração, você está referenciando células da planilha contra PDFs manualmente — o que leva mais tempo do que a extração original.
3. Tratamento de exceções em volume
Em um lote de 100 P60s, três a cinco serão casos excepcionais. Um funcionário com código tributário Semana 1 / Mês 1 porque começou no meio do ano sem um P45. Um ex-funcionário que trabalhou de janeiro a março — empregado em 5 de abril e, portanto, com direito a um P60 — mas cujo certificado foi gerado por um provedor de folha que a empresa não usa mais. Um P60 em papel digitalizado de uma aquisição de 2023 onde a referência PAYE pertence à entidade adquirida, não à empresa atual. Em um fluxo de trabalho manual, você captura estes um de cada vez. Em um fluxo de trabalho em lote, toda exceção perdida se torna um valor incorreto em uma planilha de reconciliação que a HMRC pode auditar.
Cada um desses problemas tem uma solução que não envolve contratar mais funcionários de entrada de dados para maio. Elas envolvem projetar o fluxo de trabalho em lote — desde a preparação do arquivo até o esquema de colunas — como se a saída não fosse uma planilha, mas um registro de auditoria que será lido daqui a seis meses por alguém que não produziu os dados originais.
A Realidade Multiformato: Sage Não É BrightPay, Não É um Scan de 150 DPI
A HMRC não exige um layout único de P60. Ela exige o conteúdo: de acordo com a especificação RD1, um P60 substituto deve exibir certos campos — nome do funcionário, número do NI, referência PAYE, remuneração total do ano, total de imposto deduzido, deduções de empréstimo estudantil, código tributário final e dados do empregador — mas a disposição visual fica a cargo de cada fornecedor de software de folha de pagamento. O resultado é que um P60 do Sage 50cloud tem uma estrutura visual diferente de um P60 do BrightPay, que é diferente de um P60 do QuickBooks Online Payroll, que é diferente de um P60 do Moorepay, que é diferente de um P60 do IRIS. E isso antes de considerar cópias impressas digitalizadas de funcionários que perderam os originais.
A extração tradicional baseada em modelos — onde você desenha retângulos ao redor dos campos em um P60 de amostra — lida com isso exigindo um modelo separado para cada fornecedor de folha de pagamento. Mantenha cinco fornecedores, mantenha cinco modelos. Um fornecedor atualiza o layout do P60 para o novo ano fiscal — novas diretrizes da HMRC, uma reformulação da marca, uma alteração de formatação — e o modelo produz silenciosamente uma saída desalinhada. O administrador da folha de pagamento só descobre isso quando a reconciliação não fecha com os totais do FPS.
A extração semântica elimina o problema do modelo por fornecedor ao ler o documento pelo significado, e não pela posição. Você define as colunas desejadas uma vez — "Número do NI", "Remuneração Total do Ano (£)", "Imposto Deduzido (£)", "Referência PAYE", "Código Tributário Final" — e a IA localiza cada valor em cada P60 entendendo o que os dados representam, e não onde estão na página. Um P60 do Sage 50cloud, um P60 do BrightPay, um P60 do QuickBooks e um P60 em papel digitalizado de 2023 alimentam as mesmas definições de coluna. Para um guia detalhado sobre os campos individuais de um P60 do Reino Unido e como cada um se comporta durante a extração, comece com o guia de extração de P60 único. Este artigo continua de onde aquele parou: o que acontece quando você para de pensar em P60s um de cada vez.
O que torna isso particularmente valioso no contexto de folha de pagamento do Reino Unido é que a referência PAYE — no formato 123/AB456 — permanece consistente em todos os P60s do mesmo empregador, independentemente do software de folha de pagamento que os produziu. Uma empresa que usa Sage para funcionários permanentes e BrightPay para contratados emitirá P60s com a mesma referência PAYE, mas em dois formatos visualmente diferentes. A extração semântica lê o valor, não o layout. A coluna "Referência PAYE" na sua planilha de saída é preenchida de forma idêntica em ambos os fornecedores, fornecendo uma chave de agrupamento natural para lotes de múltiplos fornecedores.
Nomeação de Arquivos em Escala: Tornando Cada Linha Rastreável até Sua Origem
A decisão de maior impacto em um fluxo de trabalho de P60 em lote acontece antes mesmo de você enviar um único arquivo: como você nomeia os documentos de origem. Quando sua planilha de saída tem 100 linhas e, três meses depois, um auditor da HMRC pede para ver "o P60 referente à linha 47", a resposta não pode ser "Preciso cruzar a planilha com minha pasta de Downloads". A resposta precisa ser um nome de arquivo que você encontre instantaneamente.
Uma convenção de nomenclatura que atenda à rastreabilidade de auditoria inclui três componentes:
Identificador do funcionário
O número NI é a chave primária natural para registros de folha de pagamento do Reino Unido — é único, permanente e aparece em todo P60. Usá-lo como prefixo do nome do arquivo fornece uma chave de consulta instantânea: AB123456C mapeia diretamente para os registros da HMRC. Quando números NI não puderem ser usados (política de proteção de dados), use o ID de folha de pagamento do funcionário — mas adicione uma tabela de mapeamento.
Ano fiscal
Um P60 cobre o ano fiscal de 6 de abril a 5 de abril. O nome do arquivo deve codificar qual ano: 2025-26 ou FY2526. Isso evita o desastre mais comum de reorganização de lotes — misturar P60s de 2024-25 e 2025-26 na mesma pasta porque alguém os salvou no mesmo diretório com seis meses de diferença. Ao processar arquivos de vários anos fiscais em lotes separados, o ano no nome do arquivo é a única coisa que impede a contaminação cruzada.
Tag do provedor ou fonte
Não essencial para a planilha em si, mas inestimável durante a reconciliação. Um sufixo no nome do arquivo como _sage ou _bp informa a você, três semanas em maio, quando alguém perguntar por que o valor da Caixa 5 da linha 23 contradiz os dados do FPS, que a linha 23 veio do BrightPay — que pode ter uma diferença de arredondamento de exportação conhecida. Uma tag de provedor transforma uma anomalia inexplicável em um padrão de comportamento conhecido.
O padrão de nome de arquivo resultante — AB123456C_2025-26_sage.pdf — incorpora a trilha de auditoria no próprio nome do arquivo. Quando sua ferramenta de extração preserva os nomes dos arquivos na saída (ImageToTable.ai inclui uma coluna "Nome do Arquivo" por padrão em exportações em lote), cada linha em sua planilha carrega sua própria proveniência. Nenhuma referência cruzada externa é necessária.
Para equipes de folha de pagamento que lidam com funcionários em vários esquemas PAYE — uma empresa guarda-chuva gerenciando a folha de pagamento de 20 entidades clientes, ou uma estrutura de grupo onde cada subsidiária tem sua própria referência PAYE — o formato da referência PAYE 123/AB456 se torna a chave natural de agrupamento de lotes. Processe todos os P60s com 123/AB456 em um lote, todos os P60s com 456/CD789 em outro. A coluna de referência PAYE na saída de cada lote serve como ponto de pivô quando você mescla as duas planilhas posteriormente. Você nunca precisará adivinhar a qual empregador uma linha pertence.
Desligados, Ex-Funcionários e Quem Legalmente Precisa de um P60
A regra da HMRC é inequívoca: todo funcionário na folha de pagamento em 5 de abril do ano fiscal deve receber um P60 até 31 de maio. Isso inclui funcionários que se desligaram durante o ano fiscal — desde que ainda estivessem empregados em 5 de abril. Um funcionário que pediu demissão em 30 de março e cumpriu aviso prévio até 4 de abril recebe um P60. Um funcionário que se desligou em 31 de março não recebe. A distinção é importante porque errar em qualquer direção cria uma exposição de auditoria.
Em um lote de 100 P60s, os casos de desligamento se enquadram em quatro categorias — e cada uma altera o que você inclui no lote e o que verifica depois:
Empregado em 5 de abril — desligado depois
Recebe um P60. O certificado cobre o ano fiscal completo e deve ser incluído no lote. O campo "Código Fiscal Final" mostrará o código ativo no final do ano, mesmo que o funcionário tenha saído em junho.
Desligado antes de 5 de abril — sem P60
Recebe um P45, não um P60. Se o registro na folha ainda aparecer no lote devido a uma exportação desatualizada do sistema de RH, ele deve ser excluído antes da reconciliação — seus dados pertencem a uma obrigação de relatório diferente.
Ex-funcionário solicitando segunda via
A HMRC exige que os empregadores forneçam segundas vias de P60 mediante solicitação. Um ex-funcionário que precisa do P60 de 2023-24 para um pedido de hipoteca entrará em contato — e o certificado foi emitido há dois anos, possivelmente por um provedor de folha que você não usa mais. O P60 ainda contém as mesmas informações legais, mas pode existir apenas como PDF escaneado ou backup arquivado do Sage.
Funcionários de empresa adquirida
Quando a Empresa A adquire a Empresa B em outubro, os funcionários da Empresa B que estavam na folha em 5 de abril anterior ainda precisam de um P60 — emitido pela Empresa A como sucessora, mas potencialmente referenciando o esquema PAYE da Empresa B para os meses pré-aquisição. O P60 emitido pode conter a referência PAYE antiga, a nova ou ambas, dependendo de como a transferência TUPE foi estruturada. Incluir esses P60s no lote com uma coluna dedicada "Ref. PAYE Anterior" captura a complexidade em uma única linha.
A armadilha de auditoria não é omitir um P60. É incluir um P60 para alguém que não deveria ter um, ou excluir um P60 para alguém que deveria. Qualquer erro se propaga para sua reconciliação FPS, e uma verificação de conformidade da HMRC sob o Manual de Conformidade CH40000 revelará a discrepância mais rápido que seu software de folha de pagamento.
A salvaguarda prática é adicionar uma coluna inferida — "Status do P60" — onde a IA classifica cada documento com base em seu conteúdo. Valores como "Ativo em 5 de Abril", "Desligado Após 5 de Abril", "Segunda Via de Ano Anterior" e "Não é um P60" permitem classificar a saída antes da reconciliação, sinalizando linhas que precisam de revisão ou exclusão. Uma coluna na extração economiza a hora de verificação manual que, de outra forma, viria.
Projetando Colunas Prontas para Auditoria em uma Planilha de 100 Linhas
Os nomes das colunas que você define antes de enviar um lote são a decisão mais importante de todo o fluxo de trabalho. Um esquema de colunas projetado para um lote de teste com cinco funcionários geralmente falha com 100 linhas, pois não considera os casos extremos gerados pelo volume — números de NI duplicados em diferentes regimes de PAYE, códigos tributários que mudaram no meio do ano, deduções de empréstimos estudantis divididas entre planos.
Um esquema de colunas que sobrevive a uma auditoria de 100 linhas é construído em torno de três tipos de coluna, cada um com uma função distinta na saída:
1. Colunas de identidade — a chave composta que torna cada linha única
Número do NI, Nome do Funcionário, Referência PAYE e Ano Fiscal. Juntos, esses quatro campos formam uma chave composta: duas linhas na sua planilha não devem compartilhar a mesma combinação. O Número do NI sozinho não é suficiente — um funcionário que trabalhou para dois regimes PAYE no mesmo ano fiscal (comum em estruturas de grupo) terá dois P60s com o mesmo NI, mas referências PAYE diferentes. Incluir a referência PAYE no bloco de identidade evita que essas linhas colidam.
2. Colunas financeiras — os valores que conciliam com o FPS
Remuneração Total do Ano (£), Imposto Total Deduzido (£), NIC do Funcionário (£), NIC do Empregador (£), Deduções de Empréstimo Estudantil (£), Pagamentos Estatutários (£). Cada um desses valores deve corresponder à linha equivalente na sua Declaração de Pagamento Integral (FPS) para o ano fiscal. A falha de conciliação mais comum na extração de P60s em lote é uma divergência entre a Caixa 2 (Imposto Total Deduzido) de um P60 e o valor de imposto acumulado no ano (YTD) do FPS final — geralmente porque o P60 inclui um ajuste manual de código tributário aplicado após o envio do FPS final.
3. Colunas de verificação — verificações cruzadas computadas que sinalizam anomalias antes da reconciliação
São colunas que não aparecem no P60, mas são computadas durante a extração para revelar discrepâncias. Uma coluna "Verificação de Código Tributário" que sinaliza códigos não padrão — qualquer coisa diferente de códigos cumulativos como 1257L, BR, D0, D1 — informa instantaneamente quais linhas precisam de revisão manual. Uma coluna "Verificação de Categoria NI" que sinaliza qualquer coisa diferente da Categoria A (a categoria padrão para empregados não em regimes contratados) revela funcionários nas Categorias B, C, J ou Z — cada uma com diferentes alíquotas de contribuição e que pode indicar um acordo de folha de pagamento especial. Essas colunas de verificação não adicionam trabalho de transcrição, pois a IA as preenche durante a mesma passagem de extração que lê os valores financeiros.
Para equipes de folha de pagamento que gerenciam P60s de vários empregadores, uma coluna "Referência PAYE" funciona tanto como chave de agrupamento de lote quanto como pivô de reconciliação. Filtre a saída pela referência PAYE, some as colunas de Remuneração Total e Imposto Total Deduzido e compare com os totais do P35 (Declaração Anual do Empregador) de cada empregador. A IA não precisa entender o formato de uma referência PAYE — ela lê a string conforme aparece e, como as referências PAYE do Reino Unido usam um padrão consistente NNN/XXNNNNN (PAYE20005), a saída é naturalmente classificável e filtrável.
O tratamento do código tributário merece atenção especial em escala de lote. O código tributário cumulativo padrão para 2025-26 é 1257L — refletindo a isenção pessoal de £12.570 — mas o processamento em lote revela quantos desvios do padrão existem entre 100 funcionários. Um funcionário com código K (deduções totais excedem as isenções) tem tratamento tributário fundamentalmente diferente de um com 1257L. Um funcionário cujo P60 mostra um código BR (alíquota básica) provavelmente foi tributado em uma segunda fonte de renda. Um funcionário com NT (sem imposto) pode ter enviado um P85 à HMRC confirmando não residência. Cinco funcionários com 1257L e sufixo "X" foram colocados em regime não cumulativo (Mês 1) — o que significa que seus valores acumulados no ano podem não representar um cálculo de ano completo. Uma coluna chamada "Código Tributário Final" revela tudo isso. Uma segunda coluna calculada, chamada "Tipo de Código Tributário" — onde a IA classifica cada código como "Cumulativo", "Não Cumulativo", "BR/D0/D1" ou "Código K" — transforma uma planilha de códigos em uma planilha de situações tributárias, filtrável com um clique.
Mesclando Dados de P60 de Múltiplos Empregadores e Anos Fiscais
A extração em lote produz uma planilha por lote. Uma equipe de folha de pagamento gerenciando P60s em três regimes PAYE — cada um com sua própria referência no estilo 123/AB456 — acaba com três planilhas. A etapa de mesclagem é onde o design estrutural das colunas de extração compensa ou desmorona.
Se cada lote usasse os mesmos nomes de coluna — "Nº NI", "Nome do Funcionário", "Referência PAYE", "Ano Fiscal", "Remuneração Total do Ano (£)", "Imposto Total Deduzido (£)" — as três planilhas empilham verticalmente sem remapeamento de colunas. A coluna "Referência PAYE" em cada planilha identifica a qual empregador cada linha pertence, então a planilha mesclada pode ser pivotada por referência PAYE para produzir totais por empregador. Este é o propósito inteiro de padronizar nomes de colunas entre lotes: a mesclagem se torna uma operação de anexação, não um exercício de mapeamento de colunas.
Para a questão mais ampla do fluxo de trabalho — organizar arquivos, escolher uma abordagem de lote e estruturar a saída para uso downstream — o guia completo de fluxo de trabalho OCR em lote cobre preparação de arquivos, seleção de ferramentas e estruturação de saída para múltiplos tipos de documento. O esquema de colunas específico do P60 descrito aqui se encaixa nessa estrutura geral.
Um caso específico de mesclagem: um funcionário que aparece em dois lotes com o mesmo Nº NI, mas referências PAYE diferentes. Isso não é um erro — é um funcionário que teve dois empregos no mesmo ano fiscal. O P60 do empregador A mostra renda e imposto de um emprego; o P60 do empregador B mostra renda e imposto do outro. Mesclados em uma planilha, essas duas linhas não devem ser agregadas. A coluna "Referência PAYE" é o que impede você de somar dois P60s que representam empregos separados. Sem ela, uma SOMA ingênua de "Imposto Total Deduzido (£)" produz um valor que não corresponde ao P35 de nenhum empregador — e uma reconciliação com a HMRC que não vai fechar.
Perguntas Frequentes: Processamento em Lote de P60s do Reino Unido
A extração em lote funciona com P60s digitalizados em papel?
Sim — a extração semântica lê o conteúdo textual do documento, não seus metadados digitais. Uma digitalização de 150 DPI de um P60 em papel de 2022 produz a mesma saída estruturada que um PDF Sage gerado digitalmente em 2026, desde que o texto seja legível. A qualidade da extração depende da nitidez da digitalização, não de o documento ter sido criado digitalmente. Digitalizações muito distorcidas, fotocópias de baixa resolução e P60s com anotações manuscritas podem gerar menor precisão — nesses casos, as colunas de verificação (Verificação de Código Tributário, Verificação de Categoria NI) sinalizarão as linhas que precisam de revisão manual.
O que acontece com P60s que incluem deduções de empréstimos estudantis?
Os P60s do Reino Unido incluem uma seção dedicada para deduções de empréstimos estudantis e de pós-graduação (Plano 1, Plano 2, Plano 4 e Empréstimo de Pós-Graduação). O formato padrão do P60 da HMRC separa estes por tipo de plano. Defina uma coluna por plano — "Empréstimo Estudantil Plano 1 (£)", "Empréstimo Estudantil Plano 2 (£)", "Empréstimo de Pós-Graduação (£)" — em vez de uma única coluna "Empréstimo Estudantil (£)". Um funcionário que paga tanto o Plano 1 quanto o Plano 2 terá dois campos com valores não nulos, e uma coluna única combinada impossibilita distinguir a qual plano cada dedução se refere durante a reconciliação com os avisos de início e término SL1/SL2 emitidos pela HMRC.
Posso processar P60s de vários anos fiscais em um único lote?
Tecnicamente sim — a IA extrairá dados de qualquer P60, independentemente do ano fiscal — mas é uma prática melhor agrupar por ano fiscal. Uma planilha mesclada contendo P60s de 2024-25 e 2025-26 exige que a coluna "Ano Fiscal" esteja 100% correta antes de qualquer reconciliação específica do ano começar. Processar cada ano fiscal como um lote separado — com o ano fiscal codificado em uma coluna de nível de lote, em vez de depender da detecção por documento — reduz o risco de contaminação entre anos. Se precisar processar anos mistos, inclua uma coluna de verificação calculada que sinalize qualquer linha onde a data de fim do ano fiscal não corresponda ao esperado 5 de abril do ano fiscal.
Como a extração em lote lida com funcionários de mesmo nome?
O nome do funcionário não é usado como identificador único — o Número NI é. Dois funcionários chamados "João Silva" que compartilham o mesmo empregador, mas têm números NI diferentes, produzirão duas linhas distintas com o mesmo nome, mas números NI e valores financeiros diferentes. O processador em lote trata cada documento de forma independente. O risco está na etapa de mesclagem: se você mesclar dois lotes e classificar por nome, as duas linhas de "João Silva" aparecerão adjacentes, e a pessoa revisando a planilha pode não perceber que elas têm números NI diferentes. Incluir o Número NI como a primeira coluna em sua saída — antes do Nome do Funcionário — o torna a chave de classificação visual e evita confusão baseada em nomes.
E se um P60 não exibir claramente a referência PAYE?
A HMRC exige que todo P60 exiba a referência PAYE do empregador — é um campo obrigatório conforme RD1. No entanto, alguns softwares de folha de pagamento imprimem a referência em tamanho pequeno, oculta na seção de detalhes do empregador ou ao lado do logotipo da HMRC, em vez do corpo principal do certificado. Se o layout de um provedor específico ocultar consistentemente a referência PAYE, você pode adicionar uma coluna de valor fixo — defina a referência PAYE manualmente para esse lote em vez de depender da extração por IA. Como a referência PAYE é a mesma para todos os P60s em um lote de um único empregador, uma coluna definida manualmente cobre o lote inteiro. A coluna "Nome do Arquivo" na saída ainda fornece a proveniência por linha, mesmo quando uma coluna é definida em lote em vez de extraída individualmente.
O prazo de 31 de maio para o P60 não vai desaparecer — e a lacuna entre o que o software de folha de pagamento gera e o que a conciliação exige também não. As cinco horas entre "P60s emitidos" e "a planilha concilia com o FPS" é um problema estrutural que a velocidade do teclado não resolve. É um problema de design de colunas. Defina suas colunas uma vez. Faça o upload do lote. Deixe a planilha se preencher sozinha.
Teste em seus P60s