Outras Obrigações > SAF-T PT > Questões Técnicas

 
 

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:

IS
PT
ISE
0

Isento do Selo ao abrigo do artigo 7.º, nº 1, alínea b) do CIS
M99

Existe um ficheiro de exemplo do SAF-T (PT) em formato XML, em https://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Faturacao/Paginas/certificacao-de-software.aspx. A ferramenta de validação estrutural do ficheiro encontra-se em https://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/SAFT_PT/Paginas/news-saf-t-pt.aspx 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.

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.


Transitoriamente, para os registos relativos ao período de tributação de 2019, o campo "Data do documento” (TransactionDate) poderá ser preenchido com a data do final do mês/ano do documento de suporte do lançamento contabilístico, quando não sejam registados por integração de documentos produzidos pelo sistema de faturação no sistema informático de contabilidade. Para os documentos de faturação emitidos aos clientes, pode ser colocada a data do final do mês/ano de emissão das faturas (e documentos retificativos de faturas). Para os documentos de faturação rececionados dos fornecedores e outros documentos externos de terceiros, pode ser colocada a data do final do mês/ano indicado na data do documento. Para os documentos internos, pode ser colocada a data do final do mês/ano de emissão dos mesmos.

Nas transmissões de bens e prestações de serviços, quando não seja obrigado a identificar o cliente no movimento contabilístico ou este não forneceu a sua identificação, as operações poderão ser registadas diariamente nos termos do artigo 46.º do Código do IVA, devendo registar a data dos documentos (TransactionDate) e a data da relevação contabilística (GLPostingDate).
Nas seguintes aquisições de bens e serviços, pode registar um conjunto de documentos num único movimento contabilístico desde que o intervalo de datas dos documentos comerciais não ultrapasse um período mensal que permita verificar o cumprimento do n.º 3 do artigo 123.º do CIRC, devendo neste caso registar no campo da data do documento (TransactionDate) a mais antiga do conjunto de documentos:



  • aquisições, pelo seu valor facial, de selos do correio em circulação ou de valores selados referidas no n.º 24 do artigo 9.º do Código do IVA) com exceção das respetivas comissões de venda;

  • operações bancárias e financeiras referidas no n.º 27 do artigo 9.º do Código do IVA;

  • operações de seguro e resseguro referidas no n.º 28 do artigo 9.º do Código do IVA com exceção das respetivas prestações de serviços conexas efetuadas pelos corretores e intermediários de seguro;

  • despesas referidas nas alíneas b), c), d) e e) do n.º 1 do artigo 21.º do Código do IVA.

A identificação do fornecedor (SupplierID) é obrigatória em:



  • Operações com entidade não residente;

  • Operações efetuadas com entidades residentes, sendo excluídas, desde que não utilizem sistemas informáticos integrados de faturação e contabilidade nem exista acordo de autofacturação, as seguintes:


    • aquisições, pelo seu valor facial, de selos do correio em circulação ou de valores selados referidas no n.º 24 do artigo 9.º do Código do IVA) com exceção das respetivas comissões de venda;

    • operações bancárias e financeiras referidas no n.º 27 do artigo 9.º do Código do IVA;

    • operações de seguro e resseguro referidas no n.º 28 do artigo 9.º do Código do IVA com exceção das respetivas prestações de serviços conexas efetuadas pelos corretores e intermediários de seguro;

    • despesas referidas nas alíneas b), c), d) e e) do n.º 1 do artigo 21.º do Código do IVA.

Cada movimento deve estar apoiado num documento rececionado justificativo, contendo a respetiva identificação do fornecedor (SupplierID), a data impressa no documento justificativo (TransactionDate) e a do movimento contabilístico (GLPostingDate).

A identificação do cliente (CustomerID) no movimento contabilístico é obrigatória nas seguintes operações quando os documentos comerciais sejam emitidos com número de identificação fiscal do adquirente:


  • Operações com entidade não residente;

  • Operações efetuadas com entidades residentes, sendo excluídas, desde que não utilizem sistemas informáticos integrados de faturação e contabilidade, as seguintes:


    • transmissões, pelo seu valor facial, de selos do correio em circulação ou de valores selados referidas no n.º 24 do artigo 9.º do Código do IVA com exceção das respetivas comissões de venda;

    • operações bancárias e financeiras referidas no n.º 27 do artigo 9.º do Código do IVA;

    • operações de seguro e resseguro referidas no n.º 28 do artigo 9.º do Código do IVA com exceção das respetivas prestações de serviços conexas efetuadas pelos corretores e intermediários de seguro;

    • transmissões referidas nas alíneas b), c), d) e e) do n.º 1 do artigo 21.º do Código do IVA.

