O que faz arrancar o prazo de dois dias

O nosso objetivo é a primeira fatura de teste válida no prazo de dois dias úteis. Quem ouve isto pergunta quando começam a contar esses dois dias. A resposta honesta é: quando estão reunidos sete elementos. Esta checklist de faturação eletrónica reúne esses sete elementos. Enquanto não estiverem reunidos, ninguém pode prometer uma data, nem nós, porque o trabalho que leva tempo está à espera de algo que só a sua empresa pode fornecer.

Esta nota percorre os sete elementos: porque é que cada um importa, quem é responsável por ele e onde os projetos costumam parar. Assinale-os abaixo à medida que lê. O prazo começa a contar quando os sete estiverem assinalados.

• Um conjunto representativo de faturas, que cubra todas as variantes do âmbito
• Acesso funcional à origem, ou uma entrega estável por ficheiro ou API
• Credenciais de teste, certificados e autorização do contribuinte, emitidos em seu nome
• A rota escolhida, com o respetivo ambiente de testes ativo
• Um responsável técnico do seu lado, disponível durante esse período
• Decisões por escrito sobre códigos fiscais, isenções, dados de pagamento e identificadores
• Um URL de webhook para o estado devolvido

0 / 7 reunidos. O prazo ainda não começou.

Porque é que o prazo conta a partir dos requisitos de arranque

Uma assinatura diz-nos que quer o trabalho feito. Não nos dá as faturas, o acesso nem as decisões de que o trabalho precisa. Se começássemos a contar no dia da assinatura, os dois dias passariam à espera de uma exportação ou de um acesso de teste, e o objetivo não significaria nada.

Por isso, o objetivo está ligado aos requisitos de arranque. São uma lista curta, igual para todas as rotas, e cada elemento tem um único responsável. Quando chega o último elemento, temos tudo aquilo de que precisamos para mapear, validar e enviar uma fatura de teste, e cumprir os dois dias úteis passa a depender de nós. No glossário, esta mesma lista chama-se «readiness package».

Isto também torna os atrasos fáceis de discutir. Se a fatura de teste se atrasar, a pergunta não é «quem está a demorar?», mas «que elemento falta e quem é responsável por ele?». Ambas as partes conseguem ver a resposta.

A checklist de faturação eletrónica, elemento a elemento

1. Um conjunto representativo de faturas

Precisamos de faturas reais do seu ERP que cubram todas as variantes do âmbito: faturas normais, notas de crédito e as menos habituais, como linhas com autoliquidação, faturas em moeda estrangeira ou faturas que referem uma encomenda. O mapeamento é construído a partir delas. Uma variante que nunca vemos é uma variante que não podemos testar.

Responsável: a sua equipa. A falha habitual: um conjunto que só tem os casos fáceis.

2. Acesso funcional à origem

Lemos os dados de faturação onde o seu ERP os produz. Pode ser um acesso funcional ao sistema de origem ou uma entrega estável: o mesmo ficheiro ou a mesma chamada de API todas as vezes, com dados de teste. Uma folha de cálculo feita à mão uma única vez não conta, porque a produção não vai ser assim.

Responsável: a sua equipa. A falha habitual: uma exportação que ainda muda de semana para semana.

3. Credenciais de teste, certificados e autorização do contribuinte, emitidos em seu nome

Cada rota tem a sua própria forma de dar entrada a uma empresa: um token, um certificado, uma autorização num portal fiscal, uma conta num ponto de acesso ou numa plataforma. São emitidos à sua empresa, em seu nome, na rota que escolheu.

Responsável: a sua equipa. A falha habitual: um pedido que ainda está pendente na plataforma.

4. A rota escolhida, com o respetivo ambiente de testes ativo

A rota é o caminho pelo qual a sua fatura chega ao comprador num país: Peppol, uma plataforma francesa, KSeF, RO e-⁠Factura, entre outras. A escolha é sua, e o ambiente de testes dessa rota tem de estar ativado para a sua empresa. Nós fazemos a ligação.

Responsável: a sua empresa escolhe, nós ligamos. A falha habitual: um ambiente de testes que existe no papel, mas ainda não está ativo.

5. Um responsável técnico do seu lado, disponível durante o período de trabalho

Alguém do seu lado tem de responder a perguntas enquanto trabalhamos: de onde vem um campo, porque é que um código tem aquele aspeto, se uma fatura de teste pode ser enviada. Dois dias úteis não sobrevivem a uma espera de três dias por uma resposta.

