Automatisierung der Dokumentenverarbeitung mit OpenClaw

Jedes Unternehmen basiert auf Dokumenten. Rechnungen, Verträge, Bestellungen, Lieferscheine, Compliance-Berichte, Spesenabrechnungen – das Volumen nimmt nie ab und der Aufwand für die manuelle Bearbeitung ist enorm. Konservative Schätzungen gehen davon aus, dass die durchschnittlichen Kosten für die manuelle Rechnungsbearbeitung bei 12–16 US-Dollar pro Dokument liegen, wobei die Fehlerquote zwischen 3 % und 5 % liegt. Multiplizieren Sie das mit Tausenden von Dokumenten pro Monat und die Argumente für die Automatisierung schreiben sich von selbst ab.

Die Dokumentenverarbeitungsagenten von OpenClaw kombinieren OCR, strukturierte Datenextraktion, Validierungsregeln und ERP-Integration in einer einzigen autonomen Pipeline. Das Ergebnis ist ein System, das ein Dokument empfängt, seinen Typ und Inhalt versteht, die Daten anhand Ihrer Geschäftsregeln validiert und die extrahierten Informationen an das richtige Ziel weiterleitet – bei den meisten Dokumenten ohne menschliches Eingreifen.

Wichtige Erkenntnisse

– OpenClaw-Dokumentagenten verarbeiten PDFs, gescannte Bilder, E-Mails mit Anhängen und strukturierte Dateiformate (CSV, XML, EDI) über eine einheitliche Pipeline.

Die Bewertung der OCR-Qualität grenzt an die KI-Extraktion – Scans mit geringer Qualität lösen eine Anforderung für einen erneuten Scan aus, bevor die Verarbeitung fortgesetzt wird. – Die Extraktionsebene verwendet eine Kombination aus Layoutanalyse, Erkennung benannter Entitäten und LLM-basierter Analyse für maximale Genauigkeit über Dokumentformate hinweg.

Validierungsfähigkeiten prüfen extrahierte Daten anhand von Lieferantenstammdatensätzen, Bestellnummern, Steuercodes und Geschäftsregeln, bevor Daten Ihr ERP erreichen. – Die Ausnahmebehandlung leitet nur wirklich mehrdeutige Dokumente an Menschen weiter – der Agent stellt ein vorab ausgefülltes Formular mit seiner besten Vermutung bereit, sodass der Mensch nur bestätigt, anstatt sie erneut einzugeben. – Die Pipeline verarbeitet standardmäßig über 300 Dokumenttypen; Benutzerdefinierte Vorlagen können über einen Low-Code-Schema-Editor hinzugefügt werden. – Die End-to-End-Latenz vom Dokumenteneingang bis zum ERP-Eintrag beträgt bei sauberen Dokumenten durchschnittlich weniger als 90 Sekunden.

ECOSIRE erstellt und verwaltet OpenClaw-Dokumentverarbeitungspipelines, die in Odoo, SAP, QuickBooks und benutzerdefinierte ERPs integriert sind.

Überblick über die Architektur der Dokumentenverarbeitung

Eine OpenClaw-Dokumentenverarbeitungspipeline für die Produktion besteht aus sechs Phasen, die jeweils als eine oder mehrere Fähigkeiten implementiert sind:

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

Jeder Agent läuft unabhängig und kommuniziert über den Taskbus. Fehlerhafte Dokumente werden in jeder Phase an den Ausnahmeagenten weitergeleitet, ohne dass die bereits in den vorgelagerten Phasen abgeschlossenen Arbeiten verloren gehen.

Dokumentenaufnahme: Jedes Format akzeptieren

Dokumente kommen über mehrere Kanäle an: E-Mail-Anhänge, Dateisystem-Drops, API-Uploads, Fax-zu-E-Mail-Gateways und Anbieterportale. Die Aufnahmeschicht normalisiert all dies in eine Standarddokumentaufgabe.

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),
    };
  },
});

Der Normalisierungsschritt konvertiert Word-Dokumente, Excel-Dateien, Bilddateien (JPEG, PNG, TIFF) und E-Mail-HTML-Körper in PDF, bevor sie weitergegeben werden. Nachgelagerte Agenten erhalten immer nur PDFs – dies vereinfacht die OCR- und Layout-Analyse erheblich.

Dokumentenklassifizierung: Wissen, was Sie haben

Bevor die Extraktion beginnt, identifiziert der Classifier Agent den Dokumenttyp. Die Klassifizierung ist wichtig, da unterschiedliche Dokumenttypen unterschiedliche Extraktionsvorlagen erfordern – eine Rechnung sieht überhaupt nicht wie ein Lieferbeleg aus.

