Por que os despachantes de carga ainda
digitam dados de BOL manualmente em 2026

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

Pergunte a um agente de carga de tamanho médio quantos formatos de BOL de transportadora eles manejam em um mês típico. A resposta raramente é inferior a 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, alineado com o nome do navio em outra, e em uma seção somente de código de barras em uma terceira.

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

Esta fragmentação não é resultado de negligência. É a consequência natural de um ecossistema de transportadoras em que cada operador desena seu BOL para servir seu próprio fluxo de trabalho operativo — recepção de almacén, programación de muelles, check-in de condutores — não as necessidades de dados a jusante do agente de carga que deve agregar dados de embarque para clientes, declarações aduaneras e facturación. O BOL nunca foi desenado como um formato de transferência de dados. Fue desenado como um recibo e um contrato. O fato de que os agentes de carga precisam extraer dados dele é um caso de uso secundário que os desenadores do BOL de cada transportadora não tinham incentivo para acomodar.

O resultado prático: um agente de carga que maneja 200 embarques por mês em 20 transportadoras está efetivamente executando uma operación manual de traducción de datos. Cada BOL que chega à sua caixa de entrada apresenta os mesmos 20 ou mais campos de dados — nome do remitente, endereço do consignatário, número de contêiner, número de selo, nome do navio, número de viagem, porto de carga, porto de descarga, peso bruto, número de pacotes, descripción da mercancía, classe de frete, cargos — organizados em uma ordem espacial diferente, com rótulos diferentes, às vezes abreviados, às vezes em códigos internos da transportadora. O cérebro humano traduz esta variabilidade instintivamente. Um sistema de software, a menos que seja 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 BOL (conhecimento de embarque) ocupa uma posição única no comércio global que a maioria dos documentos — faturas, pedidos de compra, relatórios de inspeção — não ocupa. Ele é um documento de título negociável. A entidade que detém o BOL original tem posse construtiva das mercadorias. Essa função legal é a razão pela qual BOLs em papel são entregues por courrier entre continentes a um custo considerável, mesmo quando a carga em si se move eletronicamente por meio de pré-liberação alfandegária. O papel importa porque, sob séculos de direito marítimo, a posse do BOL original é o que dá a um banco o direito de liberar o pagamento sob uma carta de crédito, o que dá ao consignatário o direito de reclamar a carga no porto de destino e o que dá a um reclamante legitimidade em litígios de perda de carga.

Essa arquitetura legal cria uma barreira estrutural à digitalização qualitativamente diferente de, digamos, automatizar o processamento de faturas. Uma fatura é um artefato contábil. Um BOL é 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 controle exclusivo e verificável a 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 desse problema em janeiro de 2026 que expõe a lacuna entre a tecnologia eBL e a realidade legal. 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 instrumento negociável em um fundamento mais básico: livre circulação. Um 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 a IQAX exige associação à plataforma, autenticação do usuário e sistemas compatíveis em cada elo da cadeia. Se uma parte — o banco de um consignatário em uma jurisdição que não adotou o MLETR da UNCITRAL, por exemplo — não puder acessar a plataforma ou não reconhecer a validade legal de um eBL, a cadeia se rompe e o embarque volta ao papel.

Os dados confirmam isso. Uma pesquisa de dezembro de 2024 da FIT Alliance constatou que apenas 21% dos representantes bancários disseram 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 de ou para 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, porque o papel não pode preencher automaticamente um TMS (sistema de gerenciamento de transporte).

A cadeia de nove partes pela qual um embarque marítimo típico passa torna essa dependência composta: embarcador → agente de carga → transportador → consignatário → despachante aduaneiro → operador de terminal → parte notificada → transportador terrestre → banco financiador. Cada parte consome dados do BOL em um sistema diferente, para um propósito diferente, em um cronograma diferente. O agente de carga precisa dos dados do embarque para conciliação de reservas e atualizações ao cliente. O despachante aduaneiro precisa de descrições de mercadorias e códigos HS para o registro de entrada. O consignatário precisa da confirmação de entrega. O banco precisa de prova de embarque antes de liberar o pagamento. Um único campo digitado incorretamente — um peso incorreto que aciona uma sobretaxa de repesagem do transportador, um endereço de consignatário errado que causa uma entrega falha — se propaga por essa cadeia de maneiras que uma simples porcentagem de precisão de OCR (reconhecimento óptico de caracteres) não consegue capturar. O custo downstream de um erro de dados na etapa do BOL é ordens de magnitude maior do que a digitação que o criou.

A ponte com TMS (sistema de gerenciamento de transporte) que a maioria dos agentes de carga de médio porte não pode pagar

