Primavera BSS PDF para Excel: guia para contabilistas

Passar Primavera BSS PDF para Excel passa por três caminhos, consoante a origem dos dados que tem em mãos. Com acesso ao ERP, o caminho directo é o módulo Office Extensions ou a exportação nativa dos mapas. Para transferência formal ou auditoria, o suporte certo é o ficheiro SAF-T, não uma conversão de PDF. Quando só existe o relatório em PDF — arquivado, digitalizado ou enviado por um cliente — o caminho prático é a extração por IA.

Em qualquer dos três caminhos, a folha resultante só é contabilisticamente utilizável se preservar o mesmo conjunto de campos: número de conta, data do lançamento, documento, entidade, débito, crédito e saldo, com formato decimal por vírgula e continuidade do saldo entre páginas. São esses os critérios pelos quais o resultado se julga, independentemente de como foi obtido.

Uma desambiguação rápida que vale a pena despachar já: este guia trata de Cegid Primavera BSS, o ERP português de gestão e contabilidade (anteriormente Primavera Business Software Solutions), não de Oracle Primavera P6, que é software de planeamento de obra e aparece nas mesmas pesquisas por acidente de nome.

O guia é escrito a pensar no profissional que efectivamente usa estes mapas no dia a dia. Em Portugal, a profissão é regulada pela Ordem dos Contabilistas Certificados, com cerca de 68 mil contabilistas certificados inscritos na OCC — é esse o público a quem este conteúdo se dirige, com o vocabulário de extrato de conta, balancete, razão, lançamento, débito, crédito e saldo que o leitor já reconhece sem tradução.

A partir daqui, o artigo identifica primeiro o tipo de relatório que tem à frente e percorre os três caminhos com os limites e os pontos fortes de cada um. Para o cenário em que só existe o PDF, desce depois ao detalhe campo a campo de extrato, razão, balancete e mapas de IVA, e à forma de pedir uma extração que respeite a estrutura contabilística desses mapas.

Cegid Primavera BSS e os relatórios que vai converter

A Cegid Primavera BSS é o ERP português comercializado actualmente pela Cegid e originalmente desenvolvido pela Primavera Business Software Solutions. Reúne módulos de Contabilidade, Gestão Comercial, Activos, Recursos Humanos, e o módulo Office Extensions que liga o Excel à base de dados. Não confundir com o Oracle Primavera P6: apesar do nome partilhado, esse é um produto totalmente diferente, dedicado a planeamento e calendarização de obra, sem qualquer relação com contabilidade ou faturação. Se o relatório que tem à frente fala de extratos, balancetes, razão, IVA ou movimentos contabilísticos, é Cegid Primavera BSS — e é desse universo que tratamos aqui.

Antes de escolher um caminho de conversão, vale a pena ter a certeza de qual é o relatório PDF Cegid Primavera que tem em mãos, porque cada um pede uma estrutura tabular diferente em Excel. Os mapas mais frequentes são estes:

• Extrato de conta de clientes e extrato de conta de fornecedores: listagem cronológica de lançamentos por entidade, com débito, crédito e saldo cumulativo. Confirme visualmente que o cabeçalho identifica a entidade ou a conta corrente, que existem colunas separadas de débito e crédito, e que aparece um saldo que vai sendo actualizado linha a linha.
• Balancete analítico: agregados por conta de movimento, com saldo inicial, movimento do período e saldo final, descendo até ao último nível do plano de contas. Confirme a presença de colunas de saldo inicial, movimento e saldo final, em pares débito/crédito.
• Balancete sintético: a mesma estrutura agregada até um determinado nível hierárquico (classe ou subclasse), sem descer à conta de movimento. Confirme se as contas listadas terminam em níveis intermédios (1, 2 ou 3 dígitos) e não em contas de folha.
• Razão geral: listagem cronológica completa por conta, normalmente do balancete inteiro, com cabeçalho de conta a abrir cada bloco e movimentos sequenciais por baixo.
• Diário: lançamentos por ordem de inserção (não por conta), com a contrapartida de cada lançamento visível. Confirme se a chave de ordenação é o número do lançamento e não a conta.
• IVA recapitulativo e mapa de IVA dedutível: agregados por taxa e por documento, com base tributável e IVA por taxa. Confirme a presença das colunas de taxa, base e IVA, e a separação entre operações sujeitas, isentas e não sujeitas.