Der Klassifikator verwendet einen zweistufigen Ansatz:

Stufe 1 – Layoutanalyse: Die visuelle Struktur des Dokuments (Tabellenpositionen, Kopfzeilenblöcke, Fußzeilenmuster, Logoplatzierung) wird analysiert, um die Dokumentkategorie auf eine kleine Gruppe von Kandidaten einzugrenzen.

Stufe 2 – Inhaltsklassifizierung: Schlüsselphrasen und Strukturmuster im Text bestätigen den spezifischen Dokumenttyp. Der Klassifikator erzeugt eine Typenbezeichnung und einen Konfidenzwert.

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],
    };
  },
});

Gängige Dokumenttypen und ihre Extraktionsvorlagen sind vorgefertigt: Lieferantenrechnungen, Gutschriften, Bestellungen, Lieferscheine, Kontoauszüge, Verträge, Spesenabrechnungen und Zollerklärungen. New document types can be added through the template editor without code changes.

OCR und Extraktion: Daten präzise ausgeben

Der größte Teil der technischen Komplexität liegt im Extraktionsagenten. Es kombiniert OCR-Ausgabe mit Layoutanalyse und LLM-basierter Analyse, um strukturierte Daten aus unstrukturierten Dokumenten zu erzeugen.

Die OCR-Qualität wird bewertet, bevor mit der KI-Extraktion begonnen wird. Wenn die durchschnittliche Zeichensicherheit von OCR unter 0,80 liegt (was auf einen verschwommenen Scan, eine niedrige Auflösung oder eine verzerrte Seite hinweist), markiert der Agent das Dokument zum erneuten Scannen, anstatt mit unzuverlässigem Text fortzufahren.

Bei Dokumenten, die die OCR-Qualitätsprüfung bestehen, erfolgt die Extraktion in drei Durchgängen:

Durchgang 1 – Vorlagenabgleich: Für bekannte Anbieter und Dokumentformate stellt die Extraktionsvorlage Feldpositionen (Koordinaten oder Regex-Anker) bereit. Der Vorlagenabgleich erfolgt schnell und genau für strukturierte Dokumente aus bekannten Quellen.

Durchgang 2 – Erkennung benannter Entitäten: NER identifiziert Beträge, Daten, Adressen, Identifikatoren (Rechnungsnummern, Bestellnummern, Umsatzsteuer-Identifikationsnummern) und Einzelpostengrenzen, die beim Vorlagenabgleich fehlten.

Durchgang 3 – LLM-Begründung: Bei mehrdeutigen Feldern oder wenn die ersten beiden Durchgänge Werte mit geringer Konfidenz ergeben, analysiert ein LLM den umgebenden Textkontext, um den richtigen Wert abzuleiten.

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) };
  },
});

Validierung: Fehler erkennen, bevor sie Ihr ERP erreichen

Roh extrahierte Daten werden niemals direkt in Ihr ERP geschrieben. Der Validierungsagent prüft jedes Feld anhand Ihrer Geschäftsregeln und Stammdaten, bevor etwas gepostet wird.

Zu den Validierungsprüfungen für eine Kreditorenrechnung gehören:

Lieferant vorhanden: Der Name des Lieferanten und die Umsatzsteuer-Identifikationsnummer stimmen mit einem Datensatz im Lieferantenstamm überein.
Bestellungsübereinstimmung: Die Bestellnummer auf der Rechnung stimmt mit einer offenen Bestellung überein und die Beträge liegen innerhalb der Toleranz (typischerweise ±5 % für Flexibilität bei der Rechnungsstellung).
Duplikaterkennung: Die Rechnungsnummer dieses Lieferanten wurde in den letzten 180 Tagen nicht verarbeitet.
Steuerberechnung: Die Einzelpostensummen zuzüglich Steuern entsprechen der Rechnungssumme, innerhalb der Rundungstoleranz.
Währung und Wechselkurs: Rechnungen in Fremdwährung werden anhand des Wechselkurses für das Rechnungsdatum validiert.
Hauptbuchzeitraum: Das Rechnungsdatum liegt in einem offenen Buchungszeitraum.

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,
    };
  },
});

Validierungsfehler werden an den Ausnahmeagenten weitergeleitet, anstatt das Dokument stillschweigend zu löschen. Der Ausnahmeagent erstellt eine Überprüfungsaufgabe, die vorab mit den extrahierten Daten und den spezifischen Validierungsfehlern gefüllt ist, sodass ein Mensch nur die markierten Felder korrigieren kann.

