Por que os Despachantes Ainda
Digitam Dados do BL Manualmente em 2026

O BOL não é um documento — são dezenas

Pergunte a um transitário de médio porte quantos formatos de BOL de transportadoras eles lidam em um mês típico. A resposta raramente fica abaixo de uma dúzia. Cada transportadora — Maersk, MSC, CMA CGM, Hapag-Lloyd, ODFL, Estes, SAIA e as centenas de empresas de caminhões regionais que preenchem as lacunas — gera BOLs em seu próprio modelo, com suas próprias convenções de nomenclatura de campos, sua própria lógica de layout e seu próprio posicionamento de pontos de dados críticos. Um número de contêiner aparece no canto superior direito no BOL de uma transportadora, alinhado com o nome do navio em outra e em uma seção apenas de código de barras em uma terceira.

Os modelos públicos de BOL ilustram a amplitude do problema. O BOL padrão da ODFL agrupa as informações do embarcador e do consignatário no terço superior da página, com as linhas de unidades de manuseio abaixo. O BOL marítimo da Maersk organiza os mesmos dados verticalmente, com o porto de embarque e descarga em destaque em uma seção dedicada. Os BOLs genéricos de transportadoras do padrão GS1 US usam um número de BOL de 17 dígitos com um dígito verificador módulo 10 — um esquema de numeração que as transportadoras regionais de caminhões podem ignorar completamente. Um transitário que recebe BOLs de cinco transportadoras em uma única consolidação está olhando para cinco documentos estruturalmente diferentes, nenhum dos quais compartilha um modelo de dados comum.

Essa fragmentação não é resultado de negligência. É a consequência natural de um ecossistema de transportadoras no qual cada operador projeta seu BOL para atender ao seu próprio fluxo de trabalho operacional — recebimento no armazém, agendamento de doca, check-in do motorista — e não às necessidades de dados a jusante do transitário que deve agregar dados de embarque para clientes, declarações alfandegárias e faturamento. O BOL nunca foi projetado como um formato de transferência de dados. Ele foi projetado como um recibo e um contrato. O fato de os transitários precisarem extrair dados dele é um caso de uso secundário que os projetistas do BOL de cada transportadora não tinham incentivo para acomodar.

O resultado prático: um agente de carga que processa 200 embarques por mês em 20 transportadoras está, na prática, operando uma tradução manual de dados. Cada BL que chega em sua caixa de entrada apresenta os mesmos 20 campos de dados — nome do embarcador, endereço do consignatário, número do contêiner, número do lacre, nome do navio, número da viagem, porto de embarque, porto de descarga, peso bruto, número de volumes, descrição da mercadoria, classe de frete, taxas — organizados em uma ordem espacial diferente, com rótulos distintos, às vezes abreviados, às vezes em códigos internos da transportadora. O cérebro humano traduz essa variabilidade instintivamente. Um sistema de software, a menos que explicitamente configurado para reconhecer o formato de cada transportadora, não o faz.

Um documento de título não é o mesmo que um campo de dados

O BL ocupa uma posição única no comércio global que a maioria dos documentos — faturas, ordens de compra, relatórios de inspeção — não ocupa. Ele é um título de crédito negociável. A entidade que detém o BL original tem a posse presumida das mercadorias. Essa função jurídica é a razão pela qual BLs em papel são enviados por courier entre continentes a um custo considerável, mesmo quando a carga em si se move eletronicamente por meio de despacho aduaneiro prévio. O papel importa porque, sob séculos de direito marítimo, a posse do BL original é o que dá a um banco o direito de liberar o pagamento sob uma carta de crédito, o que dá a um consignatário o direito de reivindicar a carga no porto de destino e o que dá a um reclamante legitimidade em litígios de perda de carga.

Essa arquitetura jurídica cria uma barreira estrutural à digitalização qualitativamente diferente de, por exemplo, automatizar o processamento de faturas. Uma fatura é um artefato contábil. Um BL é um instrumento de título. E a distinção importa porque instrumentos de título exigem um sistema de transferência confiável — um mecanismo pelo qual uma parte pode passar o controle exclusivo e verificável para outra parte, sem que o emissor original ou um operador de plataforma retenha uma cópia residual que possa comprometer a integridade do título.

