Extrair recibos de vencimento para preparar a DMR

Um recibo de vencimento não é a DMR. Mas, quando o processamento salarial foi feito fora do gabinete, é muitas vezes o documento mais completo que o contabilista recebe para reconstruir o mapa de trabalho da Declaração Mensal de Remunerações.

Para extrair recibos de vencimento para preparar a DMR, o ponto de partida deve ser uma tabela por trabalhador, com NIF, NISS quando conste do recibo, entidade empregadora, mês de pagamento, período a que respeita, tipo ou código de rendimento, bruto sujeito, componentes isentas ou não sujeitas, retenção IRS, contribuição do trabalhador para a Segurança Social, outras deduções, líquido pago, ficheiro de origem, página e flags de validação. Só depois essa tabela deve ser comparada com as regras em vigor, com as guias de IRS e com os valores da Segurança Social.

Esta distinção evita dois erros comuns. O primeiro é tratar o PDF como se bastasse converter texto para Excel. O segundo é tratar a extracção como se calculasse salários ou substituísse o Portal das Finanças. O recibo dá evidência documental sobre o que foi processado; a DMR exige enquadramento, códigos, períodos e validação profissional.

Quando o gabinete processa os salários no seu próprio software, o mapa, a DMR e a DRI costumam nascer do mesmo circuito. O caso mais trabalhoso é outro: o cliente envia um PDF mensal gerado no TOConline, PHC, Primavera, Sage, Cegid, Eticadata, Artsoft ou até num modelo manual, e a equipa precisa de produzir uma base consistente para revisão. Nesse cenário, a extracção útil não é uma lista de textos lidos do PDF. É um mapa com colunas estáveis, valores numéricos utilizáveis e uma referência directa ao documento que justifica cada linha.

Desenhe primeiro a tabela DMR, não o OCR

O erro mais caro é começar pelo OCR e aceitar as colunas que a ferramenta devolver. Um recibo pode chamar "vencimento base" a uma rubrica, outro pode usar "remuneração mensal", e outro pode agrupar subsídios e acertos num bloco de abonos. Se a tabela de destino não estiver definida antes da extracção, o gabinete acaba com folhas diferentes por cliente e com trabalho manual no momento em que menos tempo tem.

Uma estrutura de trabalho para DMR deve separar, pelo menos, quatro grupos de dados. Identificação: trabalhador, NIF, NISS quando disponível, entidade empregadora e, se fizer sentido no gabinete, código interno do trabalhador. Período: mês de pagamento, período a que respeita a remuneração, ano de referência e indicação de valores de anos anteriores. Rendimento e descontos: bruto sujeito, componentes isentas, componentes não sujeitas, retenção na fonte de IRS, contribuição do trabalhador para a Segurança Social, outras deduções e líquido pago. Controlo: ficheiro, página, rubrica original, confiança da extracção, anomalia detectada e estado de revisão.

A diferença entre mês de pagamento e período a que respeita merece uma coluna própria. Um subsídio de Natal pago em Novembro, um acerto de meses anteriores ou um valor de férias referente a outro período não deve ser achatado numa única data. A DMR olha para rendimentos pagos ou colocados à disposição, mas também exige que certos valores sejam individualizados pelo período ou ano a que respeitam. Se essa distinção só for feita no fim, as correcções passam a depender de memória e de pesquisa manual no PDF.

Para processar uma folha de vencimentos em Excel para contabilidade, a folha deve ser uma ferramenta de revisão, não apenas um depósito de valores. Colunas de flags ajudam a equipa a filtrar "retenção IRS fora do esperado", "NISS ausente", "subsídio de refeição acima do limite isento", "possível duodécimo", "MOE ou regime especial" e "confirmar período". A utilidade do mapa está em reduzir a lista de recibos que precisam de leitura integral, sem retirar ao contabilista a decisão final.

Normalize recibos vindos de TOConline, PHC, Primavera, Sage ou modelos manuais

Num gabinete com vários clientes, o problema raramente é a ausência de dados. O problema é a forma. Um recibo gerado num ERP pode apresentar NIF e NISS no cabeçalho, outro pode pôr a identificação do trabalhador numa zona lateral, e um modelo manual pode misturar abonos, descontos e observações num bloco sem separadores claros. A normalização deve tratar estes layouts como variantes de uma mesma realidade salarial.