Bereicherung: Geschäftskontext hinzufügen

Saubere, validierte Daten benötigen noch einen Geschäftskontext, bevor sie in ein ERP gebucht werden können. Der Enrichment Agent fügt die Informationen hinzu, die Dokumente nicht enthalten: FIBU-Kontencodes, Kostenstellenzuweisungen, Steuerbehandlungscodes, Genehmigungsworkflow-Zuweisungen und Zahlungsbedingungen.

Anreicherungsregeln werden in einem Richtlinienspeicher definiert und können auf Lieferantenattribute, Einzelpostenbeschreibungen, Abteilungen, Projektcodes und Betragsschwellenwerte verweisen. Bei den meisten Anreicherungsregeln handelt es sich um deterministische Suchvorgänge. Für mehrdeutige Fälle (Einzelposten mit Beschreibungen, die mehreren Hauptbuchkonten zugeordnet werden könnten) stellt das LLM eine nach Rang sortierte Vorschlagsliste mit Erläuterungen zur Verfügung.

ERP-Integration: Daten gleich beim ersten Mal korrekt schreiben

Der Integration Agent sendet validierte, angereicherte Daten an Ihr ERP. Es verwendet idempotente API-Aufrufe mit einer Korrelations-ID, die aus dem Hash des Originaldokuments abgeleitet wird. Wenn der ERP-Schreibversuch wiederholt wird (aufgrund eines Netzwerk-Timeouts), werden doppelte Datensätze verhindert.

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,
    };
  },
});

Nach der Buchung wird das Originaldokument mit dem ERP-Datensatz verknüpft und mit vollständigen Metadaten in Ihrem Dokumentenmanagementsystem archiviert. The audit trail is complete: from the email attachment or file drop through every processing stage to the final ERP entry.

Ausnahmebehandlung: Human-in-the-Loop, wenn es darauf ankommt

Nicht jedes Dokument wird sauber verarbeitet. Der Ausnahmeagent behandelt vier Kategorien von Ausnahmen:

Klassifizierungsfehler: Der Dokumenttyp konnte nicht mit ausreichender Sicherheit bestimmt werden.
Extraktionsfehler: Kritische Felder (Gesamtbetrag, Lieferanten-ID, Rechnungsnummer) konnten nicht extrahiert werden.
Validierungsfehler: Extrahierte Daten bestehen die Geschäftsregelprüfungen nicht.
Integrationsfehler: ERP hat die Buchung abgelehnt (z. B. Buchungsperiode geschlossen, Konto gesperrt).

Für jede Ausnahme erstellt der Agent eine Überprüfungsaufgabe in Ihrem Helpdesk- oder Workflow-System mit einem vorab ausgefüllten Formular, das den besten Versuch des Agenten und den spezifischen Fehler anzeigt. Der Mensch korrigiert nur die fehlerhaften Felder und genehmigt – der Agent kümmert sich um die erneute Übermittlung.

Häufig gestellte Fragen

Welche Dokumentauflösung ist für eine genaue OCR erforderlich?

Bei gedruckten Dokumenten ist 150 DPI das Minimum für akzeptable OCR-Ergebnisse; Für eine zuverlässige Extraktion werden 300 DPI empfohlen. Für handschriftliche Dokumente oder Dokumente mit sehr kleinen Schriftgrößen werden 400 DPI oder höher bevorzugt. Die Fähigkeit zur OCR-Qualitätsbewertung markiert Dokumente unterhalb des Schwellenwerts, bevor mit der Extraktion begonnen wird, und löst automatisch eine Anforderung zum erneuten Scannen aus.

Wie geht das System mit mehrseitigen Dokumenten um?

Mehrseitige Dokumente werden mit Seitengrenzenerkennung verarbeitet. Bei Rechnungen identifiziert der Agent die Kopfzeile, die Einzelpostenseiten und alle Fortsetzungsseiten. Werbebuchungen, die sich über Seitenumbrüche erstrecken, werden vom Layout-Analyse-Layer korrekt rekonstruiert. Bei anderen Dokumenttypen (Verträge, Berichte) verarbeitet der Agent alle Seiten und aggregiert extrahierte Felder von jeder Seite.

Kann das System aus von Menschen vorgenommenen Korrekturen lernen?

