Mais de 100 P60 do Reino Unido antes de 31 de maio
Uma Planilha de Auditoría, Sem Inserção Manual
De acordo com o Regulamento 67 do Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682), todo empregador do Reino Unido deve fornecer um P60 a cada empregado na folha de pagamento a partir de 5 de abril — e o prazo de 31 de maio é definido por estatuto, não pelo software de folha de pagamento. O P60 em si não é o gargalo. Sage 50cloud, BrightPay, QuickBooks Online, Moorepay e IRIS geram certificados conformes em segundos. O gargalo é o que acontece depois: alguém precisa consolidar mais de 100 desses PDFs — além de cópias impressas digitalizadas de empregados que perderam os seus, e capturas de tela do portal HMRC — em uma única planilha que concilie com os Full Payment Submissions do ano antes do final do mês. A dois minutos por certificado para o fluxo de trabalho manual — abrir PDF, localizar Box 1 a Box 6, transcribir em uma linha da planilha — uma empresa de 150 empregados gasta cinco horas da janela de folha de pagamento de maio em puro copiar e colar. E isso suponiendo que ninguém tenha mudado de software de folha de pagamento a meio do ano, que nenhun empregado tenha saído em março, e que nenhun P60 digitalizado tenha chegado impresso a 150 DPI.
Principais Conclusões
- De acordo com a legislação do Reino Unido, todo empregador deve emitir um P60 a cada empregado até 31 de maio — e para uma empresa de 150 empregados que usa vários provedores de folha de pagamento, "simplemente abra os PDFs e copie-os no Excel" significa cinco horas de pura transcrição no mês mais movido do calendário de folha de pagamento.
- 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 (NI Number + PAYE Reference), um conjunto de colunas financeiras (salário, imposto, NICs) e um conjunto de colunas de verificação (tipo de código de imposto, verificação de categoria NI) que juntas tornan cada linha auditable e cada fusão de planilhas uma simples adição.
- Defina esse esquema de colunas uma vez, aplique os mesmos nomes a cada lote independentemente do provedor de folha de pagamento ou do ano fiscal, e fusionar 100 filas de Sage com 50 de BrightPay se torna uma operação verticalmente empilable — sin remapeo de columnas, sin plantillas por proveedor, sin conjeturas sobre a qué empleador pertenece cada fila.
Por que 100+ P60s é um Problema Fundamentalmente Diferente de 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.
Para o caso de um único certificado, uma execução de P60 para Excel pontual é suficiente; os problemas abaixo só aparecem quando a pasta é grande o suficiente para que ninguém consiga inspecionar as linhas visualmente.
Três problemas estruturais aparecem 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 NI number 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 nova varredura visual — localizar onde cada caixa está na renderização específica daquele provedor antes de digitar qualquer coisa. Em 100 P60s divididos entre três provedores, apenas esse custo de re-varredura visual — cerca de 10 segundos por documento para se reorientar — consome 15 minutos de tempo morto antes de uma única tecla de transcrição.
2. Proveniência de linhas na escala de auditoria
Quando você extrai 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 "Total Pay" com £38.450, mas nenhuma coluna identificando de qual P60 de funcionário esse valor veio, a planilha é um passivo de auditoria — não um ativo de auditoria. Sob verificações de conformidade do 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á cruzando células de planilha com 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 de exceção. Um funcionário com código de imposto Week 1 / Month 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 de pagamento que a empresa não usa mais. Um P60 em papel escaneado de uma aquisição de 2023 em que a referência PAYE pertence à entidade adquirida, não à empresa atual. Em um fluxo de trabalho manual, você identifica esses casos um a um. Em um fluxo de trabalho em lote, cada exceção perdida se torna um valor incorreto em uma planilha de reconciliação que o HMRC pode auditar.
Cada um destes problemas tem uma solução que não envolve contratar mais pessoal de entrada de dados para maio. Eles envolvem desenhar o fluxo de trabalho do 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 seis meses a partir de agora por alguien que não produjo os dados originais.
A Realidade Multi-Formato: Sage Não É BrightPay Não É um Scan de 150 DPI
O HMRC não exige um único layout de P60. Exige o conteúdo: de acordo com a especificação RD1, um P60 substituto deve exibir determinadas caixas — nome do empregado, NI number, referência PAYE, pagamento total do ano, imposto total deducido, deduções de empréstimo estudantil, código tributário final e detalhes do empregador — mas a disposição visual é deixada a cada fornecedor de software de folha de pagamento. O resultado é que um P60 de Sage 50cloud parece estruturalmente diferente de um P60 de BrightPay, que parece diferente de um P60 de QuickBooks Online Payroll, que parece diferente de um P60 de Moorepay, que parece diferente de um P60 de IRIS. E isso antes de introducir cópias em papel escaneadas de empregados que perderam seus originais.
A extração tradicional baseada em modelo — onde você desenha retângulos ao redor dos campos em um P60 de exemplo — lida com isso exigendo um modelo separado para cada provedor de folha de pagamento. Mantenga cinco provedores, mantenga cinco modelos. Um provedor atualiza seu layout de P60 para o novo ano fiscal — novas diretrices do HMRC, um rebranding, uma mudança de formato — e o modelo produz silenciosamente uma saída desalinhada. O administrador de folha de pagamento só descobre isso quando a reconciliação não bate com os totais de FPS.
A extração sem modelo elimina o problema de modelo por provedor ao ler o documento pelo significado em vez da posição. Você define as colunas que deseja uma vez — "NI Number," "Total Pay for Year (£)," "Tax Deducted (£)," "PAYE Reference," "Final Tax Code" — e a IA localiza cada valor em cada P60 ao entender o que os dados representam, não onde estão na página. Um P60 de Sage 50cloud, um P60 de BrightPay, um P60 de QuickBooks e um P60 de papel escaneado de 2023 alimentam todos as mesmas definições de coluna. Para um aprofundamento dos campos individuais em 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 esse termina: o que acontece quando você para de pensar em P60s um de cada vez.
O que torna isso particularmente valioso em um 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 de qual software de folha de pagamento os produjo. Uma empresa que usa Sage para pessoal permanente e BrightPay para contratistas emitirá P60s com a mesma referência PAYE, mas em dois formatos visualmente diferentes. A extração sem modelo lê o valor, não o layout. A coluna "PAYE Reference" em sua planilha de saída se preenche de forma idéntica em ambos provedores, dando a você uma chave de agrupamento natural para lotes de múltiples provedores.
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 de você enviar qualquer arquivo: como você nomeia os documentos de origem. Quando sua planilha de saída tem 100 linhas e, três meses depois, um oficial de conformidade do 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ê possa localizar instantaneamente.
Uma convenção de nomenclatura que atenda à rastreabilidade de auditoria inclui três componentes:
Identificador do funcionário
O número do NI é a chave primária natural para registros de folha de pagamento do Reino Unido — é único, permanente e aparece em todos os P60s. Usá-lo como prefixo do nome do arquivo oferece uma chave de consulta instantânea: AB123456C mapeia diretamente para os registros do HMRC. Quando números de NI não podem 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 em lote — 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 lote em planilhas separadas, o ano no nome do arquivo é a única coisa que evita 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 pergunta 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 conhecida de arredondamento na exportação. Uma tag do provedor transforma uma anomalia inexplicável em um padrão comportamental 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 de arquivo na saída (o ImageToTable.ai inclui uma coluna "File Name" por padrão em exportações em lote), cada linha da sua planilha carrega sua própria proveniência. Sem necessidade de referência cruzada externa.
Para equipes de folha de pagamento que gerenciam funcionários em vários esquemas PAYE — uma empresa guarda-chuva gerenciando folhas de pagamento de 20 entidades clientes, ou uma estrutura de grupo onde cada subsidiária tem sua própria referência PAYE — o formato de referência PAYE 123/AB456 se torna a chave natural de agrupamento em lote. Processe todos os P60s com 123/AB456 em um lote, e todos os P60s com 456/CD789 em outro. A coluna de referência PAYE na saída de cada lote serve como ponto de articulação ao mesclar as duas planilhas posteriormente. Você nunca precisa 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 de imposto merece atenção especial em escala de lote. O código de imposto 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 isenções) tem tratamento tributário fundamentalmente diferente de um com 1257L. Um funcionário cujo P60 mostra um código BR (Basic Rate) provavelmente foi tributado em uma segunda fonte de renda. Um funcionário com NT (No Tax) pode ter enviado um P85 ao HMRC confirmando não residência. Cinco funcionários com 1257L com sufixo "X" foram colocados em base não cumulativa (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 "Final Tax Code" revela tudo isso. Uma segunda coluna calculada chamada "Tax Code Type" — onde a IA classifica cada código como "Cumulative," "Non-Cumulative," "BR/D0/D1," ou "K Code" — transforma uma planilha de códigos em uma planilha de situações fiscais, 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 esquemas 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 suas colunas de extração compensa ou colapsa.
Se cada lote usasse os mesmos nomes de coluna — "NI Number," "Employee Name," "PAYE Reference," "Tax Year," "Total Pay for Year (£)," "Total Tax Deducted (£)" — as três planilhas empilham verticalmente sem remapeamento de colunas. A coluna "PAYE Reference" 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 do fluxo de trabalho de OCR em lote cobre preparação de arquivos, seleção de ferramentas e estruturação de saída em múltiplos tipos de documento. O esquema de colunas específico para P60 descrito aqui se encaixa nesse framework geral.
Um caso específico de mesclagem: um funcionário que aparece em dois lotes com o mesmo NI number, 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 "PAYE Reference" é o que impede você de somar dois P60s que representam empregos separados. Sem ela, uma SOMA ingênua de "Total Tax Deducted (£)" produz um valor que não corresponde ao P35 de nenhum dos empregadores — e uma reconciliação com o 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 de folha exige também não. As cinco horas entre "os P60s são 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. Envie o lote. Deixe a planilha se preencher sozinha.
Experimente com seus P60s