Cada movimento deve estar apoiado num documento emitido justificativo, contendo a respetiva identificação do cliente (CustomerID), a data impressa no documento justificativo (TransactionDate) e a do movimento contabilístico (GLPostingDate).


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


SalesInvoices


Tipo de documento


Aviso de pagamento de prémio (WorkType = “RP”)


Fatura (InvoiceType = “FT” ou “FR”)


Aviso de pagamento de prémio (InvoiceType =“RP”)


Data de emissão


“Data do documento” (WorkDate)


“Data do documento de venda” (InvoiceDate)


“Data do documento de venda” (InvoiceDate)


Data limite de pagamento




“Acordos de pagamento” (PaymentTerms)


Data de recebimento



“Data do pagamento” (PaymentDate)


“Data do pagamento” (PaymentDate)


Data de início do período de cobertura



“Data de receção” (…/ShipFrom/DeliveryDate)


“Data de receção” (…/ShipFrom/DeliveryDate)


Data de fim do período de cobertura



“Data da entrega” (…/ShipTo/DeliveryDate)


“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:








































Com emissão de fatura


Sem emissão de fatura (*)


Tabela de registo


WorkingDocuments


SalesInvoices


SalesInvoices


Tipo de documento


Aviso de Estorno


(WorkType “RE”) (**)


Nota de Crédito


(InvoiceType “NC”)


Aviso de Estorno


(InvoiceType “RE”)


Data de emissão


“Data do documento” (WorkDate)


“Data do documento de venda” (InvoiceDate)


“Data do documento de venda” (InvoiceDate)


Data do pagamento



“Data do pagamento” (PaymentDate)


“Data do pagamento” (PaymentDate)


Data de início do período de cobertura a que se refere a correção



“Data de receção” (…/ShipFrom/DeliveryDate)


“Data de receção” (…/ShipFrom/DeliveryDate)


Data de fim do período de cobertura a que se refere a correção



“Data da entrega” (…/ShipTo/DeliveryDate)


“Data da entrega” (…/ShipTo/DeliveryDate)


(*) Para operações até à entrada em vigor da alínea a) do n.º 3 do art.º 29.º do CIVA com a redação decorrente da publicação do Decreto-Lei n.º 28/2019, de 15 de fevereiro para as quais não tenha sido emitido fatura.


(**) 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.

Os 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”.
Nas 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 na “Referência ao documento de origem” (SourceDocumentID).

Nas operações que devam ser identificados os respetivos clientes ou fornecedores não é possível efetuar o movimento descrito. Nestas operações a relação entre a emissão de qualquer documento comercial e a sua contabilização corresponde a um movimento unívoco.

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:

…




1


CRED


Concessão de crédito


2


UN


0.00


100000.00


2017-04-04


Crédito de prazo inferior a um ano – por cada mês ou fração


0.00




IS


PT


17.1.1


0.04








80.00


0


80.00




</Invoice>


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.

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.

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.

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


IVA


B. trib. arredondado


Imp. arredondado


Correção


Recibo n.º 1


500


0,406504


406,504065


93,49593496


406,50


93,50


406,50


93,50


Recibo n.º 2


500


0,406504


406,504065


93,49593496


406,50


93,50


406,50


93,50


Recibo n.º 3


230


0,186992


186,9918699


43,00813008


186,99


43,01


187,00


43,00


Total


1230


1


1000


230


999,99


230,01


1000,00


230,00




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.

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á:



1130.00


…




100.00


900.00




IVA


PT


NOR


23








230.00


900.00


1130.00






100.00




…




…


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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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).

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.

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.

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.

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.

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.



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:


…




1


BEB


Bebida alcoólica 1


100


LT


9.9178


2017-12-04


Bebida alcoólica 1


991.78




IVA


PT


NOR


23








2


IECCER033


Imposto sobre o álcool e as bebidas alcoólicas (IABA)


100


LT


0.0822


2017-12-04


Imposto sobre o álcool e as bebidas alcoólicas (IABA)


8.22




IVA


PT


NOR


23








230.00


1000.00


1230.00






Não sendo o imposto especial de consumo identificado como produto, o imposto encontra-se incluído no valor do bem transmitido. Por exemplo:


…




1


BEB


Bebida alcoólica 1


100


LT


10


2017-12-04


Bebida alcoólica 1


1000




IVA


PT


NOR


23






8.22








230.00


1000.00


1230.00





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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).