Há ainda dois detalhes operacionais que aparecem em quase todos estes mapas e que vão importar mais à frente. O primeiro é a distinção entre data do lançamento (a data atribuída ao registo contabilístico) e data do movimento (a data do facto subjacente, normalmente a data do documento). Em organizações onde as duas divergem, ambas as colunas costumam estar presentes no extrato e na razão, e têm de ser preservadas como colunas distintas na folha. O segundo é o centro de custo ou a conta analítica: organizações com contabilidade analítica activa mostram o centro de custo numa coluna própria do mapa, e essa coluna tem de chegar à folha como informação separada, não dissolvida no histórico do lançamento.

---

Caminho 1: Office Extensions e exportações nativas para acesso directo ao ERP

Quando o leitor tem licença activa e ligação à base de dados Primavera, o caminho recomendado para ter dados em Excel é o próprio ERP. O módulo Office Extensions liga o Excel directamente ao Primavera: a folha vai buscar a informação à base de dados via fórmulas e funções dedicadas, e refresca-se contra a base actualizada sempre que o utilizador o pede. Isto é diferente de uma exportação estática. A folha mantém-se viva, e a estrutura do mapa pode ser desenhada uma vez para depois ser reutilizada nos fechos seguintes.

Para quem não tem o módulo Office Extensions, há ainda duas alternativas nativas que servem boa parte dos casos. A primeira é a exportação directa a partir da pré-visualização de impressão dos mapas: o ecrã que mostra o relatório antes de imprimir oferece, nos mapas standard, uma opção de exportar para Excel ou para CSV, que produz uma folha derivada do mesmo motor que produz o PDF. A segunda é o ecrã de consulta de movimentos do módulo de Contabilidade, onde se podem filtrar lançamentos por conta, período ou outro critério e exportar os movimentos visíveis para folha de cálculo — é o trabalho típico de quem precisa de Primavera contabilidade exportar movimentos Excel para uma análise pontual sem passar pelo desenho de um mapa formal.

Este caminho é o adequado quando se cumprem três condições simples: o utilizador tem acesso interno à base de dados, os dados pedidos são actuais ou correspondem a um período ainda activo, e a operação vai repetir-se em fechos seguintes. Nesse cenário, vale o investimento de configurar Office Extensions ou de definir os mapas para exportar directamente, porque a folha resultante é ligada à fonte e o trabalho de preparação amortiza-se ao longo do tempo.

Há também limites que convém reconhecer. Office Extensions e exportações nativas não funcionam para períodos arquivados em sistemas que já não estão licenciados ou aos quais o utilizador deixou de ter acesso, e não servem nada quando o relatório chegou em PDF de fora — de um cliente, de um colega que tem o acesso, ou de um período em que a base de dados original foi descomissionada. Nesses casos, o caminho passa a ser outro, não porque Office Extensions seja menos capaz, mas porque a fonte que ele precisa simplesmente não está disponível.

Caminho 2: SAF-T e exportações estatutárias para transferência formal

Quando o objectivo não é trabalhar o mapa em Excel para uso interno mas sim entregar dados a uma terceira parte — auditor, contabilista que herda o cliente, autoridade fiscal — o suporte certo é o SAF-T (PT), não uma conversão de PDF. O Primavera gera o SAF-T directamente a partir da base de dados, em ficheiro XML normalizado pelo Estado português, e esse ficheiro carrega a informação na forma estruturada que estes destinatários esperam.

Os cenários típicos para este caminho são quatro. A entrega à Autoridade Tributária para cumprimento da obrigação fiscal usa o SAF-T de faturação ou o SAF-T da contabilidade, consoante o que a obrigação concreta pede. O fornecimento a auditores externos é mais limpo em SAF-T do que em pacotes de mapas paginados, porque o auditor pode importar o ficheiro nas próprias ferramentas. A migração para outro ERP ou para outro contabilista responsável é feita preferencialmente sobre o SAF-T, porque o sistema de destino tem em geral um importador desenhado para o formato. E a partilha entre contabilistas envolvidos no mesmo cliente — nas situações em que vários profissionais tocam o mesmo dossier ao longo do ano — beneficia da estrutura única do SAF-T em vez de uma colecção de relatórios soltos.