Se você é um agente de carga de médio porte — de 15 a 50 funcionários, movimentando de 200 a 1.000 embarques por mês — você ocupa uma posição particularmente difícil no cenário de automação. Você é grande demais para que as planilhas continuem gerenciáveis (a abordagem de tabela dinâmica se quebra em algum lugar em torno de 100 embarques por mês, quando cruzar os BOL das transportadoras com cotações de clientes e faturas de fornecedores se torna 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 de transportadoras via EDI (intercâmbio eletrônico de dados), migração de dados, treinamento e o primeiro ano de suporte — custa entre US$ 20.000 e US$ 50.000, de acordo com a análise de preços do setor da PCS Software e de outros fornecedores de TMS. Esse valor cobre a configuração; os custos recorrentes de assinatura para plataformas como a CargoWise, que passou a adotar preços baseados em pacotes por embarque de US$ 6 a US$ 10 por embarque em 2025, adicionam de 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, normalmente cobrado como configuração única mais manutenção anual por parceiro comercial — o que significa que um agente de carga 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 mensagem — ANSI X12 204 (tender de carga de transportadora rodoviária), 210 (fatura de frete), 214 (status do embarque), 211 (BOL) — cada um com variantes específicas da transportadora e guias de implementação que exigem um especialista em integração dedicado para configurar e manter. O próprio mercado de TMS reconhece o atrito: o relatório do setor de 2025 da MarketsandMarkets identifica os "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 com prioridade em API — forçando os fornecedores de TMS a manter continuamente bibliotecas de adaptadores que nunca estão completas.

Para uma forwarder de 25 pessoas sem equipe interna de TI, esta 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 da forwarder abrem os PDFs das transportadoras, leem os campos e os digitam no sistema que possuem, seja um TMS (sistema de gerenciamento de transporte) leve, uma planilha Excel compartilhada ou uma tela de entrada do QuickBooks. Esse fluxo de trabalho é genuinamente mais rápido e barato do que tentar automatizá-lo por meio de EDI (intercâmbio eletrônico de dados) — quando você considera o custo de implementação, a manutenção contínua e o fato de que até mesmo transportadoras totalmente integradas ainda enviam exceções (BOLs (conhecimentos de embarque) alterados, embarques divididos, substituições de transportadora) que exigem intervenção manual de qualquer forma.

Isso não é uma falha da tecnologia. É um reflexo do fato de que a integração de EDI e TMS foi construída para logística empresarial — para as Kuehne + Nagels e C.H. Robinsons do mundo, que movimentam volume suficiente para amortizar orçamentos de integração de seis dígitos em milhões de transações. A forwarder de médio porte nunca foi o alvo do design. E a entrada manual de dados, para esse segmento, não é uma escolha que um concorrente mais orientado à tecnologia evitaria. É o modelo operacional padrão de uma indústria cuja infraestrutura de integração foi construída para uma escala diferente.

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

Se existe uma saída desse bloqueio de três camadas — diversidade de formatos das transportadoras, restrições de título de documento e limites de custo de integração com TMS — ela não vem de resolver os três ao mesmo tempo. Ela vem do desacoplamento da 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 da forwarder — um link EDI ou API que preencha os campos de embarque automaticamente. Esse caminho é eficaz quando funciona, mas é limitado por barreiras: você precisa da cooperação da transportadora, de sistemas compatíveis em ambos os lados e de volume suficiente para justificar o custo da integração. Para a forwarder de médio porte que trabalha com 20 transportadoras, das quais apenas uma fração suporta API ou EDI confiável — e ainda menos com as quais o TMS leve da forwarder 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 desacoplada da etapa de integração? Em vez de exigir uma conexão transportadora-para-TMS para cada transportadora, a forwarder recebe o BOL no formato em que ele 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 BOL da mesma forma que um humano: entendendo o que cada campo significa, não onde ele está em um modelo. A forwarder define as colunas de que precisa — Número do Contêiner, Número do Lacre, Navio/Viagem, Peso Bruto, Expedidor, Consignatário, Porto de Descarga — e o mecanismo de extração localiza cada valor em qualquer layout de BOL de qualquer transportadora. A saída é uma planilha que alimenta o TMS ou o sistema contábil nos termos da forwarder, 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. Ela não exige configuração transportadora por transportadora. Não exige EDI (intercâmbio eletrônico de dados). Não exige uma implementação completa de TMS (sistema de gerenciamento de transporte) para começar a economizar tempo. Um agente de carga que lida com 200 BOLs (conhecimentos de embarque) por mês, cada um levando de 10 a 15 minutos para ser inserido manualmente, gasta aproximadamente de 35 a 50 horas por mês apenas com a inserção de dados de BOL. Considerando o salário médio por hora de $23,24 do BLS para agentes de carga e frete, isso representa de $800 a $1.160 em custo de mão de obra por mês — sem contar o custo de erros de dados, que, segundo os dados da UNCTAD, adiciona em média $1.450 por incidente quando um erro causa atraso. A extração no nível do documento resolve esse custo sem exigir que o agente de carga ultrapasse primeiro o limite da integração com TMS.

Isso não substitui a integração com EDI (intercâmbio eletrônico de dados) ou TMS (sistema de gerenciamento de transporte) quando essas são viáveis. É uma extensão de cobertura — uma forma de lidar com os 70% do volume de BOLs (conhecimentos de embarque) que vêm de transportadoras sem um feed digital confiável, de clientes que enviam PDFs por e-mail, de embarques consolidados em que o sistema do próprio agente de carga gera o BOL mestre, mas os BOLs domésticos subjacentes de 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 funcionário de entrada de dados à medida que o volume cresce — é a diferença entre um negócio que consegue escalar sem aumentar o quadro de funcionários e um que não consegue.

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 uma visão unificada de todos os embarques, independentemente de qual transportadora gerou qual BOL. 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 uma única visão é o grande ganho operacional — e não exige que nenhuma transportadora mude nada.

Perguntas frequentes

Por que os freight forwarders não exigem simplesmente que as transportadoras enviem os BOL (conhecimentos de embarque) em um formato padrão?

Porque, na maioria das relações de rota, o freight forwarder não é o cliente da transportadora — o embarcador é. O forwarder organiza o transporte em nome do embarcador, mas o BOL (conhecimento de embarque) é um contrato entre o embarcador e a transportadora. As necessidades de dados do forwarder estão a jusante desse contrato. As transportadoras não têm incentivo comercial para reformatar seus BOL (conhecimentos de embarque) para uma parte que é intermediária na cadeia de transação. Até grandes forwarders com significativa influência de volume — os 20 maiores forwarders globais — raramente conseguem que as transportadoras adotem um formato de dados BOL (conhecimento de embarque) padrão. Para forwarders de tamanho médio, essa exigência nem está sobre a mesa.

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

À taxa de referência do setor de 10 a 15 minutos de entrada manual por BOL (conhecimento de embarque) e ao salário médio por hora de $23,24 para agentes de carga e frete do BLS, um forwarder que processa 200 BOL (conhecimentos de embarque) por mês gasta de $800 a $1.160 apenas em trabalho de entrada de dados — sem contar a correção de erros, que os dados de 2025 da UNCTAD estimam em uma perda média de $1.450 por atraso de envio relacionado a dados de BOL (conhecimento de embarque). Para um detalhamento mais completo, consulte nuestra análise de quanto custa a entrada manual de dados de BOL (conocimiento de embarque) para freight forwarders por envio e por mês.

O software OCR (reconhecimento óptico de caracteres) consegue ler automaticamente os dados do conhecimento de embarque?

O OCR (reconhecimento óptico de caracteres) tradicional consegue ler texto impresso em um BOL (conhecimento de embarque), mas enfrenta duas limitações: não tem a compreensão semântica para distinguir um "número de contenedor" de um "número de reserva" quando ambos aparecem como strings alfanuméricos na mesma página, e exige treinamento de modelo para o layout de cada transportadora — o que anula o propósito para forwarders que manejam BOL (conocimientos de embarque) 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 escaneo de BOL (conocimiento de embarque) arrugado ou com muitas marcas de água apresenta o mesmo desafio para a IA que para um lector humano.

Como funcionam, na prática, os lotes de BOL (conhecimento de embarque) de múltiplas transportadoras?

Um agente de carga recebe BOLs (conhecimentos de embarque) de várias transportadoras — por exemplo, Maersk para o trecho marítimo, uma transportadora rodoviária regional para o transporte terrestre interno e uma transportadora ferroviária para o segmento intermodal — todos relacionados a embarques diferentes ou a diferentes segmentos da mesma consolidação. Em vez de abrir cada PDF, digitar manualmente os campos no TMS (sistema de gerenciamento de transporte) e cruzar os IDs de embarque, o agente de carga envia todos os BOLs para uma única sessão de processamento e especifica os nomes das colunas que deseja extrair. O resultado é uma única planilha com todos os embarques de todas as transportadoras em colunas consistentes. Abordamos esse fluxo de trabalho em detalhes no nosso guia sobre como agentes de carga processam BOLs de múltiplas transportadoras em lote 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 transportadoras de contêineres — que juntas movimentam a maior parte da carga conteinerizada global — se comprometeram, por meio da DCSA, a atingir 100% de eBL (conhecimento de embarque eletrônico) até 2030, e a meta "25 by 25" da BIMCO visa 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 de TMS. Mas a execução permanece concentrada no topo do mercado. As transportadoras 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 parcela significativa da documentação de transporte até o final da década.