Comece por mapear cada rubrica para uma família de dados, em vez de tentar copiar a aparência do recibo. Identificação do trabalhador, remunerações fixas, remunerações variáveis, subsídios, descontos legais, deduções não fiscais, líquido e dados de pagamento devem ficar em colunas próprias. A rubrica original também deve ser guardada. Se um valor foi lido como "subsídio alimentação", "S. refeição" ou "cartão refeição", essa designação ajuda a explicar a classificação quando o recibo for revisto.

Invoice Data Extraction encaixa aqui como camada de extracção, não como software de salários. O gabinete pode carregar PDFs ou imagens, pedir em linguagem natural as colunas pretendidas, definir regras de formatação e receber a saída em Excel, CSV ou JSON. A mesma lógica que permite extrair documentos financeiros para Excel em lotes de facturas ou extratos pode ser usada para pedir uma tabela consistente a partir de recibos de vencimento, mantendo referência ao ficheiro e à página de origem para conferência.

Essa referência é indispensável porque nem todos os recibos resolvem ambiguidades da mesma forma. Uma rubrica de ajudas de custo pode estar dentro de abonos, fora da base sujeita, parcialmente sujeita ou descrita apenas numa nota. Um subsídio pago em duodécimos pode aparecer como linha autónoma ou como parte de um total. A extracção deve preservar a pista documental que permite ao técnico confirmar a decisão, em vez de devolver apenas um número solto.

Também convém manter fronteiras claras entre documentos. Recibos de vencimento não são facturas, não surgem no SAF-T PT Faturação e não têm ATCUD como um documento fiscal de venda. Para esse trabalho, use um circuito separado para extrair dados de faturação SAF-T PT para Excel. Misturar estes conceitos na mesma tabela cria ruído no gabinete: o objectivo aqui é construir dados salariais revistos a partir de recibos, não transformar a folha de salários numa rotina de validação de facturação.

Validações que um conversor PDF para Excel não apanha

Converter um recibo de vencimento PDF para Excel dá pouco valor se o resultado não distinguir valores normais de valores que merecem revisão. A tabela deve sinalizar riscos, não decidir sozinha a conformidade. O contabilista continua responsável por confirmar tabelas em vigor, regimes aplicáveis, códigos e excepções.

A primeira flag é a retenção na fonte de IRS. O mapa pode comparar a retenção extraída com uma estimativa baseada na tabela aplicável ao mês, mas essa comparação depende de variáveis que nem sempre estão no recibo: estado civil, número de dependentes, deficiência, residência fiscal, regime de trabalhador dependente ou pensionista, e enquadramentos como IRS Jovem. Quando o desvio é material, a linha deve ficar marcada para revisão, não corrigida automaticamente.

A contribuição do trabalhador para a Segurança Social também deve ser tratada como plausibilidade. Para muitos trabalhadores por conta de outrem, 11% sobre a base relevante é uma referência prática de revisão. Mas MOE, estagiários remunerados, regimes especiais, pré-reforma e situações com bases contributivas específicas não devem ser achatados numa única regra. Uma linha com "SS trabalhador fora do padrão" é mais útil do que um cálculo silencioso que parece definitivo.

O subsídio de refeição exige outra separação. A tabela deve identificar valor diário, número de dias, modo de pagamento quando o recibo o indique, parcela potencialmente isenta e eventual excesso sujeito a IRS. Como os limites mudam e dependem do enquadramento, o mapa deve guardar as componentes e marcar a necessidade de confirmação contra o regime em vigor no mês de pagamento.

Há rubricas que raramente devem passar sem flag: subsídio de férias, subsídio de Natal, horas extraordinárias, trabalho nocturno, ajudas de custo, compensações, penhoras e pagamentos relativos a períodos anteriores. Algumas afectam a retenção, outras a classificação entre sujeito, isento e não sujeito, e outras apenas a reconciliação. A tabela não precisa de resolver todos estes casos; precisa de os tornar visíveis antes de a DMR ser preparada ou validada.

Os duodécimos merecem uma flag própria porque espalham parcelas de férias ou Natal por vários meses. Para revisão, o mapa deve preservar a componente que foi paga em duodécimos, o período a que respeita e a rubrica de origem, em vez de a misturar no vencimento base. O IRS Jovem também não deve ficar escondido numa retenção baixa: a linha precisa de uma indicação de regime, tabela ou código a confirmar, para que o gabinete não trate uma redução legítima como erro nem aceite uma aplicação indevida sem revisão.

Como transformar a tabela em linhas de DMR-AT

Depois de normalizada, a tabela ainda não é a DMR. É a base que permite ao gabinete construir ou validar linhas de declaração com menos pesquisa manual. A leitura deve ser feita por titular do rendimento, por tipo de rendimento e, quando necessário, por período ou ano a que o rendimento respeita.

