Integração de fatura eletrónica e-Fatura em sistemas ERP

Para operar na Turquia, um ERP tem de emitir e-Fatura e e-Arşiv — e também e-İrsaliye em alguns setores — através da Administração Tributária (GİB), quase sempre com um integrador privado. O ERP gera o documento no formato UBL-TR, o vendedor assina-o com o selo financeiro (mali mühür), o integrador valida-o perante a GİB e o contribuinte mantém-se responsável pela conservação de todos os documentos.

O que tem de suportar um ERP para operar na Turquia?

A Turquia aplica a faturação eletrónica como sistema de validação prévia: o documento é criado pelo vendedor, transmitido por um canal autorizado, validado pela Administração Tributária e só depois produz efeitos legais. Para um negócio que gere as operações num ERP, isso tem consequências em quatro pontos do sistema:

• Criação do documento. O ERP — ou um motor de faturação ligado a ele — tem de gerar as faturas na estrutura UBL-TR exigida, com os códigos, os identificadores das partes e os dados de linha previstos no esquema, e não com um layout de impressão adaptado para XML.


• Assinatura digital. Os documentos são assinados com o selo financeiro emitido ao contribuinte; a etapa de assinatura tem de ficar dentro do fluxo, com a gestão das chaves a corresponder às regras de custódia do selo.


• Troca bidirecional. No regime de e-Fatura, a situação de registo da contraparte decide o tipo de documento, e os documentos recebidos — faturas, respostas, cancelamentos quando permitidos — têm de chegar ao ERP com os identificadores originais, ou a contabilidade perde a ligação entre o sistema e o registo oficial.


• Conservação e recuperação. Os documentos emitidos e recebidos têm de poder ser consultados durante o prazo legal de conservação; se quem os guarda é o integrador, o ERP ou ambos, é uma decisão a tomar antes da entrada em produção, e não a partir de um pedido de auditoria.

Um ponto estrutural que surpreende as equipas novas à validação prévia: a fatura não está concluída no momento em que o ERP a imprime. Está quando a troca termina e as respostas chegam — o que obriga a que a noção de estado de uma fatura no ERP vá além de «criada» e «enviada» e inclua aceite, rejeitada e corrigida. Quem ignora isto acaba por conciliar, à mão, duas versões da verdade — o seu razão e o registo oficial — no fim do mês, que é precisamente o trabalho que a faturação eletrónica deveria eliminar.

Outra questão é o tempo de resposta. Os documentos num sistema de validação prévia não são assíncronos como um anexo de e-mail: uma rejeição chega enquanto a equipa ainda está a trabalhar, e a correção que ela exige toca sobretudo nos dados mestres e não no próprio documento. Conceber o fluxo de modo a que a pessoa capaz de corrigir a causa seja notificada na hora — em vez de a descobrir num relatório mensal — é o que separa um sistema que funciona de um sistema que precisa de vigilância constante.

e-Fatura, e-Arşiv e e-İrsaliye explicados

Quem fica abrangido por que obrigação é definido pelas regras e comunicados da GİB, que mudam; os limiares e as designações de setor são fixados pelas autoridades e mudam com elas. Para um comprador, a afirmação correta é de natureza procedimental: confirme a sua situação de registo com o contabilista ou consultor fiscal perante as regras em vigor antes de desenhar a integração — e não com um artigo, incluindo este.

Opções de integração de ERP com a GİB

O modelo do integrador merece uma clarificação, porque é frequentemente mal interpretado: usar um integrador privado não transfere as obrigações do contribuinte. O integrador fornece o canal técnico, a transmissão e o serviço de armazenamento; a responsabilidade legal pelos documentos — a sua correção, a sua emissão e a sua conservação nos termos da Lei do Procedimento Tributário (Vergi Usul Kanunu) — continua a ser do contribuinte. Quando a página de vendas de um integrador faz parecer que o problema do cumprimento fica resolvido por si, releia esta frase.