O Kentucky Law Journal publicou uma análise detalhada deste problema em janeiro de 2026, que expõe a lacuna entre a tecnologia eBL e a realidade jurídica. Embora sistemas eBL baseados em blockchain, como o IQAX (usado pela Hapag-Lloyd), possam garantir autenticidade criptográfica, eles falham no teste clássico de um título negociável em um aspecto mais fundamental: livre circulação. Um conhecimento de embarque (BOL) em papel circula de forma independente — a posse é binária, a transferência não exige permissão ou intermediário, e os direitos estão vinculados ao próprio documento físico. Um eBL em uma plataforma como o IQAX exige adesão à plataforma, autenticação do usuário e sistemas compatíveis em cada elo da cadeia. Se uma das partes — por exemplo, o banco de um consignatário em uma jurisdição que não adotou o MLETR da UNCITRAL — não puder acessar a plataforma ou não reconhecer a validade legal de um eBL, a cadeia se rompe e o embarque retorna ao papel.

Os dados confirmam isso. Uma pesquisa da FIT Alliance de dezembro de 2024 constatou que apenas 21% dos representantes bancários afirmaram que sua instituição havia adotado eBLs, e apenas 28% planejavam começar em até dois anos — apesar da conscientização quase universal sobre a tecnologia. Estados Unidos, Canadá, Japão, México, Coreia do Sul e Rússia não adotaram o MLETR ou leis equivalentes. Para um agente de carga que lida com embarques para ou de qualquer uma dessas jurisdições, o BOL em papel não é uma opção — é uma necessidade regulatória. E onde existe um BOL em papel, a entrada manual de dados existe por definição, pois o papel não pode preencher automaticamente um TMS.

A cadeia de nove partes que uma remessa marítima típica percorre torna essa dependência composta: embarcador → transitário → transportador → consignatário → despachante aduaneiro → operador portuário → parte notificada → transportador interno → banco financiador. Cada parte consome dados do BOL em um sistema diferente, para uma finalidade diferente, em um prazo diferente. O transitário precisa dos dados da remessa para conciliação de reservas e atualizações ao cliente. O despachante aduaneiro precisa das descrições da mercadoria e códigos NCM para o registro de declaração. O consignatário precisa da confirmação de entrega. O banco precisa da prova de embarque antes de liberar o pagamento. Um único campo digitado errado — um peso incorreto gerando uma sobretaxa de repesagem pela transportadora, um endereço de consignatário errado causando uma falha na entrega — repercute nessa cadeia de maneiras que uma simples porcentagem de precisão do OCR não consegue capturar. O custo downstream de um erro de dados na fase do BOL é ordens de magnitude maior do que o toque de tecla que o criou.

A ponte de TMS que a maioria dos transitários de médio porte não pode pagar

Se você é um agente de cargas de médio porte — 15 a 50 funcionários, movimentando 200 a 1.000 embarques por mês — ocupa uma posição particularmente difícil no cenário de automação. Você é grande demais para que planilhas continuem gerenciáveis (a abordagem de tabela dinâmica quebra em algum lugar por volta de 100 embarques por mês, quando cruzar BOLs de transportadoras com cotações de clientes e faturas de fornecedores vira um trabalho de conciliação em tempo integral). Mas você é pequeno demais para absorver o custo total de propriedade de uma infraestrutura de integração de nível empresarial.

Os números contam a história. Uma implementação completa de TMS para uma operação de médio porte — incluindo licenciamento de software, conexões EDI com transportadoras, migração de dados, treinamento e o primeiro ano de suporte — custa entre US$ 20.000 e US$ 50.000, de acordo com análises de preços do setor da PCS Software e outros fornecedores de TMS. Esse valor cobre a configuração; os custos de assinatura contínua para plataformas como CargoWise, que migraram para preços de pacotes por embarque a US$ 6 a US$ 10 por embarque em 2025, adicionam US$ 1.200 a US$ 10.000 por mês, dependendo do volume. As conexões EDI que fazem os dados do BOL fluírem automaticamente das transportadoras para o TMS são um item separado, geralmente cobrado como configuração única mais manutenção anual por parceiro comercial — o que significa que um agente que trabalha com 20 transportadoras paga por 20 conexões EDI, não por uma.

E o EDI não é um padrão único. É uma família de formatos de mensagens — ANSI X12 204 (solicitação de carga para transportadora), 210 (fatura de frete), 214 (status de embarque), 211 (conhecimento de embarque) — cada um com variantes específicas de transportadoras e guias de implementação que exigem um especialista dedicado em integração para configurar e manter. O próprio mercado de TMS reconhece o atrito: o relatório da indústria de 2025 da MarketsandMarkets identifica "padrões fragmentados na documentação de frete" como o principal obstáculo para a adoção de TMS, observando que as transportadoras usam variantes proprietárias de mensagens EDI, enquanto as regiões preferem cada vez mais declarações XML ou esquemas JSON baseados em API — forçando os fornecedores de TMS a manter continuamente bibliotecas de adaptadores que nunca estão completas.

