30 Albaranes pro Tag, ein Protokoll
Spanische Lieferscheine im Batch verarbeiten

Ein einzelner Lieferschein dauert Minuten. Das Problem beginnt, wenn jeden Morgen 30 Stück von 20 verschiedenen Lieferanten kommen.

Die Einzelbeleg-Erfassung löst ein 3-Minuten-Problem. Die Stapelverarbeitung löst ein strukturelles Workflow-Problem: 30 Minuten Dateneingabe sind nicht die Kosten – es sind die 30 eigenständigen Entscheidungen über Feldzuordnungen, die 30 Gelegenheiten, eine handschriftliche Menge falsch zu lesen, und die 30 manuellen Tastatureingaben ins WMS, die jeweils eine Fehlerquote von 1-3 % mit sich bringen.

Ein einzelner spanischer Lieferschein (Albarán) ist handhabbar. Der Wareneingangsmitarbeiter liest die gedruckten Felder – Albarán-Nummer, Lieferanten-NIF, Produktcodes, gelieferte Mengen – und tippt sie ins WMS oder ERP. Bei 3 Minuten pro Beleg dauert ein Stapel von 5 Stück 15 Minuten. Das ist mühsam, aber machbar. Das Problem ist, dass Lager, die von einem typischen spanischen Lieferantenstamm beliefert werden, nicht 5 Albaranes pro Tag sehen. Ein mittelgroßes Distributionszentrum für den regionalen Einzelhandel oder ein Produktionswerk, das Rohstoffe von einer Mischung aus großen und kleinen spanischen Lieferanten erhält, verarbeitet täglich 20-50 Albaranes. Bei diesem Volumen ergeben 3 Minuten pro Beleg 1-2,5 Stunden reine Dateneingabe. Aber die wahren Kosten sind nicht die Tippzeit – es ist das, was passiert, wenn diese 50 manuellen Übertragungen auf den Drei-Wege-Abgleich treffen.

Wenn Sie eine Einführung benötigen, was spanische Albaranes strukturell von generischen Lieferscheinen unterscheidet – einschließlich des NIF-Steuer-ID-Formats, der Tradition des Durchschlagpapiers und ihrer rechtlichen Bedeutung nach dem Código de Comercio – beginnen Sie mit dem Leitfaden zur Einzelbeleg-Erfassung von Albaranes. Dieser Artikel setzt voraus, dass Sie bereits wissen, was ein Albarán ist, und konzentriert sich darauf, was sich ändert, wenn Sie sie dutzendweise statt einzeln verarbeiten.

Batch-Verarbeitung verstärkt Formatfragmentierung nicht – sie zeigt, dass templatebasierte Extraktion nie eine echte Lösung war.

Bei der Verarbeitung eines einzelnen Albaráns kann man dessen Eigenheiten tolerieren. Bei 30 Belegen von 20 Lieferanten sind die Formatunterschiede zwischen einem Albarán eines Mercadona-Logistikzentrums, einem handschriftlich geführten Albarán-Buch eines andalusischen Herstellers und einer Sage-Murano-PDF eines baskischen Industrielieferanten keine Eigenheiten mehr – sie sind eine strukturelle Hürde, die templatebasierte Extraktion nicht überwinden kann.

Die spanische Albarán-Formatslandschaft ist dauerhaft heterogen, weil die wirtschaftlichen Anreize für Standardisierung nicht zusammenpassen. Die AECOC (Asociación de Fabricantes y Distribuidores, Spaniens GS1-Standardisierungsgremium mit über 35.000 Mitgliedsunternehmen) hat über ihre Plattformen AECOC EDI und AECOC TRANSP elektronische Lieferscheinstandards entwickelt. Große Einzelhändler wie Mercadona, Carrefour Spanien und El Corte Inglés schreiben EDI für ihre Tier-1-Lieferanten vor. Im Mittelstand – regionale Distributoren, Industrielieferanten, lokale Hersteller – sind jedoch Papier-Albaránes aus der jeweiligen ERP-Software des Lieferanten weiterhin die Norm.

UNO Logística, Spaniens wichtigster Logistikverband mit über 350 Mitgliedsunternehmen aus Logistik und Transport, identifiziert die Fragmentierung der Dokumentformate als strukturelle Hürde für die Digitalisierung der Lieferkette. Das Centro Español de Logística (CEL), Spaniens größte Logistik-Fachgemeinschaft seit 1978, kommt in seinen Digitalisierungs-Arbeitsgruppen zum gleichen Schluss: Standardisierung wird zunächst in Hochvolumen-Korridoren Einzug halten, aber der lange Schwanz der mittelständischen Lieferanten wird noch Jahre lang heterogene Papier- und PDF-Albaránes produzieren.