Na prática, esta divisão aparece de formas pequenas e concretas. Se um documento é rejeitado porque o identificador tributário do cliente estava errado nos seus dados mestres, o sistema do integrador funcionou perfeitamente e o erro é seu para corrigir. Se uma fatura é emitida com o código de imposto errado, nenhuma verificação do canal o salva. O integrador é infraestrutura; a qualidade dos dados que por ele circulam é disciplina interna, e o ERP é onde essa disciplina está embutida ou fica ao sabor do hábito. Os compradores que comparam integradores devem por isso gastar menos tempo na lista de funcionalidades e mais nas perguntas que revelam quem faz o quê quando algo falha: quem é notificado, em que formato, e em que rapidez pode um documento corrigido ser retransmitido.

Passos de implementação e testes do ERP

Uma sequência viável para uma integração do lado do ERP:

1. Definir o âmbito das obrigações. Que documentos se aplicam ao negócio — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — confirmado perante as regras em vigor com o contabilista da empresa.


2. Escolher o canal. A maioria das empresas seleciona um integrador privado; as perguntas de seleção — qualidade da API, disponibilidade de ambiente de testes, idioma e horário do apoio, gestão das atualizações do esquema, referências — merecem um exercício próprio de pré-seleção.


3. Mapear os dados mestres. Clientes e respetivos identificadores tributários, artigos, unidades, moedas e códigos de imposto têm de corresponder ao que o esquema espera; os desencontros aqui são a maior fonte individual de erros mais tarde.


4. Desenhar o fluxo do documento. Quem cria o quê, quando o selo é aplicado, o que acontece em caso de falha, como os documentos de saída e de entrada se cruzam com os registos do ERP e como se emitem as correções.


5. Usar o ambiente de testes. Ambos os lados disponibilizam ambiente de testes; execute lá todos os tipos de documento, todos os caminhos de erro e todos os cenários de correção antes da entrada em produção, com o mesmo mapeamento usado em produção.


6. Tratar os erros como processo. As rejeições chegam depois da transmissão; alguém tem de as ver, perceber a causa e corrigir os dados de origem — uma caixa de alertas sem responsável é como uma empresa acaba por emitir documentos com atraso.


7. Planear a conservação e o acesso. Onde os documentos ficam guardados, quem os pode recuperar e como se responde a um pedido de auditoria dentro do prazo de conservação.

Pontos para esclarecer com um consultor quando há matriz estrangeira ou não residentes

Para uma empresa com matriz estrangeira, ou que entra na Turquia sem uma equipa financeira local completa, várias perguntas pertencem ao consultor fiscal e não ao projeto de TI — as respostas determinam o desenho, por isso faça-as antes de a integração começar, e não depois:

• Percurso de inscrição. Como a empresa fica sujeita às obrigações, quem assina os pedidos e que representante é reconhecido — questões de registo fiscal, e não de software.


• Arranjos do selo. Como o selo financeiro é obtido para a empresa e como se organiza a sua custódia quando os signatários estão fora da Turquia.


• Representantes e assinaturas. Quem está autorizado a assinar que documentos, e o que o ERP tem de registar sobre o signatário para o rasto de auditoria.


• A situação da subsidiária estrangeira. Se há requisitos adicionais para empresas com participação de não residentes, e como é tratada a faturação dentro do grupo.

Também compensa decidir quem é o responsável pela relação com o consultor. Nas empresas em que finanças e TI presumem que a outra parte fez a pergunta, estes pontos chegam tarde à integração — normalmente nas semanas antes da entrada em produção, quando o fluxo do documento já está fixado. Um responsável com nome de cada lado, e uma reunião conjunta antes do ponto 3 da implementação, previne a maior parte desse problema.

Problemas frequentes

As falhas que mais aparecem neste tipo de projeto, e o que cada uma normalmente indica:

• Rejeições na validação. Quase sempre um problema de mapeamento: um código de imposto, um formato de identificador ou um campo de linha que não corresponde ao que o esquema espera. Corrija os dados mestres, e não a lógica de nova tentativa.


• Numeração duplicada. Sequências geradas por mais de um sistema, ou regeradas após uma falha; a numeração tem de ter um único responsável e uma regra de recuperação documentada.


• Erros na situação da contraparte. Emitir o tipo de documento errado porque a situação de registo do cliente veio de cache ou foi presumida; consulte a situação segundo as regras do integrador, e não segundo a memória.