Responsável: a sua equipa. A falha habitual: um nome sem tempo reservado.

6. Decisões por escrito sobre códigos fiscais, isenções, dados de pagamento e identificadores

Algumas perguntas não são técnicas. Que categoria de IVA se aplica a esta linha? Que motivo de isenção vai naquela? Que identificador usamos para o vendedor e para o comprador? São decisões fiscais, e cabem à sua empresa e ao seu contabilista. Precisamos delas por escrito, para que o mapeamento siga as suas decisões e não as nossas suposições.

Responsável: a sua equipa, com o seu contabilista. A falha habitual: uma decisão tomada numa reunião e nunca passada a escrito.

7. Um URL de webhook para o estado devolvido

Cada rota responde de forma diferente. Convertemos cada resposta num único evento que o seu ERP consegue ler, mantendo ao lado o código próprio da rota. Para isso, precisamos de um destino para onde o enviar: um URL de webhook do seu lado, ou um acordo de que lê o estado através da API.

Responsável: a sua equipa. A falha habitual: um URL que ninguém do lado do ERP está ainda a escutar.

O que acontece nos dois dias úteis

Assim que chega o sétimo elemento, o trabalho segue uma ordem fixa. Construímos o mapeamento das suas faturas para a EN 16931 [1] e para o formato do país, verificamos cada variante face às regras oficiais e enviamos faturas através do ambiente de testes da rota. O estado volta para si da mesma forma que voltará em produção. Carregue em «Reproduzir» para acompanhar uma fatura do início ao fim.

▶Reproduzir

1. 01Exportação do ERP
2. 02Mapeamento
3. 03Validação
4. 04Rota
5. 05Comprador e plataforma fiscal

↺O estado volta por webhook ou API: aceite, rejeitada com um código ou recusada pelo comprador.

Exportação do ERPDados do ERP

O seu ERP produz os dados da fatura: um relatório, um ficheiro ou uma chamada de API.

O que pode correr malFalta um campo na exportação, como o número de IVA do comprador.

O objetivo é a primeira fatura de teste válida dentro desses dois dias úteis. Uma fatura de teste válida é uma fatura que o ambiente de testes da rota aceita. É a primeira prova de que os seus dados, o nosso mapeamento e a rota estão de acordo entre si.

Onde encaixam os sete elementos nos seis passos

A lista dos requisitos de arranque não é um processo à parte. É a parte dos nossos seis passos que só a sua empresa pode iniciar. Eis como o trabalho se divide depois de assinado o âmbito:

Passo	O que faz	O que fazemos
Definir	Trazer o caso e os dados da entidade	Verificá-lo face à unidade-padrão
Mapear	Dar acesso e faturas representativas	Construir a tabela de mapeamento
Validar	Decidir os códigos fiscais e os identificadores	Executar os conjuntos de regras e corrigir o mapeamento
Testar	Obter as credenciais de teste	Enviar, confirmar e mapear o estado
Entrar em produção	Realizar o seu teste de aceitação e dar a aprovação final	Acompanhar as primeiras faturas em produção
Monitorizar	Corrigir os dados na origem quando lhe for pedido	Triagem, correções no mapeamento e o relatório mensal

Os elementos 1, 2 e 6 alimentam os passos de mapeamento e validação. Os elementos 3, 4 e 7 alimentam o passo de teste. O elemento 5, o responsável técnico, mantém todos eles em andamento.

O que significam os elementos 3 e 4 em três rotas

As palavras da lista são as mesmas em todo o lado, mas o trabalho por trás delas depende da rota: um token do KSeF na Polónia [2], um Peppol ID na Bélgica, um registo numa Plateforme Agréée em França [3].

• KSeFPL

  Elemento 3: acesso, emitido em seu nome

  Um token ou certificado KSeF com a permissão de emissão de faturas para o seu NIP

  Elemento 4: o ambiente de testes

  O ambiente de testes do KSeF

  Atenção a

  Um token sem a permissão InvoiceWrite não consegue abrir uma sessão de envio, por isso o KSeF nunca vê a fatura

• PeppolBE

  Elemento 3: acesso, emitido em seu nome

  Uma conta num ponto de acesso certificado e o Peppol ID com que a sua empresa está registada

  Elemento 4: o ambiente de testes

  A configuração de testes do seu ponto de acesso

  Atenção a

  Sem o seu Peppol ID como endereço eletrónico do vendedor, uma regra Peppol rejeita a fatura