Im Einzelbeleg-Maßstab kann man pro Lieferant eine Vorlage erstellen. Bei 20 Lieferanten sind das 20 Vorlagen, die erstellt und gepflegt werden müssen – und Vorlagen brechen, wenn ein Lieferant sein ERP-Ausgabeformat ohne Vorankündigung ändert. Der Wareneingangsmitarbeiter hat keine Kontrolle über die Lieferantenformate. Er erhält, was am Dock ankommt. Der einzig gangbare Weg im Batch-Maßstab ist die Benutzerdefinierte Spaltenextraktion: eine Methode, bei der Sie die gewünschten Feldnamen definieren – „Albarán-Nummer", „Lieferanten-NIF", „Versandmenge" – und die KI jedes Dokument liest, um diese Werte zu finden, indem sie versteht, was der Feldname bedeutet, und nicht durch Abgleich einer festen Pixelposition auf dem Layout eines bestimmten Lieferanten.

Eine Spaltendefinition funktioniert über 20 verschiedene Lieferantenformate hinweg, weil die KI nach Bedeutung liest, nicht nach Position. Die von Ihnen eingegebenen Spaltennamen werden zu den Kopfzeilen Ihrer Ausgabetabelle – kein Vorlagen-Pflegeaufwand erforderlich.

Der Batch-Workflow für spanische Albarane: Tagesstapel hochladen, Spalten einmal definieren, einheitliches Wareneingangsprotokoll exportieren.

Die gesamten morgendlichen Albarane – PDFs aus dem Lieferantenportal, gescannte Durchschläge vom Wareneingang, bei Anlieferung aufgenommene Fotos – gehen in einen Upload. Eine Spaltendefinition. Eine Ausgabetabelle.

Batch-Verarbeitung bei ImageToTable.ai bedeutet das gleichzeitige Hochladen mehrerer Dateien, das einmalige Definieren Ihrer Extraktionsspalten und den Erhalt einer einzigen konsolidierten Ausgabe, bei der jedes Dokument eine Zeile in der Tabelle wird. Der grundlegende Vorteil ist, dass Sie den Schritt der Spaltendefinition nicht pro Dokument wiederholen – Sie führen ihn einmal für den gesamten Batch durch, und die KI wendet das gleiche semantische Verständnis auf jedes Lieferantenlayout an. Für Google Sheets-Nutzer extrahiert das Add-on in der Seitenleiste die Ergebnisse direkt in das aktive Blatt, ohne die Tabelle verlassen zu müssen.

Testen Sie den Extraktionsablauf unten mit einem Muster-Lieferschein. Die Demo lädt eine Voreinstellung – eine vorkonfigurierte Liste von Spaltennamen, die der Standardstruktur von Lieferscheinen und Packlisten entspricht – sodass Sie sofort Extraktionsergebnisse sehen, ohne Spaltennamen eingeben zu müssen.

Der Dreifachabgleich skaliert nicht linear – eine falsche Albarán-Nummer in einem Batch von 50 kann den Abgleich für die gesamten Monatsrechnungen eines Lieferanten zerstören.

Der spanische Plan General de Contabilidad (PGC) weist jedem Albarán einen bestimmten Buchungspfad zu: Soll an Grupo 3 Existencias (Konto 600 für Wareneinkäufe oder 601 für Rohstoffe) und Haben an Konto 400 Proveedores. Die Albarán-Nummer ist die Referenz, die den Wareneingang mit diesem Buchungssatz verbindet – bevor die Factura (Rechnung) eintrifft.

In einem Einzelbeleg-Workflow fällt ein Tippfehler bei der Albarán-Nummer sofort auf, wenn die zugehörige Factura eintrifft und nicht passt. Sie brauchen 5 Minuten, um die Papierspur zu verfolgen und korrigieren den Eintrag. Ärgerlich, aber begrenzt. In einem Batch-Workflow, bei dem Sie 30–50 Albaránes ins ERP eingeben, bevor Facturas eintreffen, potenziert sich der Schaden still: Falsche Albarán-Nummern bleiben im System, bis der Lieferant seine Rechnung sendet. Dann scheitert der Dreifachabgleich – Bestellung → Albarán (Wareneingang) → Factura (Rechnung) – nicht nur für ein Dokument, sondern potenziell für alle Lieferungen eines Monats von diesem Lieferanten. Die Buchhaltung muss nun rückwirkend ermitteln, welche Einträge bei Dutzenden von Transaktionen falsch sind.

Hier ändert die Extraktion der Albarán-Nummer direkt aus dem Dokument – statt menschlicher Abschrift – das Risikoprofil. Eine abgetippte Albarán-Nummer hat eine Fehlerrate von 1–3 % pro Feld. Eine maschinell aus dem Belegbild gelesene Albarán-Nummer hat bei gedrucktem Text praktisch keine Transkriptionsfehler. Bei gescannten Durchschlägen mit blasser Schrift markiert die KI unsichere Werte, statt still ein falsches Ergebnis zu liefern – der Wareneingangsprüfer prüft dann die 2–3 unsicheren Lesungen, statt alle 50 Einträge Korrektur zu lesen.

