Automação de processamento de documentos com OpenClaw

Toda empresa funciona com base em documentos. Faturas, contratos, pedidos de compra, recibos de entrega, relatórios de conformidade, relatórios de despesas – o volume nunca diminui e o custo de processá-los manualmente é enorme. Estimativas conservadoras estimam o custo médio do processamento manual de faturas entre US$ 12 e US$ 16 por documento, com taxas de erro entre 3% e 5%. Multiplique isso por milhares de documentos por mês e o argumento da automação se manifestará sozinho.

Os agentes de processamento de documentos do OpenClaw combinam OCR, extração estruturada de dados, regras de validação e integração de ERP em um único pipeline autônomo. O resultado é um sistema que recebe um documento, entende seu tipo e conteúdo, valida os dados de acordo com suas regras de negócios e encaminha as informações extraídas para o destino certo – sem intervenção humana para a maioria dos documentos.

Principais conclusões

Os agentes de documentos OpenClaw lidam com PDFs, imagens digitalizadas, e-mails com anexos e formatos de arquivos estruturados (CSV, XML, EDI) por meio de um pipeline unificado.

A pontuação de qualidade do OCR bloqueia a extração de IA: verificações de baixa qualidade acionam uma solicitação de nova verificação antes que o processamento continue.

A camada de extração usa uma combinação de análise de layout, reconhecimento de entidade nomeada e análise baseada em LLM para máxima precisão em formatos de documentos.

As habilidades de validação verificam os dados extraídos em relação aos registros mestre de fornecedores, números de pedidos, códigos de impostos e regras de negócios antes que quaisquer dados cheguem ao seu ERP.

O tratamento de exceções encaminha apenas documentos genuinamente ambíguos para humanos - o agente fornece um formulário pré-preenchido com sua melhor estimativa para que o humano apenas confirme em vez de entrar novamente.

O pipeline lida com mais de 300 tipos de documentos prontos para uso; modelos personalizados podem ser adicionados por meio de um editor de esquema de baixo código.

A latência ponta a ponta, desde o recebimento do documento até a entrada no ERP, é em média inferior a 90 segundos para documentos limpos.

ECOSIRE cria e gerencia pipelines de processamento de documentos OpenClaw integrados com Odoo, SAP, QuickBooks e ERPs personalizados.

Visão geral da arquitetura de processamento de documentos

Um pipeline de processamento de documentos OpenClaw de produção consiste em seis estágios, cada um implementado como uma ou mais habilidades:

Document Ingestion
        ↓
[ Classifier Agent ]     — document type detection, routing
        ↓
[ Extraction Agent ]     — OCR + structured data extraction
        ↓
[ Validation Agent ]     — business rule validation, master data lookup
        ↓
[ Enrichment Agent ]     — GL coding, cost center assignment, approver lookup
        ↓
[ Integration Agent ]    — ERP/downstream system write
        ↓
[ Exception Agent ]      — handles ambiguous documents, requests human review

Cada agente funciona de forma independente e se comunica através do barramento de tarefas. Documentos com falha em qualquer etapa são encaminhados para o Agente de Exceção sem perder o trabalho já concluído nas etapas anteriores.

Ingestão de documentos: aceitando todos os formatos

Os documentos chegam por meio de vários canais: anexos de e-mail, descarte de sistemas de arquivos, uploads de API, gateways de fax para e-mail e portais de fornecedores. A camada de ingestão normaliza tudo isso em uma tarefa de documento padrão.

export const DocumentIngester = defineSkill({
  name: "document-ingester",
  tools: ["email", "storage", "queue"],
  async run({ input, tools }) {
    let rawFile: Buffer;
    let mimeType: string;

    if (input.source === "email") {
      const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
      rawFile = attachment.buffer;
      mimeType = attachment.mimeType;
    } else if (input.source === "storage") {
      rawFile = await tools.storage.get(input.storageKey);
      mimeType = detectMimeType(rawFile);
    }

    // Normalize to PDF for consistent downstream processing
    const normalizedPdf = mimeType === "application/pdf"
      ? rawFile
      : await convertToPdf(rawFile, mimeType);

    const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
    await tools.storage.put(storageKey, normalizedPdf);

    return {
      storageKey,
      originalSource: input.source,
      originalMimeType: mimeType,
      pagCount: await getPdfPageCount(normalizedPdf),
    };
  },
});

A etapa de normalização converte documentos do Word, arquivos do Excel, arquivos de imagem (JPEG, PNG, TIFF) e corpos HTML de e-mail em PDF antes de transmiti-los posteriormente. Os agentes downstream só recebem PDFs – isso simplifica drasticamente o OCR e a análise de layout.