Para um agente de cargas de 25 pessoas, sem equipe de TI interna, isso não é uma decisão de compra. É uma lacuna de capacidade — um limite abaixo do qual a economia da integração não se fecha. O resultado é que os funcionários do agente de cargas abrem PDFs das transportadoras, leem os campos e os digitam em qualquer sistema que tenham, seja um TMS leve, uma planilha compartilhada do Excel ou uma tela de entrada do QuickBooks. Esse fluxo de trabalho é genuinamente mais rápido e mais barato do que tentar automatizá-lo via EDI — quando se considera o custo de implementação, a manutenção contínua e o fato de que mesmo transportadoras totalmente integradas ainda enviam exceções (conhecimentos de embarque alterados, embarques divididos, substituições de transportadoras) que exigem intervenção manual de qualquer forma.

Isso não é uma falha da tecnologia. É um reflexo do fato de que a integração entre EDI e TMS foi criada para a logística empresarial — para as Kuehne + Nagel e C.H. Robinson, que movimentam volume suficiente para amortizar orçamentos de integração de seis dígitos em milhões de transações. O transitário de médio porte nunca foi o alvo do projeto. E a entrada manual de dados, para esse segmento, não é uma escolha que um concorrente mais tecnológico evitaria. É o modelo operacional padrão de um setor cuja infraestrutura de integração foi construída para uma escala diferente.

O que muda quando a extração se desvincula da integração

Se existe uma saída desse bloqueio de três camadas — diversidade de formatos de transportadoras, restrições de documentos de título e custos de integração com TMS — ela não vem de resolver todos os três de uma vez. Vem de desvincular a extração de dados da integração de sistemas.

O caminho convencional de automação pressupõe que a única maneira de eliminar a entrada manual de BOL é conectar o sistema da transportadora diretamente ao TMS do transitário — um link EDI ou API que preenche automaticamente os campos de embarque. Esse caminho é eficaz quando funciona, mas é cheio de barreiras: você precisa da cooperação da transportadora, sistemas compatíveis em ambos os lados e volume suficiente para justificar o custo da integração. Para o transitário de médio porte que trabalha com 20 transportadoras, das quais apenas uma fração oferece API ou EDI confiável — e ainda menos com as quais o TMS leve do transitário consegue se conectar nativamente — o caminho convencional cobre talvez 30% do volume de BOL. O restante permanece manual.

E se a etapa de extração fosse dissociada da etapa de integração? Em vez de exigir uma conexão transportadora-TMS para cada transportadora, o agente de carga recebe o BL no formato em que chega — PDF, imagem digitalizada, captura de tela do portal da transportadora — e extrai os dados no nível do documento usando IA que lê o BL como um humano faria: entendendo o que cada campo significa, não onde ele está em um modelo. O agente define as colunas necessárias — Número do Contêiner, Número do Lacre, Navio/Viagem, Peso Bruto, Embarcador, Consignatário, Porto de Descarga — e o motor de extração localiza cada valor em qualquer layout de BL da transportadora. O resultado é uma planilha que alimenta o TMS ou sistema contábil nos termos do agente, sem exigir que a transportadora mude de formato, adote uma API ou participe de forma alguma.

Essa abordagem — extração na camada do documento em vez de integração na camada do sistema — muda o cálculo econômico. Não exige configuração transportadora por transportadora. Não exige EDI. Não exige uma implementação completa de TMS para começar a economizar tempo. Um agente que lida com 200 BLs por mês, cada um levando de 10 a 15 minutos para ser inserido manualmente, gasta aproximadamente 35 a 50 horas por mês apenas com a entrada de dados do BL. Considerando o salário médio por hora de US$ 23,24 do BLS para um agente de carga e frete, isso representa US$ 800 a US$ 1.160 em custo de mão de obra por mês — sem contar o custo de erros de dados, que, segundo dados da UNCTAD, adiciona em média US$ 1.450 por incidente quando um erro causa um atraso. A extração no nível do documento aborda esse custo sem exigir que o agente ultrapasse primeiro o limite de integração do TMS.

Isto não substitui a integração com EDI ou TMS onde estas são viáveis. É uma extensão de cobertura — uma forma de lidar com os 70% do volume de CT-e que vêm de transportadoras sem um feed digital confiável, de clientes que enviam PDFs por e-mail, de embarques de consolidação onde o sistema do próprio agente de carga gera o CT-e mestre, mas os CT-es subjacentes das sub-transportadoras ainda chegam como documentos digitalizados. Para o agente de carga de médio porte, cobrir esses 70% sem digitação manual — sem contratar outro digitador à medida que o volume cresce — é a diferença entre um negócio que pode escalar sem aumentar o quadro de funcionários e um que não pode.