As instruções da AT para a DMR-AT indicam que a declaração mensal de remunerações declara rendimentos de trabalho dependente pagos a residentes em Portugal, incluindo retenções de IRS, contribuições obrigatórias e quotizações sindicais, e que a entrega é feita pela Internet até ao dia 10 do mês seguinte ao pagamento. Esse facto explica porque o recibo de vencimento é apenas uma parte da evidência: a declaração precisa de enquadrar quem recebeu, que tipo de rendimento recebeu, quando foi pago e a que período respeita.

Num caso simples, um trabalhador dependente gera uma linha principal de categoria A com vencimento, retenção e contribuições do mês. Mas a realidade mensal do gabinete raramente é só isso. Rendimentos de anos anteriores, regularizações, subsídios pagos fora do mês corrente, valores isentos, componentes não sujeitas e códigos especiais podem exigir linhas separadas ou pelo menos revisão antes de serem agregados.

Na prática, o mapa deve permitir transformar cada recibo em linhas de trabalho com trabalhador, NIF, tipo ou código de rendimento, mês de pagamento, período a que respeita, bruto sujeito, valor isento ou não sujeito quando exista, retenção, contribuições obrigatórias e estado de revisão. Se o mesmo trabalhador tiver vencimento corrente, duodécimos e acerto de período anterior, o gabinete não deve perder essas componentes numa única soma sem rasto. A linha final que alimenta a preparação da DMR precisa de mostrar o valor e a razão do valor.

A coluna "período a que respeita" é decisiva. Um valor pago em Janeiro pode corresponder a trabalho de Dezembro, a acerto de meses anteriores ou a subsídio de férias. O mês de pagamento ajuda a definir a obrigação mensal; o período de referência ajuda a não misturar remunerações correntes, atrasados e regularizações. Se o mapa só tiver uma data, a equipa perde uma das validações mais importantes.

Também vale separar o universo dos recibos de vencimento do universo dos recibos verdes. O trabalhador dependente entra na lógica do recibo de vencimento e da categoria A. O prestador independente segue o circuito da categoria B, com documentos, retenções e leitura diferentes, pelo que faz sentido tratar em separado o trabalho de extrair retenção na fonte de recibos verdes de fornecedores que também alimenta a DMR e o Modelo 10. Um gabinete pode ter ambos no mesmo mês de DMR, mas não deve forçar os dois regimes para a mesma tabela de extracção.

Reconcilie antes de submeter ou entregar o ficheiro

O mapa extraído só deve entrar no circuito final depois de reconciliado. No ficheiro de revisão, a equipa deve filtrar a retenção na fonte por cliente, mês e trabalhador e comparar o total com a guia de retenções de IRS preparada para o mesmo período. Quando há diferença, o valor precisa de apontar para a rubrica e para a página do recibo, não apenas para uma célula agregada que obriga a reabrir todos os PDFs.

A Segurança Social pede a mesma disciplina documental. A DMR-AT e a DRI não são a mesma declaração, mas os recibos de vencimento que alimentam uma também alimentam a revisão da outra. Diferenças entre bases, contribuições do trabalhador e totais por trabalhador devem aparecer como uma lista curta de casos a abrir, com o recibo de origem ao lado.

Quando o gabinete tem acesso aos extratos do cliente, os líquidos pagos nos recibos devem ser confrontados com os movimentos bancários. Um recibo com líquido de 1.184,37 euros e uma transferência de valor diferente pode ser adiantamento, acerto, pagamento parcial ou erro de extracção. Para essa parte do trabalho, o processo de converter extratos bancários PDF para Excel fecha o ciclo entre recibo, pagamento e conciliação.

A DMR também compete por tempo com outras obrigações do mesmo calendário mensal. A declaração periódica de IVA tem outra base documental, mas ocupa a mesma agenda de gabinete; por isso, faz sentido que a equipa tenha rotinas separadas para preparar a declaração periódica de IVA a partir de faturas recebidas e para validar remunerações. Misturar as duas obrigações no mesmo mapa cria confusão, mesmo quando os prazos pressionam a mesma semana.

O princípio é reutilizável para outros documentos financeiros que o gabinete recebe em formato fechado. Tal como é possível extrair o mapa de responsabilidades do Banco de Portugal para Excel para análise estruturada, os recibos de vencimento devem sair do PDF com colunas, origem e flags suficientes para serem revistos. A submissão continua a exigir critério contabilístico; a extracção reduz o trabalho repetitivo que impede esse critério de ser aplicado a tempo.