Classificação de documentos: sabendo o que você tem

Antes do início da extração, o Agente Classificador identifica o tipo de documento. A classificação é importante porque diferentes tipos de documentos exigem diferentes modelos de extração – uma fatura não se parece em nada com um recibo de entrega.

O classificador usa uma abordagem em dois estágios:

Etapa 1 — Análise de layout: A estrutura visual do documento (posições de tabela, blocos de cabeçalho, padrões de rodapé, posicionamento do logotipo) é analisada para restringir a categoria do documento a um pequeno conjunto de candidatos.

Etapa 2 — Classificação do conteúdo: Frases-chave e padrões estruturais no texto confirmam o tipo específico de documento. O classificador produz uma etiqueta de tipo e uma pontuação de confiança.

export const ClassifyDocument = defineSkill({
  name: "classify-document",
  tools: ["storage", "classification-model"],
  async run({ input, tools }) {
    const pdfBuffer = await tools.storage.get(input.storageKey);
    const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
    const textContent = await performOcr(pdfBuffer, { mode: "fast" });

    const classification = await tools.classificationModel.classify({
      layoutFeatures,
      textContent: textContent.slice(0, 2000), // First 2000 chars for speed
    });

    if (classification.confidence < 0.70) {
      return {
        type: "unknown",
        confidence: classification.confidence,
        requiresManualClassification: true,
      };
    }

    return {
      type: classification.label,
      confidence: classification.confidence,
      requiresManualClassification: false,
      extractionTemplate: TEMPLATE_MAP[classification.label],
    };
  },
});

Tipos de documentos comuns e seus modelos de extração são pré-construídos: faturas de fornecedores, notas de crédito, pedidos de compra, notas de entrega, extratos bancários, contratos, relatórios de despesas e declarações alfandegárias. Novos tipos de documentos podem ser adicionados através do editor de modelos sem alterações de código.

OCR e extração: obtendo dados com precisão

O Agente de Extração é onde reside a maior parte da complexidade técnica. Ele combina saída de OCR com análise de layout e análise baseada em LLM para produzir dados estruturados a partir de documentos não estruturados.

A qualidade do OCR é avaliada antes do início da extração de IA. Se a confiança média dos caracteres do OCR estiver abaixo de 0,80 (indicando uma digitalização borrada, baixa resolução ou página distorcida), o agente sinaliza o documento para nova digitalização em vez de prosseguir com texto não confiável.

Para documentos que passam nas verificações de qualidade do OCR, a extração ocorre em três etapas:

Passe 1 — Correspondência de modelo: para fornecedores e formatos de documentos conhecidos, o modelo de extração fornece posições de campo (coordenadas ou âncoras regex). A correspondência de modelos é rápida e precisa para documentos estruturados de fontes conhecidas.

Passe 2 — Reconhecimento de Entidade Nomeada: NER identifica valores, datas, endereços, identificadores (números de fatura, números de ordem de compra, números de IVA) e limites de itens de linha que a correspondência de modelo perdeu.

Passagem 3 — Raciocínio LLM: para campos ambíguos ou quando as duas primeiras passagens produzem valores de baixa confiança, um LLM analisa o contexto do texto circundante para inferir o valor correto.

export const ExtractInvoiceData = defineSkill({
  name: "extract-invoice-data",
  tools: ["storage", "ocr-service", "llm"],
  async run({ input, tools, memory }) {
    const buffer = await tools.storage.get(input.storageKey);
    const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });

    if (ocrResult.averageConfidence < 0.80) {
      return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
    }

    // Pass 1: Template matching
    const templateFields = applyTemplate(ocrResult, input.extractionTemplate);

    // Pass 2: NER for missing fields
    const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });

    // Pass 3: LLM for remaining low-confidence fields
    const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
    const llmFields = lowConfidenceFields.length > 0
      ? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
      : {};

    const extracted = mergeExtractions(templateFields, nerFields, llmFields);
    await memory.working.set("extractedData", extracted);

    return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
  },
});

Validação: detectando erros antes que eles cheguem ao seu ERP

Os dados brutos extraídos nunca são gravados diretamente no seu ERP. O Agente de Validação verifica todos os campos em relação às suas regras de negócios e dados mestre antes de qualquer coisa ser publicada.

As verificações de validação para uma fatura de fornecedor incluem:

O fornecedor existe: O nome do fornecedor e o número de IVA correspondem a um registro no cadastro do fornecedor.
Correspondência da ordem de compra: o número da ordem de compra na fatura corresponde a uma ordem de compra aberta e os valores estão dentro da tolerância (normalmente ±5% para flexibilidade de faturamento).
Detecção de duplicatas: o número da fatura deste fornecedor não foi processado nos últimos 180 dias.
Cálculo de impostos: os totais dos itens de linha mais os impostos são iguais ao total da fatura, dentro da tolerância de arredondamento.
Moeda e taxa de câmbio: as faturas em moeda estrangeira são validadas em relação à taxa de câmbio da data da fatura.
Período contábil: a data da fatura cai dentro de um período contábil aberto.

export const ValidateInvoice = defineSkill({
  name: "validate-invoice",
  tools: ["erp", "vendor-master"],
  async run({ input, tools }) {
    const errors: ValidationError[] = [];

    // Vendor validation
    const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
    if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });

    // PO match
    if (input.data.poNumber) {
      const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
      if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
      else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
        errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
      }
    }

    // Duplicate check
    const isDuplicate = await tools.erp.invoiceExists({
      vendorId: vendor?.id,
      invoiceNumber: input.data.invoiceNumber,
    });
    if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });

    return {
      valid: errors.length === 0,
      errors,
      validatedData: errors.length === 0 ? input.data : null,
    };
  },
});

As falhas de validação são encaminhadas para o Agente de Exceção, em vez de eliminar silenciosamente o documento. O Agente de Exceção cria uma tarefa de revisão pré-preenchida com os dados extraídos e os erros de validação específicos, para que um ser humano possa corrigir apenas os campos sinalizados.

Enriquecimento: Adicionando Contexto de Negócios

Dados limpos e validados ainda precisam de contexto de negócios antes de serem publicados em um ERP. O Agente de Melhoria adiciona as informações que os documentos não contêm: códigos de conta contábil, atribuições de centro de custo, códigos de tratamento fiscal, atribuições de fluxo de trabalho de aprovação e condições de pagamento.

As regras de enriquecimento são definidas em um armazenamento de políticas e podem fazer referência a atributos do fornecedor, descrições de itens de linha, departamento, códigos de projeto e limites de valor. A maioria das regras de enriquecimento são pesquisas determinísticas; para casos ambíguos (itens de linha com descrições que podem ser mapeadas para várias contas GL), o LLM fornece uma lista de sugestões classificadas com explicações.

Integração ERP: Gravando dados com precisão na primeira vez

O Agente de Integração publica dados enriquecidos e validados em seu ERP. Ele usa chamadas de API idempotentes com um ID de correlação derivado do hash do documento original – se a gravação do ERP for repetida (devido a um tempo limite de rede), registros duplicados serão evitados.

export const PostToErp = defineSkill({
  name: "post-to-erp",
  tools: ["erp"],
  async run({ input, tools }) {
    const correlationId = hashDocument(input.storageKey);

    const result = await tools.erp.createVendorBill({
      correlationId, // ERP uses this for idempotency
      vendorId: input.enrichedData.vendorId,
      invoiceNumber: input.enrichedData.invoiceNumber,
      invoiceDate: input.enrichedData.invoiceDate,
      lineItems: input.enrichedData.lineItems,
      taxLines: input.enrichedData.taxLines,
      paymentTerms: input.enrichedData.paymentTerms,
      glCodes: input.enrichedData.glCodes,
    });

    return {
      erpRecordId: result.id,
      erpRecordUrl: result.url,
      posted: true,
    };
  },
});

Após a postagem, o documento original é vinculado ao registro do ERP e arquivado no seu sistema de gestão documental com metadados completos. A trilha de auditoria é completa: desde o anexo do e-mail ou entrega do arquivo, passando por todas as etapas do processamento até a entrada final no ERP.

Tratamento de exceções: humano no circuito quando é importante

Nem todos os documentos serão processados de forma limpa. O Agente de Exceção lida com quatro categorias de exceções:

Falhas de classificação: O tipo de documento não pôde ser determinado com confiança suficiente.
Falhas de extração: Campos críticos (valor total, ID do fornecedor, número da fatura) não puderam ser extraídos.
Falhas de validação: os dados extraídos não passam nas verificações de regras de negócios.
Falhas de integração: o ERP rejeitou o lançamento (por exemplo, período contábil encerrado, conta bloqueada).

Para cada exceção, o agente cria uma tarefa de revisão em seu sistema de suporte técnico ou de fluxo de trabalho com um formulário pré-preenchido mostrando a melhor tentativa do agente e o erro específico. O humano corrige apenas os campos com falha e aprova – o agente cuida do reenvio.