Um detalhe que vale a pena fixar: o SAF-T é um ficheiro XML, não Excel. Para o ler em folha de cálculo, o leitor passa por uma transformação separada — abrir o XML, mapear os elementos para colunas, achatar a estrutura aninhada — que é um trabalho próprio. O fluxo está coberto noutro artigo deste blog que mostra como extrair SAF-T PT de faturação para Excel sem perder a relação entre cabeçalhos e linhas; quem vai por este caminho beneficia de o consultar antes de começar.

O caminho SAF-T tem ainda assim limites próprios. O ficheiro cobre faturação, contabilidade ou autofaturação, consoante o tipo solicitado, e não substitui qualquer mapa de gestão. Um balancete analítico desenhado de uma forma específica, um extrato de conta de fornecedor formatado para reconciliação, ou um mapa de IVA dedutível com a estrutura interna que o departamento usa — nada disso vem assim do SAF-T. Para esses mapas concretos, e para todo o trabalho que assenta sobre eles, os caminhos 1 e 3 continuam a ser os adequados.

Caminho 3: extração por IA quando só tem o PDF do relatório

Há um conjunto de situações em que os dois caminhos anteriores simplesmente não estão disponíveis, e que cobrem boa parte do trabalho real do contabilista. Um pacote de relatórios arquivado de um período em que a base de dados Primavera já não está acessível. Um conjunto de PDFs enviados por um cliente que tem o acesso e o exportou a pedido. Uma impressão digitalizada que ficou guardada como prova de auditoria e cujo original digital se perdeu. Um deliverable de migração entregue quando o sistema antigo foi descontinuado e a única forma de recuperar o conteúdo é o PDF que sobrou. Em qualquer destes casos, o conteúdo só existe na forma paginada do relatório, e os caminhos 1 e 2 deixam de servir: sem licença activa não há Office Extensions, sem acesso ao período não há SAF-T retroactivo prático.

O caminho útil aqui é a extração de dados de PDF com IA. O utilizador carrega o PDF do relatório, descreve em linguagem natural o que precisa de extrair e como precisa que a folha esteja estruturada, e recebe um ficheiro XLSX, CSV ou JSON com o conteúdo do relatório em forma tabular. Para o cenário de extrair dados de relatórios Primavera BSS sem acesso ao ERP, é a alternativa concreta — não um substituto do Office Extensions ou do SAF-T, que continuam a ser as respostas certas nos cenários em que se aplicam.

A ferramenta concreta que opera este caminho é o Invoice Data Extraction. A interface é apenas um campo de prompt e uma área para carregar ficheiros, sem templates a configurar nem assistentes a percorrer; o prompt é toda a configuração, e o ficheiro fica pronto para download minutos depois. Como o Primavera produz mapas com particularidades próprias — cabeçalhos repetidos no topo de cada página, linhas de subtotal entre blocos de movimento, saldo cumulativo que continua entre páginas, valores em formato decimal por vírgula — o que o leitor escreve no prompt é o que faz a diferença entre uma folha utilizável e uma folha que precisa de ser corrigida à mão.

Os pontos práticos que precisam de ficar claros no prompt são, em resumo, estes: como tratar os cabeçalhos de conta que se repetem após mudança de página, o que fazer com as linhas de subtotal por conta ou por período, como manter o saldo cumulativo correcto entre páginas, e como preservar a vírgula decimal e o formato de data DD-MM-YYYY. As duas secções seguintes sobre os campos a preservar descem ao detalhe de cada tipo de mapa; aqui basta ficar com a ideia de que a qualidade do output depende directamente da clareza com que estas particularidades são descritas à IA.

Uma recomendação operacional antes de seguir: testar este caminho num único relatório representativo do pacote — um extrato típico, um balancete típico — antes de o aplicar a centenas de páginas. Os relatórios Primavera variam consoante o desenho que o cliente faz dos mapas (colunas adicionais, escolhas de cabeçalho, presença ou ausência de centro de custo), e um teste pequeno revela rapidamente o que precisa de ser ajustado no prompt antes de processar tudo de uma vez.

---

Campos a preservar no extrato de conta e no razão geral

Para o extrato de conta de clientes, o extrato de conta de fornecedores e o razão geral, a folha resultante tem de chegar ao Excel com a mesma estrutura tabular que um contabilista esperaria ver se o relatório tivesse vindo directamente do ERP. Em ordem natural de leitura do mapa, as colunas a preservar são estas:

• Número de conta e descrição da conta, em colunas separadas. O número tem de chegar como texto, não como número, para preservar zeros à esquerda e a estrutura hierárquica do plano (uma conta 2111001 é texto, não sete milhões). Esta é a falha mais comum e a mais cara de corrigir depois.
• Data do lançamento no formato DD-MM-YYYY. Onde o relatório também mostra a data do movimento (a data do facto subjacente, em geral a data do documento), preservar como segunda coluna distinta. Não fundir as duas, mesmo quando coincidem na maior parte dos lançamentos.
• Número e tipo de documento, e a referência quando exista. Tipo e número costumam vir juntos no mapa Primavera (FT 2024/123, RC 2024/45); separar em duas colunas se o destino vai filtrar por tipo, ou manter junto se o destino é apenas para consulta humana.
• Entidade (cliente ou fornecedor), com nome ou código consoante o que aparece no mapa, em coluna própria.
• Descrição ou histórico do lançamento, em coluna de texto livre.
• Débito e crédito como duas colunas numéricas separadas, nunca colapsadas numa única coluna com sinal positivo ou negativo. Esta é a regra contabilística que mais facilmente se quebra numa extração mal pedida; uma vez que os dois lados se misturam, recuperar a separação é trabalho manual sobre todas as linhas.
• Saldo numa coluna numérica própria, com vírgula decimal preservada e nunca convertida em ponto.
• Centro de custo ou conta analítica como coluna própria, onde o relatório a mostra.

A maior fonte de problemas em extrações de extrato de conta e de razão geral Primavera Excel não está nos campos em si, mas no que o relatório faz quando muda de página. Três comportamentos pedem instrução explícita à IA:

Continuidade do saldo entre páginas. O saldo é cumulativo: a última linha de uma página termina com um valor de saldo que tem de ser o ponto de partida da primeira linha de movimento da página seguinte. A IA não pode recalcular do zero por página, e não pode tratar o saldo de cabeçalho da página seguinte como um lançamento. Convém pedir no prompt, sem ambiguidade, que a coluna saldo é cumulativa e tem de continuar entre páginas sem reset.

Cabeçalhos de conta repetidos. Em razões e em extratos por conta, o nome e número da conta voltam a aparecer no topo da página seguinte, como cabeçalho de continuação. Sem instrução, a IA pode interpretar essa linha como um registo novo. O prompt tem de pedir explicitamente que linhas de cabeçalho de conta — as que repetem o número e a descrição mas não têm valores de débito/crédito de movimento — não se tornem linhas de movimento na folha.

Linhas de subtotal. Os mapas Primavera intercalam subtotais por conta (no fim de cada bloco de uma conta), por período, ou ambos. Estas linhas têm de ser distinguidas das linhas de movimento. Há três tratamentos possíveis e o prompt deve indicar qual escolher: marcar com uma coluna identificadora Tipo (Movimento versus Subtotal) que o destino pode filtrar; excluir os subtotais e deixar a folha apenas com lançamentos; ou guardar os subtotais em folhas separadas. A escolha depende do que se vai fazer com a folha, mas tem de ser feita conscientemente, não deixada à inferência da IA.

Vale a pena cruzar este cenário com outro mapa pt-PT que tem comportamento paralelo de continuidade entre páginas e cabeçalhos repetidos: o fluxo para passar o mapa de responsabilidades do Banco de Portugal para Excel trata exactamente o mesmo tipo de armadilha, e as instruções escritas para um destes mapas adaptam-se com pequenas alterações para o outro.

Campos a preservar no balancete e nos mapas de IVA

Um balancete não tem a forma de um extrato. Não é uma sequência cronológica de movimentos com saldo a actualizar-se a cada linha; é um agregado por conta para um período fechado, com colunas separadas para o estado inicial, o movimento do período, e o estado final. Os mapas de IVA têm ainda outra forma — agregação por taxa e por documento — que pede atenção própria. As instruções para extrair balancete Primavera Excel ou um mapa de IVA são, por isso, diferentes das que servem o extrato.

Para um balancete analítico ou balancete sintético, as colunas a preservar são estas:

• Número de conta (como texto, pelas mesmas razões da secção anterior) e descrição da conta.
• Classe ou nível hierárquico da conta: 1, 2, 3, ou folha. Esta coluna é a chave para depois filtrar o balancete em Excel. Ainda que no PDF a hierarquia seja sugerida apenas pela indentação visual ou pelo número de dígitos da conta, vale a pena pedir uma coluna explícita com o nível, em vez de a inferir depois com fórmulas.
• Saldo inicial débito e saldo inicial crédito como par de colunas separadas.
• Movimento débito do período e movimento crédito do período como segundo par de colunas separadas.
• Saldo final débito e saldo final crédito como terceiro par.

A diferença entre balancete sintético e analítico não está nos campos, está no nível ao qual a agregação termina. O sintético pára em níveis intermédios do plano (classe, subclasse) e não desce à conta de movimento; o analítico desce até à conta de folha. A extração tem de preservar exactamente a hierarquia que aparece no PDF — se o sintético pára no nível 3, a folha não deve inventar contas de nível 4 onde elas não estão. O prompt deve fixar explicitamente que a folha tem de respeitar a granularidade do mapa de origem.

Dois pontos operacionais adicionais. Primeiro, o saldo final tem de respeitar a equação contabilística da conta (saldo inicial mais movimento débito menos movimento crédito, ou a forma equivalente conforme o lado natural da conta), não é apenas a diferença numérica entre os movimentos do período; isto importa porque qualquer arredondamento mal feito numa coluna corrompe a outra. Segundo, em extracções rápidas a IA pode tentar "simplificar" o balancete colapsando os pares débito/crédito numa única coluna com sinal — o que destrói a leitura contabilística. O prompt tem de fixar explicitamente que os três pares (inicial, movimento, final) ficam como seis colunas separadas.

Para o IVA recapitulativo e o mapa de IVA dedutível, os campos são outros:

• Período (mês ou trimestre, conforme a periodicidade).
• Número do documento e data do documento.
• Entidade (cliente ou fornecedor) e NIF.
• Base tributável por taxa, em colunas separadas para cada taxa aplicável.
• IVA por taxa, em colunas correspondentes às anteriores.
• Total do documento.
• Indicação clara da classificação fiscal: operações sujeitas, operações isentas, operações não sujeitas.

As taxas de IVA portuguesas que aparecem nestes mapas são as três taxas continentais (6%, 13%, 23%) e as taxas regionais reduzidas da Madeira e dos Açores. O prompt tem de pedir que a coluna de taxa seja preservada como percentagem ou como número, não convertida em texto: 23% ou 0,23 valem em Excel; "23%" como texto bloqueia qualquer cálculo posterior. E quando o mapa apresenta operações isentas ou não sujeitas em linhas próprias com taxa zero, essas linhas devem manter-se identificadas, não ser absorvidas como movimentos a 0% indistintos.

Os mapas de IVA extraídos do balancete e dos mapas dedicados são frequentemente cruzados com o lado das faturas digitalizadas para fechar a declaração periódica. Quando esse trabalho é o destino da folha — em particular para empresas que processam volume significativo de faturas recebidas em formato PDF — compensa combinar este fluxo com o de preparar a declaração periódica de IVA a partir de faturas recebidas, que cobre o lado complementar do mesmo cruzamento.

Onde isto encaixa no fluxo contabilístico português

A folha que sai destas extrações não fica num vazio. Na rotina do contabilista português, é peça de um ou dois fluxos imediatamente adjacentes, e o nível de exigência das secções anteriores justifica-se precisamente pelo que vem a seguir.

O uso a jusante mais comum é a reconciliação. O extrato de conta de clientes ou de fornecedores extraído do PDF Primavera entra numa conferência contra o extrato bancário do mesmo período, normalmente para fechar contas correntes ou para identificar lançamentos por regularizar. Quando o lado bancário também só existe em PDF — extrato enviado pelo banco ou recuperado de um arquivo — o mesmo fluxo de extração aplica-se aos dois lados, e o trabalho passa a ser, na prática, converter extratos bancários em PDF para Excel e cruzar a folha resultante com o extrato Primavera. Os dois mapas têm armadilhas distintas (o bancário não tem cabeçalhos repetidos da mesma forma, mas tem outras particularidades), e quem trabalha os dois lados beneficia de pensar em ambos como peças do mesmo trabalho de reconciliação.

