Custo de Integração de Contabilidade: Um Projeto por Fornecedor
As estimativas publicadas variam entre três semanas e doze meses por sistema de contabilidade, e o trabalho não se transfere de um fornecedor para o seguinte. Eis os números, as respetivas fontes e a alternativa.
Uma plataforma que se liga aos sistemas de contabilidade dos seus clientes cria uma integração por fornecedor. As estimativas publicadas para uma integração variam entre três a quatro semanas para uma primeira ligação funcional ao QuickBooks e seis a doze meses para o NetSuite, e todas as estimativas que encontrámos provêm de uma empresa que vende uma forma de evitar esse trabalho. O trabalho não se transfere: o QuickBooks, o Xero, o NetSuite e o Microsoft Dynamics 365 Business Central têm cada um o seu próprio método de início de sessão, tempos de vida dos tokens, sintaxe de consulta, limites de taxa, taxas e calendário de descontinuação. Seis fornecedores significam seis projetos e seis orçamentos de manutenção.
Este artigo reúne os valores publicados com as respetivas fontes, mostra onde os fornecedores diferem e explica a outra opção: manter a contabilidade dentro do seu próprio produto através de uma única API de contabilidade, para que haja apenas uma integração a desenvolver em vez de uma por fornecedor.
Quanto tempo demora uma integração de contabilidade
Ninguém publica um estudo neutro sobre o tempo de desenvolvimento de integrações. Os valores abaixo provêm todos de empresas que vendem APIs de contabilidade unificadas, pelo que têm incentivo para fazer com que o trabalho pareça avultado. Ainda assim, são os números mais específicos disponíveis e são coerentes entre si, desde que se separe a "primeira versão funcional" da "produção".
| Fonte | O que dizem | O seu interesse |
|---|---|---|
| Apideck (2026) | QuickBooks: "um programador competente consegue ter algo funcional em três a quatro semanas". A manutenção de mais de 35 conectores exige "no mínimo, um programador dedicado à manutenção das integrações". | Vende uma API unificada |
| Rutter (Abril de 2026) | "Três meses de engenharia por plataforma", a que a Rutter chama conservador. No caso do NetSuite, "o prazo estende-se de seis a doze meses". Um cliente estimou o QuickBooks em dois engenheiros durante um par de meses; demorou "pelo menos três meses com várias iterações". | Vende uma API unificada |
| Merge | 150 horas para criar uma integração e 300 horas por ano para a manter, com base num salário de 150.000 dólares. A Merge fixa o custo entre "50.000 e 150.000 dólares por ano". | Vende uma API unificada |
Há dois aspetos nestes números que importam mais do que os totais.
Em primeiro lugar, a diferença entre três semanas e três meses é a diferença entre uma demonstração e a produção. Uma ligação que cria uma fatura funciona rapidamente. Uma ligação que sobreviva à expiração de tokens, webhooks duplicados, limites de taxa, falhas parciais e a um cliente que volte a ligar um ficheiro de empresa diferente consome o resto do tempo. O nosso guia sobre como integrar uma API de contabilidade na nuvem numa plataforma SaaS enumera esse trabalho passo a passo.
Em segundo lugar, a manutenção é superior ao desenvolvimento no modelo da Merge: 300 horas por ano contra 150 horas numa única fase. Esse custo repete-se todos os anos para cada fornecedor que suportar.
Porque é que a segunda integração custa tanto como a primeira
Se os fornecedores expusessem a mesma interface, a segunda integração reutilizaria a maior parte da primeira. Não o fazem. A tabela compara quatro sistemas amplamente utilizados.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Início de sessão | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; autenticação baseada em tokens desativada para novas integrações a partir da versão 2027.1 | Apenas Microsoft Entra ID OAuth |
| Tempo de vida do token de acesso | 1 hora | 30 minutos | 60 minutos | Definido pelo Entra ID |
| Token de atualização (refresh token) | 100 dias renováveis, no máximo cinco anos | 60 dias renováveis | 7 dias | Definido pelo Entra ID |
| Estilo de consulta | Semelhante a SQL (SELECT … FROM Invoice), sem OR, sem junções (joins) |
REST com um parâmetro where |
SuiteQL (SQL) sobre REST, além de SOAP até 2028 | OData v4 |
| Limite de taxa | 500 pedidos por minuto e 10 por segundo por empresa | 60 por minuto, 5.000 por dia e 5 concorrentes por empresa | 5 a 20 pedidos concorrentes por conta, por nível de serviço | 6.000 pedidos por 5 minutos e 5 concorrentes por utilizador |
| Taxa de API separada | App Partner Program: escalão gratuito, depois de 300 a 4.500 dólares por mês | Planos de aplicação de gratuito até 1.445 dólares australianos por mês | Não encontrada; a concorrência adicional é vendida como licenças SuiteCloud Plus | Não encontrada |
Fontes: FAQ de autorização da Intuit, Limites e restrições da Intuit, Guia do App Partner Program da Intuit, Guia de OAuth 2.0 do Xero, Limites da API do Xero, Preços do Xero, Tokens OAuth 2.0 do NetSuite, Autenticação baseada em tokens do NetSuite, Limites operacionais do Business Central.
Os tokens expiram segundo quatro calendários diferentes
Uma integração tem de atualizar os tokens de cada fornecedor antes de estes expirarem e guardar o novo token de atualização todas as vezes, caso contrário o cliente tem de efetuar a ligação novamente. Os calendários diferem por um fator de catorze: um token de atualização do NetSuite dura sete dias, enquanto o do QuickBooks dura 100 dias. O QuickBooks acrescenta um limite estrito: os tokens de atualização são válidos por um máximo de cinco anos, pelo que as ligações de longa duração começarão a expirar numa data fixa, independentemente da utilização. Cada calendário exige a sua própria tarefa de atualização, o seu próprio tratamento de falhas e a sua própria mensagem de "por favor, volte a ligar" dirigida ao cliente.
Cada fornecedor tem a sua própria linguagem de consulta
A leitura de dados é a vertente onde o código mais diverge. O QuickBooks aceita um dialecto SQL restrito, sem OR e sem junções, devolvendo no máximo 1.000 registos por página. O Xero filtra através de uma expressão where no URL e aconselha testes de igualdade simples para organizações de grande dimensão. O NetSuite dispõe do SuiteQL, um dialecto SQL completo enviado para o seu próprio endpoint. O Business Central utiliza filtros OData. Uma consulta para localizar faturas por pagar num cliente resulta em quatro pedaços de código diferentes, cada um com a sua própria paginação e os seus próprios casos limite.
Cada fornecedor limita o tráfego de forma diferente
O QuickBooks e o Xero contam os pedidos por empresa e por minuto. O NetSuite conta os pedidos concorrentes em toda a conta, o que significa que a sua integração partilha o orçamento com qualquer outra integração executada pelo cliente, rejeitando as chamadas que ultrapassem o limite. O Business Central conta por utilizador numa janela de cinco minutos. Uma importação em massa segura num fornecedor é limitada noutrou, pelo que a limitação de velocidade (throttling) e a lógica de nova tentativa têm de ser programadas de raiz para cada fornecedor.
O acesso é uma relação comercial
Dois dos quatro fornecedores cobram agora pelo acesso à API com base no volume. O App Partner Program da Intuit contabiliza as chamadas "CorePlus", que cobrem a maioria das leituras de dados, bloqueando-as acima da quantidade incluída no escalão gratuito; os escalões pagos custam 300, 1.700 e 4.500 dólares por mês. O Xero adotou planos de aplicações pagos a 2 de março de 2026, variando desde um plano gratuito limitado a 5 ligações até 1.445 dólares australianos por mês para 10.000 ligações. Por conseguinte, o custo de funcionamento da integração depende de quantos clientes utilizam cada fornecedor e do volume de dados lidos.
Os fornecedores mudam as regras segundo o seu próprio calendário
Uma integração funcional hoje tem uma lista conhecida de reescritas obrigatórias já anunciadas:
- O NetSuite deixa de aceitar novas integrações que utilizem autenticação baseada em tokens a partir da versão 2027.1, e o aviso SOAP da Oracle indica que "com a versão 2028.2 do NetSuite, todos os endpoints serão desativados e as integrações baseadas em SOAP deixarão de funcionar" (Aviso SOAP do NetSuite).
- O Xero atribui âmbitos de permissão granulares às aplicações criadas a partir de março de 2026 e dá às aplicações existentes até setembro de 2027 para efetuarem a transição (Visão geral de OAuth 2.0 do Xero).
- O QuickBooks aplica o limite de cinco anos para os tokens de atualização descrito anteriormente e retirou as versões menores anteriores da API, tornando a versão 75 a base.
- O Business Central online deixou de aceitar chaves de acesso (autenticação básica) para serviços Web em 2022; as integrações tiveram de migrar para o Entra ID OAuth (Lista de descontinuação da Microsoft).
Nenhuma destas alterações acrescenta uma funcionalidade para os seus clientes. Cada uma representa tempo de engenharia gasto apenas para manter uma ligação existente a funcionar, multiplicado pelo número de fornecedores que suporta.
A aritmética de seis integrações
Se pegarmos na estimativa da Rutter de três meses de engenharia por plataforma e na estimativa da Merge de 300 horas de manutenção por ano, e as aplicarmos a seis sistemas de contabilidade, obtemos:
| Um fornecedor | Seis fornecedores | |
|---|---|---|
| Desenvolvimento | 3 meses de engenharia | 18 meses de engenharia |
| Manutenção anual | 300 horas | 1.800 horas, próximo de um engenheiro a tempo inteiro |
Estes são os pressupostos dos próprios fornecedores e não os nossos, sendo que apenas o NetSuite excederia estes valores. O ponto central é a estrutura de custos: o custo cresce com o número de fornecedores e a linha de manutenção nunca termina. Uma API unificada reduz o esforço de desenvolvimento, mas passa a depender da eficácia com que esta cobre as escritas e os casos limite de cada fornecedor, pagando por esta através de uma comissão por ligação ou por chamada. O nosso artigo sobre desenvolver versus comprar analisa estes custos de forma transparente.
Integrar uma vez: manter a contabilidade no seu produto
O modelo de conectores pressupõe que a contabilidade de cada cliente reside num sistema escolhido pelo próprio, e que a sua plataforma copia os dados para o mesmo. Existe um segundo modelo: a sua plataforma gere diretamente a contabilidade, através de uma única API de contabilidade, e apresenta-a na sua própria interface. É para isso que o Nordlet foi criado. Há apenas uma integração a desenvolver, independentemente do software de contabilidade que os seus clientes utilizavam anteriormente.
Eis o aspeto dessa integração única no Nordlet:
- Um formato de pedido uniforme. Cada operação é
POST /v1/{module}/{resource}/{action}. Cada açãolistaceita o mesmo corpo de filtro, ordenação e paginação, e todos os erros utilizam o mesmo invólucro. O código escrito para um endpoint funciona da mesma forma para os restantes. Consulte as convenções da API. - Chaves de API em vez de tokens de atualização. Uma chave pertence a uma empresa, possui âmbitos de permissão fixos, pode ter uma data de validade definida por si e pode ser revogada. Não há nenhum token de atualização para rodar e armazenar.
- Novas tentativas seguras. Cada alteração aceita um cabeçalho
Idempotency-Key. Repetir um pedido com a mesma chave devolve a resposta guardada em cache em vez de criar uma segunda fatura. - Webhooks assinados com novas tentativas. Os eventos são registados na mesma transação de base de dados da alteração, assinados com HMAC-SHA256 e reenviados durante cerca de 24 horas.
- Um limite de taxa público. 300 pedidos por minuto por chave de API, comunicados nos cabeçalhos
x-ratelimit-*. - SDKs tipados em nove linguagens, gerados a partir de uma única especificação OpenAPI. Consulte os SDKs.
- Empresas de testes (sandbox) ilimitadas numa única conta para testes de integração.
- Uma tabela de preços clara. Os planos são cobrados por utilização com base no número de pedidos, a partir de 10 euros por mês para 3.000 pedidos. Consulte os preços.
O livro razão de partidas dobradas, as faturas, a reconciliação bancária, as declarações de IVA e os relatórios ficam disponíveis através dessa mesma API, permitindo que a integração abranja a própria contabilidade e não uma mera cópia da mesma. A página de funcionalidades enumera o que está incluído, e o artigo o que é uma API de contabilidade explica o modelo em detalhe.
Clientes que já possuem contabilidade noutro sistema
Duas soluções substituem os conectores por fornecedor que uma plataforma teria de criar para estes clientes:
- Migração. O plano de contas de uma empresa, os parceiros, os saldos de abertura ou o histórico completo de diários, as faturas em aberto, os ativos fixos e o inventário são importados numa única chamada. Consulte migrar a partir de outro sistema.
- Ficheiros para o contabilista. Nos casos em que o contabilista do cliente trabalha no seu próprio software, o Nordlet exporta o razão nos formatos lidos por esse software: um lote de lançamentos DATEV (
POST /v1/reports/datev) para contabilistas alemães e um ficheiro SIE 4 (POST /v1/reports/sie) para contabilistas suecos. A exportação de ficheiros não requer início de sessão, atualização de tokens nem taxas por chamada cobradas pelo fornecedor de contabilidade.
Quando é que os conectores continuam a ser a resposta certa
Manter a contabilidade no seu produto não é a escolha certa para todas as plataformas:
- Se as equipas financeiras dos seus clientes exigirem que o respetivo sistema de contabilidade atual permaneça como o sistema de registo principal, necessitará de conectores para esse sistema, quer criados diretamente, quer através de uma API unificada.
- Se apenas precisar de enviar alguns documentos para a contabilidade do cliente, como uma fatura por encomenda, um conector direto para o fornecedor utilizado pela maioria dos seus clientes poderá ser suficiente.
- Se a maioria dos seus clientes utilizar um único fornecedor, uma única integração direta consome apenas um projeto, e não seis.
O argumento de integrar uma vez aplica-se quando a sua plataforma precisa de gerir a contabilidade dos seus utilizadores em vez de a espelhar: mercados que efetuam pagamentos a vendedores, plataformas que emitem faturas em nome dos seus utilizadores e produtos SaaS onde a escrituração contabilística faz parte do produto. Antes de escolher qualquer um dos caminhos, o nosso plano de testes pré-produção para uma API de contabilidade lista o que deve testar.
FAQ
Quanto tempo demora a criar uma integração com o QuickBooks?
A Apideck estima três a quatro semanas para uma primeira versão funcional desenvolvida por um programador competente. Um cliente da Rutter estimou dois engenheiros durante um par de meses e precisou de pelo menos três meses com várias iterações. O trabalho de produção - atualização de tokens, repetições, limites de taxa, religação e reconciliação - constitui a diferença entre esses valores.
Quanto tempo demora uma integração com o NetSuite?
A Rutter estima que o NetSuite exija entre seis a doze meses. O NetSuite acrescenta limites de concorrência a nível da conta, tokens de atualização válidos por sete dias, SuiteQL juntamente com SOAP, além das alterações anunciadas: proibição de novas integrações baseadas em autenticação por token a partir da versão 2027.1 e desativação dos endpoints SOAP na versão 2028.2.
Uma API de contabilidade unificada elimina o trabalho por fornecedor?
Reduz o esforço de desenvolvimento, uma vez que uma única interface abrange vários fornecedores. No entanto, não elimina as diferenças entre fornecedores: as escritas, os campos personalizados e os casos limite têm frequentemente um suporte irregular, e o preço da API unificada soma-se às taxas de API dos próprios fornecedores. As vantagens e desvantagens são abordadas no nosso guia de integração SaaS.
Quanto custa o acesso à API do QuickBooks e do Xero?
O App Partner Program da Intuit inclui um escalão Builder gratuito e escalões pagos de 300, 1.700 e 4.500 dólares por mês, com as leituras de dados contabilizadas acima de um montante incluído. Os planos de aplicações do Xero, em vigor desde 2 de março de 2026, variam desde um plano gratuito para 5 ligações até 1.445 dólares australianos por mês para 10.000 ligações, sendo os planos de maior dimensão sob consulta.
O Nordlet pode substituir as integrações com os sistemas de contabilidade dos meus clientes?
Quando a sua plataforma gere a contabilidade dos seus utilizadores, sim: cria uma única integração com a API do Nordlet em vez de uma por fornecedor de contabilidade. A contabilidade existente é importada numa única chamada e os contabilistas que utilizam software compatível com DATEV ou SIE recebem ficheiros de exportação. O Nordlet não sincroniza dados para o QuickBooks, Xero, NetSuite ou Business Central; se estes tiverem de permanecer como o sistema de registo principal, continuará a precisar de conectores para os mesmos.