EET 2.0 na Chéquia a partir de 1 de janeiro de 2027: o que o software de POS e de quiosques à medida tem de fazer

O registo de vendas está de volta à Chéquia. O presidente Petr Pavel promulgou a lei do EET 2.0 a 17 de setembro de 2026, e o comunicado da Administração Financeira é claro quanto à data: a obrigação de registar as vendas começa a 1 de janeiro de 2027. Abrange os pagamentos presenciais entre a empresa e o cliente, incluindo todo o numerário. Numerário, cartão, telemóvel ou código QR: se o cliente paga presencialmente ou nas suas instalações, a venda segue para a administração fiscal no momento em que acontece.

Para a maioria dos pequenos comerciantes, isto significa uma atualização do fornecedor ou uma aplicação web gratuita do Estado. Para as cadeias com software de caixa próprio, quiosques de self-service ou uma aplicação de pagamento que os funcionários levam pela loja, é um projeto de integração com cerca de 90 dias pela frente. Este artigo é para elas.

O que mudou desde o primeiro EET

O EET original foi abolido em 2022. O EET 2.0 mantém a ideia central (cada venda abrangida é enviada online e confirmada pelo Estado) e alivia muito o resto:

• Dados mínimos. O sistema antigo discriminava cada venda por taxa de IVA. O EET 2.0 envia um único total, com IVA incluído, sejam quais forem as taxas.
• Sem obrigação de recibo. As empresas deixam de ter de emitir um recibo para efeitos de EET, e o código de confirmação não tem de constar de nenhum.
• Um âmbito mais estreito. Só se registam os pagamentos presenciais entre o cliente e a empresa; o sistema antigo abrangia um leque mais vasto de pagamentos.
• Uma opção gratuita do Estado. O MOJE eet, uma aplicação web para as empresas mais pequenas, e uma dispensa chamada EET OFF para alguns empresários em nome individual em regime forfetário.

A mudança técnica é maior do que a lista sugere. O transporte é conhecido: SOAP 1.1 sobre HTTPS com assinaturas WS-Security, como antes. A mensagem não. A nova interface é a versão 4.1, a antiga era a 3.1, e a especificação diz que as alterações de 2026 «are incompatible with previous system». A apresentação do seminário para programadores indica como eliminados o código de segurança BKP, o indicador de modo simplificado e as rubricas de IVA. O código do EET antigo serve de referência para a infraestrutura e para nada mais.

O que está abrangido

A página oficial sobre quem tem de registar vendas fixa três condições: o pagamento é presencial ou é um pagamento em numerário, é rendimento empresarial, e não se aplica nenhuma isenção.

Um pagamento presencial ocorre em contacto pessoal consigo ou com os seus funcionários, ou nas suas instalações ou no seu veículo, em ligação com o bem ou o serviço. A apresentação do seminário diz sem rodeios que a segunda regra visa as caixas de self-service e os espaços de self-service. Um quiosque dentro da sua loja está abrangido, mesmo que nenhum funcionário toque na transação. O numerário é sempre registado, mesmo fora das suas instalações, exceto a cobrança contra reembolso feita por um serviço postal.

O meio de pagamento não importa. Numerário, cartão, código QR, uma transferência bancária ou um débito direto feitos no ponto de venda, criptoativos, cartões-oferta, vales de refeição e cartões pré-pagos constam todos da lista.

Os pagamentos à distância ficam de fora: uma loja online paga através de um gateway de pagamento, ou uma fatura que o cliente paga a partir do escritório. O que conta é a forma como o dinheiro efetivamente circulou, não o que diz a fatura. Se um cliente paga 200 CZK com cartão ao balcão e os restantes 800 CZK por transferência a partir de casa no dia seguinte, só os 200 CZK são registados.

As máquinas de venda automática que constituem, elas próprias, instalações (a máquina de café é o exemplo oficial) estão isentas, tal como os postos de self-service fora das suas instalações em que o registo seria impraticável. A lista de isenções abrange também, entre outros, entidades públicas, bancos, jogos de fortuna e azar e energia.

Quem pode saltar a maior parte disto

As microempresas podem usar o MOJE eet, que arranca a 1 de dezembro de 2026. O seminário para programadores de junho apresentou-o como destinado a empresas com até duas unidades de registo e dois funcionários. Os empresários em nome individual em regime forfetário do primeiro escalão, com rendimentos até 1 milhão de CZK, podem ficar de fora através do EET OFF.

As empresas com um produto de POS corrente devem receber uma atualização do fornecedor. Pergunte quando sai e o que acontece durante uma falha de ligação, e depois registe-se no portal fiscal e instale o certificado.

Todos os outros devem continuar a ler: software de caixa interno ou personalizado, quiosques desenvolvidos por si, aplicações de pagamento para os funcionários, ou um grupo em que um pagamento pode pertencer a duas empresas.

O que tem de ser desenvolvido

