TL;DR
Materialzeugnis-Validierung im Wareneingang frisst bei einem mittelständischen Fertiger pro Tag fünf bis acht Personen-Tage. Wir bauen mit Azure Document Intelligence plus einer eigenen Domain-Regel-Engine eine Pipeline, die 320k EUR Annual Value liefert — bei 55-85k EUR Sprint-Festpreis über zwölf Wochen. Der Hebel ist die saubere Trennung: OCR kaufen, Regeln selber schreiben.
Was Wareneingang in Defense und Maschinenbau 2026 leidet
Wer in der DACH-Verteidigungs- und Antriebstechnik einkauft, weiß: jede Lieferung Stahl, Aluminium oder Sonderwerkstoff kommt mit einem Werkstoff-Zeugnis nach EN 10204. Die Typen 2.1, 2.2, 3.1 und 3.2 unterscheiden sich in der Prüf-Tiefe und in der Frage, wer das Dokument unterschrieben hat — der Hersteller selbst oder ein unabhängiger Sachverständiger. Auf dem Papier (meist tatsächlich Papier oder schlecht gescannte PDFs) stehen chemische Zusammensetzung, Zugfestigkeit, Streckgrenze, Bruchdehnung, Wärmebehandlung, Charge und Schmelzanalyse.
Die Pflicht-Validierung ist nicht verhandelbar: Werte gegen die Bestell-Spezifikation prüfen, Stempel der Hütte kontrollieren, Unterschrift verifizieren, Charge im ERP verbuchen, Freigabe für die Produktion erteilen. Bei einem unserer Kunden — einem bayerischen Hersteller von Antriebstechnik für die Verteidigungs- und Marineindustrie — laufen pro Tag 80 bis 200 Zeugnisse durch den Wareneingang. Pro Zeugnis brauchen erfahrene Prüfer 25 bis 45 Minuten. Das sind in der Spitze acht Personen, die nichts anderes tun.
Was uns aus der Praxis am häufigsten gemeldet wird: 30 bis 50 Prozent der Fehler bleiben unentdeckt. Eine verrutschte Kommastelle in der Zugfestigkeit, eine Charge, die im ERP auf das falsche Material gebucht wird, ein Sonderzeichen das das OCR-Modul der ERP-Anbindung killt. Im zivilen Maschinenbau ist das ärgerlich — in der Defense-Lieferkette ist es ein Compliance-Vorfall mit NCR-Pflicht (Non-Conformance Report) und im Worst Case Stopp der BAFA-Lieferfreigabe.
Was wir bauen — Architektur in einem Satz
Azure Document Intelligence übernimmt die OCR- und Layout-Extraktion mit einem auf den Kunden trainierten Custom Model. Unsere Domain-Regel-Engine in Python prüft die extrahierten Werte gegen die Bestell-Spezifikation aus dem ERP. Ein Confidence-Routing entscheidet pro Zeugnis: Auto-Freigabe, Sichtprüfung oder Vollkontrolle. Alles landet als Audit-Trail in Loki, abrufbar für Zoll, BAFA und Defense-Audits.
In unserer Erfahrung ist die Architektur banal. Der Wert entsteht in der Domain-Regel-Engine und im Custom-Model-Training. Beides muss tief im Kunden-Kontext sitzen — Spec-Toleranzen pro Werkstoff, Lieferanten-Stempel-Katalog, ERP-Charge-Logik. Generische SaaS-Tools, die „EN 10204 Validator“ verkaufen, scheitern genau hier.
Die Doktrin — OCR kaufen, Domain-Regeln bauen
Wir empfehlen Kunden konsequent: kauft die OCR ein, baut die Domain-Regel-Engine selbst. Das ist keine Religion, sondern Kalkül.
Azure Document Intelligence liefert auf einem sauber trainierten Custom Model 95 Prozent Out-of-the-Box-Genauigkeit auf Standard-Zeugnissen. Die OCR-Stack-Tiefe (Layout, Tabellen-Erkennung, Handschrift-Fallback) reproduziert ein Mittelständler nicht in einem 12-Wochen-Sprint. Hier kaufen ist richtig.
Die Domain-Regel-Engine ist das genaue Gegenteil. Sie entscheidet, ob eine 4140-Charge in den Defense-Auftrag fließt oder nicht. Diese Logik darf nicht in einer fremden Cloud liegen, nicht in einer YAML-Config ohne Versionierung, nicht in einer Vendor-DSL. Sie muss als getesteter Python-Code im Kunden-Repo leben — auditierbar, versioniert, von der internen IT wartbar.
Klare Empfehlung: Wer Komplett-Lösungen kauft („EN 10204 Validator as a Service“), zahlt zweimal. Einmal die Lizenz, einmal später den Ausstieg. Defense-Kunden trifft es härter — Daten dürfen nicht in US-Cloud, BAFA verlangt Nachvollziehbarkeit der Validierungs-Logik. Eine Black-Box besteht das Audit nicht.
Code-Beispiel — Azure DI Custom Model
Das Custom Model wird auf 100+ historische Materialzeugnisse trainiert. Die Feld-Definition (ChargenNummer, ZugfestigkeitMPa etc.) entsteht in der ersten Sprint-Woche zusammen mit dem Qualitäts-Team des Kunden. Der Aufruf ist trivial:
from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.core.credentials import AzureKeyCredential
di_client = DocumentIntelligenceClient(
endpoint="https://pexon-di-eu.cognitiveservices.azure.com/",
credential=AzureKeyCredential(KEY),
)
with open("materialzeugnis_charge_4477.pdf", "rb") as f:
poller = di_client.begin_analyze_document(
model_id="materialzeugnis-en10204-v3", # Custom Model
body=f.read(),
)
result = poller.result()
# Extrahierte strukturierte Felder
doc = result.documents[0]
extracted = {
"charge": doc.fields["ChargenNummer"].value_string,
"werkstoff": doc.fields["Werkstoffbezeichnung"].value_string,
"zugfestigkeit_mpa": float(doc.fields["ZugfestigkeitMPa"].value_string),
"streckgrenze_mpa": float(doc.fields["StreckgrenzeMPa"].value_string),
"stempel_huette": doc.fields["StempelLieferantenHuette"].value_boolean,
"unterschrift_vorhanden": doc.fields["Unterschrift"].value_boolean,
}Wichtig ist hier nicht der Code, sondern die Endpoint-Wahl. Wir deployen Azure DI ausschließlich in der EU-Region (Frankfurt oder Zürich-Nord) mit Customer-Managed Keys. Für Defense-Kunden mit zusätzlicher BSI-Anforderung läuft die Inferenz in einer Azure Sovereign Cloud oder über Azure Local on-premise — die Custom-Model-Datei verlässt das Kunden-Rechenzentrum nicht.
Code-Beispiel — Domain-Regel-Engine
Hier sitzt der eigentliche Wert. Die Regel-Engine ist getesteter Python-Code, kein YAML, kein Vendor-Lock. Jede Regel hat einen Unit-Test, jede Spec-Änderung läuft durch ein Pull Request.
from dataclasses import dataclass
from typing import Optional
@dataclass
class MaterialSpec:
werkstoff: str
zugfestigkeit_min: float
zugfestigkeit_max: float
streckgrenze_min: float
en_10204_typ: str # z.B. "3.1"
def validiere_zeugnis(extracted: dict, spec: MaterialSpec) -> dict:
fehler = []
if not extracted.get("stempel_huette"):
fehler.append("Stempel Lieferanten-Hütte fehlt")
if not extracted.get("unterschrift_vorhanden"):
fehler.append("Unterschrift fehlt")
if extracted["werkstoff"] != spec.werkstoff:
fehler.append(f"Werkstoff-Abweichung: {extracted['werkstoff']} vs {spec.werkstoff}")
if not (spec.zugfestigkeit_min <= extracted["zugfestigkeit_mpa"] <= spec.zugfestigkeit_max):
fehler.append(
f"Zugfestigkeit {extracted['zugfestigkeit_mpa']} MPa außerhalb "
f"Toleranz [{spec.zugfestigkeit_min}, {spec.zugfestigkeit_max}]"
)
if extracted["streckgrenze_mpa"] < spec.streckgrenze_min:
fehler.append(f"Streckgrenze unter Minimum {spec.streckgrenze_min} MPa")
return {"freigabe": len(fehler) == 0, "fehler": fehler}Confidence-Routing kommt eine Ebene darüber: Liegt die Azure-DI-Confidence über 0,9 und ist freigabe=True, läuft die Charge automatisch ins ERP. Zwischen 0,7 und 0,9 geht das Zeugnis an einen Sichtprüfer mit Markierung der unsicheren Felder. Unter 0,7 oder bei Regel-Fehlern landet es bei der Vollkontrolle. Diese Schwellen tunen wir in den ersten vier Wochen mit echten Daten — Default-Werte sind ein Startpunkt, kein Endzustand.
ROI — 320k Annual Value bei 55-85k Sprint
Die Rechnung ist konservativ gehalten, wir bauen sie immer von unten nach oben.
Nicht in der Tabelle, aber real: weniger NCR-Vorfälle, schnellere Time-to-Production (Stunden statt Tagen), entlastete Defense-Compliance-Teams. Bei einem unserer Kunden hat allein die Reduktion der Charge-Fehlbuchungen im ERP einen sechsstelligen Folge-Schaden im Jahr verhindert — Schäden, die niemand vorher in einem Business Case auf der Habenseite verbucht hat.
Klare Empfehlung: Den Business Case nie nur über FTE-Save argumentieren. Defense-Kunden überzeugt die Time-to-Production-Verkürzung und die NCR-Reduktion zusätzlich. Beide Zahlen müssen vor Sprint-Start in einer Baseline gemessen werden, sonst fehlt nach Go-Live der Vergleich.
Defense-Compliance-Pfad
Defense-Lieferanten haben mehr Auflagen als zivile Fertiger. Unsere Erfahrung mit der DACH-Verteidigungswelle 2024-2026 (Bundeswehr-Sondervermögen, EU Defence Fund, NATO-Beschaffungen) sagt: die Architektur muss von Tag eins compliance-fest sein, nachträgliches Härten ist teurer als sauberer Start.
Der Punkt mit der Domain-Regel-Engine als Code ist nicht akademisch. Eine BAFA-Prüfung verlangt im Ernstfall, dass jede Charge-Freigabe rekonstruierbar ist — welche Regel hat zu welchem Zeitpunkt mit welchen Toleranzen gegriffen. Ein YAML-Switch oder eine SaaS-Konfiguration im Browser eines Dritten erfüllt das nicht. Versionierter Code mit Pull-Request-Historie schon.
Anti-Patterns — was wir nicht machen
Aus zwei Jahren Document-AI-Praxis in der DACH-Fertigung haben wir eine kurze Liste von Mustern, die zuverlässig scheitern:
- Pure-VLM auf Materialzeugnis-Tabellen. Vision-Language-Modelle (auch GPT-4o, Gemini, Claude Vision) halluzinieren bei strukturierten Mess-Werten. Kommastellen werden vertauscht, Zellen falsch zugeordnet. Für Layout-freie Dokumente (Fließtext-Verträge) sind VLMs stark, für tabellarische Prüf-Zeugnisse sind sie ein Compliance-Risiko.
- Komplett-Lösungen Cloud-only. „Materialzeugnis-Validierung as a Service“ mit Daten-Upload in US-Cloud. Defense-tauglich Null, BAFA-Audit Fehlanzeige.
- Domain-Regel-Engine als YAML-Config. Klingt elegant, killt den Audit-Trail. Wer hat wann welche Regel geändert? Code mit Git beantwortet das, YAML in einer Datenbank nicht.
- Kein Confidence-Routing. Entweder alles automatisch (90 Prozent Müll werden durchgewinkt) oder gar nichts (kein ROI). Beides falsch.
- Custom Model ohne 100+ Trainings-Samples. Out-of-the-Box-Modelle scheitern an der Varianten-Breite — jeder Stahl-Hersteller hat ein eigenes Layout. Wir bestehen auf mindestens 100 Beispielen vor Go-Live.
Defense-Wave 2026 — warum jetzt
Die DACH-Verteidigungsindustrie wächst seit 2024 zweistellig. Bundeswehr-Sondervermögen, EU Defence Fund, NATO-Lückenfüller in der Ukraine-Logistik. Antriebstechnik, Munition, Sensorik, Avionik — überall steigen die Liefer-Volumina. Mehr Lieferungen bedeuten mehr Wareneingang. Mehr Wareneingang bedeutet mehr Materialzeugnisse. Und parallel zieht der Compliance-Druck an: NATO STANAG, BSI-IT-Grundschutz, BAFA-Genehmigungen.
Wir sehen in unserer Pipeline drei Defense-Tier-1-Lieferanten, die genau dieses Bottleneck angehen. Der Sprint-ROI ist in dem Sektor besonders steil, weil jede vermeidbare Liefer-Verzögerung in einem Defense-Programm sechsstellige Pönalen auslöst. Document-AI wird hier nicht zum Nice-to-Have, sondern zum Bottleneck-Killer.
FAQ
1. Materialzeugnis-Validierung — was ist EN 10204 3.1 vs 3.2?
Typ 2.1 ist die Werksbescheinigung des Herstellers ohne Prüf-Ergebnisse, Typ 2.2 enthält Prüf-Ergebnisse aus einer nicht-spezifischen Prüfung. Typ 3.1 ist ein Abnahmeprüfzeugnis, ausgestellt vom Hersteller, aber mit spezifischen Prüfungen am gelieferten Material und unterschrieben von einer vom Fertigungs-Bereich unabhängigen Stelle. Typ 3.2 hat zusätzlich die Unterschrift eines externen Sachverständigen — Pflicht in den meisten Defense- und Druckbehälter-Anwendungen. Unsere Regel-Engine prüft den Typ explizit gegen die Bestellung.
2. Warum Azure Document Intelligence statt eines reinen VLM?
Azure DI ist auf strukturierte Dokumente mit Tabellen und Layout-Erkennung trainiert. Reine VLMs halluzinieren bei Mess-Werten — eine 4 wird zur 1, eine Kommastelle verschwindet. Für eine 4140-Stahl-Charge mit Spec-Toleranz von ±30 MPa ist das ein Compliance-Killer. Azure DI mit Custom-Training liefert in unserer Erfahrung 95-98 Prozent Feld-Genauigkeit, VLMs liegen auf den gleichen Dokumenten bei 70-85 Prozent.
3. Defense-tauglich — wie sieht der Compliance-Pfad aus?
Drei Stufen: Azure EU-Region für zivile Defense-Lieferanten, Azure Sovereign Cloud für klassifizierte Bereiche, Azure Local on-premise für die strengsten BSI-Anforderungen. In allen drei Fällen läuft die Domain-Regel-Engine als Python-Code im Kunden-Repo, der Audit-Trail landet in einem Loki-Stack im Kunden-Netz. Wir haben Kunden in allen drei Konfigurationen produktiv.
4. Was kostet der Sprint und wann amortisiert er sich?
Der Sprint-Festpreis liegt zwischen 55k und 85k EUR über zwölf Wochen, abhängig von ERP-Komplexität (SAP S/4HANA versus Eigenentwicklung) und Zahl der Lieferanten-Layouts. Bei 80 Zeugnissen pro Tag und 2,5 FTE-Save liegt der Annual Value bei 325k EUR — Payback unter vier Monaten. Bei höheren Volumina (200+ Zeugnisse/Tag) entsprechend früher.
5. Brauchen wir Custom Model Training oder reicht Prebuilt?
Prebuilt reicht nicht. Materialzeugnisse haben pro Stahl-Hersteller eigene Layouts, eigene Tabellen-Strukturen, teils handschriftliche Ergänzungen. Wir trainieren immer ein Custom Model auf mindestens 100 historische Zeugnisse pro Hauptlieferant. Das passiert in den ersten vier Sprint-Wochen, parallel zum Aufbau der Regel-Engine.
Nächster Schritt
Wer im Wareneingang täglich mehr als 50 Materialzeugnisse prüft, hat einen klaren Business Case. Wer zusätzlich in der Defense- oder Druckbehälter-Lieferkette sitzt, hat einen unverhandelbaren Compliance-Hebel obendrauf. Wir liefern den Sprint mit Festpreis, klarem Pflichtenheft und einem messbaren Annual Value.
Materialzeugnis-Sprint anfragen — 12 Wochen mit Festpreis 55-85k EUR
