30 Lieferscheine (albaranes) pro Tag, ein Protokoll
Spanische Lieferscheine im Batch verarbeiten
Der spanische Hersteller von Lagerverwaltungssoftware Mecalux – eine in Barcelona ansässige Intralogistik-Gruppe, die in über 70 Ländern tätig ist und im Gartner Magic Quadrant 2026 für WMS (Lagerverwaltungssysteme) genannt wird – berichtet, dass seine Plattform Easy WMS bei Lagerkunden eine Fehlereliminierung von 99 % und eine Produktivitätssteigerung von 60 % erreicht. Diese Zahlen beschreiben, was passiert, wenn das WMS saubere Daten erhält. Die Kluft zwischen diesem Versprechen und der Realität ist der Stapel Lieferscheine (albaranes), der jeden Morgen auf dem Wareneingangsschreibtisch liegt: 30 Seiten von 20 verschiedenen Lieferanten, gedruckt von 20 verschiedenen ERP-Systemen, einige auf Thermopapier, einige als Durchschlag, die meisten mit handschriftlichen Mengenkorrekturen des Empfängers. In diesem Artikel geht es darum, diese Kluft im Batch-Maßstab zu schließen.
Die wichtigsten Erkenntnisse
- Ein Morgenstapel von 30 Lieferscheinen (albaranes) von 20 Lieferanten kostet 2 Stunden Tipparbeit – und das ist noch der günstigste Teil.
- Vertippen Sie sich bei einer Lieferscheinnummer (albarán) nur um eine Ziffer, bricht der Drei-Wege-Abgleich für die gesamten Monatsrechnungen dieses Lieferanten zusammen – aber Sie merken es erst nach drei Wochen.
- ImageToTable.ai liest Lieferscheinnummern (albaranes), NIF (Steueridentifikationsnummern) und Mengen aus 20 verschiedenen Lieferantenformaten mit einer einzigen Spaltendefinition – weil die KI danach sucht, was das Feld bedeutet, nicht wo es auf der Seite steht.
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.
Die Skalierungsklippe betrifft nicht die Geschwindigkeit – sondern die Entscheidungsdichte. Die Verarbeitung eines Albarán erfordert einen Satz von Feldort-Entscheidungen. Die Verarbeitung von 30 von verschiedenen Lieferanten erfordert 30 unabhängige Sätze. Das menschliche Gehirn kann 5 ohne Ermüdung bewältigen. Bei 30 potenzieren sich die Fehlerraten. Bei 50 beginnt der Drei-Wege-Abgleich – Albarán → Factura → Bestellung – zu versagen, nicht weil ein einzelner Eintrag falsch war, sondern weil die kumulative Wahrscheinlichkeit einer Nichtübereinstimmung über 150 Referenznummern (50 Albaranes × 3 Abgleichschlüssel) nahezu sicher wird.
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.
Ladescheine des Tages hochladen – alle Formate zusammen
Laden Sie PDF-Ladescheine von Lieferantenportalen, gescannte Durchschläge vom Wareneingang oder Handyfotos von Lieferkontrollen hoch. Digitale PDFs, gescannte Papiere und Fotos können in einem Batch gemischt werden. Wenn Ihre Fahrer oder Mitarbeiter im entfernten Lager Ladescheine direkt einreichen müssen, generiert der Sammel-Link eine teilbare Upload-Seite – der Absender öffnet den Link, gibt einen Bestätigungscode ein und lädt Dateien hoch. Kein Login oder Registrierung für den Absender erforderlich. Ladescheine landen direkt in Ihrer Verarbeitungswarteschlange und umgehen E-Mail-Anhänge und WhatsApp-Fotos vollständig.
Wareneingangslog-Spalten einmal definieren – für alle Lieferanten gültig
Geben Sie die Feldnamen ein, die Ihr Wareneingangsprozess und Ihr ERP benötigen: Ladeschein-Nr. | Bestellbezug | Lieferantenname | Lieferanten-UID | Lieferdatum | Artikelcode | Artikelbezeichnung | Gelieferte Menge | Erhaltene Menge | Ausnahmevermerk | Unterschrift Empfänger. Die KI findet jeden Wert auf jedem Ladeschein, indem sie die Bedeutung des Spaltennamens versteht – nicht durch Abgleich einer gespeicherten Pixelposition. Fügen Sie eine berechnete Spalte wie Mengendifferenz (Geliefert − Erhalten) hinzu, und die KI berechnet die Differenz während der Extraktion und markiert Abweichungen, bevor die Daten Ihr WMS erreichen. Fügen Sie eine abgeleitete Spalte wie Lieferzustand (Optionen: Vollständig/Teilweise/Beschädigt) hinzu, und die KI bewertet den Ladeschein-Inhalt, um den korrekten Status für jedes Dokument im Batch zuzuweisen.
Konsolidierten Wareneingangslog exportieren
Herunterladen als XLSX, CSV oder JSON. Jeder Ladeschein wird zu einer Zeile. Jedes Feld – Ladeschein-Nummer, Lieferanten-UID, Artikelcodes, gelieferte und erhaltene Mengen, Ausnahmevermerke, Unterschriftsstatus – erscheint in einer eigenen Spalte. Die Tabelle ist bereit für die WMS-Wareneingangsbuchung in SAP Business One, Sage 200 / Sage Murano, Microsoft Dynamics NAV / Business Central, Holded oder Mecalux Easy WMS. Die Spalte mit der Ladeschein-Nummer ist der Schlüssel, der jede Zeile mit der späteren Rechnung für den Drei-Wege-Abgleich verknüpft. Die Verarbeitung läuft mit 5–10 Sekunden pro Seite.
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.
Dateien werden sicher verarbeitet und nicht gespeichert.
Der Drei-Wege-Abgleich skaliert nicht linear — eine falsch getippte Lieferscheinnummer (albarán) in einer Charge von 50 kann den Abgleich für die gesamten Monatsrechnungen eines Lieferanten zunichtemachen.
Der spanische Kontenrahmen (PGC) weist jedem Lieferschein (albarán) einen bestimmten Buchungspfad zu: Soll an Kontenklasse 3 Vorräte (Konto 600 für Wareneinkauf oder 601 für Rohstoffeinkauf) und Haben an Konto 400 Verbindlichkeiten aus Lieferungen und Leistungen. Die Lieferscheinnummer (albarán) ist die Referenz, die den physischen Wareneingang mit diesem Buchungssatz verbindet — bevor die Rechnung (factura) eintrifft.
In einem Einzeldokument-Workflow fällt ein Tippfehler bei der Lieferscheinnummer (albarán) auf, sobald die zugehörige Rechnung (factura) eintrifft und nicht übereinstimmt. Sie verbringen 5 Minuten damit, den Papierweg nachzuverfolgen, und korrigieren den Eintrag. Ärgerlich, aber begrenzt. In einem Batch-Workflow, bei dem Sie 30–50 Lieferscheine (albaranes) in das ERP-System eingeben, bevor Rechnungen (facturas) eintreffen, wirkt der Schaden stillschweigend kumulativ: Falsche Lieferscheinnummern (albarán) bleiben im System, bis der Lieferant seine Rechnung sendet. Dann schlägt der Drei-Wege-Abgleich — Bestellung → Lieferschein (albarán, Wareneingang) → Rechnung (factura) — fehl, nicht nur für ein Dokument, sondern potenziell für die gesamten Monatslieferungen dieses Lieferanten. Die Buchhaltung muss nun bei Dutzenden von Transaktionen rekonstruieren, welche Einträge falsch sind.
Hier verändert eine Extraktion, die die Lieferscheinnummer (albarán) direkt aus dem Dokument zieht — statt auf menschliche Transkription zu setzen — das Risikoprofil. Eine getippte Lieferscheinnummer (albarán) hat eine Fehlerquote von 1–3 % pro Feld. Eine maschinell aus dem Dokumentbild gelesene Lieferscheinnummer (albarán) hat bei gedrucktem Text praktisch null Transkriptionsfehler. Bei gescannten Durchschlägen mit möglicherweise verblasstem Druck kennzeichnet die KI Werte mit geringer Konfidenz, statt stillschweigend ein falsches Ergebnis zu liefern — der Wareneingangsmitarbeiter prüft dann die 2–3 unsicheren Lesungen, statt alle 50 Einträge Korrektur zu lesen.
Der Drei-Wege-Abgleich scheitert nicht erst bei der Rechnungsprüfung, sondern bereits bei der Erfassung des Lieferscheins (albarán) — Wochen bevor es jemandem auffällt. Die Korrektur an der Datenerfassung kostet Sekunden. Die Korrektur nach Eingang der Rechnungen (facturas) kostet Stunden pro Lieferant.
Ein spanischer Lieferschein (albarán) trägt zwei Datenschichten: was der Lieferant versendet hat und was der Empfänger tatsächlich gezählt hat. Bei Batch-Verarbeitung bedeutet das manuelle Lesen beider Schichten, identische Korrekturen 30-mal zu lesen.
Der Kreislauf des Lieferscheins (albarán) — der Lieferant druckt ihn, die Ware reist mit ihm, der Empfänger ergänzt Anmerkungen, die unterschriebene Kopie geht zurück — erzeugt ein Dokument mit zwei Schichten, das bei der Einzelverarbeitung beherrschbar ist, aber bei Batch-Verarbeitung zum dominierenden Engpass wird.
Jeder spanische Lieferschein (albarán), der am Datenerfassungsplatz ankommt, enthält drei Arten handschriftlicher Inhalte: Mengenkorrekturen („solo 8 uds recibidas“ neben einer gedruckten „10“), Zustandsvermerke („caja dañada“, „embalaje roto“) und die Unterschrift des Empfängers als Bestätigung des Eingangs. Im Einzeldokument-Workflow liest der Wareneingangsmitarbeiter diese Anmerkungen und tippt die korrigierte Menge ins WMS (Lagerverwaltungssystem). Bei 30 Lieferscheinen liest der Mitarbeiter 30 handschriftliche Korrekturen — viele mit ähnlicher Formulierung von verschiedenen Lieferanten — und muss jede Korrektur korrekt der entsprechenden gedruckten Positionszeile zuordnen, ohne Daten zwischen Dokumenten zu vertauschen.
Das ist kein Geschwindigkeitsproblem. Es ist ein Problem der kognitiven Belastung. Nach 10 Lieferscheinen hört das Gehirn auf, zwischen „8 uds recibidas“ auf dem Lieferschein von Mercadona und „8 uds“ auf dem Lieferschein von RS Components España zu unterscheiden. Vorlagenbasierte Extraktionstools verschärfen das Problem, indem sie die handschriftliche Schicht entweder komplett ignorieren (was Versandmengen liefert, die nicht den tatsächlich empfangenen Mengen entsprechen) oder handschriftlichen und gedruckten Text in derselben Ausgabezelle vermischen (was unsinnige Daten erzeugt).
Ein semantischer Ansatz löst das, indem er die gedruckte und die handschriftliche Schicht als separate Extraktionsziele behandelt. Definieren Sie Qty Shipped und die KI liest die gedruckte Versandmenge des Lieferanten aus der Positionstabelle. Definieren Sie Qty Received im selben Spaltenaufbau und die KI liest die handschriftliche Korrektur. Diese landen in benachbarten Spalten der Ausgabe — gedruckte Menge und empfangene Menge nebeneinander, Abweichungen sofort sichtbar. Definieren Sie Exception Notes und handschriftliche Randbemerkungen werden als strukturierter Text extrahiert.
Standardmäßige Blockschrift wird zuverlässig über den gesamten Batch extrahiert. Stark eilige Schreibschrift — typisch für Fahreranmerkungen, die am Dock hingekritzelt werden — kann bei der Volltext-Transkription eine punktuelle Überprüfung erfordern, aber die strukturierte Erkennung (Unterschrift vorhanden: ja/nein, Mengenkorrekturen) bleibt auch bei eiliger Handschrift zuverlässig. Das ist die ehrliche Grenze: Das Tool liest, was lesbar ist, kennzeichnet, was mehrdeutig ist, und erzeugt niemals stillschweigend einen falschen Wert.
Häufig gestellte Fragen
Wie viele Albaranes kann ich in einem Durchgang verarbeiten?
Das Tool verarbeitet Dateien sequenziell innerhalb eines Batches und bewältigt Uploads jeder praktischen Größe – 30, 50 oder mehr Albaranes auf einmal. Jede Seite benötigt etwa 5–10 Sekunden zur Verarbeitung, sodass ein Batch mit 30 Albaranes in etwa 3–5 Minuten abgeschlossen ist. Sie beobachten nicht den Fortschrittsbalken – Sie starten den Batch und kehren zu einer fertigen Tabelle zurück. Die praktische Grenze liegt nicht in der Kapazität des Tools, sondern im Aufnahmerhythmus des Wareneingangs: Die meisten Lager verarbeiten den morgendlichen Albarán-Stapel in einer Sitzung und die Nachmittagslieferungen in einem zweiten Durchlauf.
Was passiert, wenn ein Albarán keine gedruckte, sondern nur eine handschriftliche Nummer hat?
Die KI liest handschriftlichen Text unabhängig von der Sprache. Wenn die Albarán-Nummer handschriftlich ist – was bei manchen kleinen Lieferanten mit generischen Albarán-Blöcken vorkommt – versucht die Extraktion dennoch, sie anhand des von Ihnen definierten Spaltennamens zu lokalisieren. Die Genauigkeit ist geringer als bei gedruckten Nummern (leserliche Blockschrift extrahiert zuverlässig; flüchtige Schreibschrift kann manuelle Überprüfung erfordern). Wenn die KI keinen Wert sicher finden kann, bleibt die Zelle leer, anstatt mit einer Schätzung gefüllt zu werden. Zur Qualitätskontrolle können Sie eine Spalte namens Albarán-Nummer Vertrauensniveau hinzufügen, um Einträge zu kennzeichnen, die manuell überprüft werden müssen.
Kann ich Albaranes verarbeiten, die spanische, katalanische und englische Feldbezeichnungen im selben Batch mischen?
Ja. Die KI liest die Bedeutung der Felder, nicht die Sprache der Bezeichnung. Ob ein Lieferant "Albarán N.º", "Albarà Núm." oder "Delivery Note Ref" druckt, die von Ihnen als Albarán-Nummer definierte Spalte findet den korrekten Wert, weil die KI semantisch versteht, was eine Lieferscheinnummer ist, und nicht, in welcher Sprache sie beschriftet ist. Dies ist besonders nützlich für spanische Lager, die von internationalen Lieferanten erhalten, bei denen Albaranes eine Mischung aus spanischen, englischen und regionalen Sprachbezeichnungen tragen können – sowie von inländischen Lieferanten aus zweisprachigen Regionen (Katalonien, Baskenland, Galicien, Valencia), wo Feldbezeichnungen in der Regionalsprache erscheinen können.
Führt die Batch-Verarbeitung die NIF/CIF-Validierung für Steuer-ID-Felder durch?
Die KI extrahiert den NIF so, wie er auf dem Dokument erscheint, führt aber keine algorithmische NIF-Validierung durch (Prüfziffernverifikation gegen den Modulo-23-Algorithmus). Das Format aus 8 Ziffern plus Prüfziffer hilft der KI, den NIF während der Extraktion von der Albarán-Nummer zu unterscheiden, aber eine formelle Validierung sollte in Ihrem ERP oder über den Online-Verifizierungsdienst der Agencia Tributaria erfolgen. Zur Qualitätskontrolle profitieren NIF-Felder von einer berechneten Spalte wie NIF-Formatprüfung (gültig/ungültig), um Einträge zu markieren, die nicht dem erwarteten Muster entsprechen – dies ist jedoch eine Formatprüfung, keine rechtliche Validierung.
Wie erhalte ich Albaranes von Fahrern oder entfernten Lagern ohne E-Mail?
Die Funktion Sammellink erstellt eine teilbare Upload-Seite. Senden Sie den Link an Lieferfahrer, Mitarbeiter entfernter Lager oder externe Logistikpartner. Diese öffnen den Link, geben einen Bestätigungscode ein und laden Albaranes direkt hoch – entweder als Fotos bei der Lieferung oder als PDF-Scans. Keine Registrierung oder Anmeldung für den Absender erforderlich. Dateien landen automatisch in Ihrer Verarbeitungswarteschlange. Dies ist besonders nützlich für spanische Logistikabläufe mit Lieferungen an mehreren Standorten – eine Zentrale in Madrid, ein Außenlager in Valencia, ein Verteilzentrum in Barcelona – wo eingehende Dokumente ein zentrales AP- oder Inventarteam erreichen müssen, ohne dass Fahrer E-Mail-Anhänge verwalten müssen.
Der Stapel spanischer Lieferscheine, 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 das Layout jedes Lieferanten funktioniert, wird aus dem Stapel ein einziger Upload, ein einziger Verarbeitungslauf und eine einzige Tabelle, die Ihrem WMS (Lagerverwaltungssystem) 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 sie tatsächlich an Ihrer Rampe erreicht.
Verarbeiten Sie Ihre Albaranes im Batch
Verwandte Themen: So extrahieren Sie Daten aus spanischen Lieferscheinen (albaranes) in Excel · Lieferscheine und Versandpapiere im Batch nach Excel extrahieren · Lieferscheinfelder aus jedem Format nach Excel extrahieren · Französische Lieferscheine (bons de livraison) im Batch verarbeiten · Deutsche Lieferscheine im Batch verarbeiten · Lieferschein-zu-Excel-Konverter