• Documentos de entrada perdidos. Documentos recebidos mas nunca lançados no ERP, ficando as contas a pagar a trabalhar a partir de um ecrã à parte; o sentido da troca faz parte da integração, e não é um extra opcional.


• Atualizações do esquema ignoradas. A estrutura muda com o tempo; quem for responsável tem de saber quando mudou e o que a mudança fez ao mapeamento.


• Testes saltados por pressão do prazo. Todos os problemas acima saem mais baratos no ambiente de testes; a pressão da entrada em produção é onde se transformam em incidentes.

Perguntas frequentes

Qual é a diferença entre e-Fatura e e-Arşiv?

A e-Fatura abrange as faturas trocadas entre contribuintes inscritos no regime, como documentos estruturados entre partes inscritas; a e-Arşiv abrange as faturas em que o comprador está fora desse regime — retalho e B2C, e alguns B2B —, que o comprador normalmente recebe em PDF gerado através da mesma cadeia oficial. Qual das duas se aplica a uma determinada fatura resulta da situação de registo da contraparte, e é por isso que a integração a verifica em vez de a presumir.

Preciso de um integrador privado?

Para a maioria das empresas, sim — esse é o percurso comum, e o canal direto é descrito como complexo e raro. Um integrador privado fornece o canal técnico para a GİB e o serviço de armazenamento; as obrigações do contribuinte continuam a ser suas. Escolher um integrador é um exercício de compras: a qualidade da API, o ambiente de testes, o apoio e a gestão das atualizações do esquema decidem a experiência diária muito mais do que a marca.

O que é o selo financeiro (mali mühür)?

É a credencial de assinatura digital do contribuinte, usada para assinar os documentos eletrónicos antes de serem transmitidos; a custódia e quem pode usá-lo são questões práticas a resolver dentro da empresa. Para equipas com signatários fora da Turquia, o arranjo de quem guarda e aplica o selo é um dos primeiros pontos a levar a um consultor fiscal.

Qualquer ERP pode emitir faturas eletrónicas turcas?

Não. O ERP tem de gerar a estrutura UBL-TR exigida com dados mestres corretos, ou estar ligado a um motor ou integrador que o faça; um layout de fatura padrão não chega. Por isso a maioria das empresas liga em vez de reescrever — a perguntar a um fornecedor é que integradores suporta o seu conector, o que ele mapeia e onde está a documentação.

Como testo antes da entrada em produção?

Através dos ambientes de testes disponibilizados pelo integrador e pelo lado oficial, usando o mesmo mapeamento de dados mestres da produção: todos os tipos de documento, todos os caminhos de rejeição, todas as correções e todos os documentos de entrada lançados no ERP. Trate o teste também como um ensaio do processo de erro — alguém tem de receber, diagnosticar e corrigir uma rejeição, e não apenas ver um visto verde.

Quem guarda as faturas?

O contribuinte mantém-se responsável pela conservação nos termos da Lei do Procedimento Tributário; o integrador fornece normalmente o armazenamento técnico, e muitas empresas mantêm também os documentos no ERP para uso diário. O que importa é decidir o arranjo antes da entrada em produção, saber quem pode apresentar que documento dentro do prazo de conservação, e testar essa recuperação antes de um auditor pedir.

Fontes e normas

• GİB — Gelir İdaresi Başkanlığı — a Administração Tributária publica as regras, os comunicados e a documentação técnica para e-Fatura, e-Arşiv, e-İrsaliye e e-Defter; as versões correntes publicadas aí prevalecem sobre tudo o que está resumido nesta página.
• A situação de registo, os limiares, as designações de setor e os prazos são fixados pelas autoridades e mudam; confirme com o seu contabilista ou consultor fiscal perante as regras em vigor. Nada nesta página é aconselhamento fiscal, e não é afirmada qualquer relação de integrador, parceria ou certificação para a WorldwideTradeX.

Páginas relacionadas

Desenvolvimento de software · Odoo ERP para empresas de comércio · ERP à medida versus ERP de pacote · Auditoria e consultoria de TI · Pedir orçamento