Ja. Wenn ein Mensch ein Ausnahmedokument korrigiert, wird die Korrektur an den Knowledge Agent zurückgemeldet. Wenn das gleiche Korrekturmuster mehr als dreimal vorkommt (z. B. wenn ein neuer Lieferant seine Rechnung immer auf eine nicht standardmäßige Weise formatiert), schlägt das System automatisch eine neue Extraktionsvorlage für diesen Lieferanten vor. Ein Administrator überprüft und genehmigt die vorgeschlagene Vorlage, und das System wendet sie ab diesem Zeitpunkt an, ohne dass eine menschliche Überprüfung für diesen Anbieter erfolgt.

Wie wird mit handschriftlichen Dokumenten umgegangen?

Handschriftliche Dokumente sind die anspruchsvollste Kategorie. Die OCR-Schicht verwendet für diese Dokumente ein spezielles Handschrifterkennungsmodell, und der Vertrauensschwellenwert für die Weitergabe an die KI-Extraktion ist höher (0,90 gegenüber 0,80 für gedruckte Dokumente). In der Praxis können die meisten Dokumenten-Workflows in Unternehmen durch Prozessänderungen (elektronische Einreichungsportale, digitale Signatur-Workflows) auf handschriftliche Dokumente verzichten. Für Organisationen, die handschriftliche Dokumente verarbeiten müssen, empfiehlt ECOSIRE einen Hybridansatz mit menschlicher Überprüfung für handschriftlastige Dokumente.

Welche Sprachen werden für die Extraktion unterstützt?

Die Dokumentenverarbeitung von OpenClaw unterstützt mehr als 40 Sprachen für OCR, mit validierten Extraktionsvorlagen für die wichtigsten Geschäftsdokumentformate in Englisch, Deutsch, Französisch, Spanisch, Arabisch, Chinesisch (vereinfacht und traditionell), Japanisch und Portugiesisch. Für andere Sprachen funktioniert OCR, aber die Qualität der Extraktionsvorlage hängt von Ihrem Dokumentbeispielsatz ab. Die LLM-Argumentationsschicht verarbeitet viele Sprachen nativ.

Wie wird die Vertraulichkeit von Dokumenten gewahrt?

Dokumente werden während der Übertragung (TLS 1.3) und im Ruhezustand (AES-256) verschlüsselt. Jedes Dokument wird in einem isolierten Kontext verarbeitet – kein Dokumentinhalt wird zwischen Organisationen geteilt. Für hochsensible Dokumente (rechtliche Verträge, Finanzberichte) können Sie die Pipeline so konfigurieren, dass sie ein lokales LLM für die Begründungsschicht verwendet, sodass der Dokumentinhalt vollständig innerhalb Ihres Netzwerkumfangs bleibt.

Wie hoch ist die typische Genauigkeitsrate bei der Rechnungsverarbeitung?

Bei strukturierten Rechnungen bekannter Anbieter mit Vorlagenabgleich liegt die Genauigkeit auf Feldebene nach der Vorlagenkalibrierung typischerweise über 99,5 %. Bei unstrukturierten Rechnungen von neuen Anbietern liegt die Genauigkeit beim ersten Versuch in der Regel bei 95–98 % und verbessert sich, wenn das System das Format des Anbieters lernt. Die wichtigste Messgröße, die es zu verfolgen gilt, ist die Ausnahmerate – bei gut konfigurierten Pipelines liegen Ausnahmeraten unter 5 % des gesamten Dokumentenvolumens.

Nächste Schritte

Die manuelle Dokumentenverarbeitung ist eine Kostenstelle, die keinen Wettbewerbswert schafft. Die Automatisierung der OpenClaw-Dokumentenverarbeitung wandelt sie von einem personalintensiven Vorgang in eine automatisierte Pipeline um, die über 95 % Ihres Dokumentenvolumens ohne menschliches Eingreifen verarbeitet.

Das [OpenClaw-Implementierungsteam] (/services/openclaw) von ECOSIRE ist auf den Aufbau von Dokumentenverarbeitungspipelines spezialisiert, die in Odoo, SAP, QuickBooks und benutzerdefinierte ERPs integriert sind. Wir kümmern uns um das Design von Dokumentklassifizierungsvorlagen, die OCR-Kalibrierung, die Konfiguration von Validierungsregeln, die ERP-Integration und die Einrichtung von Ausnahme-Workflows – und liefern in sechs bis acht Wochen ein produktionsbereites System.

Kontaktieren Sie ECOSIRE, um mit einem Dokumentenverarbeitungsaudit Ihres aktuellen Betriebs zu beginnen.

Document Processing Automation with OpenClaw