- A confusão entre integração de verdade e ter API
- As formas de integração que existem na prática
- Por que a troca de arquivos texto segue sendo o caminho mais comum
- O que uma integração ERP precisa entregar, independente da forma
- Os três modelos de quem faz a integração
- O que avaliar antes de assumir que existe integração
No discurso de mercado de software corporativo, “integração com ERP” virou quase sinônimo de “API ERP”. A pergunta padrão em uma demonstração é “vocês têm API para o SAP?”. Resposta “sim” costuma ser tratada como problema resolvido. A realidade, entretanto, se mostra muito mais multifacetada.
O que se vê no parque instalado é bem diverso. Em produção, uma parte significativa das integrações entre plataformas corporativas e ERPs enterprise ainda funciona por troca de arquivos texto. Não é um detalhe arqueológico, é o jeito como o dado contábil efetivamente trafega em boa parte das empresas brasileiras de médio e grande porte hoje.
Tratar a mera existência de API como sinônimo de integração ERP simplifica o discurso, mas pode levar a expectativas equivocadas em uma decisão de compra. A escolha de plataforma corporativa para uma empresa enterprise não termina quando se confirma que há API. Na verdade é aí que a coisa começa.
A confusão entre integração de verdade e ter API
O termo “integração” descreve um resultado: a informação nasce em um sistema e termina em outro, no formato adequado, no momento certo, sem retrabalho manual. O termo “API” descreve um dos caminhos técnicos pelos quais esse resultado pode ser obtido.
A confusão entre os dois conceitos não é acidental. APIs modernas, baseadas em REST ou GraphQL, com documentação publicada e autenticação por token, viraram a referência técnica do que se entende por “sistemas conversando entre si”. Esse padrão é familiar para qualquer time de tecnologia formado nos últimos anos, e a literatura técnica o trata como o jeito natural de fazer integrações.
Mas ERPs enterprise são sistemas que coexistem com várias gerações tecnológicas simultaneamente. Uma instalação SAP em produção pode ter mais de duas décadas de história, com módulos customizados ao longo do tempo, processos de carga em batches consolidados, equipes internas de TI organizadas em torno de uma rotina específica de fechamento. Quando uma plataforma corporativa nova precisa se conectar a esse ERP, a forma técnica da conexão depende do que aquele ERP, naquela instalação, naquele cliente, permite e suporta.
A pergunta certa não é “vocês têm API?”. É “como a plataforma efetivamente se conecta ao nosso ERP, no estado em que ele está hoje, com as regras que ele segue”.
As formas de integração que existem na prática
Em produção, a integração entre plataforma corporativa e ERP pode acontecer de várias formas:
Troca de arquivos texto. A plataforma gera arquivos em formato definido (colunado de largura fixa, separado por vírgula, separado por tabulação ou outros) e os coloca em um local previamente acordado. Geralmente o servidor é SFTP e o arquivo é criptografado com PGP assimétrico. Há, entretanto, muitas outras combinações de tecnologias possíveis (FTP, FTPS, CIFS, WebDAV, PGP simétrico, AES-256, etc.). O ERP do cliente lê esses arquivos em rotina agendada e os processa para gerar lançamentos contábeis.
API REST ou SOAP. A plataforma faz chamadas a webservices publicados pelo ERP, autenticadas, com payload estruturado. Esse é o modelo que o discurso de mercado costuma chamar de “integração nativa”, e funciona em ERPs e instalações que oferecem essa interface de forma estável.
Webservices proprietários. Alguns ERPs expõem interfaces de comunicação que não são API REST padrão e tampouco SOAP no formato clássico. São interfaces específicas do produto, com bibliotecas próprias, autenticação específica e formato de mensagem definido pelo fabricante do ERP.
Bases intermediárias compartilhadas. A plataforma escreve dados em uma tabela ou conjunto de tabelas em um banco de dados intermediário, e o ERP lê dali. Na maioria dos casos esse banco é uma área de stage controlada pelo time de TI do cliente.
Exportação seguida de importação manual. O modelo mais elementar. A plataforma gera relatório em formato estruturado (geralmente CSV) e alguém da equipe financeira ou contábil faz a carga manual no ERP. Não é o caminho preferido, mas existe em produção, especialmente em empresas com volume baixo ou em situações de migração.
Cada uma dessas formas é uma integração legítima quando funciona. Não há ranking moral entre elas. Há trade-offs em prazo, manutenção, robustez, custo de implementação, sensibilidade a mudanças nos dois lados.
Por que a troca de arquivos texto segue sendo o caminho mais comum
A primeira reação de um leitor de área de tecnologia ao ver “arquivo texto” em 2026 pode ser surpresa. O modelo é antigo, antecede a internet em sua forma atual, e contrasta com o discurso de modernidade que cerca o software corporativo. Mas há razões operacionais legítimas para que ele continue sendo o caminho mais comum em uma boa parte do parque instalado.
A principal razão é a longevidade dos ERPs em produção. Uma empresa enterprise não troca de ERP a cada cinco anos. Implantações duram décadas, e dentro de uma mesma corporação convivem versões diferentes do mesmo ERP em filiais distintas. Sistemas antigos podem não ter API REST disponível, ou podem ter uma versão de API limitada que cobre só parte dos casos de uso. Arquivo texto, em contraste, é universal: praticamanete qualquer ERP consegue ler e gravar arquivos.
Mesmo dentro do mundo de arquivo texto, a variedade é grande. Não existe padrão único: colunados de largura fixa, delimitados por vírgula, pipe ou tabulação, com ou sem cabeçalho, com ordens de campo distintas e codificações de caracteres específicas. Cada instalação de ERP tem sua configuração própria, definida pela equipe de TI do cliente e pelo histórico da implantação. Integrar com um cliente novo, mesmo em um ERP familiar, exige sempre calibragem específica para a instalação dele.
E isso não é um argumento contra as APIs. É o reconhecimento que cada forma de integração resolve um problema, e que a escolha entre uma e outra depende do contexto técnico e organizacional do cliente, não da modernidade aparente da forma.
O que uma integração ERP precisa entregar, independente da forma
Olhar para as formas de integração sem perder de vista o que importa: a integração existe para entregar um resultado. Esse resultado tem características invariáveis, seja qual for a forma técnica usada.
Dado contábil correto. O lançamento que chega ao ERP precisa refletir corretamente a despesa que aconteceu na plataforma corporativa, com classificação, valor, data, centro de custo, contas contábeis e demais informações apropriadas para a contabilização da empresa.
Momento certo. A informação precisa chegar no ritmo que o processo da empresa exige. Para algumas empresas é em tempo real. Para a maioria é diário ou em ciclo de fechamento. O importante é que o ritmo da integração seja compatível com o ritmo da operação.
Formato que o ERP do cliente lê. Ponto óbvio mas frequentemente subestimado. Não basta enviar a informação. Ela precisa chegar exatamente no formato, na codificação e na ordem que o ERP do cliente foi configurado para receber. Variações pequenas (um caractere a mais no separador, uma codificação incorreta, uma ordem de campo trocada) quebram a integração.
Rastreabilidade. Cada lançamento gerado no ERP precisa ter origem reconstruível. Quando algo dá errado, é necessário saber exatamente qual arquivo ou chamada de API, em que data, com que conteúdo, para identificar a causa.
Tratamento de erro. Falhas acontecem. Arquivos podem ser corrompidos, APIs podem retornar erro, dados podem violar regras de validação do ERP. A integração precisa detectar esses casos, notificar quem possa resolver, e permitir reprocessamento sem duplicação.
Manutenção contínua. Tanto o ERP quanto a plataforma corporativa recebem atualizações ao longo do tempo. Quando um lado muda algo que afeta a integração, alguém precisa ajustar. Sem manutenção contínua, a integração funciona no início e falha em algum momento depois.
Esses critérios valem para integração por API, por arquivo, por base intermediária ou por qualquer outra forma. A escolha da forma é meio. A entrega desses critérios é o fim.
Os três modelos de quem faz a integração
A pergunta “vocês têm integração com ERP” admite três respostas honestas distintas, cada uma com implicação prática diferente.
Modelo A. O fornecedor da plataforma corporativa desenvolve e mantém a integração. O conector com o ERP, em qualquer das formas técnicas listadas anteriormente, é construído pela equipe do fornecedor, está em produção em outros clientes, é mantido frente a atualizações dos dois lados, tem documentação e suporte vinculados ao contrato. Quando um cliente novo entra, a integração entra junto, com calibragem específica para a instalação do cliente, mas sem partir do zero.
Modelo B. O cliente desenvolve a integração com equipe interna. A plataforma corporativa publica documentação técnica (API ou especificação de arquivo) e o time de TI do cliente constrói o conector entre essa interface e o ERP da empresa. A responsabilidade pelo desenvolvimento, pelos testes, pela manutenção contínua e pelo suporte fica do lado do cliente.
Modelo C. Um integrador terceiro contratado faz o trabalho. Uma consultoria especializada em integração com ERPs é contratada para construir o conector. O trabalho é projeto, com escopo, prazo e preço definidos no contrato com o terceiro. Após a entrega, a manutenção pode ficar com o terceiro, com o cliente ou com o fornecedor da plataforma, dependendo do acordo.
Os três modelos coexistem no mercado. O modelo A oferece o caminho mais curto entre contratação e operação. O modelo B oferece mais controle ao cliente, com custo de equipe interna. O modelo C cobre o caso em que nenhum dos outros é viável.
O ponto a verificar em uma decisão de compra é qual modelo o fornecedor está oferecendo, não apenas se a integração “existe”. A resposta simplista ‘existe API’ não diferencia entre os três modelos, e cada um implica esforço, prazo e custo distintos para a empresa cliente.
O que avaliar antes de assumir que existe integração
A escolha de plataforma corporativa para uma empresa enterprise envolve a pergunta sobre integração com o ERP em uso. A resposta a essa pergunta precisa ir além de “temos API”. Vale perguntar:
- Qual é a forma técnica da integração proposta para o ERP específico do cliente: arquivo, API, base intermediária, outra?
- Qual modelo de quem faz e mantém: o fornecedor da plataforma, equipe interna do cliente, integrador terceiro?
- Em quais clientes essa integração, nesse ERP, está em produção, há quanto tempo?
- Como é tratada a calibragem específica do formato exigido pela instalação do cliente?
- E por fim, quem é o responsável quando algo precisa mudar?
Essas perguntas não exigem resposta técnica complicada do fornecedor. Exigem honestidade sobre o que está pronto, o que precisa ser construído, e por quem. Empresas que avaliam plataforma com essa profundidade chegam à implantação sem surpresa. Empresas que avaliam apenas pela existência de API descobrem, depois, que entre a existência da API e o lançamento contábil funcionando há trabalho específico que alguém precisa fazer.
A integração com ERP enterprise não termina quando se confirma que existe. Começa aí.
