Contabilidade embutida: Construir ou comprar para plataformas digitais (marketplaces)

Uma lista de requisitos, um modelo de custos com pressupostos explícitos e as condições em que cada resposta está correcta.

Mais tarde ou mais cedo, todas as plataformas digitais (marketplaces) acabam por construir um livro-razão (ledger). A única questão é se o fazem de forma deliberada, como um sistema com controlos, ou por mero acaso, como uma coluna de balance onde três serviços escrevem e em que ninguém confia totalmente.

Este artigo serve para tomar essa decisão de forma consciente. Aborda o que o trabalho realmente implica, como calcular o custo sem ilusões e as condições específicas em que construir é a resposta certa - porque, por vezes, é mesmo.

O que significa "contabilidade embutida" (embedded accounting) neste contexto

Contabilidade embutida significa que a contabilidade vive dentro do seu produto, em vez de numa aplicação separada que alguém abre à parte. O seu software regista os lançamentos à medida que os acontecimentos ocorrem, os seus utilizadores veem o que a sua interface lhes mostra e ninguém precisa de exportar uma folha de cálculo para um técnico oficial de contas no final do mês.

Para um marketplace, isto abrange, no mínimo: pagamentos de compradores recebidos, montantes devidos a vendedores, comissões obtidas, comissões de processamento de pagamentos, IVA sobre as suas comissões e sobre a transação subjacente, reembolsos, contestações de pagamento (chargebacks), reservas, pagamentos a parceiros (payouts) e a reconciliação de tudo isto com um banco ou fornecedor de pagamentos.

O que está realmente a construir se decidir avançar por conta própria

O livro-razão propriamente dito é a parte mais pequena. As equipas costumam estimar apenas o primeiro item e só mais tarde descobrem o resto.

Componente	O que envolve
Diário e contas	Lançamentos equilibrados, plano de contas, tipos de conta, saldos de abertura
Imutabilidade	Armazenamento de apenas escrita (append-only), fluxo de estorno e correcção, sem edições diretas
Controlo de período	Encerramento, fecho, rejeição de lançamentos tardios, reabertura controlada com registo de auditoria
Idempotência	Chaves, armazenamento de respostas anteriores, detecção de colisões em dados alterados
Gestão de valores monetários	Aritmética decimal exata ou em unidades fracionárias (minor units), códigos de moeda, taxas de câmbio e respetiva origem, contas de arredondamento
Motor de IVA	Taxas por país com datas de validade, local da transação, inversão do sujeito passivo (reverse charge), regras de fornecedor presumido (deemed supplier), isenções
Verificações de identificação fiscal para IVA	Validação com o registo oficial, cache, carimbos temporários, identificadores de pedido, fila de revisão manual para falhas
Documentos	Faturas, notas de crédito, numeração sequencial sem saltos por série e ano, geração de PDF, entrega
Faturação eletrónica	Formatados estruturados como EN 16931 UBL e formatos nacionais por país, quando obrigatórios
Ingestão bancária	Importação de extratos ou ligação bancária com consentimento, desduplicação de transações já importadas
Reconciliação	Regras de correspondência, pontuação, correspondências parciais, exceções que um humano possa resolver
Pagamentos (payouts)	Geração de ficheiros de pagamento, lotes de pagamento, reconciliação de pagamentos com os itens subjacentes
Relatórios	Balancete, balanço, demonstração de resultados, fluxo de caixa, resumos de IVA, saldos em dívida por antiguidade
Registos fiscais e declarações	Tudo o que os países onde opera exigem, no formato aceitado pela autoridade tributária
Auditoria	Ator, ação, entidade e a própria alteração, consultável, para cada mutação
Retenção e exportação	Retenção de dez anos para registos OSS, exportação completa de dados, arquivo defensável

Aproximadamente duas destas dezassete linhas correspondem à parte que a maioria das equipas imagina quando diz "vamos criar um livro-razão".

Calcular os custos com honestidade

Qualquer número aqui depende da sua equipa, pelo que deve encarar o que se segue como um método e não como um orçamento fechado. Pegue nos componentes acima, atribua a cada um uma estimativa em semanas de engenharia com base na velocidade da sua equipa e aplique três correções que as estimativas normalmente ignoram.

Primeira correção: os componentes de conformidade não são únicos. As taxas mudam, os limiares mudam, os formatos mudam e o pacote do IVA na Era Digital (VAT in the Digital Age) da União Europeia traz obrigações com prazos definidos - alterações ao OSS e IOSS a partir de 1 de janeiro de 2027, regras alargadas para plataformas a partir de 1 de julho de 2028 e reporte digital transfronteiriço a partir de 1 de julho de 2030. Construir significa assumir a responsabilidade por cada uma dessas migrações.

Segunda correção: o trabalho de correção dura mais do que o trabalho de novas funcionalidades. A primeira versão lida com o cenário ideal (happy path). A longa cauda é composta por reembolsos após o pagamento, reembolsos parciais, chargebacks que chegam semanas mais tarde, arredondamentos de moeda, webhooks duplicados e ficheiros de liquidação que não coincidem com os seus registos. É aqui que o calendário desaparece.

Terceira correção: o contabilista é um interveniente ativo, não um revisor. Contas que um profissional de contabilidade não assine não estão terminadas, e esse feedback chega tarde num processo de desenvolvimento próprio.

