Liquidações de marketplace: pagamentos versus encomendas

Uma empresa que integrou as encomendas do seu marketplace no seu ERP resolveu um problema visível e herdou um problema invisível. As encomendas fluem, o armazém expede, as faturas existem. Depois o marketplace paga: um único valor líquido, que cobre algumas centenas de encomendas, menos comissões, taxas de expedição, encargos de publicidade, reembolsos processados segundo o calendário do marketplace, uma conversão cambial aplicada a uma taxa que não escolheu e, ocasionalmente, um ajustamento que refere um litígio que ninguém na empresa conhecia.

Essa única linha bancária tem de ser decomposta e feita corresponder a encomendas individuais, ou o razão de clientes nunca fica regularizado. Na maioria das empresas mid-market não é decomposta. Alguém lança o valor líquido numa conta transitória, o razão geral acumula contas a receber de marketplace não reconciliadas e a verdadeira rentabilidade do canal torna-se impossível de conhecer. Já encontrámos empresas com um saldo transitório que representa meses de atividade em marketplace e sem qualquer perspetiva realista de o saldar.

Este é um problema distinto da integração de encomendas e precisa do seu próprio desenho. Tratá-lo como uma extensão do fluxo de encomendas é o erro mais comum e mais caro nas finanças multicanal.

Por que é que isto importa

O custo imediato é não poder responder se o canal dá dinheiro. As taxas de marketplace são estratificadas e em parte variáveis: comissão por categoria, expedição por peso e dimensão, armazenamento por duração, publicidade por campanha, processamento de devoluções por evento. Sem decompor as liquidações ao nível da encomenda, tem rédito bruto e um recebimento líquido, e a diferença é um único valor sem explicação. As decisões sobre preços, sortido e investimento no canal passam então a ser tomadas com base numa margem bruta que ignora uma camada de custo material.

O segundo custo é o controlo. Uma conta transitória não reconciliada é um lugar onde os erros persistem sem deteção: uma taxa aplicada incorretamente, um reembolso processado duas vezes, um pagamento em falta por um valor que ninguém consegue rastrear. Os marketplaces cometem erros, e as empresas que não conseguem reconciliar não os conseguem detetar, muito menos contestá-los dentro do prazo permitido.

O terceiro é a auditoria e a fiscalidade. As transações de marketplace têm um tratamento de IVA que depende do fluxo — se o marketplace é considerado fornecedor, para onde se moveram as mercadorias, se o cliente era uma empresa ou um consumidor — e na UE esse tratamento tem vindo a mudar. Um processo de liquidação que não consegue produzir detalhe ao nível da encomenda não consegue sustentar a posição de IVA, e em Espanha e Portugal a granularidade de reporte esperada pelas autoridades fiscais aumentou, não abrandou.

Num relance: os componentes de uma liquidação

O padrão que torna isto tratável: alguns componentes estão ligados à encomenda e têm de chegar ao nível da encomenda, outros são de período ou de campanha e nunca devem ser forçados sobre encomendas. Tentar imputar uma taxa de armazenamento a encomendas individuais produz um número de aparência precisa e sem significado.

O que funciona e sobre o que ser honesto

O que funciona:

Tratar a reconciliação de liquidações como um processo próprio com um responsável próprio. Não um passo da integração de encomendas, nem parte da reconciliação bancária. Tem uma fonte de dados distinta — o relatório de liquidação do marketplace — e uma lógica de correspondência distinta.

Ingerir o relatório de liquidação, não apenas a linha bancária. O banco mostra um valor líquido; o relatório de liquidação mostra os componentes. A ingestão automatizada desse relatório é a base. As empresas que reconciliam apenas a partir do banco estão a tentar resolver o problema sem os dados.

Correspondência ao nível da encomenda para os componentes ligados à encomenda, contas de período para o resto. A comissão, as taxas de expedição e os reembolsos chegam à encomenda. Armazenamento, publicidade e taxas de plataforma são lançados nas suas próprias contas por período. Não force tudo ao nível da encomenda.

Reservas modeladas como contas a receber. Uma retenção é dinheiro que lhe é devido mais tarde, não um custo. Tratá-la como custo subavalia a margem e depois sobreavalia-a na libertação, produzindo dois meses errados em vez de um mês certo.

Decomposição baseada em agentes com uma verdadeira fila de exceções. É trabalho de grande volume, sujeito a regras, repetitivo e com um resíduo ambíguo persistente — o caso clássico de agente. O agente decompõe a liquidação, faz corresponder o que consegue e encaminha os ajustamentos sem explicação e os estornos sem referência com o contexto envolvente anexado.

Reconciliar todas as liquidações, sempre. Uma liquidação ignorada torna-se uma liquidação insolúvel. Os dados necessários para explicar uma discrepância têm um prazo de validade efetivo, tanto porque a janela de contestação do marketplace fecha como porque o contexto se torna irrecuperável.

Sobre o que ser honesto:

Os formatos dos relatórios de marketplace mudam sem aviso. São acrescentados campos, mudam nomes, aparece um tipo de taxa que não existia no trimestre anterior. Qualquer integração aqui precisa de monitorização e manutenção periódica, e deve falhar de forma ruidosa em vez de mapear silenciosamente uma taxa desconhecida para uma conta por omissão.

Haverá um resíduo que não reconcilia, e precisa de uma política para ele. Pequenas diferenças sem explicação são normais. Defina um limiar de materialidade, uma conta de abate e uma regra de aprovação, e reveja o agregado periodicamente para detetar um padrão em vez de investigar cada item.

O multi-marketplace multiplica o trabalho, não a complexidade. Cada marketplace tem o seu próprio formato de relatório, estrutura de taxas e cadência de liquidação, pelo que cada um precisa do seu próprio mapeamento. A lógica é semelhante; a configuração não é partilhada.

