Nota Prévia: Ao contrário do primeiro post sobre este tema, neste caso foi absolutamente impossível não tecer algumas considerações politicas sobre o tema do SAFT da contabilidade, mas fica complicado não o fazer quando a AT continua a insistir em não cumprir a lei e a criar regras que apenas complicam a vida dos profissionais da contabilidade
Quando falamos em datas, relacionadas com o ficheiro SAFT (da parte da contabilidade), importa desde logo enunciar que no ficheiro são incluídas 3 datas distintas, associadas aos movimentos contabilísticos:
(SystemEntryDate) – Data do registo contabilístico, que consiste na data e hora em que o registo contabilístico foi introduzido no sistema.
(GLPostingDate) – Data relevante para o registo contabilístico, determina em que mês contabilístico o registo foi considerado na contabilidade.
(TransactionDate) – Data do documento que serve de suporte ao registo contabilístico, deve coincidir com a data impressa no documento.
Enquanto as duas últimas, são introduzidas “manualmente” pelo utilizador, a primeira é introduzida automaticamente pelo sistema e inclusive em muitos softwares não é visível de forma direta pelo utilizador, não devendo nunca poder ser alterada por este.
Qual a razão da existência de 3 datas distintas, para o mesmo registo contabilístico??
Não podemos esquecer que o ficheiro SAFT é na sua essência um suporte à auditoria tributaria, assim sendo não bastaria incluir a data relevante para a contabilidade, pois certamente que uma auditoria não pode ser eficazmente efetuada se não for possível o cruzamento de dados, dai a necessidade da data do documento (associada p.e. à identificação do fornecedor), pois é necessário possibilitar ao auditor tributário validar se o nosso registo contabilístico corresponde a um documento efetivamente emitido pelo nosso fornecedor.
Sobre a SystemEntryDate falarei mais à frente.
Depois desta introdução analisemos alguns dos problemas relacionados com a questão das datas:
As datas e o registo por ordem cronológico
Segundo os normativos fiscais, os registos contabilísticos devem ser efetuados por ordem cronológica (o que não deixa desde logo de ser estranho serem os normativos fiscais a impor regras aos registos contabilísticos algo que as normas contabilísticas se abstém de fazer).
No entanto, quando estamos perante documentos emitidos por terceiros, logicamente a ordem cronológica tem de ser aferida em função da ordem em que recebemos os documentos e nunca pela ordem em que os mesmos são emitidos, pois caso contrário se por um qualquer motivo não recebêssemos um documento ficaríamos impedidos de proceder ao registo dos documentos seguintes, o que obviamente não faria qualquer sentido.
Assim, concretizando com um exemplo:
Fatura de fornecedor com data de 6/1/2019, recebida apenas em Junho, contabilizada com data de 30/6/2019 (GLPostingDate) sendo preenchido o campo (TransactionDate) com a data 06/01/2019.
Ainda que contabilizada depois de uma fatura com data de 07/06/2019, preenche os requisitos do registo por ordem cronológico.
Sendo de destacar que o que verdadeiramente importa, é que seja adequadamente preenchido o campo “TransactionDate”, algo que nos dias de hoje pela evolução dos softwares, que entre outras coisas permitem a integração através do E-fatura, tornou relativamente fácil e automático o adequado preenchimento dos referidos campos.
Systementrydate e os 90 dias
Prazo fiscais para registo das operações
Este será certamente um dos temas que mais preocupa os CC, pois a verdade é que a atual redação dos normativos fiscais (nomeadamente o número 2 do artigo 121º do RGIT), aliado a conhecida falta de bom senso da AT, é base suficiente para que essa preocupação exista.
Mas convém relembrar que o ficheiro SAFT é desde logo um ficheiro de auditoria (tributaria) e logicamente que esta data é importante para um auditor, pois certamente que um registo contabilístico que 6 meses depois de ser inserido foi alterado, merece um olhar particular do auditor.
Daí que, na minha opinião, o futuro para esta questão não passe, como alguns defendem pela eliminação deste campo, mas sim pela reformulação do referido artigo do RGIT, clarificando que a simples alteração de um registo, ou a sua gravação após o período de 90 dias não configura desde logo uma infração passível da aplicação de uma coima.
Essa deve ser a luta a travar, clarificar o número 2 do artigo 123º do RGIT clarificando que a coima nele referida apenas é aplicada pela inexistência de contabilidade e não por um mero registo ter sido efetuado após aquela data.
As datas e o envio do SAFT para pré-preencher a IES
Algumas validações que serão efetuadas:
1ª “GLPostingDate” – Obviamente que este campo apenas pode ter datas compreendida no período do SAFT enviado, facilmente se compreende que não é possível num ficheiro SAFT da contabilidade de 2020 existir um registo com data relevante para a contabilidade de 2021.
Esta seria a única validação que deveria ser feita em termos de datas face ao atual enquadramento legal, mas sabemos que a AT tem tendência a extravasar o que diz a lei e a incluir validações adicionais.
Inclusive quebrando a regra de não tecer comentários políticos sobre o processo do SAFT da contabilidade convém dizer que as validações adicionais que a AT pretende fazer sobre datas, são absolutamente ilegais no âmbito do envio do SAFT para pré-preenchimento da IES, e apenas devem ser efetuadas no âmbito de uma fiscalização, e o fato de a AT ter intenção de efetuar validações adicionais ainda que com o argumento que serão meros alertas é absolutamente inaceitável, pois neste processo não podem ser retiradas alertas sobre eventuais "problemas" com datas que no futuro eventualmente servirão de indicador de potenciais fiscalizações.
2ª “TransactionDate” – data do documento de suporte, não serão admitidas datas posteriores ao ano a que o SAFT diz respeito.
O que faz algum sentido, pois mesmo numa situação de um acréscimo, ainda que tenhamos já em nosso poder o documento (com data p.e. de janeiro do ano seguinte) a verdade é que a operação que estamos a registar contabilisticamente é a melhor estimativa possível para esse valor reportando a 31-12.
3º (SystemEntryDate) - O incumprimento dos 90 dias– Obviamente que aquando do envio do ficheiro SAFT para pré-preenchimento da IES, não poderá ser efetuado qualquer tipo de controle deste tipo pelo que terão que ser aceites todos os ficheiros com estas questões, o que não quer dizer que as mesmas não possam depois ter consequências no âmbito de uma futura inspeção tributaria.
Adicionalmente a AT projeta fazer outra validações, que além de ilegais, são na sua maioria absurdas.
Exemplo validar se o (SystemEntryDate) – data em que foi efetuado o registo é inferior quer ao GLPostingDate quer ao “TransactionDate”.
E fica a pergunta o quê que isso importa para pré-preencher a IES???
Sem falar que, em bom português, isso é uma imbecilidade, senão vejamos em janeiro a empresa paga um seguro referente ao ano inteiro, de forma a tornar a contabilidade num verdadeiro instrumento de gestão, o contabilista automaticamente faz o registo mensal dos gastos.
Em Janeiro faz movimentos com GLPostingDate de dezembro, segundo os senhores da AT isso será um erro que obstará ao envio do SAFT.
Repito este género de validações, que até podem ser compreensíveis no âmbito de uma fiscalização tributária, onde pretendemos selecionar os potenciais registos que devem merecer a nossa atenção são absolutamente desnecessários e, portanto, ilegais no âmbito de envio do SAFT para pré-preenchimento da IES.
Deixo um conselho aos senhores da AT limitem-se ao que diz a lei e deixem a contabilidade para os Contabilistas.