• Plateforme AgrééeFR

  Elemento 3: acesso, emitido em seu nome

  O seu registo na plataforma, com o seu SIREN ativo no diretório nacional

  Elemento 4: o ambiente de testes

  O ambiente de testes da plataforma, separado da produção

  Atenção a

  Teste e produção são separados: estar configurado num não é estar configurado no outro

Duas das três falhas param um teste antes de qualquer comprador o ver. O KSeF não abre uma sessão de envio para um token sem a permissão InvoiceWrite [4], e na Peppol a regra PEPPOL-⁠EN16931-⁠R020 rejeita a fatura antes de ela sair [5]. É por isso que ambos os elementos estão na lista dos requisitos de arranque, antes de o prazo começar a contar, e não dentro dos dois dias úteis.

Em França, o diretório nacional funciona nos dois sentidos. Uma empresa que não escolheu uma plataforma de receção não consta dele, e as faturas dirigidas a essa empresa não podem ser entregues [6].

O que o prazo não cobre

Alguns passos ficam fora dos dois dias porque nenhuma das partes os controla. A figura mostra onde se situam ao lado do prazo.

Requisitos de arranqueAo seu ritmoOs dois dias úteisDentro do prazoDepois da primeira fatura de teste válidaCom a sua aprovação

A sua equipaOs sete elementos da listaResponde a perguntas durante o período de trabalhoTeste de aceitação e aprovação final

EurInvoiceLiga a rota que escolheuMapeia, valida e envia faturas de testeAcompanha as primeiras faturas em produção

1. O prazo arranca: os sete elementos reunidos
2. Primeira fatura de teste válida

Fora do prazo

• Adesão à plataforma e KYC
• Autorização do contribuinte para produção
• Terceiros, como um fabricante de ERP que altera uma exportação

• A adesão à plataforma e o KYC, que o ponto de acesso ou a plataforma conduz ao seu próprio ritmo.
• A autorização do contribuinte para produção, que a administração fiscal concede.
• O seu teste de aceitação, que a sua equipa realiza e aprova.
• A disponibilidade de terceiros, como um fabricante de ERP que tem de alterar uma exportação.

Nenhum destes é motivo para esperar antes de começar os sete elementos. A maioria pode avançar em paralelo com os requisitos de arranque, e começá-los cedo é a melhor forma de manter curto o projeto inteiro.

Algum trabalho fica também fora da própria unidade-padrão. Mais entidades ou países, fluxos de entrada, e-⁠reporting, arquivo, trabalho na interface do ERP e taxas de plataforma são orçamentados à parte. Saber isto desde o início mantém o objetivo de dois dias centrado numa só coisa: a primeira fatura de teste válida.

Quando falta um elemento

Acontece na maioria dos projetos, e não faz mal. Quando falta um elemento, dizemos qual é, quem é responsável por ele e o que é preciso exatamente. O prazo espera. Não se perde nada além de tempo, e a lista dos requisitos de arranque mostra para onde vai esse tempo.

Uma mensagem nossa sobre um elemento em falta é assim: «O elemento 3 continua em aberto. A plataforma ainda não ativou a sua conta de teste. Responsável: a sua equipa. Assim que estiver ativa, envie-nos o ID da conta e o prazo pode começar.» Curta, concreta e com um único responsável.

Se um elemento em falta acabar por estar do nosso lado, como a integração da rota, dizemo-lo da mesma forma. A lista aplica-se às duas partes, e é a mesma quer compre diretamente connosco, quer através do seu parceiro de ERP.

Uma checklist para enviar à sua equipa

Copie isto para um e-⁠mail dirigido a quem for responsável pelo lado do ERP:

1. Um conjunto representativo de faturas anonimizadas, com todas as variantes do âmbito.
2. Acesso à origem, ou uma entrega estável por ficheiro ou API com dados de teste.
3. Credenciais de teste, certificados e autorização do contribuinte para a rota escolhida, emitidos em nome da sua empresa.
4. A rota escolhida, com o respetivo ambiente de testes ativo.
5. Um responsável técnico com tempo reservado durante o período de trabalho.
6. Decisões por escrito sobre códigos fiscais, isenções, dados de pagamento e identificadores.
7. Um URL de webhook para o estado devolvido.

Quando os sete estiverem prontos, avise-nos e os dois dias úteis começam a contar.