E uma vez extraídos, os dados são estruturados. Uma vez estruturados, podem ser mesclados entre transportadoras em uma única planilha — uma visão em lote que dá ao agente de carga um painel único para todos os embarques, independentemente de qual transportadora gerou qual CT-e. Para um agente de carga cuja realidade diária é alternar entre portais de transportadoras, anexos de e-mail e uma planilha compartilhada, essa consolidação em um único painel é o desbloqueio operacional — e não exige que nenhuma transportadora mude nada.

Perguntas frequentes

Por que os agentes de carga simplesmente não exigem que as transportadoras enviem CT-es em um formato padrão?

Como o transitário não é cliente da transportadora na maioria das relações de rota — quem é é o embarcador. O transitário organiza o transporte em nome do embarcador, mas o conhecimento de embarque é um contrato entre o embarcador e a transportadora. As necessidades de dados do transitário são posteriores a esse contrato. As transportadoras não têm incentivo comercial para reformatar seus conhecimentos de embarque para uma parte que é um intermediário na cadeia de transações. Mesmo grandes transitários com alavancagem de volume significativa — os 20 maiores transitários globais — raramente conseguem que as transportadoras adotem um formato padrão de dados de conhecimento de embarque. Para transitários de médio porte, o pedido nem sequer é considerado.

Quanto custa realmente a entrada manual de dados de conhecimento de embarque por mês?

Com a taxa de referência do setor de 10 a 15 minutos de entrada manual por conhecimento de embarque e o salário médio por hora do BLS de US$ 23,24 para agentes de carga e frete, um transitário que processa 200 conhecimentos de embarque por mês gasta de US$ 800 a US$ 1.160 apenas com mão de obra de entrada de dados — sem contar a correção de erros, que os dados da UNCTAD de 2025 estimam em uma perda média de US$ 1.450 por atraso no transporte relacionado a dados de conhecimento de embarque. Para uma análise mais detalhada, veja nossa análise sobre quanto custa a entrada manual de dados de conhecimento de embarque para o transporte de cargas por remessa e por mês.

O software de OCR pode ler dados de conhecimento de embarque automaticamente?

O OCR tradicional consegue ler texto impresso em um BL, mas enfrenta duas limitações: falta compreensão semântica para distinguir um "número do contêiner" de um "número da reserva" quando ambos aparecem como sequências alfanuméricas na mesma página, e exige treinamento de modelo para o layout de cada transportadora — o que anula o propósito para despachantes que lidam com BLs de dezenas de transportadoras. A extração baseada em IA, que lê campos entendendo seu significado em vez de sua posição na página, evita o problema do modelo, mas a precisão ainda depende da qualidade do documento — um BL digitalizado amassado ou com muitas marcas d'água apresenta o mesmo desafio para a IA que para um leitor humano.

Como funcionam na prática os lotes de BL de múltiplas transportadoras?

Um despachante recebe BLs de várias transportadoras — por exemplo, Maersk para o trecho marítimo, uma transportadora rodoviária regional para o transporte interno e uma transportadora ferroviária para o segmento intermodal — todos relacionados a embarques diferentes ou a diferentes segmentos de uma mesma consolidação. Em vez de abrir cada PDF, digitar manualmente os campos no TMS e cruzar os IDs dos embarques, o despachante faz upload de todos os BLs em uma única sessão de processamento e especifica os nomes das colunas que deseja extrair. O resultado é uma planilha com todos os embarques de todas as transportadoras em colunas consistentes. Abordamos esse fluxo de trabalho em detalhes em nosso guia sobre como despachantes processam em lote BLs de múltiplas transportadoras em uma única planilha de controle.

A adoção do conhecimento de embarque eletrônico está realmente acelerando?

Sim, mas de forma desigual. As nove maiores operadoras de contêineres — que juntas movimentam a maior parte da carga conteinerizada global — se comprometeram, por meio da DCSA, a 100% de eBL até 2030, e a meta "25 por 25" da BIMCO prevê 25% do volume do comércio marítimo em eBL para pelo menos uma commodity. O eFBL digital negociável da FIATA já está disponível em mais de 50 plataformas TMS. Mas a execução permanece concentrada no topo do mercado. As operadoras de médio porte e regionais, que formam a espinha dorsal do transporte doméstico e de curta distância na maioria dos países, não têm compromisso equivalente, e a taxa de adoção do setor bancário — 21% dos bancos, segundo a pesquisa de 2024 da FIT Alliance — é a restrição limitante. A adoção do eBL vai acelerar, mas o BOL em papel continuará sendo uma parte significativa da documentação de transporte até o final da década.