Está tudo na página de documentos para programadores: a descrição da interface (a versão inglesa não é vinculativa), o XSD e o WSDL, exemplos de pedidos assinados e certificados para o playground. A edição inglesa vai agora na versão 1.2a, de 2 de outubro de 2026; corrige um comprimento máximo errado para porad_cis na secção 3.3.3.10, por isso confira os limites dos seus campos com ela.

Unidades de registo e identificadores de dispositivo

Cada mensagem leva um identificador de unidade de registo. As unidades (uma loja, um posto móvel, um veículo de entregas) são criadas no DIS+, o portal fiscal, e o sistema atribui um número a cada uma. As cadeias podem importar unidades em massa, e as alterações têm de ser comunicadas no prazo de 15 dias. O seu POS precisa de uma correspondência atualizada entre cada local e o respetivo identificador de unidade, mais um identificador de dispositivo com até 20 caracteres, único dentro da unidade.

Certificados

É aqui que os sistemas à medida costumam perder tempo. O procedimento de certificados descreve os passos:

• O par de chaves é gerado pela autoridade de certificação do EET, não no seu dispositivo. Descarrega um ficheiro PKCS#12 protegido por palavra-passe, disponível até confirmar a transferência e durante 30 dias, no máximo.
• O ficheiro usa a antiga cifra 3DES por causa das caixas mais antigas. O documento avisa que pode não carregar no OpenSSL 3 sem o legacy provider e recomenda voltar a empacotá-lo ou passar a chave para um cofre.
• Os certificados são válidos por um ano. Um certificado pode servir um dispositivo ou vários; quantos emite é decisão sua.
• A renovação pode ser automatizada através de uma API REST: um JWT de curta duração assinado com o certificado a renovar e, depois, consultar o pedido, descarregar e confirmar. A autoridade recomenda renovar duas a três semanas antes de o certificado expirar. Depois de expirado, a via da API fecha-se, e alguém tem de o renovar à mão.
• Proteger a chave privada é um dever legal do contribuinte. Um único ficheiro de chave copiado para quarenta caixas é uma revogação à espera de acontecer.

A mensagem de dados

O cabeçalho contém um UUID novo para cada tentativa, a hora de envio, um indicador de primeira tentativa e um indicador opcional de verificação. A parte de dados contém o EIČ do contribuinte, o identificador da unidade, o identificador do dispositivo, um número sequencial (até 25 caracteres, único por unidade e dispositivo), a hora da venda com o desvio do fuso horário e o total em CZK com exatamente duas casas decimais. Dois montantes opcionais cobrem os carregamentos e os consumos de saldos pré-pagos; outros dois campos cobrem o registo em nome de outro contribuinte.

Registe o que foi efetivamente recebido: uma conta de 78,90 paga em numerário e arredondada para 79 entra como 79,00; a mesma conta paga com cartão entra como 78,90. Uma conta paga em parte com vales de refeição e em parte com cartão é uma única mensagem com o total.

Assinatura e envio

Cada mensagem é assinada com XML Signature no cabeçalho WS-Security: canonicalização exclusiva, digest SHA-256, RSA-SHA256, o certificado anexado como BinarySecurityToken e apenas o corpo SOAP assinado. Não inclua cabeçalhos adicionais, como Timestamp ou WS-Addressing: as mensagens com mais de 12 kB são rejeitadas, e uma mensagem que pareça um ataque pode nem sequer receber resposta. O TLS 1.2 ou posterior é obrigatório, e o cliente tem de verificar o certificado do servidor. A produção usa balanceamento por DNS, por isso resolva o nome do anfitrião a cada ligação em vez de fixar um IP.

Desde a versão 1.2, o endpoint suporta CORS, pelo que um POS baseado no browser o pode chamar diretamente. Decida onde fica a chave privada antes de alguém escrever esse JavaScript.

Respostas, falhas e a regra das 48 horas

Uma mensagem válida recebe uma resposta síncrona com um código de confirmação de 39 caracteres (POK), assinado pela administração fiscal. Verifique essa assinatura e guarde o POK com a venda. Uma mensagem inválida recebe um código de erro; -1 significa uma falha temporária, por isso volte a enviar mais tarde. Os problemas menores chegam como avisos, um deles quando a hora da venda está mais de duas horas adiantada em relação ao relógio do servidor. Os relógios dos quiosques desacertam-se. Sincronize-os.

O tempo limite de resposta é definido por si, nunca inferior a dois segundos. Se não chegar nenhum POK a tempo, a venda vai para uma fila. Segundo a apresentação do seminário, a repetição reutiliza o corpo original com um cabeçalho novo: novo UUID, indicador de primeira tentativa a false, nova hora de envio e a hora de venda original. Sai assim que a ligação regressa e, no máximo, 48 horas depois da venda. A obrigação também não caduca às 48 horas: uma mensagem atrasada continua a ser devida.

Por isso, a fila tem de sobreviver a um reinício e lançar um alerta bem antes de passarem as 48 horas. Mais uma armadilha: se o certificado expirar enquanto houver vendas à espera, estas têm de ser assinadas com um certificado válido nesse momento.