A montante, os lançamentos que aparecem no extrato Primavera têm origem em faturas que entraram no fluxo de contabilização — em muitas equipas, com validação de ATCUD e QR Code antes do registo no módulo de Contabilidade. Quem trabalha também o lado do intake pode reduzir significativamente o ruído que depois aparece no extrato fazendo essa validação a montante; o fluxo está coberto no artigo sobre como validar ATCUD e QR Code em faturas recebidas, e é a peça natural para fechar o ciclo entre o documento que chega e o lançamento que aparece no relatório Primavera meses depois.

Cada uma das exigências dos dois capítulos anteriores existe porque este trabalho a jusante não tolera falhar em silêncio: uma coluna de débito mal lida arruina a reconciliação sem que o total deixe de fechar, e uma vírgula decimal convertida em ponto pode esconder uma diferença de ordem de magnitude até à última semana do fecho.

Como tirar partido da extração por IA num pacote de relatórios Primavera

Quando o caminho 3 está escolhido, o que faz a diferença entre uma folha utilizável à primeira tentativa e várias rondas de correcção manual é a estrutura do prompt. Um prompt eficaz para um pacote de relatórios Primavera tem cinco peças, sempre na mesma ordem:

1. Finalidade declarada: para que vai a folha — reconciliação contra extrato bancário, auditoria, migração para outro sistema, análise de movimentos. A IA usa este contexto para decidir bem casos ambíguos.
2. Tipo de mapa em causa: extrato de conta de clientes, extrato de conta de fornecedores, balancete analítico, balancete sintético, razão geral, IVA recapitulativo. O nome correcto evita interpretações genéricas.
3. Lista dos campos a extrair, com o nome explícito da coluna desejada na folha: Conta, Descrição da conta, Data lançamento, Documento, Entidade, Débito, Crédito, Saldo, Centro de custo. Indicar o nome da coluna na folha tira ambiguidade ao mapeamento.
4. Formato de cada campo: data como DD-MM-YYYY, conta como texto, valores numéricos com vírgula decimal, taxa de IVA como percentagem nativa do Excel.
5. Regras de tratamento das particularidades do mapa: cabeçalhos repetidos, linhas de subtotal, continuidade do saldo, centros de custo. Esta é a parte que separa um prompt útil de um prompt genérico.

Algumas das regras úteis específicas do contexto Primavera, em formulações que costumam funcionar bem:

• "Não criar linhas de movimento a partir de linhas de subtotal por conta nem das linhas de subtotal por período. Marcar essas linhas com a coluna Tipo igual a Subtotal, ou excluir, conforme indicado."
• "Manter o saldo cumulativo na coluna Saldo entre páginas. Não recalcular a partir do zero quando o relatório muda de página."
• "Tratar 'data movimento' e 'data lançamento' como duas colunas distintas se ambas existirem no mapa. Não fundir."
• "Quando o número e a descrição da conta aparecem repetidos no topo de uma página de continuação, ignorar essa linha. Não criar registo de movimento a partir dela."

Antes de aplicar o prompt a um pacote de centenas de páginas, vale a pena fazer um teste sobre um único relatório representativo — um extrato típico, um balancete típico — e verificar três coisas na folha resultante: que o número de linhas bate com o número de movimentos do PDF original, que a soma de débitos iguala a soma de créditos onde se espera, e que a coluna de saldo termina no valor que aparece no fim do PDF. Quando estas três conferências passam, o prompt está afinado e pode ser aplicado a todo o pacote; quando alguma falha, a falha aponta directamente para a regra que precisa de ser reescrita, em vez de obrigar a uma revisão linha a linha.

O Invoice Data Extraction encaixa neste trabalho com algumas características práticas que importa conhecer. O mesmo prompt processa tanto um único relatório como pacotes grandes na mesma interface — até 6.000 ficheiros por lote, ou um único PDF de até 5.000 páginas — pelo que um pacote de relatórios mensais ou um arquivo histórico inteiro entra de uma só vez sem mudar a forma de trabalhar. O output sai em XLSX, CSV ou JSON, consoante o formato que o sistema de destino aceita. E os prompts que ficam afinados podem ser guardados na Biblioteca de Prompts e reutilizados sempre que o mesmo cliente, o mesmo tipo de mapa, ou a mesma rotina mensal voltarem a aparecer — o que torna o investimento de afinação amortizável ao longo do ano contabilístico.