Der Dreifachabgleich scheitert nicht erst bei der Rechnung, sondern bereits bei der Albarán-Erfassung – Wochen bevor es jemand merkt. Die Korrektur an der Datenerfassungsstelle kostet Sekunden. Die Korrektur nach Eintreffen der Facturas kostet Stunden pro Lieferant.

Ein spanischer Albarán enthält zwei Datenschichten: die gelieferte Menge des Lieferanten und die tatsächlich gezählte Menge des Empfängers. Bei der Stapelverarbeitung bedeutet das manuelle Lesen beider Schichten, 30 Mal dieselben Korrekturen zu lesen.

Der Rundlauf des Albaráns – der Lieferant druckt ihn, die Ware reist mit, der Empfänger ergänzt ihn, die unterschriebene Kopie geht zurück – erzeugt ein Zwei-Schichten-Problem, das bei Einzelbelegen beherrschbar ist, aber bei Stapelverarbeitung zum dominanten Engpass wird.

Jeder spanische Albarán, der am Dateneingabeplatz ankommt, enthält drei Arten handschriftlicher Inhalte: Mengenkorrekturen („nur 8 Stk erhalten“ neben gedruckten „10“), Zustandsvermerke („Karton beschädigt“, „Verpackung defekt“) und die Unterschrift des Empfängers als Bestätigung. Im Einzelbeleg-Workflow liest der Wareneingangsmitarbeiter diese Notizen und gibt die korrigierte Menge ins WMS ein. Bei 30 Albaranes liest der Mitarbeiter 30 handschriftliche Korrekturen – viele mit ähnlicher Formulierung verschiedener Lieferanten – und muss jede Korrektur korrekt der zugehörigen gedruckten Position zuordnen, ohne Daten zwischen den Belegen zu vertauschen.

Das ist kein Geschwindigkeits-, sondern ein kognitives Belastungsproblem. Nach 10 Albaranes unterscheidet das Gehirn nicht mehr zwischen „8 Stk erhalten“ auf dem Mercadona-Albarán und „8 Stk“ auf dem Lieferschein von RS Components España. Vorlagenbasierte Extraktionstools verschärfen dies, indem sie entweder die handschriftliche Schicht komplett ignorieren (Versandmengen liefern, die nicht dem tatsächlichen Eingang entsprechen) oder handschriftlichen und gedruckten Text in derselben Ausgabezelle vermischen (unsinnige Daten erzeugen).

Ein semantischer Ansatz löst dies, indem er die gedruckte und die handschriftliche Schicht als separate Extraktionsziele behandelt. Definieren Sie Menge geliefert und die KI liest die gedruckte Liefermenge aus der Positionstabelle. Definieren Sie Menge erhalten im selben Spaltensetup und die KI liest die handschriftliche Korrektur. Diese landen in benachbarten Spalten der Ausgabe – gedruckte und erhaltene Menge nebeneinander, Abweichungen sofort sichtbar. Definieren Sie Ausnahmevermerke und handschriftliche Randnotizen werden als strukturierter Text extrahiert.

Standardmäßige Blockschrift wird zuverlässig über den gesamten Stapel extrahiert. Stark eilige Schreibschrift – typisch für Fahrernotizen, die am Dock hingekritzelt werden – kann für die Volltexterkennung eine punktuelle Überprüfung erfordern, aber die strukturierte Erkennung (Unterschrift vorhanden: ja/nein, Mengenkorrekturen) bleibt auch bei flüchtiger Handschrift zuverlässig. Das ist die ehrliche Grenze: Das Tool liest, was lesbar ist, markiert, was mehrdeutig ist, und erzeugt niemals stillschweigend einen falschen Wert.

Häufig gestellte Fragen

Der Stapel spanischer Albaráns, der jeden Morgen auf dem Wareneingangstisch liegt, ist kein Datenerfassungsproblem – es ist ein Formatübersetzungsproblem, multipliziert mit der Anzahl Ihrer Lieferanten. Wenn eine Spaltendefinition für jedes Lieferantenlayout funktioniert, wird aus dem Stapel ein einzelner Upload, ein einzelner Verarbeitungslauf und eine einzelne Tabelle, die Ihrem WMS die sauberen Daten liefert, für die es entwickelt wurde. Das ist der Unterschied zwischen einem WMS, das auf dem Papier eine 99%ige Fehlereliminierung meldet, und einem, das dies tatsächlich auf Ihrer Rampe erreicht.

Albaranes stapelweise verarbeiten

Verwandte Themen: Daten aus spanischen Lieferscheinen (Albaranes) in Excel extrahieren · Paketbelege und Lieferscheine stapelweise in Excel extrahieren · Paketbelegfelder aus jedem Format in Excel extrahieren · Lieferschein-zu-Excel-Konverter