Reembolsos, correções e duplicados

Um reembolso ou uma anulação é uma mensagem nova com um montante negativo, com a data atual e sem ligação à original. Uma correção é ou uma anulação seguida da mensagem certa, ou uma única mensagem com a diferença. Os duplicados são detetados por seis campos (EIČ, unidade, dispositivo, número sequencial, hora da venda e total), pelo que uma repetição com o mesmo corpo é segura. Uma repetição que gera um novo número sequencial é uma segunda venda.

Recibos

Menos trabalho do que no primeiro EET: não é exigido recibo para efeitos de EET, e o POK não tem de constar de nenhum. Retire qualquer código que atrase a impressão até chegar o POK. Quando emitir recibos ao abrigo da legislação de defesa do consumidor, mantenha o número sequencial do EET alinhado com o número do recibo; a especificação nota que, na prática, os dois costumam coincidir.

Casos-limite com que as cadeias se deparam

• Cartões pré-pagos, pulseiras e carteiras: o carregamento e cada consumo são registados, com os campos de montante adicionais preenchidos.
• Um pagamento, dois contribuintes: o exemplo da bomba de gasolina na apresentação (combustível vendido em nome de outra empresa, café por conta própria) exige duas mensagens, cada uma com os dados do respetivo contribuinte.

O calendário

• 5 de junho de 2026: publicação da documentação técnica.
• 1 de julho de 2026: abertura do playground. Entre 26 de julho e 26 de agosto, processou 170 389 transações de teste a partir de 624 endereços IP de clientes, 94,6 % delas processadas com êxito.
• 1 de novembro de 2026: o EET no DIS+, as unidades de registo e os certificados de produção.
• 1 de dezembro de 2026: arranque do MOJE eet.
• 1 de janeiro de 2027: a obrigação começa para todos ao mesmo tempo, sem faseamento.

O calendário oficial chama a janeiro um mês-piloto e acrescenta logo a seguir que já será registo normal. Um comunicado anterior descrevia o piloto como voluntário. Até isso ser esclarecido, planeie enviar mensagens reais a partir de 1 de janeiro.

A lei foi publicada na Coleção de Leis a 7 de outubro de 2026 como Lei n.º 180/2026 Sb.. Produz efeitos a 1 de janeiro de 2027; sete das suas secções entraram em vigor no dia seguinte à publicação.

Um plano de 90 dias

Outubro: âmbito e desenvolvimento.

1. Faça a lista de todos os pontos onde há dinheiro a mudar de mãos: caixas, quiosques, terminais portáteis, encomendas à mesa pagas no local, os seus próprios motoristas que recebem numerário. Atribua cada um a um contribuinte e a uma futura unidade de registo.
2. Escolha a arquitetura: assinar em cada dispositivo, ou ter um único serviço que assina e gere a fila para todos. O sistema aceita ambas. Numa cadeia, a solução central costuma ganhar: um só cofre de chaves, uma só fila, um só sítio para vigiar.
3. Desenvolva o gerador de mensagens, o assinador e a fila contra o playground, com os certificados de teste partilhados. Valide todas as mensagens face ao XSD na integração contínua.

Novembro: credenciais de produção.

4. A partir de 1 de novembro, ative o EET no DIS+, crie as unidades (importação em massa, se tiver muitas) e emita os certificados de produção. Guarde-os num cofre, não em pens USB.
5. A especificação fixa 1 de novembro de 2026 como a data de venda válida mais antiga em produção. Envie mensagens em modo de verificação com o certificado real: testam toda a cadeia sem registar uma venda.
6. Conclua os reembolsos, os fluxos pré-pagos, a renovação de certificados e os alertas sobre a idade da fila.

Dezembro: ensaio.

7. Implemente num único local. Desligue o cabo de rede na hora de ponta do almoço e veja a fila esvaziar-se depois.
8. Faça um teste de carga da sua hora de maior movimento através do assinador.
9. Congele as alterações antes do pico do Natal. Explique aos funcionários como é uma falha de ligação; se a fila funcionar, não têm de fazer nada.

Janeiro: o mês-piloto.

10. Reconcilie diariamente. Compare os totais do seu POS com as somas agregadas no DIS+, onde também pode pedir uma exportação CSV detalhada com todos os POK.

Onde obter ajuda

Desenvolvemos e alteramos integrações de POS: o gerador de mensagens e o assinador, a fila para falhas de ligação, o armazenamento e a renovação de certificados, a correspondência de unidades e a reconciliação com o DIS+. Quando o software de caixa é antigo e os autores já seguiram caminho, é no nosso serviço de manutenção de sistemas legados que esse trabalho começa. Se a sua própria equipa conhece o sistema mas lhe faltam mãos antes de janeiro, podemos reforçá-la com programadores.

Se gere as suas próprias caixas ou quiosques na Chéquia e ainda não enviou nenhuma mensagem para o playground, escreva para office@c9group.dev.