Source: http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/questoes_frequentes/Pages/faqs-00276.aspx
Timestamp: 2019-04-24 08:52:28+00:00

Document:
Outras Obrigações > SAF-T (PT) > Questões Técnicas
01-2733 O que é o ficheiro de SAF-T(PT)?
SAF-T (PT) (Standard Audit File for Tax Purposes – Portuguese version) é um ficheiro normalizado (em formato XML) com o objetivo de permitir uma exportação fácil, em qualquer altura, de um conjunto predefinido de registos contabilísticos e de faturação ou equiparados, num formato legível e comum, independente do programa utilizado, sem afetar a estrutura interna da base de dados do programa ou a sua funcionalidade. A adoção deste modelo proporciona às empresas uma ferramenta que permite satisfazer os requisitos de obtenção de informação dos serviços de inspeção, simplificando procedimentos e impulsionando a utilização de novas tecnologias. A geração do ficheiro pelos sistemas de informação abrange sempre um determinado período anual de tributação, total ou parcial, desde o início desse período até ao seu termo ou à data da geração se anterior estando vedada a existência de funcionalidades que permitam ao utilizador escolher documentos, séries ou tipo de documentos a exportar para o SAF-T (PT).
02-2734 Quais são as vantagens do SAF-T (PT) e a quem se destina?
O ficheiro SAF-T (PT) destina-se a facilitar a recolha, em formato eletrónico, dos dados fiscais relevantes dos contribuintes, por parte dos inspetores/auditores tributários, enquanto suporte das suas declarações fiscais e/ou para a análise dos registos contabilísticos ou de outros com relevância fiscal e ainda para o cumprimento de obrigações declarativas que o exijam.
03-2736 Existe alguma ferramenta para validar a coerência dos dados exportados no ficheiro SAF-T (PT)?
O SAF-T (PT) constitui uma forma de representar os dados existentes no repositório de dados. Não existe uma ferramenta oficial de validação pelo que a coerência dos dados deve ser assegurada pela aplicação que os criou e os exporta. A exportação dos dados não pode alterar ou excluir os registos existentes na base de dados – vide alínea a) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
04-2737 Existe algum ficheiro de exemplo ou validador para aferir estruturalmente o ficheiro SAF-T (PT)? Onde posso encontrar a estrutura de dados do ficheiro (xsd)?
Existe um ficheiro de exemplo do SAF-T (PT) em formato XML, em http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/CertificacaoSoftware.htm. A ferramenta de validação estrutural do ficheiro encontra-se em http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/NEWS_SAF-T_PT.htm onde igualmente se pode consultar a estrutura de dados - vide alínea b) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
05-2738 É possível adquirir uma aplicação que leia o repositório de dados da minha aplicação com o objetivo de gerar o SAF-T (PT) ou integrar os seus dados numa outra com esse objetivo?
Não. As aplicações de contabilidade e/ou faturação ou equiparadas devem, elas próprias, efetuar a exportação dos registos das bases de dados que produzam.
É possível efetuar a integração dos dados de uma aplicação (integrada) numa outra (integradora) e nesta última exportar um SAF-T (PT) com os dados de ambas as aplicações. Contudo, a aplicação integrada terá sempre que ter capacidade de exportar o seu próprio ficheiro - vide alíneas a) e f) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
06-2739 No Anexo I à Portaria n.º 302/2016, de 02 de dezembro (alterou a Portaria n.º 321-A/2007, de 26 de março), menciona-se a existência de campos “obrigatórios” e outros sem essa menção. Significa isto que compete ao utilizador ou ao produtor de software definir se estes campos “não obrigatórios” são exportados?
Compete ao produtor de software gerar o ficheiro de SAF-T (PT) com a estrutura prevista na Portaria n.º 302/2016, de 02 de dezembro, para todos os campos obrigatórios, com a informação existente na aplicação e, ainda, para todos os outros campos sem essa menção, pertencentes à mesma estrutura, para os quais, no repositório de dados, exista informação para o seu preenchimento. Ao utilizador deve estar vedada qualquer opção sobre se uma determinada operação ou registo deve ser incluída ou excluída no ficheiro de SAF-T (PT).
Nem todos os campos são considerados de geração obrigatória no esquema de validação, uma vez que existem alguns de escolha alternativa e outros cuja geração poderá não fazer sentido, em determinado contexto. Por exemplo, se não tiver sido atribuído qualquer desconto, não será pertinente exigir-se o preenchimento do campo “Montante do desconto da linha” (SettlementAmount).
De igual modo, não devem ser gerados os campos não referenciados como obrigatórios sempre que no repositório de dados não exista informação para o seu preenchimento. Com esse procedimento, diminui-se o tempo despendido na geração do ficheiro bem como a sua dimensão. Acresce que, no SAF-T (PT), não podem existir campos vazios sob pena de violação do esquema de validação [ficheiro xsd associado à produção do SAF-T (PT])] - vide alíneas b e d) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
07-2740 É possível exportar o SAF-T (PT) por períodos inferiores ao ano fiscal?
O SAF-T (PT), regra geral, abrange um exercício fiscal completo. No que concerne à geração do SAF-T (PT) com os registos contabilísticos terá, obrigatoriamente, que contemplar o exercício fiscal completo num único ficheiro. Excecionalmente, e apenas por motivos técnicos associados à dimensão das tabelas dos documentos comerciais, é possível gerar o ficheiro SAF-T (PT) de faturação por períodos mensais completos - vide alíneas c), e) e i) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
08-2741 É possível mudar de aplicação informática de contabilidade num momento não coincidente com o início do ano fiscal e iniciar a utilização do novo programa realizando apenas uma migração de saldos?
O SAF-T (PT) de contabilidade tem de ser gerado num único ficheiro. A nova aplicação de contabilidade terá que assegurar a geração do SAF-T (PT) com os registos efetuados na anterior aplicação ainda que reportados às novas referências e nomenclaturas acrescidos dos registos após a sua entrada em funcionamento. A transição dos registos para um novo programa de contabilidade num momento não coincidente com o início do ano fiscal não pode efetuar-se apenas com a migração de saldos.
A aplicação de contabilidade substituída também terá que assegurar a geração do SAF-T (PT) de contabilidade até ao momento da sua descontinuação - vide alíneas a), c) e e) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
09-2742 A Portaria n.º 302/2016, de 02 de dezembro (alterou a Portaria n.º 321-A/2007, de 26 de março) instituiu a estrutura com a versão 1.04_01. Em que formato devem ser exportados os registos de anos anteriores para o SAF-T (PT)?
A geração do SAF-T (PT) na versão 1.04_01 resultante da publicação da Portaria n.º 302/2016, de 02 de dezembro, cuja data de entrada em vigor é 2017-07-01, é aplicável exclusivamente aos registos produzidos a partir dessa data, com exceção dos movimentos contabilísticos, que deverão respeitar as respetivas taxonomias desde 2017-01-01. O SAF-T (PT) para registos anteriores a 2017-07-01 deve ser gerado com a estrutura 1.03_01, sem prejuízo de, opcionalmente, poder ser utilizada a versão 1.04_01.
10-2743 Como devem ser tratados os acordos de autofaturação com fornecedores, no ficheiro SAF-T (PT), relativamente às faturas emitidas nesse âmbito?
O SAF-T (PT) não contempla informação relativa a “Documentos comerciais a fornecedores” pelo que, no SAF-T (PT) do adquirente dos bens ou serviços, esses documentos não devem constar.
Contudo, terá de ser disponibilizado, por cada fornecedor com autofaturas emitidas, um ficheiro SAF-T (PT), com o campo “Sistema contabilístico” (TaxAccountingBasis) do tipo "S", sempre que estes o solicitem.
O ficheiro de autofaturação possui a seguinte estrutura:
Tabela Header
• Identificação do fornecedor dos bens objeto de acordo de autofaturação (campos 1.2 a 1.8);
• TaxAccountingBasis preenchido com o código “S”;
• Identificação do software que produziu o SAF-T (PT) na posse do cliente (campos 1.14 a 1.17).
Tabela Customer
• Cliente autofaturador;
• SelfBillingIndicator preenchido com “1”;
Tabela SalesInvoices
• InvoiceStatus preenchido com “S”;
• SelfBillingIndicator preenchido com “1”.
Desta forma garante-se que o cabeçalho identifica o sujeito passivo fornecedor dos bens ou que prestou os serviços - vide alínea g) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
11-2744 Qual a codificação (encoding) a utilizar na geração do SAF-T (PT)?
O encoding a utilizar é o Windows-1252, definido no xsd de validação da estrutura e conteúdo restrito de campos - vide alínea b) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
12-2745 Quais são os campos relativos ao produtor de software e quais são os campos alusivos ao sujeito passivo no cabeçalho (Header) do SAF-T (PT)?
Somente os campos “Identificação fiscal da entidade produtora do software” (ProductCompanyTaxID), “Número do certificado atribuído ao software” (SoftwareCertificateNumber), “Nome da aplicação” (ProductID) e “Versão da aplicação” (ProductVersion) são referentes ao produtor de software ou à aplicação informática. Os restantes campos são respeitantes ao sujeito passivo - vide Tabela 1 – “Cabeçalho” (Header) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
13-2746 Como deve ser exportada uma fatura emitida em moeda estrangeira no SAF-T (PT)?
A moeda de geração do SAF-T (PT) é o Euro [campo “Código de moeda” (CurrencyCode)], pelo que se deve proceder à conversão das unidades monetárias estrangeiras em Euros em qualquer das tabelas que devam constar no ficheiro. No caso particular dos documentos que devam constar em qualquer das tabelas subordinadas da estrutura “Documentos comerciais” (SourceDocuments), apesar do valor ser expresso em euros, é ainda exigível a geração do elemento complexo “Moeda” (Currency) com a indicação do código ISO 4217 da moeda estrangeira e montante total com impostos nessa moeda, tal como consta no documento emitido.
14-2747 Quais os clientes, fornecedores, produtos e serviços e taxas de imposto que devem constar nas respetivas tabelas da estrutura Masterfiles? Todos ou somente os que apresentem movimentos no período de tributação a que o ficheiro de SAF-T (PT) se refere?
As tabelas subordinadas da MasterFiles devem conter a informação existente no repositório de dados dos elementos que foram objeto de movimentação no período de tributação a que o ficheiro se refere.
Estas tabelas devem conter a informação existente no repositório de dados nas respetivas fichas acrescidas dos dados provenientes dos movimentos contabilísticos ou da documentação emitida que deva constar do ficheiro SAF-T (PT). Assim, se existisse, por exemplo, um cliente identificado num documento que não constasse numa ficha de clientes da aplicação, deveria ser criado este cliente na tabela de clientes do SAF-T (PT). De igual modo, se fosse aplicada uma taxa de imposto incorreta deveria ser criada uma entrada na tabela de impostos com a referida taxa de imposto que tivesse sido utilizada, ainda que indevidamente, nesse período de tributação - vide tabelas 2.2, 2.3, 2.4 e 2.5 das “Tabelas mestres” (MasterFiles) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
15-2748 De acordo com o meu sector de atividade, utilizo um referencial de classificação de contas distinto do Sistema de Normalização Contabilística e das Normas Internacionais de Contabilidade, a minha aplicação informática de contabilidade terá que gerar o SAF-T (PT) de contabilidade? Como preencho os campos “Referencial de classificação de contas” (TaxonomyReference) e “Código de classificação da conta” (TaxonomyCode)?
As aplicações informáticas de contabilidade utilizadas pelas entidades comerciais ou civis sob forma comercial, as cooperativas, as empresas públicas e as demais entidades que exerçam, a título principal, uma atividade comercial, industrial ou agrícola, com sede ou direção efetiva em território português, bem como as entidades que, embora não tendo sede nem direção efetiva naquele território, aí possuam estabelecimento estável, têm de gerar o SAF-T (PT).
Na situação descrita, o campo “Referencial de classificação de contas” (TaxonomyReference) deve ser preenchido com “O” e campo “Código de classificação da conta” (TaxonomyCode) das contas de movimento do tipo “GM” deve ser preenchido com “1” – vide 2.1 - “Tabela de código de contas” (GeneralLedgerAccounts) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
16-2749 A aplicação está configurada de modo a permitir a utilização de contas e a realização de movimentos relativos a contabilidade analítica. Essas contas e registos devem constar no SAF-T (PT)?
As contas e movimentos relativos à contabilidade analítica devem ser exportados para o ficheiro SAF-T (PT) - vide 2.1 - “Tabela de código de contas” (GeneralLedgerAccounts) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
17-2799 Quem está obrigado a produzir o SAF-T (PT)?
São obrigados a produzir o SAF-T (PT) os sujeitos passivos que exerçam, a título principal, atividade comercial, industrial ou agrícola. Esta obrigação estende-se ainda aos sujeitos passivos que utilizem programa de faturação certificado.
18-2750 No preenchimento do campo “Código da conta” (AccountID) terá que se utilizar a codificação existente no plano de contas SNC?
A codificação a exportar para o campo “Código da conta” (AccountID) é a que se encontrar definida pelo utilizador na aplicação de contabilidade - vide 2.1 - “Tabela de código de contas” (GeneralLedgerAccounts) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
Não devem ser exportados os registos das classes de contas independentemente do referencial de classificação de contas utilizado.
19-2751 Como preencho o campo “Código de classificação da conta” (TaxonomyCode)? Este campo deve ser preenchido em todas as contas existentes no plano de contas utilizado?
O campo “Código de classificação da conta” (TaxonomyCode) é unicamente preenchido nas contas cuja “ Categoria e tipo de conta” (GroupingCategory) se encontrar definido com “GM”. De acordo com o referencial aposto no campo “Referencial de classificação de contas” (TaxonomyReference) - “S” e “N” para SNC base e NIC, respetivamente ou “M” para SNC Microentidades - utilizar-se-á os valores constantes do Anexo II para os dois primeiros ou do Anexo III para o último – vide 2.1 - “Tabela de código de contas” (GeneralLedgerAccounts) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
20-2752 De acordo com o Anexo II da Portaria 302/2016, de 02 de dezembro, a conta SNC 41 está associada às taxonomias 236, 237 ou 238 e a conta SNC 416 está associada à taxonomia 235. Por exemplo, na conta 416 - Amortizações acumuladas (subsidiárias), a subconta “participações” (4161) pode estar associada à taxonomia 235 e a subconta “goodwill” (4162) estar associada à taxonomia 236?
Nas contas que não se encontrem definidas no plano de contas SNC, o “Código de classificação da conta” (TaxonomyCode) é atribuído de acordo com a coluna da “Descrição completa” existente nos anexos relativos às taxonomias. Por exemplo, para a taxonomia 235, devem ser consideradas as subcontas da 4158 e qualquer uma das consideradas em “Observações” (4152, 4153, 4154, 4155, 4156, 4157, 4158, 4159, 416, 417 e 418 que não sejam amortizações de Goodwill) que contenham “Investimentos financeiros - Outros investimentos financeiros – Outros” e na taxonomia 236 devem ser consideradas as subcontas da 41 que contenham “Investimentos financeiros - Amortizações acumuladas - Investimentos em subsidiárias - Participações de capital — método da equivalência patrimonial – Goodwill”.
Este entendimento deve percorrer todos os anexos de taxonomia.
21-2753 De acordo com as notas técnicas ao campo CustomerID da tabela 2.2. – “Tabela de clientes” (Customer) deve ser criado um cliente genérico designado como “Consumidor final”. Isto significa que todos os documentos comerciais emitidos a clientes que não indiquem o seu NIF são registadas sob este CustomerID?
Com o CustomerID que referencia o “Consumidor final” são registadas as transmissões de bens ou prestações de serviços aos clientes que não providenciem qualquer elemento de identificação. Se nos documentos comerciais emitidos foram averbados quaisquer elementos identificativos, por exemplo nome ou morada, devem ser criados CustomerID diferenciados de acordo com essas diferentes identificações existentes nos documentos. O NIF do consumidor final deve estar conforme com as notas técnicas do campo CustomerTaxID - vide 2.2. “Tabela de clientes” (Customer) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
22-2754 Na base de dados de fornecedores e de clientes existem vários locais de carga e descarga por entidade, como exportar essa informação?
No atual esquema de validação é possível gerar tantas estruturas “Morada de expedição” (ShipToAddress) e “Morada da expedição” (ShipFromAddress) quantas venham a ser necessárias nas respetivas tabelas de clientes e fornecedores - vide alínea b) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
23-2755 Como exportar a informação relativa a uma ficha de cliente, para o qual foram emitidas exclusivamente faturas simplificadas, cujo único dado disponível é o respetivo NIF, considerando que a estrutura de dados do SAF-T (PT) exige o preenchimento de diversos campos tais como o nome e a morada?
Nos campos obrigatórios cuja informação não exista em base de dados histórica ou na situação exposta na questão, o seu conteúdo deve ser preenchido com uma expressão que indicie a sua inexistência, por ex. "Omisso". Deverá ser utilizada a expressão "Desconhecido" nas operações realizadas com “Consumidor final”. Relativamente ao campo “País” (Country) deve ser utilizado o código ISO do país ou a expressão "Desconhecido” - vide 2.2. “Tabela de clientes” (Customer) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
24-2756 Em determinadas operações tenho a necessidade de averbar o Código de Nomenclatura Combinada da União Europeia e o código ONU para produtos perigosos que identifico no campo observações das faturas que emito através do meu programa de faturação. Porém, verifico que na estrutura de SAF-T (PT) foram criados os campos “Código de Nomenclatura Combinada” (CNCode) e “Número ONU” (UNNumber). Em virtude de não possuir local próprio para identificar esses dados posso continuar com o procedimento descrito?
Se determinado dado constar da impressão do documento e, simultaneamente, existir um campo específico na estrutura do SAF-T (PT) para o albergar, obrigatoriamente essa informação tem de constar da base de dados. A aplicação informática de faturação terá que ser atualizada de modo a acolher essa informação e exportá-la para o ficheiro sempre que necessário – vide alínea d) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
25-2757 Nas notas técnicas do elemento “Período contabilístico” (Period) da tabela 3 – Movimentos contabilísticos (GeneralLedgerEntries) é indicado que deve referir o mês de 1 a 12 e que pode ser ainda 13, 14, 15 e 16. Anualmente é necessário efetuar os lançamentos contabilísticos de abertura, o que em alguns sistemas de informação é efetuado no mês zero (0). Neste elemento podem aparecer movimentos no mês 0?
Não. Os valores correspondentes aos movimentos de abertura (mês 0) são exclusivamente mencionados na tabela 2.1 – “Tabela de código de contas” (GeneralLedgerAccounts), nos campos “Saldo de abertura a débito da conta do plano de contas” (OpeningDebitBalance) e “Saldo de abertura a crédito da conta do plano de contas” (OpeningCreditBalance) - vide tabela 3. “Movimentos contabilísticos” (GeneralLedgerEntries) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
26-2758 Quando é registado um movimento contabilístico incorreto, a aplicação permite um lançamento negativo na respetiva conta para o corrigir. Todavia, o esquema de validação associado ao SAF-T (PT), devolve uma mensagem de erro. Como exportar essa informação?
Os movimentos de estorno devem ser registados inversamente ao registo inicial na própria conta a corrigir, a débito ou a crédito, sendo que a própria aplicação informática deve acautelar esta situação.
Não tendo sido utilizado o procedimento mais correto e com o objetivo de salvaguardar o histórico dos registos, a representação dos montantes a negativo passa pela exportação a débito ou a crédito inversa àquela em que os movimentos contabilísticos se encontram averbados - vide alínea l) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
27-2759 Como devem ser exportados no ficheiro de SAF-T (PT), os respetivos campos “Período contabilístico” (Period) das tabelas: 3 — “Movimentos contabilísticos” (GeneralLedgerEntries) e 4 — “Documentos comerciais” (SourceDocuments), nos casos em que o ano fiscal não coincide com o ano civil, por exemplo, com início a 01 de dezembro e fim a 30 de novembro do ano seguinte?
Os conteúdos desses campos devem ser preenchidos de acordo com os meses dentro do ano fiscal. No caso exposto, o campo Period do 1º mês (dezembro do ano n) é preenchido com 1, no 2º mês (janeiro do ano seguinte) com 2 e assim sucessivamente - vide notas técnicas aos campos “Período contabilístico” (Period) definidos no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
28-2760 Como referenciar vários documentos pertencentes a diversos clientes ou fornecedores num único movimento contabilístico? Não é possível a identificação do CustomerID e do SupplierID ao nível da linha do movimento?
Não é possível efetuar o movimento descrito. A relação entre a emissão de qualquer documento comercial e a sua contabilização corresponde a um movimento unívoco.
29-2761 Em qual dos campos da tabela 3 – “Movimentos contabilísticos” (GeneralLedgerEntries) deve ser averbada a data relevante para efeitos contabilísticos?
Para efeitos de geração do SAF-T (PT), a data de movimento contabilístico deve ser averbada no campo “Data do movimento contabilístico” (GLPostingDate). No campo “ Data do registo do documento contabilístico” (SystemEntryDate) deve constar a data e hora do sistema informático em que se procedeu à gravação do registo ao segundo e no campo “Data do documento” (TransactionDate) deve constar a data do documento que dá suporte ao lançamento contabilístico - vide notas técnicas aos campos “Data do movimento contabilístico” (GLPostingDate) e “Data do documento” (TransactionDate) da tabela 3. “Movimentos contabilísticos” (GeneralLedgerEntries) definida no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
30-2762 Na estrutura da tabela 3 – “Movimentos contabilísticos” (GeneralLedgerEntries) verifica-se a existência de “Linha a débito” (DebitLine) e “Linha a crédito” (CreditLine). É obrigatório que por cada movimento contabilístico existam lançamentos a débito e a crédito? Em caso afirmativo, têm que ser efetuados todos os lançamentos a débito e posteriormente todos os lançamentos a crédito?
No método digráfico (ou método das partidas dobradas), cada facto patrimonial origina um registo em duas ou mais contas de modo que o valor de cada débito ou débitos corresponda um ou mais créditos de igual montante. Na tabela 3.- Movimentos contabilísticos (GeneralLedgerEntries) é possível criar múltiplas “Linha a débito” (DebitLine) e “Linha a crédito” (CreditLine) sem qualquer ordem predefinida.
31-2763 Não existe redundância na informação dos campos “Data e hora do estado atual do documento” (InvoiceStatusDate, MovementSatusDate, WorkStatusDate, PaymentSatusDate) e “Data de gravação do documento” (SystemEntryDate)?
Não existe redundância. A “Data de gravação do documento” é a data de registo do documento na aplicação, as outras datas referidas registam a última alteração efetuada, na aplicação, ao estado do documento. O conteúdo de ambos os campos coincide apenas nos documentos que não sofrerem alteração do seu estado após o seu registo na aplicação. Se ocorrer qualquer alteração do seu estado, por exemplo, se o documento for anulado, a data e hora dessa alteração tem que ficar registada no campo “Data e hora do estado atual do documento”, bem como a identificação do utilizador que procedeu à sua anulação (SourceID). Deve ser atualizado o campo “Motivo de alteração de estado” (Reason) no caso de ser identificado o motivo que originou a alteração de estado do documento - vide notas técnicas aos campos SystemEntryDate, InvoiceStatusDate, MovementStatusDate, WorkStatusDate e PaymentStatusDate das tabelas 4 – “Documentos comerciais” (SourceDocuments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
32-2764 Quais são os casos em que um documento é emitido com o valor do campo “Estado atual do documento” = “N” e assim deve constar no SAF-T (PT)? Quando deverão ser utilizados os restantes estados “A” e “F”?
Normalmente os documentos são criados com o estado "N", o que significa que se encontram vigentes. O estado “N” pode, posteriormente ser modificado para outros estados, de acordo com o seguinte:
- Adquire o estado "A" (anulado) se o documento for anulado pelo facto de ter sido invalidamente emitido. Note-se que nesta situação o original do documento em circunstância alguma pode ficar na posse do cliente e deve ser mantido no arquivo do emitente. Acresce que, uma 2ª via do documento após a anulação, deve indicar que se encontra anulado.
- Passa a ter o estado "F" quando, para esse documento, é emitida 2.ª fatura para a mesma operação tributável, por exemplo, fatura relativa a uma operação já registada numa fatura simplificada. Este estado foi criado com o objetivo de evitar a duplicação de proveitos ou para indicar que foi emitida fatura. O estado "F" num documento de conferência de mercadorias ou de prestação de serviços (WorkingDocument) ou num documento de transporte (StockMovement) indica que foi emitida a respetiva fatura - vide notas técnicas aos campos InvoiceStatus, MovementStatus, WorkStatus e PaymentStatus das tabelas 4 – “Documentos comerciais” (SourceDocuments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
33-2766 Na atividade seguradora é usual emitir um aviso de pagamento de prémio (também conhecido como “Aviso/Recibo de Prémio”) ao cliente com um período de antecedência em relação à data de pagamento da respetiva apólice. Em que tabela do SAF-T (PT) deve constar esse documento?
Caso a entidade do setor segurador emita ou deva emitir fatura e emita também avisos de pagamento de prémio, estes avisos devem ser exportados na tabela 4.3 WorkingDocuments com o “Tipo de documento” (WorkType) “RP” e devem fazer referência ao n.º da apólice que lhes está subjacente na estrutura “Referência ao documento de origem” (OrderReferences).
As faturas devem constar na tabela “Documentos comerciais a clientes” (SalesInvoices) com o “Tipo de documento” (InvoiceType) “FT” ou “FR” (caso atue simultaneamente como recibo) e os avisos de pagamento de prémio que lhe estiveram na origem devem ser identificados na estrutura “Referência ao documento de origem” (OrderReferences).
Após a emissão da fatura, os avisos de cobrança (avisos/recibos de prémio) registados na tabela “Documentos de conferência de mercadorias ou de prestação de serviços” (WorkingDocuments) devem exibir no respetivo campo “Estado atual do documento” (WorkStatus) o valor “F”.
Se a entidade prestadora de serviços de seguro não emitir fatura no âmbito da sua atividade, os avisos de pagamento devem constar na tabela “Documentos comerciais a clientes” (SalesInvoices) com o “Tipo de documento” (InvoiceType) “RP”.
Em todas as situações acima descritas deve ser gerada a estrutura Payment em cada documento que deva constar na tabela “Documentos comerciais a clientes” (SalesInvoices) ou emitir o respetivo recibo, a constar na tabela “Documentos de recibos emitidos” (Payments), identificando a fatura ou o aviso de pagamento, conforme o caso, na “Referência ao documento de origem” (SourceDocumentID).
34-2767 Como devem ser exportados no SAF-T (PT), os diferentes momentos relevantes no âmbito dos serviços prestados no setor segurador, uma vez que, na celebração de contratos de seguro existem: • a emissão do aviso de pagamento de prémio ao cliente com um período de antecedência em relação à data de pagamento do respetivo prémio; • a data limite de pagamento; • a data de recebimento; • o período de cobertura do risco.
Devido à especificidade inerente à atividade exercida, dever-se-á considerar o seguinte:
Com emissão de fatura
Sem emissão de fatura
Tabela de registo
WorkingDocuments
SalesInvoices
Aviso de pagamento de prémio (WorkType = “RP”)
Fatura (InvoiceType = “FT” ou “FR”)
Aviso de pagamento de prémio (InvoiceType =“RP”)
“Data do documento” (WorkDate)
“Data do documento de venda” (InvoiceDate)
“Acordos de pagamento” (PaymentTerms)
Data de recebimento
“Data do pagamento” (PaymentDate)
Data de início do período de cobertura
“Data de receção” (…/ShipFrom/DeliveryDate)
Data de fim do período de cobertura
“Data da entrega” (…/ShipTo/DeliveryDate)
Por outro lado, caso exista necessidade de corrigir/estornar um ou vários documentos já pagos pelo cliente, dever-se-á ter em conta o seguinte:
Aviso de Estorno
(WorkType “RE”) (*)
(InvoiceType “NC”)
(InvoiceType “RE”)
Data do pagamento
Data de início do período de cobertura a que se refere a correção
Data de fim do período de cobertura a que se refere a correção
(*) Este documento somente será gerado caso haja necessidade no âmbito do ciclo operacional da aplicação
As soluções acima não prejudicam a possibilidade da seguradora poder adotar, para parte ou para a totalidade do seu negócio, um processo de faturação idêntico ao dos restantes setores de atividade sem a prévia emissão de aviso de pagamento de prémio ou de aviso de estorno.
35-2798 Como exportar a informação relativa aos documentos anulados? Exportar os documentos sem linhas ou exportar integralmente com os valores das linhas a zero?
Os documentos devem ser exportados integralmente sem qualquer modificação, com exceção do conteúdo relativo à “Situação do documento” (DocumentStatus), que deve evidenciar o estado atual do documento como anulado (“A”), a data/hora de anulação, a identificação do utilizador que procedeu à anulação e eventualmente o motivo da sua anulação integrada - vide notas técnicas à estrutura “Situação do documento” (DocumentStatus) das tabelas 4 – “Documentos comerciais” (SourceDocuments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
36-2765 Quando é que o campo “Estado atual do documento” (InvoiceStatus, MovementStatus) na emissão de documentos pode assumir valores ”S” ou “R”?
Nos casos de autofaturação, no âmbito de um acordo escrito, em que o documento é emitido pelo adquirente, o campo “Estado atual do documento” (InvoiceStatus), no momento de emissão, assume o valor "S".
O campo “Estado atual do documento” (InvoiceStatus, MovementStatus) exibe o valor "R" nos documentos gerados na aplicação que constituem resumos de outros emitidos em outras aplicações.
Com efeito, existem vários ERP's que, para efetuarem a gestão de existências, a contabilização das vendas e exercerem outras funções de gestão, necessitam que as faturas, os documentos retificativos de faturas ou os documentos de movimentação de mercadorias constem no sistema para que os procedimentos sejam automaticamente efetuados mas, normalmente, apenas necessitam das quantidades vendidas e dos montantes apurados, não sendo o objetivo a replicação dos dados das vendas documento a documento, o que apenas provocaria redundância de dados, não trazendo mais-valia ao utilizador.
Como as aplicações não podem ter funcionalidades que permitam ao utilizador escolher documentos, séries ou tipo de documentos a exportar para o SAF-T (PT), foi, por isso, prevista a criação de um documento não válido para efeitos fiscais que funciona como um resumo das vendas do sistema integrado. Este documento não pode ser impresso em momento algum, sob pena de ser considerado um documento válido e, por conseguinte, produzir a duplicação de proveitos e duplicação de IVA liquidado.
Não existe desta forma a duplicação de proveitos, pois os SAF-T (PT) das aplicações integradas continuam a ser necessariamente gerados. Mas, por outro lado, as séries dos documentos-resumo na aplicação integradora estão identificadas com o estado "R", para além de referenciarem na estrutura “Referência ao documento de origem” (OrderReferences) (atualmente podem ser gerados múltiplas referências) o primeiro e último documento de cada série integrada - vide notas técnicas aos campos InvoiceStatus e MovementStatus, das tabelas 4 – “Documentos comerciais” (SourceDocuments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
37-2768 A aplicação mantém os registos referentes à emissão de notas de crédito e descontos com valores negativos na base de dados. O SAF-T (PT) não admite a exportação de valores negativos. Como evidenciar esta informação?
Os registos são exportados como valores positivos. Considerando que se trata de um registo de uma nota de crédito, o campo a utilizar nas linhas do documento é o “Valor a débito” (DebitAmount) por se tratar de uma regularização. Os descontos são exportados em valor absoluto no campo SettlementAmount também existente ao nível da linha do SAF-T (PT) - vide alíneas b) e l) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
38-2769 Como deve ser exportado o campo “Indicador de regime de IVA de caixa (CashVATSchemeIndicator) nas entidades que aderiram ao Regime de IVA de Caixa?
Todos os sujeitos passivos que aderiram ao Regime de IVA de Caixa (RIC) necessitarão de séries de faturas e documentos retificativos de fatura no âmbito desse regime e outras séries para as operações tributáveis que não podem usufruir desse regime, por exemplo, vendas a consumidores finais, transmissões intracomunitárias, etc. A distinção destas séries é realizada no campo “Indicador de Regime de IVA de Caixa” (CashVATSchemeIndicator).
As operações realizadas por sujeitos passivos que aderiram ao RIC e que são passíveis de usufruir desse regime exibem o campo CashVATSchemeIndicator = 1.
As operações realizadas por sujeitos passivos que aderiram ao RIC mas que não são passíveis de usufruir desse regime, ou aquelas realizadas por sujeitos passivos não aderentes, terão o campo CashVATSchemeIndicator = 0.
39-2770 No ficheiro de SAF-T (PT) a emissão de uma fatura para cobrir despesas incorridas em nome e por conta de outrem, considera-se como sendo autofaturação ou como sendo faturação em nome e por conta de terceiros?
Nenhuma das situações. De facto, a autofaturação, a faturação emitida por terceiros e o ressarcimento de despesas realizadas em nome e por conta de terceiros são situações distintas.
A faturação em nome e por conta de terceiros (TaxAccountingBasis = “E”) refere-se às situações em que uma entidade é contratada ou autorizada pelo fornecedor dos bens/prestador de serviços para emitir a sua faturação aos adquirentes dos bens ou das prestações de serviços. A fatura continua a ser do fornecedor, apenas é emitida por outrem (campo ThirdPartiesBillingIndicator = 1).
Aqui não se incluem as despesas incorridas por conta de outrem. Uma fatura emitida por despesas pagas em nome e por conta do cliente, não deixa de ser uma fatura "normal" emitida pelo prestador de serviços. Na verdade, ele possui um conjunto de documentos que suportam essas despesas em seu nome e não em nome do cliente. Ora sendo essas importâncias consideradas como custo (pois estão em seu nome embora devam ser suportadas pelo cliente), a emissão de fatura compensa esta situação ao ser considerada como proveito e, simultaneamente, ressarce-se das importâncias pagas.
As situações de autofaturação (TaxAccountingBasis = “S”) ocorrem quando o adquirente substitui o fornecedor na emissão das faturas. É necessária a existência de um acordo escrito e os documentos emitidos exibirão o campo SelfBillingIndicator = 1 e o seu estado (InvoiceStatus) será "S".
O documento é do tipo fatura, embora nela deva constar a expressão "autofaturação", devendo ainda identificar claramente quem é o adquirente (cliente autofaturador) e o fornecedor (autofaturado).
40-2771 Nas linhas dos documentos comerciais surgem dois campos distintos denominados “Descrição do produto ou serviço” (ProductDescription) e “Descrição da linha” (Description). Qual a diferença?
O campo ProductDescription refere-se à descrição do produto ou serviço na respetiva tabela de produtos, i.e., a denominação usual dos bens ou dos serviços prestados, com especificação dos elementos necessários à determinação da taxa de imposto aplicável. É inalterável após a sua utilização para efeitos comerciais e deve constar na impressão do documento. Contudo, essa informação pode ser complementada com alguma caraterística que, não sendo suficiente para ocorrer a necessidade de gerar um novo “Identificador de produto ou serviço” (ProductCode), complementa a descrição do produto, por exemplo, a cor ou tamanho e que consta no descritivo das linhas impressas nos documentos. Essa informação complementar deve constar no campo Description isoladamente ou concatenada com o teor do campo ProductDescription.
41-2772 Qual é a diferença dos campos “Data do documento de venda” (InvoiceDate) e “Data de envio da mercadoria ou prestação do serviço” (TaxPointDate)? A informação não coincide?
O conteúdo de ambos os campos coincide quando a emissão da fatura e a data de envio dos bens transmitidos ou dos serviços prestados é a mesma ou a emissão da fatura precede o envio dos bens transmitidos ou a prestação dos serviços. Se os bens ou os serviços foram prestados em data anterior, o campo TaxPointDate deve evidenciar essa data.
42-2773 Como evidenciar no campo “Referência ao documento de origem” (OrderReferences) a faturação global, em que os bens são entregues mediante várias guias de remessa, sendo que a fatura é emitida agregada por produto. Devo exportar a informação de cada guia, no campo “Número do documento de origem” (OriginatingON), separada por pontos e vírgulas?
No atual esquema de validação é possível gerar tantas estruturas “Referência ao documento de origem” (OrderReferences), quantas venham a ser necessárias pelo que é esse o procedimento que deve ser seguido – vide alínea b) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
43-2774 Como exportar a informação relativa à faturação da atividade de revenda de bens em 2ª mão, onde é aplicado o regime da margem previsto no Decreto-Lei n.º 199/96, de 18 de outubro, considerando que as faturas emitidas não podem legalmente discriminar o imposto devido?
Não obstante o facto de legalmente não poder ser possível discriminar o imposto devido nos documentos emitidos, se a aplicação determina ou consta no seu repositório de dados o montante do IVA apurado, na linha com o bem objeto de venda dever-se-á criar a estrutura “Taxa de imposto” (Tax). Desta constará o elemento “Código da taxa” (TaxCode) com o valor “OUT”. O elemento “Montante do imposto” (TaxAmount) conterá o valor do imposto. Nesta conjuntura, nos campos “Valor a crédito” (CreditAmount) e “Valor a débito” (DebitAmount) constarão valores sem IVA.
Se a aplicação não determinar o montante do imposto devido, na linha com o bem objeto de venda dever-se-á criar a estrutura “Taxa de imposto” (Tax). Desta constará o elemento “Código da taxa” (TaxCode) com o valor “OUT”. O elemento “Percentagem da taxa de imposto” (TaxPercentage) conterá o valor zero (0). Nesta situação, nos campos “Valor a crédito” (CreditAmount) e “Valor a débito” (DebitAmount) constarão valores com IVA.
De igual forma deve ser considerada a geração do ficheiro SAF-T (PT) nas restantes situações previstas no referido Decreto-Lei ou em outros regimes da margem em que legalmente esteja interdita a discriminação de imposto na impressão dos documentos emitidos como, por exemplo, no regime aplicável às agências de viagens, com as devidas adaptações.
44-2775 Como exportar a informação relativa ao exercício de uma atividade sujeita a diversas ecotaxas, uma vez que, a tabela de impostos (TaxTable) não os prevê?
Essa informação deve ser exportada como linha de produto. Para tal devem ser criados produtos do tipo (ProductType) “I” na tabela 2.4 – Tabela de produtos/serviços (Product).
Independentemente da sua sujeição a algum dos impostos previstos na tabela de impostos (Imposto sobre o Valor Acrescentado ou Imposto do Selo) deve-se gerar a estrutura Tax nas respetivas linhas dos documentos sendo que, no caso da não incidência de IVA ou IS, o TaxType e TaxCode devem ser preenchidos com “NS” (não sujeição) – vide notas técnicas aos campos “Indicador de produto ou serviço” (ProductType), “Código do tipo de imposto” (TaxType) e “Código do imposto” (TaxCode) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
45-2776 Como evidenciar a informação relativa a impostos especiais de consumo (IEC) quando a introdução ao consumo desses bens é efetuada através de fatura?
Os impostos especiais de consumo podem ser reportados quer como produto quer como valor na linha dos bens sujeitos a esses impostos.
Encontrando-se o imposto especial de consumo discriminado como linha de produto urge criar na tabela de produtos/serviços (Product) um “Indicador de produto ou serviço” (ProductType = “E”). Nessa linha deve-se gerar a estrutura “Taxa de imposto” (Tax) correspondente. Por exemplo:
<LineNumber>1</LineNumber>
<ProductCode>BEB</ProductCode>
<ProductDescription>Bebida alcoólica 1</ProductDescription>
<Quantity>100</Quantity>
<UnitOfMeasure>LT</UnitOfMeasure>
<UnitPrice>9.9178</UnitPrice>
<TaxPointDate>2017-12-04</TaxPointDate>
<Description>Bebida alcoólica 1</Description>
<CreditAmount>991.78</CreditAmount>
<Tax>
<TaxType>IVA</TaxType>
<TaxCountryRegion>PT</TaxCountryRegion>
<TaxCode>NOR</TaxCode>
<TaxPercentage>23</TaxPercentage>
<LineNumber>2</LineNumber>
<ProductCode>IECCER033</ProductCode>
<ProductDescription>Imposto sobre o álcool e as bebidas alcoólicas (IABA)</ProductDescription>
<UnitPrice>0.0822</UnitPrice>
<Description>Imposto sobre o álcool e as bebidas alcoólicas (IABA)</Description>
<CreditAmount>8.22</CreditAmount>
<DocumentTotals>
<TaxPayable>230.00</TaxPayable>
<NetTotal>1000.00</NetTotal>
<GrossTotal>1230.00</GrossTotal>
</DocumentTotals>
Não sendo o imposto especial de consumo identificado como produto, o imposto encontra-se incluído no valor do bem transmitido. Por exemplo:
<UnitPrice>10</UnitPrice>
<CreditAmount>1000</CreditAmount>
<CustomsInformation>
<IECAmount>8.22</IECAmount>
</CustomsInformation>
46-2777 Como e quando exportar a informação relativa ao campo “Valor tributável unitário” (TaxBase)?
O campo “Valor tributável unitário” (TaxBase) é gerado quando o que constar na linha do documento seja apenas imposto, i.e., a base tributável subjacente à determinação desse imposto não constitui receita do sujeito passivo.
Por exemplo, nas situações de concessão de crédito por instituições mutuantes com o encargo de liquidar Imposto do Selo pelo crédito concedido, a base considerada para a liquidação desse imposto não constitui sua receita pelo que essa base deverá constar no campo TaxBase.
Igualmente, se ocorrer a necessidade de emitir um documento retificativo de fatura, seja ele uma nota de débito ou crédito, por a taxa de imposto mencionada na fatura se encontrar incorreta e não existindo a possibilidade ou intenção de proceder à anulação desta ou de se efetuar o seu estorno integral, ter-se-á que liquidar ou devolver o imposto, respetivamente, em falta ou em excesso.
Assim, considerando a taxa de imposto que deve ser aplicada (a mencionar no campo TaxPercentage no caso de ser uma percentagem) e o valor do imposto em falta (TaxPayable), no campo TaxBase deverá constar o valor que aplicando o TaxPercentage corresponda ao valor do imposto em falta [Quantity*TaxBase*TaxPercentage=TaxPayable  TaxBase=TaxPayable /(TaxPercentage* Quantity)] – vide o seguinte exemplo:
<ProductCode>CRED</ProductCode>
<ProductDescription>Concessão de crédito</ProductDescription>
<UnitOfMeasure>UN</UnitOfMeasure>
<UnitPrice>0.00</UnitPrice>
<TaxBase>100000.00</TaxBase>
<TaxPointDate>2017-04-04</TaxPointDate>
<Description>Crédito de prazo inferior a um ano – por cada mês ou fração</Description>
<CreditAmount>0.00</CreditAmount>
<TaxType>IS</TaxType>
<TaxCode>17.1.1</TaxCode>
<TaxPercentage>0.04</TaxPercentage>
<TaxPayable>80.00</TaxPayable>
<NetTotal>0</NetTotal>
<GrossTotal>80.00</GrossTotal>
Nestas situações os campos UnitPrice, CreditAmount ou DebitAmount são sempre preenchidos com 0.00 em virtude da base que serviu de cálculo ao apuramento do imposto não constituir receita da instituição (as receitas são as comissões cobradas e eventuais juros).
Nas situações em que ocorra liquidação de Imposto do Selo sobre importâncias que constituem receitas do credor segue-se a regra geral, i.e., o elemento “Valor a crédito” (CreditAmount) é preenchido com o valor da linha ou seja o produto da multiplicação dos elementos Quantity e UnitPrice. Nesta situação não é gerado o campo TaxBase.
Os documentos retificativos de fatura devem referenciar a fatura implícita.
47-2778 As aplicações de faturação carecem de ser desenvolvidas para que se guarde a informação relativa aos n.ºs de série dos itens no repositório de dados? Como exportar vários n.ºs de série quando existe uma linha de faturação com vários itens?
Se esta informação constar da impressão do documento, obrigatoriamente tem de constar da base de dados pois não poderá ser considerada texto livre e como tal, terá que ser criado um campo ou tabela para conter essa informação.
Acresce que este campo será preenchido se esta informação constar da base de dados, seja ela impressa ou não no documento.
O campo “Número de série” (SerialNumber) pode ser gerado múltiplas vezes na mesma linha do documento emitido pelo que o n.º de série de cada item pode ser exportado para o respetivo campo.
48-2779 Como exportar no SAF-T (PT) a informação relativa à emissão de cheques no caso de serem ofertados ao cliente considerando que são sujeitos a uma verba unitária fixa de Imposto do Selo (IS)? O campo “Montante do imposto” (TaxAmount) é preenchido com o valor unitário aplicável ou com a totalidade do imposto apurado na operação?
O campo “Montante do imposto” (TaxAmount) deve ser preenchido com o valor unitário aplicável (atualmente € 0.05). O valor total do imposto apurado constará do campo “Valor do imposto a pagar” (TaxPayable).
A oferta dos cheques não introduz qualquer alteração à regra geral, i.e., o campo “Preço unitário” (UnitPrice) deve exibir o valor cobrado por cada cheque. No caso de não ser cobrado qualquer valor deve de ser preenchido com 0.00.
O campo “Quantidade” (Quantity) deverá conter a quantidade dos cheques emitidos para o cliente.
49-2780 Como exportar, para o SAF-T (PT), as linhas referentes a operações que são simultaneamente isentas de IVA ao abrigo do artigo 9.º do CIVA e de Imposto do Selo ao abrigo do artigo 7.º do CIS ou em que a isenção dependa de normas que concedam isenções ao adquirente como, por exemplo, o n.º 12 do art.º 66.º-A do EBF, em virtude de não ser possível gerar duas estruturas “Taxa de imposto” (Tax) por linha de documento?
Efetivamente apenas é admissível um elemento “Taxa de imposto” (Tax) por linha. Contudo, verifica-se que, não são sujeitas a Imposto do Selo apenas as operações sujeitas a IVA e dele não isentas (n.º 2 do art.º 1.º do CIS), não se verificando norma recíproca em sede de IS.
Numa fatura é identificado o bem vendido ou a prestação de serviço prestada, isto é, a operação real objeto de transmissão.
Se em sede de IVA, determinada a operação é isenta e, simultaneamente, é sujeita a IS, ainda que deste imposto seja igualmente isenta, ou o reconhecimento da isenção dependa de norma que isente o adquirente desse encargo, apenas constará nas linhas correspondentes do SAF-T (PT) o elemento “Taxa de imposto” (Tax) relativo a IS e o respetivo motivo de isenção:
<TaxCode>22.2</TaxCode>
<TaxPercentage>0</TaxPercentage>
<TaxExemptionReason>Isento do Selo ao abrigo do artigo 7.º, nº 1, alínea b) do CIS</TaxExemptionReason>
<TaxExemptionCode>M99</TaxExemptionCode>
50-2781 Qual a diferença entre os campos “Motivo da isenção de imposto” (TaxExemptionReason) e “Código do motivo de isenção de imposto” (TaxExemptionCode)? É obrigatório a geração de ambos os campos? Em caso afirmativo, na emissão de uma fatura isenta de imposto nos termos do artigo 9.º do CIVA, pode ser preenchido como motivo de isenção o código M07 em ambos os campos?
No campo “Motivo de isenção de imposto” (TaxExemptionReason) deve constar o motivo que se encontram impressos nas faturas ou documentos retificativos das faturas de acordo com as disposições contidas na legislação tributária, i.e., a expressão legal ou a norma jurídica aplicável.
O campo “Código do motivo de isenção de imposto” (TaxExemptionCode) deve ser preenchido com o código do motivo de isenção ou não liquidação, que consta do ponto 4.2.1 do Manual de Integração de Software – Comunicação das Faturas à AT para comunicação via Webservice ao e-Fatura.
Existindo uma operação isenta de imposto, é obrigatório a geração simultânea de ambos os campos.
51-2782 Como deve ser preenchido o campo “Taxa de câmbio” (ExchangeRate)?
Este campo deve ser preenchido seguindo o conceito de “1 moeda estrangeira para x euros”. Assim no campo ExchangeRate deve constar o valor que multiplicado pelo conteúdo do campo “Valor total em moeda estrangeira” (CurrencyAmount) produzirá a importância que constará no campo “Total do documento com impostos” (GrossTotal) – vide notas técnicas aos campos “Taxa de câmbio” (ExchangeRate) das tabelas 4 – “Documentos comerciais” (SourceDocuments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
52-2783 Deve ser criada a estrutura “Pagamentos” (Payment) na tabela “Documentos comerciais a clientes” (SalesInvoices) para registar a receção de um meio de pagamento, mesmo que não tenha sido emitido recibo? E se o registo da receção de um meio de pagamento é efetuado em outra aplicação?
A estrutura “Pagamentos” (Payment) deve ser gerada sempre e apenas quando existir informação no repositório de dados da aplicação em que o pagamento foi recebido independentemente da emissão de recibo. É por este facto que a estrutura em si, elemento Payment, não está como obrigatória advindo a sua obrigatoriedade do cumprimento da alínea d) do n.º 1 do Anexo I à Portaria 302/2016, de 02 de dezembro.
Numa situação relativa à emissão de uma fatura a crédito, se a introdução do pagamento, ainda que posterior, for realizada na mesma aplicação, esta estrutura será exportada. Se o registo do pagamento não for realizado na mesma aplicação, a estrutura não será gerada.
É possível criar a estrutura Payment diversas vezes possibilitando o registo de vários pagamentos em datas diferentes e com meios de pagamento igualmente diferentes.
53-2784 Como exportar os valores relativos a retenção na fonte que devam constar numa fatura? E as franquias?
A menção de franquias, valores de garantia ou retenções na fonte não terão qualquer influência nos totais do documento emitido, devendo ser referidos após o apuramento do campo “Total do documento com impostos” (GrossTotal) das tabelas existentes na estrutura Documentos comerciais (SourceDocuments).
Estes valores devem constar em campos próprios criados para o efeito e nunca como linhas de produtos ou serviços.
A informação relativa a retenções na fonte é exportada na estrutura “Retenção na fonte” (WithholdingTax). As franquias e valores de garantia não são exportáveis por inexistência de campo específico no SAF-T (PT).
54-2785 Como evidenciar o facto de ter sido emitida uma fatura relativa a uma venda, em que o mesmo cliente procedeu a uma devolução de uma transação anterior, que foi registada nessa fatura? Como o valor global da nova venda com imposto coincide com o valor a reembolsar pela devolução das mercadorias não existem valores a cobrar nem a receber. Por se tratar de bens com taxas de IVA diferentes existe um saldo do imposto a regularizar. Contudo, ao gerar o ficheiro SAF-T(PT) apresenta erro na validação.
Deve ser emitida fatura por cada transmissão de bens ou prestação de serviços.
Quando se trate de devoluções de mercadorias anteriormente transacionadas entre as mesmas pessoas, deve ser emitida a respetiva nota de crédito. Acresce que, uma retificação para menos de uma operação tributável ou do respetivo imposto, só pode ser efetuada quando o emitente tiver na sua posse prova de que o adquirente tomou conhecimento da retificação.
Não são aceitáveis devoluções em documentos de venda nem transmissões em documentos de regularização. A forma, conteúdo e finalidade dos documentos devem ser respeitados.
55-2786 Na tabela “Documentos de movimentação de mercadorias” (MovementOfGoods) constam diversos tipos de documentos. O que significa cada tipo e quando devem ser exportados, quando derem origem a fatura?
O Regime de Bens em Circulação (RBC) aprovado pelo Decreto-Lei n.º 147/2003 de 11 de julho não estabelece norma que defina que documento deve ser emitido e em que circunstância, instituindo somente que se considera como documento de transporte qualquer fatura, guia de remessa, nota de devolução, guia de transporte ou documentos equivalentes.
Na tabela “Documentos de movimentação de mercadorias” (MovementOfGoods) devem ser exportados todos os documentos de transporte emitidos no âmbito do Regime de Bens em Circulação independentemente de darem origem a fatura, de se destinarem a clientes ou fornecedores ou constituírem transferências entre instalações da mesma entidade (vide n.º 2 do artigo 2.º do referido regime).
56-2787 Uma fatura que sirva de documento de transporte deve ser exportada na tabela de “Documentos de movimentação de mercadorias” (MovementOfGoods) ou na tabela de “Documentos comerciais a clientes (SalesInvoices)?
Se for emitida uma fatura que também sirva de documento de transporte, esta deve constar na tabela de documentos comerciais a clientes (SalesInvoices) e não deve ser replicada na tabela dos documentos de movimentação de mercadorias (MovementOfGoods) – vide notas técnicas ao elemento “Movimentos de bens” (MovementOfGoods) da tabela “Documentos de movimentação de mercadorias” (MovementOfGoods) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
57-2788 Na emissão de documentos de transporte é o utilizador que define qual o formulário de impressão, pelo que pode utilizar um formulário de documento não valorizado. Contudo, na base de dados existem valores referentes aos preços praticados. Exporta-se essa informação ou exporta-se os valores monetários a 0.00?
Não obstante o documento impresso não evidenciar valores, estes devem ser exportados para o SAF-T (PT) pelo facto de constarem na base de dados – vide alínea d) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
58-2789 Quais os documentos que devem constar na tabela “Documentos de conferência de mercadorias ou de prestação de serviços” (WorkingDocuments)?
Na tabela “Documentos de conferência de mercadorias ou de prestação de serviços” (WorkingDocuments) devem constar todos os “Tipo de documento” (WorkType) ali identificados ou seus equivalentes, bem como os restantes documentos, independentemente da sua designação e uso que se lhes dê, que pelas suas características sejam ou possam ser apresentados ao cliente para conferência de mercadorias ou de prestação de serviços deles constantes.
Não é exigível que os bens ou serviços tenham sido ou venham a ser entregues ou prestados.
A título de exemplo, uma nota de encomenda que é ou possa ser entregue ao cliente para conferência dos bens encomendados deverá constar desta tabela. Em termos gerais, qualquer documento que possa ou seja entregue ao cliente ou que, pelas suas características, se possa confundir com um documento que deva constar nas restantes tabelas da estrutura “Documentos comerciais” (SourceDocuments) deve constar nesta tabela.
59-2790 Quais são os recibos que devem constar na tabela “Documentos de recibos emitidos” (Payments), somente os que forem emitidos no âmbito do Regime de IVA de Caixa?
Na tabela “Documentos de recibos emitidos” (Payments) devem constar todos os recibos emitidos independentemente do âmbito pelo qual foram emitidos (vide PaymentType).
Os recibos emitidos fora do âmbito do Regime de IVA de Caixa (RIC) também devem identificar o documento a quitar. Nas situações em que tal não seja conhecido deve preencher o campo “Número do documento de origem” (OriginatingON) com uma expressão que indicie a ausência de informação, por exemplo, “Omisso” e o campo “Data do documento de origem” (InvoiceDate) com 1900-01-01 ou o conteúdo do campo “Data do recibo (TransactionDate).
Os recibos emitidos no âmbito do RIC devem constar em série distinta dos restantes recibos.
Todas as séries de recibos devem ter numeração sequencial e cronológica, não se admitindo falhas de numeração – vide notas técnicas ao campo “Tipo de recibo” (PaymentType) da tabela “Documentos de recibos emitidos” (Payments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
60-2791 Qual o campo a exportar, “Valor a débito” (DebitAmount) ou “Valor a crédito” (CreditAmount), na emissão de um recibo de pagamento de uma fatura?
Deve ser gerado o campo “Valor a crédito” (CreditAmount) nas situações relativas ao recebimento de importâncias constantes em faturas e notas de débito. O recebimento de uma nota de crédito deve ser emitido pelo cliente pois é este quem compete emiti-lo pelas importâncias embolsadas – vide notas técnicas aos campos “Valor a débito” (DebitAmount) e “Valor a crédito” (CreditAmount) da tabela “Documentos de recibos emitidos” (Payments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
61-2792 Por questões de coerência e fiabilidade, o ERP utilizado não permite a anulação de recibos ainda que por lapso tenham sido emitidos. Exige sempre um documento de “sinal contrário” de forma a atualizar os registos contabilísticos. Estes documentos devem ser exportados para o SAF-T (PT)?
Esses documentos devem ser exportados na tabela “Documentos de recibos emitidos” (Payments) utilizando para o efeito o campo “Valor a débito” DebitAmount – vide alínea l) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
62-2793 A aplicação permite emitir recibos evidenciando as faturas que foram objeto de pagamento e as notas de crédito emitidas aos mesmos clientes. Contudo, os recibos emitidos na aplicação discriminam de taxas de imposto e em determinadas situações o saldo do campo “Valor do imposto a pagar” (TaxPayable) é negativo. Em virtude desta situação provocar uma mensagem de erro no SAF-T (PT), como exportar esta informação?
Os recibos são emitidos pelas importâncias embolsadas e não para evidenciar movimentos numa conta-corrente que já se encontram demonstrados pela emissão de faturas e de documentos retificativos de fatura. Ainda assim, caso pretenda evidenciar que se considerou uma determinada nota de crédito, esta deverá ser referente à mesma fatura que se encontra mencionada no recibo – vide alínea l) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
63-2794 Pretende-se disponibilizar no programa informático a emissão de recibos fora do âmbito do Regime de IVA de Caixa (PaymentType = “RG”). Como nesta situação não carece de discriminação de impostos questiono como devem ser preenchidos os campos “Valor a débito” (DebitAmount) e “Valor a crédito” (CreditAmount) em virtude das notas técnicas para esses campos mencionarem que os montantes aí exportados não devem incluir imposto?
Nas situações em que não seja possível determinar os impostos associados aos pagamentos, os “Valor a débito” (DebitAmount) ou “Valor a crédito” (CreditAmount) são preenchidos com o valor embolsado com o pagamento. Pode não ser gerada a estrutura “Taxa de imposto” (Tax) mas se por alguma razão vier a ser gerada, o campo “Código do tipo de imposto” (TaxType) deverá possuir o valor "NS", o campo “Código da taxa” (TaxCode) o valor "NA" e no campo “Percentagem da taxa de imposto” (TaxPercentage) deve ser utilizado o valor “0”. Em ambas as situações, no campo “Valor do imposto a pagar” (TaxPayable) constará 0.00 e os montantes inscritos nos campos “Total do documento sem impostos” (NetTotal) e “Total do documento com impostos” (GrossTotal) coincidirão.
64-2795 Como mencionar diferentes taxas de imposto nos recibos?
Nos recibos devem ser criadas tantas linhas quantas as taxas e/ou motivos de isenção diferentes. Se um recibo respeitar a mais de uma fatura ou nota de débito, é possível criar tantas linhas quantas as taxas e/ou motivos de isenção diferentes por documento. Em alternativa, é possível identificar mais de um documento por linha, caso existam taxas/motivos de isenção comuns pois são admissíveis múltiplas estruturas “Referência ao documento de origem” (SourceDocumentID) por cada linha – vide notas técnicas do campo “Referência ao documento de origem” (SourceDocumentID) da tabela “Documentos de recibos emitidos” (Payments) definidas no n.º 2 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.
Nos recibos que não sejam relativos ao regime de IVA de Caixa e que eventualmente não discriminam os impostos, pode ser criada a estrutura “Taxa de imposto” (Tax) com o “Código do tipo de imposto” (TaxType) preenchido com "NS" e o “Código da taxa” (TaxCode) com "NA" ou simplesmente não criar a mencionada estrutura.
65-2796 Como mencionar descontos em recibos?
Nos recibos não se evidenciam descontos já constantes em fatura ou documento retificativo (nota de débito).
Nos descontos financeiros em recibo (emitidos no âmbito do Regime de IVA de Caixa ou outro) não existe regularização de IVA, pelo que o imposto mencionado na fatura é totalmente devido. Se se pretender regularizar o imposto deve-se utilizar a nota de crédito e respeitar o previsto no artigo 78.º, n.º 5 do CIVA.
Admita-se, a título exemplificativo, uma fatura que após desconto evidencia uma base de incidência de € 1000.00 e imposto (IVA) de € 230.00. É atribuído um desconto financeiro no recibo aquando do pagamento na importância de € 100.00. O desconto não é afeto a um produto específico mas à totalidade do documento.
No ficheiro SAF-T (PT), constará:
<!--Admitindo que o valor integral da fatura foi recebido -->
<PaymentAmount>1130.00</PaymentAmount>
<!-- Desconto financeiro concedido aquando do pagamento. Não se deve incluir os descontos comerciais mencionados na fatura. -->
<SettlementAmount>100.00</SettlementAmount>
<CreditAmount>900.00</CreditAmount>
<NetTotal>900.00</NetTotal>
<GrossTotal>1130.00</GrossTotal>
<!-- Somatório dos descontos de linha aquando do pagamento. Não deve refletir os descontos comerciais mencionados na fatura. -->
Note-se que aqui não se segue o mesmo raciocínio que nas restantes tabelas do SAF-T (PT) – “Documentos comerciais a clientes” (SalesInvoices), “Documentos de movimentação de mercadorias” (MovementOfGoods) e “Documentos de conferência de mercadorias ou de prestação de serviços” (WorkingDocuments). Como se pode verificar, o imposto resulta do produto do campo TaxPercentage pela soma dos campos CreditAmount e SettlementAmount, o que não acontece nas restantes tabelas onde a liquidação resulta do produto do CreditAmount pelo TaxPercentage.
Também o “Montante do desconto” (SettlementAmount) [não confundir com o campo “Montante do desconto da linha” (SettlementAmount)] não tem o mesmo conteúdo do campo “Montante do desconto” (SettlementAmount) que consta das outras tabelas onde é meramente potencial e informativo e não se reflete no total do documento. Nos recibos, campo “Montante do desconto” (SettlementAmount) constitui o somatório dos descontos evidenciados nas linhas do recibo.
66-2797 O pagamento faseado em sede de Regime de IVA de Caixa provoca discrepâncias entre o que foi faturado e o mencionado em recibo em virtude de arredondamentos. Contudo, tendo necessidade de acertar a conta-corrente do cliente e não podendo existir estas divergências, como exportar essa informação para o SAF-T (PT)?
R.66. Estas discrepâncias podem ser corrigidas no último dos pagamentos parciais. Imagine-se que se encontra a pagamento uma fatura que evidencia uma base de incidência de € 1000.00 e imposto (IVA) de € 230.00:
Pagto Parcial
B. tributável
B. trib. arredondado
Imp. arredondado
Recibo n.º 1
0,406504
406,504065
93,49593496
Recibo n.º 2
Recibo n.º 3
0,186992
186,9918699
43,00813008
230,01
Refira-se que no SAF-T (PT) não existe limitação no nº de casas decimais com exceção do campo “Total do documento com impostos” (GrossTotal) que deve utilizar 2 casas decimais.

References: artigo 9
 artigo 7
 artigo 7
 artigo 9
 artigo 2
 artigo 78