Perguntas frequentes

Qual resolução de documento é necessária para um OCR preciso?

Para documentos impressos, 150 DPI é o mínimo para resultados de OCR aceitáveis; 300 DPI é recomendado para uma extração confiável. Para documentos manuscritos ou com tamanhos de fonte muito pequenos, é preferível 400 DPI ou superior. A habilidade de avaliação de qualidade de OCR sinaliza documentos abaixo do limite antes do início da extração, acionando automaticamente uma solicitação de nova digitalização.

Como o sistema lida com documentos de múltiplas páginas?

Documentos de várias páginas são processados com detecção de limite de página. Para faturas, o agente identifica a página de cabeçalho, as páginas de item de linha e quaisquer páginas de continuação. Os itens de linha que abrangem quebras de página são reconstruídos corretamente pela camada de análise de layout. Para outros tipos de documentos (contratos, relatórios), o agente processa todas as páginas e agrega os campos extraídos de cada página.

O sistema pode aprender com as correções feitas por humanos?

Sim. Quando um ser humano corrige um documento de exceção, a correção é devolvida ao Agente de Conhecimento. Se o mesmo padrão de correção aparecer mais de três vezes (por exemplo, um novo fornecedor sempre formata sua fatura de forma não padronizada), o sistema propõe automaticamente um novo modelo de extração para esse fornecedor. Um administrador analisa e aprova o modelo proposto, e o sistema o aplica desse ponto em diante, sem revisão humana para esse fornecedor.

Como são tratados os documentos manuscritos?

Documentos manuscritos são a categoria mais desafiadora. A camada OCR usa um modelo especializado de reconhecimento de escrita manual para esses documentos, e o limite de confiança para passar para a extração de IA é maior (0,90 versus 0,80 para documentos impressos). Na prática, a maioria dos fluxos de trabalho de documentos empresariais pode eliminar documentos manuscritos através de alterações de processo (portais de envio eletrônico, fluxos de trabalho de assinatura digital). Para organizações que precisam processar documentos manuscritos, a ECOSIRE recomenda uma abordagem híbrida com revisão humana para documentos com muita caligrafia.

Quais idiomas são suportados para extração?

O processamento de documentos do OpenClaw suporta mais de 40 idiomas para OCR, com modelos de extração validados para os principais formatos de documentos comerciais em inglês, alemão, francês, espanhol, árabe, chinês (simplificado e tradicional), japonês e português. Para outros idiomas, o OCR funciona, mas a qualidade do modelo de extração depende do conjunto de amostras do documento. A camada de raciocínio LLM lida com muitos idiomas nativamente.

Como é mantida a confidencialidade dos documentos?

Os documentos são criptografados em trânsito (TLS 1.3) e em repouso (AES-256). Cada documento é processado em um contexto isolado – nenhum conteúdo do documento é compartilhado entre organizações. Para documentos altamente confidenciais (contratos legais, demonstrações financeiras), você pode configurar o pipeline para usar um LLM local para a camada de raciocínio, mantendo o conteúdo do documento inteiramente dentro do perímetro da sua rede.

Qual é a taxa de precisão típica para processamento de faturas?

Para faturas estruturadas de fornecedores conhecidos com correspondência de modelo, a precisão no nível do campo normalmente excede 99,5% após a calibração do modelo. Para faturas não estruturadas de novos fornecedores, a precisão normalmente é de 95 a 98% na primeira tentativa, melhorando à medida que o sistema aprende o formato do fornecedor. A principal métrica a ser monitorada é a taxa de exceções: pipelines bem configurados apresentam taxas de exceções abaixo de 5% do volume total de documentos.

Próximas etapas

O processamento manual de documentos é um centro de custo que não agrega valor competitivo. A automação do processamento de documentos OpenClaw converte-o de uma operação com uso intensivo de pessoal em um pipeline automatizado que lida com mais de 95% do volume de documentos sem intervenção humana.

A equipe de implementação OpenClaw da ECOSIRE é especializada na construção de pipelines de processamento de documentos integrados com Odoo, SAP, QuickBooks e ERPs personalizados. Lidamos com o design de modelos de classificação de documentos, calibração de OCR, configuração de regras de validação, integração de ERP e configuração de fluxo de trabalho de exceções – entregando um sistema pronto para produção em seis a oito semanas.

Entre em contato com a ECOSIRE para iniciar uma auditoria de processamento de documentos de sua operação atual.

Document Processing Automation with OpenClaw