Regras de contratos de receita

As regras de contratos de receita em Revenue Rules na barra lateral definem como o CryptaCount classifica as transações de entrada como receita. Estas regras automatizam a distinção entre diferentes fluxos de receita — recompensas de staking, taxas de validadores, rendimento de protocolos, receita de serviços — para que as transações sejam lançadas nas contas do razão corretas sem revisão manual.

Por que razão as regras de receita são importantes

As entidades cripto recebem frequentemente múltiplos tipos de rendimento através dos mesmos endereços de wallet:

• Recompensas de staking de operações de validadores
• Taxas de protocolo de propriedade de protocolos DeFi
• Receita de serviços de serviços SaaS ou de infraestrutura pagos em cripto
• Airdrops que podem ou não constituir receita dependendo da jurisdição
• Yield de lending ou fornecimento de liquidez

Sem regras, todos os tokens de entrada são predefinidos para uma classificação genérica. As regras de receita aplicam lógica de negócio para distinguir estas categorias automaticamente, garantindo:

• Lançamento correto em conta do razão (diferentes tipos de receita → diferentes contas)
• Categorização precisa na demonstração de resultados
• Tratamento fiscal adequado (o calendário de reconhecimento de receita pode diferir por categoria)
• Classificação pronta para auditoria com regras documentadas

Criar uma regra

Para criar uma nova regra de classificação de receita:

1. Navegue até Revenue Rules
2. Clique em Create Rule
3. Configure os critérios da regra:

Critérios da regra

Campo	Descrição
Name	Etiqueta descritiva (por exemplo, “Recompensas de Staking Ethereum — Acme Digital Holdings”)
Asset	Qual token ou moeda esta regra aplica (por exemplo, ETH)
Transaction type	Corresponder tipos específicos (STAKING_REWARD, CLAIM_REWARD, etc.)
Source address	Corresponder transações de endereços de remetente específicos (por exemplo, um contrato de staking conhecido)
Amount range	Filtro opcional de montante mínimo/máximo
Wallet	Opcionalmente restringir a wallets específicas

Ação da regra

Quando uma transação corresponde aos critérios, a regra atribui:

• Revenue classification — A categoria de receita específica (receita operacional, rendimento de staking, taxas de protocolo, etc.)
• GL account — Qual conta do razão lançar
• Economic intent — INCOME, OPERATIONAL, INVESTMENT, etc.

4. Guardar a regra

Testar regras

Antes de ativar uma regra, teste-a em relação aos seus dados de transações existentes:

1. A partir da vista de detalhe da regra, clique em Test Rule
2. O sistema avalia os critérios da regra em relação a todas as transações do espaço de trabalho
3. Os resultados apresentam:
   • Matched transactions — Quantas transações existentes seriam classificadas por esta regra
   • Sample matches — Uma pré-visualização das transações correspondidas com a sua classificação proposta
   • Conflicts — Transações que correspondem a esta regra E a outra regra existente

Testar antes de ativar

Testar é fortemente recomendado antes de ativar uma nova regra. Uma regra com critérios demasiado amplos pode classificar incorretamente transações em escala. Reveja os resultados dos testes para verificar:

• A contagem de correspondências é razoável (não inesperadamente alta ou baixa)
• As transações de amostra são genuinamente do tipo que pretende classificar
• Sem conflitos com regras de prioridade mais alta

Ativar/desativar regras

Cada regra tem um botão de ativar/desativar:

• Active — A regra é aplicada durante a classificação. As transações novas e reclassificadas serão avaliadas em relação a esta regra.
• Inactive — A regra existe mas não é aplicada. Utilize isto para desativar temporariamente uma regra sem a eliminar.

Ative/desative uma regra a partir da lista ou da vista de detalhe da regra. Desativar uma regra não desfaz classificações já feitas — apenas impede que transações futuras sejam correspondidas.

Prioridade de regras e conflitos

Quando múltiplas regras podem corresponder à mesma transação, o CryptaCount aplica regras por ordem de prioridade. A primeira regra correspondente ganha.

Gerir prioridade

As regras são avaliadas por ordem de lista. Arraste as regras para as reordenar e definir a prioridade. Coloque as regras mais específicas acima das mais amplas:

1. Contrato específico + ativo específico + wallet específica — Prioridade mais alta
2. Contrato específico + ativo específico — Prioridade média
3. Regras apenas por ativo ou tipo — Prioridade mais baixa, abrangência ampla

Resolução de conflitos

Se a funcionalidade de teste mostrar conflitos entre regras, resolva:

• Estreitando critérios — Adicionar mais condições à regra em conflito para que não se sobreponha
• Reordenando — Colocar a regra mais específica mais acima na lista de prioridade
• Fundindo — Combinar regras sobrepostas numa única regra com a classificação correta

Regras de espaço de trabalho e globais

A classificação de receita opera em dois níveis:

• Workspace rules — Criadas por utilizadores do espaço de trabalho, aplicam-se apenas a um espaço de trabalho
• Global rules — Regras ao nível da plataforma que se aplicam a todos os espaços de trabalho

As regras do espaço de trabalho têm precedência sobre as regras globais para o mesmo tipo de transação.

Integração com o pipeline contabilístico

As regras de receita alimentam o pipeline contabilístico:

1. Transação chega (de sincronização de wallet ou importação CEX)
2. Classificação automática executa, incluindo avaliação de regras de receita
3. Regra correspondida atribui a categoria de receita e conta do razão
4. Geração de lançamento utiliza a conta do razão atribuída para o lançamento de crédito
5. Relatórios financeiros refletem a receita classificada na linha correta da demonstração de resultados

Se nenhuma regra corresponder a uma transação de rendimento, cai para a lógica de classificação predefinida ou entra na fila de revisão manual.

Dica

Comece com regras para os seus fluxos de receita de maior volume. Para a Acme Digital Holdings, poderão ser recompensas de staking e taxas de protocolo. Adicione regras para casos especiais à medida que aparecem na fila de revisão — desta forma, constrói um conjunto de regras abrangente de forma incremental sem over-engineering inicial.