Um pagamento com cartão chega aos seus livros através de um relatório do adquirente que já identifica a encomenda. Uma transferência de USDC chega-lhe apenas com um endereço, um montante e um hash de transação, e mais nada. A conciliação de pagamentos em cripto funciona quando a fatura contém a referência do negócio, porque a transferência não consegue fazê-lo.
Este guia destina-se às equipas financeiras e operacionais de comerciantes, PSP e EMI que aceitam stablecoins e liquidam em euros. Enumera os campos de que cada registo de fatura necessita, como tratar pagamentos parciais e pagamentos com a moeda errada, como os webhooks e a API alimentam o livro-razão, e que regras da UE determinam durante quanto tempo tudo isto deve ser conservado.
Momentos-chave
Em resumo
- Uma transferência ERC-20 contém apenas remetente, destinatário e montante. A referência da encomenda tem de constar da fatura, e não do pagamento.
- Indique o preço da fatura em EUR e registe esse valor em euros. O montante em cripto é um número derivado que guarda para a trilha de auditoria.
- A maior parte do trabalho está nas exceções: pagamentos parciais, faturas expiradas, a moeda errada. Reveja-as diariamente, e não no fecho do mês.
- Use o webhook como gatilho, releia a fatura pelo ID como fonte de verdade, e extraia a lista de faturas todas as noites como rede de segurança e como origem da sua exportação CSV.
Porque é a conciliação de pagamentos em cripto mais difícil do que com cartões?#
A conciliação de pagamentos em cripto é mais difícil porque uma transferência em blockchain não tem um campo para o número da sua encomenda. Na Ethereum, o padrão de token ERC-20 (EIP-20) define o evento de transferência como `Transfer(address _from, address _to, uint256 _value)`: quem enviou, quem recebeu e quanto. Não existe nota, número de fatura nem nome do cliente.
Os pagamentos bancários e com cartão são construídos ao contrário. Uma transferência SEPA tem um campo de informação para preenchimento pelo ordenante, e o relatório de liquidação de um adquirente lista cada transação com cartão pela referência do comerciante. O seu sistema contabilístico faz a correspondência por essa referência.
Com stablecoins, há mais três obstáculos:
- O montante raramente é redondo. Uma fatura de 250 EUR convertida em USDC passa a ser um valor como 279,2846 USDC, pelo que duas faturas de valor semelhante podem parecer iguais.
- O pagamento não fica final de imediato. A Ethereum produz um bloco a cada 12 segundos, mas, segundo o ethereum.org (página atualizada em outubro de 2026), «demora cerca de 15 minutos para que um bloco da Ethereum seja finalizado.» Uma transferência pode estar visível e, ainda assim, não contar.
- Os ordenantes cometem erros. Enviam um valor insuficiente, enviam duas vezes, enviam outra moeda ou pagam depois de a fatura ter expirado.
Por isso, a ligação tem de existir antes de o ordenante pagar: uma fatura por encomenda, com o seu ID de encomenda e o seu próprio endereço de pagamento, para que cada transferência recebida caia num registo que já sabe a que se destina.
Que campos precisa cada registo de fatura em cripto?#
Cada fatura precisa de um conjunto fixo de campos que relacionem quatro elementos: a sua encomenda, o preço em euros, a transferência na blockchain e o estado final. Se algum faltar, alguém acaba por fazer a correspondência manualmente. A tabela abaixo usa os nomes dos campos da API de faturas da ItisPay; outros prestadores usam nomes diferentes para as mesmas ideias.
| Campo | O que contém | Porque é que a contabilidade precisa dele |
|---|---|---|
| invoice_id | ID único atribuído pelo prestador | Chave primária de cada pesquisa e de cada linha do livro-razão |
| order_id | O número da sua encomenda ou contrato, único por encomenda | A ligação ao seu ERP, loja ou CRM; a referência que os cartões lhe dão gratuitamente |
| order_name | Breve descrição da encomenda | Permite a uma pessoa verificar uma exceção sem abrir a loja |
| fiat_amount, fiat_currency | Preço em EUR | A receita que regista |
| currency, crypto_amount | Moeda faturada e montante devido | Mostra o que foi pedido ao ordenante que enviasse |
| actual_crypto_amount_paid | O que efetivamente chegou | Deteta pagamentos em falta e em excesso |
| currency_paid | Moeda utilizada, se diferente da faturada | Assinala pagamentos com moeda errada para revisão |
| network, address | Rede blockchain e endereço de pagamento | Comprova para onde foi enviado o dinheiro; necessário para qualquer rastreio ou reembolso |
| transactions (tx_hash, amount, status) | Uma linha por transferência recebida | Uma fatura pode receber várias transferências; cada hash é a sua prova on-chain |
| status | new, pending, completed, expired, cancelled, paid_partial | Decide se regista, envia, cobra ou fecha |
| created_at, updated_at, expires_at | Carimbos de data/hora | Corte no fim do mês e prova de quando a encomenda foi paga |
Dois destes campos fazem a maior parte do trabalho. `order_id` é a referência que uma transferência em blockchain não consegue transportar, por isso defina-a a partir do seu próprio sistema e torne-a única por encomenda, nunca por cliente. A lista `transactions` é importante porque uma fatura nem sempre é paga de uma só vez: cada transferência tem a sua própria linha com um hash e um estado, para que consiga ver quais as transferências que compõem o montante pago.
Guarde o montante em cripto com todas as casas decimais numa coluna separada. O seu livro-razão geral trabalha em cêntimos de euro; as colunas de cripto são prova, não valores contabilísticos.
Que montante em euros se regista na contabilidade?#
Registe o preço em euros indicado na fatura. Quando a fatura é emitida em EUR, o prestador converte-a para um montante em criptoativos à taxa atual, e o pagador envia esse montante. Se o pagamento for liquidado em euros na sua conta, o valor em euros da fatura é a sua receita, e o montante em cripto é apenas um detalhe técnico de como o pagamento chegou.
Esta é a principal razão pela qual as equipas que aceitam pagamentos em cripto automaticamente com conversão para EUR raramente precisam de contabilidade de criptoativos: não há moeda no balanço para avaliar no fecho do mês.
A situação muda se mantiver as stablecoins. O Comité de Interpretações do IFRS decidiu em junho de 2019 que as detenções de criptomoedas se enquadram na IAS 2 (inventários) quando detidas para venda no decurso normal da atividade, e na IAS 38 (ativos intangíveis) nos restantes casos. A sua definição de criptomoeda exclui ativos que criam um contrato entre o detentor e outra parte. O USDC é diferente: a Circle declara que é "resgatável 1:1 por dólares norte-americanos" e, desde julho de 2024, a Circle emite USDC e EURC na UE como tokens de moeda eletrónica ao abrigo de uma licença de moeda eletrónica da entidade reguladora francesa ACPR. A classificação de uma stablecoin detida é uma questão para o seu auditor. Liquidar em EUR à receção deixa essa questão de lado.
Como lidar com pagamentos parciais e moedas erradas?#
Trate cada fatura que não esteja em `completed` como uma exceção, com um responsável e um prazo. A maior parte do esforço de conciliação de pagamentos em cripto concentra-se aqui; uma fatura totalmente paga concilia-se por si.
Eis o que cada estado significa para a área financeira, usando os estados do ItisPay:
| Estado | O que aconteceu | O que faz a área financeira | Enviar ou libertar? |
|---|---|---|---|
| new | Fatura aberta, nada recebido | Nada a registar | Não |
| pending | Transferência detetada, ainda não final | Aguardar a mudança de estado | Não |
| completed | Pago na totalidade | Registar a receita ao preço em EUR e libertar a encomenda | Sim |
| paid_partial | Parte do valor foi recebida | Pedir o restante, reembolsar ou encerrar por acordo | Depende |
| expired | O prazo expirou sem pagamento integral | Encerrar a encomenda; verificar transferências tardias | Não |
| cancelled | Anulou a fatura | Sem lançamento; reemitir se o cliente ainda quiser pagar | Não |
Pagamentos parciais#
Um pagamento parcial significa normalmente que a carteira ou a plataforma de câmbio do pagador cobrou uma comissão sobre o montante, ou que o pagador o introduziu incorretamente. O ItisPay regista cada transferência separadamente, pelo que uma segunda transferência pode completar a fatura. A fatura tem também a definição `allowed_error_percent`: uma pequena tolerância, configurada por fatura, para que um pagamento que fique ligeiramente aquém continue a contar como pago. Defina-a uma vez como política, por exemplo num nível que também aceitaria anular numa transferência bancária, e não a altere caso a caso.
Se o restante nunca chegar, decida dentro de um número fixo de dias: aceite a diferença e anule-a, reembolse o que foi recebido ou cancele a encomenda. Registe a decisão no registo da fatura, para que o auditor perceba porque é que uma encomenda paga tem menos dinheiro associado.
Moeda errada ou pagamento tardio#
Quando um pagador envia uma stablecoin diferente da faturada, o campo `currency_paid` mostra-o. Não registe automaticamente: verifique o montante e o valor em euros e depois aceite-o ou reembolse-o. Uma transferência para uma fatura expirada é semelhante. O dinheiro está na blockchain, mas a sua encomenda está encerrada, pelo que alguém tem de decidir se reabre a encomenda ou devolve os fundos. Se anular uma encomenda do seu lado, cancele a fatura através da API (uma atualização de estado), para que os seus registos a mostrem como encerrada antes de chegar qualquer pagamento tardio.
Como devem os webhooks e a API alimentar a conciliação de pagamentos em cripto?#
Use três camadas: o webhook informa que algo mudou, uma nova leitura da fatura indica o que é verdadeiro, e uma consulta noturna de todas as faturas apanha tudo o que as duas primeiras deixaram passar.
- Cada fatura pode ter um `callback_url`; o prestador envia para aí as atualizações de estado. Trate a mensagem como um gatilho, não como prova.
- Em cada webhook, chame `GET /invoices/{invoice_id}` e atue com base no estado e nos montantes dessa resposta. Isto protege-o de chamadas forjadas ou repetidas ao seu endpoint, uma vez que o pedido à API exige a sua chave de API.
- Torne o handler idempotente: o mesmo estado pode chegar duas vezes. Associe o lançamento no seu razão a `invoice_id` mais o estado, para que uma repetição não altere nada.
- Todas as noites, liste as faturas ordenadas por `updated_at`, das mais recentes para as mais antigas, e recue até à sua última execução; volte também a verificar todas as faturas que continuem em `new`, `pending` ou `paid_partial`. Compare-as com o seu razão. Qualquer fatura paga nos registos do prestador mas aberta no seu é uma exceção.
Para testes, o ItisPay disponibiliza um endpoint que simula uma mudança de estado numa fatura, e outro que reenvia o último webhook por `invoice_id` ou `order_id`. Use o reenvio quando o seu servidor esteve em baixo. As equipas que encaminham vários métodos de pagamento por uma camada de orquestração de pagamentos aplicam o mesmo padrão a todos os canais.
Como se cria uma exportação CSV para a contabilidade?#
Crie a exportação a partir da API de lista de faturas, com uma linha por fatura e uma linha por transferência. No ItisPay, `GET /invoices` filtra por estado, moeda e data de criação, ordena por data ou montante, e devolve até 100 faturas por página, com o número de páginas. Um pequeno script pode percorrer as páginas de um dia ou de um mês e escrever as colunas a partir da tabela de campos acima.
Dois ficheiros funcionam melhor do que um:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. É este o ficheiro que o contabilista importa e cruza com as vendas.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. É o ficheiro de prova para o auditor.
Importe o ficheiro de faturas para a sua ferramenta de contabilidade da mesma forma que importaria um relatório de liquidação de cartões: uma linha por encomenda, em euros, usando o ID da encomenda como chave de correspondência.
Que regras da UE moldam os registos de pagamentos em criptoativos?#
Três regras da UE definem o contexto. Nenhuma delas torna um comerciante num prestador de serviços de criptoativos (CASP), mas determinam que dados existem e durante quanto tempo são conservados.
- Regulamento (UE) 2023/1113 relativo às transferências de fundos. Desde 30 de dezembro de 2024, o prestador de serviços de criptoativos do ordenante deve garantir que cada transferência é acompanhada de informações sobre o ordenante e o beneficiário, como nomes e endereços em blockchain (artigo 14.º). Os dados seguem com a transferência, e não dentro dela. Para transferências superiores a 1 000 EUR de ou para uma carteira autohospedada, o prestador do lado relevante deve avaliar se essa carteira pertence ao seu próprio cliente (artigos 14.º e 16.º). Esta é a função do prestador licenciado, e é uma das razões pelas quais um pagamento pode ficar em análise.
- Conservação de registos. Ao abrigo da atual Diretiva AML (UE) 2015/849, artigo 40.º, as entidades obrigadas conservam os registos das transações durante cinco anos após o fim da relação de negócio ou da realização da transação. O novo Regulamento AML (UE) 2024/1624 mantém o prazo de cinco anos (artigo 77.º) e é aplicável a partir de 10 de julho de 2027.
- DAC8, Diretiva (UE) 2023/2226. A partir de 1 de janeiro de 2026, os prestadores de serviços de criptoativos comunicam às autoridades fiscais as transações em criptoativos dos seus utilizadores. Os seus próprios registos devem coincidir com o que o seu prestador comunica.
Se trabalhar através de um parceiro licenciado, é o parceiro que assume as obrigações de CASP ao abrigo do MiCA e destas regras, como se explica no nosso guia sobre a licença MiCA para CASP. Continua a ser responsável pelos seus registos de encomendas e pela parte que lhe cabe na trilha de auditoria.
Onde é que a reconciliação de criptoativos ainda precisa de uma pessoa?#
A automatização resolve o caso do pagamento integral. O restante exige um responsável identificado e uma política escrita e curta.
Onde não ajuda
- Os reembolsos são novas transferências de saída, e não reversões. Exigem um pagamento para um endereço ou IBAN, bem como registos próprios.
- Um pagador que envia a partir de uma conta numa exchange nem sempre pode ser identificado pelo endereço de envio. Faça a correspondência pela fatura, nunca pelo remetente.
- Pagamentos a uma fatura expirada, pagamentos duplicados e moedas erradas exigem todos uma decisão humana.
- As taxas de rede e os arredondamentos geram pequenas diferenças. Defina uma tolerância uma vez e mantenha-a.
Uma rotina diária de reconciliação de pagamentos em criptoativos em cinco passos#
Uma rotina diária curta torna o fecho mensal numa simples formalidade:
- Obtenha, a partir da API, as faturas criadas ou atualizadas desde a última execução e atualize os ficheiros de faturas e de transferências.
- Verifique se cada fatura `completed` tem uma encomenda paga correspondente na sua loja ou ERP, e vice-versa.
- Trabalhe a lista de exceções: `paid_partial`, pagamentos a faturas expiradas, moedas erradas. Feche cada uma com uma decisão escrita.
- Compare a liquidação em euros na sua conta bancária com a soma das faturas concluídas do período. A liquidação para um IBAN é onde os IBAN virtuais ajudam a separar fluxos por linha de negócio.
- Arquive ambos os ficheiros durante pelo menos cinco anos.
Se quiser aceitar stablecoins e receber euros sem construir esta infraestrutura por conta própria, a ItisPay oferece a API, a faturação e os dados de reconciliação: IDs de faturas e encomendas, hashes por transferência, estados e webhooks. O licenciamento, o KYC e a liquidação para o seu IBAN passam pelo nosso parceiro licenciado na UE, CASP + Instituição de Pagamento, e a maioria das equipas passa do KYB à primeira transação em menos de uma semana.
Este artigo tem fins exclusivamente informativos e não constitui aconselhamento jurídico ou regulamentar.