Uma verificação de realidade útil: calcule o custo da construção mais económica credível - livro-razão, correções, fecho de período, idempotência, gestão de dinheiro, IVA de um país, faturas, importação bancária, reconciliação e um conjunto básico de relatórios - e compare-o com um ano de um serviço com custos baseados no uso. Os planos publicados da Nordlet começam em 10 € por mês com 3.000 pedidos incluídos e vão até 300 € por mês com 200.000 pedidos. Se construir custar uma fração do salário anual de um único engenheiro, há um argumento genuíno a favor da construção. Se custar vários anos-engenheiro mais manutenção permanente, a comparação nem sequer se coloca, e torna-se ainda mais desfavorável a cada ano que passa e cujas regras mudam.

Quando construir faz genuinamente sentido

Três casos, todos eles reais.

O seu livro-razão é o seu produto. Se está a construir uma plataforma de pagamentos, um produto bancário ou uma carteira digital (wallet) em que o comportamento do saldo sob concorrência é o seu elemento diferenciador, o livro-razão é central e deve pertencer-lhe. Considere produtos de infraestrutura de livros-razão em vez de construir de raiz, mantendo a contabilidade estatutária separada.

O seu modelo não se ajusta a nenhum sistema contabilístico. Algumas plataformas têm estruturas de liquidação genuinamente invulgares - divisões entre várias partes com libertações condicionais, depósito em garantia (escrow) com marcos faseados, políticas de reservas complexas. Se nenhum produto o modelar e as soluções alternativas forem piores do que construir, então construa.

O seu volume torna a precificação por utilização inadequada. A um volume de transações suficientemente extremo, a precificação por pedido deixa de ser atraente. Simule-o com números reais antes de o assumir, pois o conceito de "extremo" aqui é superior ao que a maioria das plataformas atinge.

Quando comprar é a melhor opção

Comprar ganha quando a contabilidade é necessária, mas não diferenciadora, que é o caso mais comum. Ninguém escolhe o seu marketplace porque os seus lançamentos de diário são elegantes. Só dão por isso quando as contas estão erradas.

Comprar também é a decisão certa quando as suas obrigações abrangem vários países. As regras de IVA por país, a retenção de provas e os mandatos de faturação eletrónica constituem um fluxo de manutenção permanente, e um fornecedor amortiza esse trabalho por todos os clientes. A Nordlet disponibiliza IVA da UE por país com validação VIES, apuramento de declarações OSS e IOSS, registos i.SAF e EN 16931 UBL para a rede Peppol como parte do produto, e não como um projeto que tenha de calendarizar.

O caminho intermédio que a maioria das equipas acaba por adotar

A resposta prática normalmente não passa por nenhum dos extremos. É a seguinte: compre o livro-razão, construa o fluxo de trabalho.

O sistema de suporte contabilístico gere os lançamentos, o tratamento fiscal, os documentos, o fecho de período e a trilha de auditoria (audit trail). O seu produto gere tudo o que os seus utilizadores veem e todas as regras de negócio específicas da sua plataforma - quando os fundos são libertados, qual é a política de reservas, como as disputas são geridas, o que o painel do vendedor exibe. Chame a API de contabilidade nos momentos em que o dinheiro é cativado e mantenha na sua posse as partes que lhe pertencem verdadeiramente.

Essa fronteira também resiste melhor à mudança do que as alternativas. Um novo país implica adicionar configuração em vez de um novo projeto. Uma nova política de pagamentos é código seu, e não um pedido a um fornecedor.

O que deve decidir antes de se comprometer

O seu livro-razão é um elemento diferenciador ou uma obrigação? Seja honesto; na maioria dos casos, é uma obrigação.
Quantos países e o que é que cada um exige? Apenas taxas, ou declarações, ou registos, ou submissão.
Qual é a sua estratégia para correções? Os reembolsos após o pagamento e os chargebacks tardios são os casos que expõem um design frágil.
Quem assina as contas? Envolva essa pessoa antes de o design estar fechado, e não depois.
Qual é o plano de retenção de dez anos? Os registos OSS devem ser guardados durante dez anos a contar do final do ano da transação, e um arquivo é um sistema, não uma cópia de segurança.
Como será uma migração daqui a três anos? Em ambas as direções. Crie uma exportação de teste no primeiro dia e mantenha-a a funcionar.

FAQ

Quanto tempo demora a construir um livro-razão para um marketplace?

Uma primeira versão que publique lançamentos equilibrados pode estar a funcionar em poucas semanas. Uma versão que lida com reembolsos após o pagamento, chargebacks tardios, arredondamentos multimoeda, webhooks duplicados de fornecedores, fecho de período e uma auditoria que um contabilista aceite demora substancialmente mais, e a manutenção nunca mais acaba. Estime o segundo caso, porque é isso que a produção significa.

Podemos começar com uma coluna de `balance` e migrar mais tarde?

Pode, e muitos fazem-no, mas planeie a migração para ser mais difícil do que a construção original. Reconstruir o histórico a partir de um saldo mutável só é possível se tiver guardado cada evento que o alterou - o que significa, no fundo, que já tinha um livro-razão.

Uma API de contabilidade embutida substitui a nossa equipa financeira?

Não. Elimina o registo manual e a reconciliação. Alguém continua a fechar o mês, a analisar exceções, a tomar decisões de julgamento e a submeter declarações.

E quanto ao RGPD se o livro-razão for imutável?

Mantenha os factos monetários e as referências pseudónimas nos registos imutáveis, e os dados pessoais num sistema separado com o seu próprio processo de retenção e eliminação. A imutabilidade aplica-se ao evento financeiro, e não a cada atributo associado ao mesmo.

O software de contabilidade de código aberto (open-source) é uma opção intermédia viável?

É uma opção real, e altera o custo em vez de o eliminar: assume o alojamento, as atualizações, a localização por país e as atualizações de conformidade por sua conta. Calcule esses custos antes de considerar a poupança na licença como o quadro completo.