As acumulações pendentes históricas são caras de saldar e às vezes não vale a pena saldá-las por completo. Um saldo transitório que representa um ano de atividade pode custar mais a reconciliar do que aquilo que a informação vale. Reconcilie de uma data escolhida em diante e trate o saldo histórico como um exercício separado e delimitado no tempo, com um abate aceite.

O tratamento de IVA é genuinamente complicado e mutável. As regras de fornecedor presumido, os fluxos transfronteiriços e a direção da UE em matéria de reporte digital influem nisto. Confirme o tratamento com um consultor para os seus fluxos específicos em vez de o inferir do relatório de liquidação.

Quadro de decisão: por onde começar

Percorra por ordem. Pare na primeira correspondência.

1. Está a lançar os recebimentos de marketplace pelo líquido numa conta transitória?
Se sim, pare a acumulação antes de abordar qualquer coisa histórica. Desenhe uma reconciliação orientada para o futuro, defina uma data de início e delimite o saldo existente como um exercício separado.

2. Ingere automaticamente o relatório de liquidação do marketplace?
Se não, este é o pré-requisito. Sem o detalhe dos componentes, a reconciliação não é possível, por muito esforço que se faça.

3. Mapeou cada tipo de taxa para uma conta, com um tratamento definido?
Se não, faça-o antes de automatizar. Inclua uma regra deliberada para os tipos de taxa desconhecidos: devem ser encaminhados para uma fila de revisão, nunca para uma conta por omissão.

4. As reservas e retenções são tratadas como contas a receber e não como custos?
Se não, corrija o tratamento. Isto distorce a margem mensal nos dois sentidos e é um dos erros mais comuns que encontramos.

5. Existe correspondência ao nível da encomenda para comissões, taxas de expedição e reembolsos?
Construa isto a seguir. É o que torna a rentabilidade do canal respondível, o que normalmente é a razão pela qual o projeto foi financiado.

6. Os ajustamentos sem explicação têm um responsável, um limiar e uma política de abate?
Defina os três. Sem um limiar irá investigar itens imateriais indefinidamente; sem um responsável nada é investigado.

7. Tudo o acima e a reconciliação continua a consumir dias por mês?
O custo restante é quase certamente o desenho da fila de exceções e não a correspondência. Apresentar as exceções com contexto e resolução num clique é onde o tempo se gasta.

Custo e esforço indicativos

Assume uma instância de ERP e um a três marketplaces. Peça um orçamento para uma estimativa com âmbito definido.

Perguntas frequentes

Podemos reconciliar apenas a partir dos extratos bancários?
Não. A linha bancária é um valor líquido; os componentes existem apenas no relatório de liquidação. Tentar a reconciliação sem ele é a razão pela qual existem a maioria das contas transitórias.

Como tratamos os reembolsos liquidados num período diferente do da encomenda original?
Faça corresponder o reembolso à encomenda original independentemente do período, e deixe o tratamento contabilístico resolver o momento. Fazer corresponder os reembolsos ao período em que foram liquidados em vez da encomenda a que se referem torna a rentabilidade do canal por produto permanentemente errada.

As taxas de armazenamento e publicidade devem ser imputadas a produtos?
Para a contabilidade estatutária, não: são custos de período. Para a análise comercial, uma imputação pode ser informativa se a base estiver documentada e for aplicada de forma consistente, e se todos os que leem o número compreenderem que é uma imputação e não um custo rastreado.

E se os valores do marketplace estiverem errados?
Acontece, e detetá-lo é um dos argumentos mais fortes para fazer isto como deve ser. A reconciliação dá-lhe a evidência e a oportunidade temporal para contestar dentro do prazo. As empresas que não conseguem reconciliar absorvem isto em silêncio.

Vale a pena para um canal de marketplace pequeno?
Se o canal for pequeno e estável, um tratamento mensal simplificado com uma variação aceite pode ser proporcionado. No momento em que o canal se torna material para o rédito, ou em que precisa de saber se é rentável, exige uma reconciliação adequada — e nessa altura a acumulação pendente já cresceu.

Fecho — Próximos passos

A reconciliação de liquidações de marketplace é a parte das finanças multicanal que é descoberta em vez de planeada. A integração de encomendas é visível e é financiada; o dinheiro que chega com outra forma três semanas depois é o problema de fecho de alguém, até a conta transitória ser grande o suficiente para ser uma questão de conselho de administração.

Um primeiro passo útil: tome a sua liquidação mais recente, descarregue o relatório e tente decompô-lo manualmente até ao nível da encomenda. Levará uma tarde e dirá exatamente quais os tipos de taxa que atualmente não consegue explicar — que é o âmbito do trabalho e, normalmente, o momento em que o saldo transitório deixa de ser um mistério.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora NetSuite que serve clientes mid-market em toda a Península Ibérica. Especializa-se em ligar sistemas CRM e ERP para fluxos de order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento documental e a reconciliação, transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são ao nível do editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação sobre rédito e reconciliação — https://docs.oracle.com/en/cloud/saas/netsuite/
• Comissão Europeia, regras de IVA para o comércio eletrónico e disposições sobre fornecedor presumido — https://taxation-customs.ec.europa.eu
• Comissão Europeia, VAT in the Digital Age (ViDA) — requisitos de reporte digital — https://taxation-customs.ec.europa.eu
• Agencia Tributaria (Espanha), obrigações de reporte do SII — https://sede.agenciatributaria.gob.es
• IFRS Foundation, IFRS 15 Revenue from Contracts with Customers — considerações sobre principal versus agente — https://www.ifrs.org
• Experiência de projetos da Atypical Tech, reconciliação de marketplace no mid-market da Península Ibérica