1Lieferschein FAQ Fragen zu 1Lieferschein
Ihre Fragen
Standard 1-Lieferschein
Der Standard 1-Lieferschein gibt vor, welche Informationen ein elektronischer 1Lieferschein enthalten muss, wie sie angeordnet sind und in welchem Format die Daten darin gespeichert werden. Der Standard 1-Lieferschein hat dieselbe Wirkung wie ein Standardformular einer Behörde, in das Inhalte eingetragen werden sollen.
1Lieferschein-Dokument
Das 1Lieferschein-Dokument ist wie das ausgefüllte Standardformular. Tatsächlich ist es eine XML-Datei, die ein Computer lesen kann.
Ein 1Lieferschein-Dokument folgt einem vorgegebenen Standard, aber die Art und Weise, wie die Daten in das Dokument gelangen, kann unterschiedlich sein.
Zum Vergleich:
SEPA-Zahlungsstandard (Standard): Definiert, wie eine Überweisung technisch aufgebaut sein muss (z. B. IBAN, BIC, Betrag, Verwendungszweck).
Wie die Daten eingetragen werden: Die Bankkund:innen geben ihre Daten z. B. manuell in ein Online-Banking-Formular ein oder eine Buchhaltungssoftware füllt das SEPA-Dokument automatisch aus.
Genauso funktioniert es bei 1Lieferschein:
1Lieferschein (Standard): Legt fest, welche Felder in einem elektronischen Lieferschein enthalten sein müssen und in welchem Format sie stehen.
Datenquelle & Eintragung: Die Daten kommen z. B. aus einem ERP-System, einer Versandsoftware oder einer manuellen Eingabe. Ein System generiert daraus eine UBL-Datei, die den Standard einhält.
Kurz gesagt: Der Standard bestimmt, wie das Dokument aussehen muss, aber die Art, wie die Daten dorthin gelangen, hängt vom jeweiligen System und Prozess ab.
Verpflichtend sind ausschließlich die Angaben, die im technischen Teil der 1Lieferschein-Spezifikation als „verpflichtend“ gekennzeichnet sind. Darüber hinaus geben die Profile vor, welche Informationsfelder in einem Dokument enthalten sein müssen. Ob diese Felder tatsächlich mit Inhalten befüllt werden, ist nicht zwingend vorgeschrieben – wird jedoch nachdrücklich empfohlen, um eine reibungslose und effiziente Verarbeitung sicherzustellen.
Typische Beispiele für solche Pflichtinformationen sind grundlegende Daten zur Identifikation der Lieferung, Angaben zu Absender und Empfänger sowie positionsbezogene Details – jeweils abhängig vom konkreten Anwendungsfall und Profil.
Der 1Lieferschein ist nicht nur Lieferschein, er kann auch gleichzeitig Frachtbrief sein und Wiegeschein. Die bei Wiegungen gemessenen Werte sind auf dem 1Lieferschein vermerkt. Erfolgt die Wiegung mit geeichten Waagen, wird die Registrierungsnummer der Waage vermerkt.
Brutto- Wiegung
Die Bruttowiegung “Brutto” gibt das Gesamtgewicht des Fahrzeugs oder des Transportmittels zusammen mit der Ladung an.
Die Bruttowiegung erfolgt nach der Beladung des Fahrzeugs. Das kann die Beladung in einer Mischanlage sein oder in einem Steinbruch. Eine Bruttowiegung kann auch vor einer Entladung des Fahrzeugs bei der Anlieferung von Ladung in einer Recyclinganlage sein.
Tara-Wiegung
Die Tarawiegung “Tara” gibt das Eigengewicht des Fahrzeugs oder des Transportmittels an.
Die Tarawiegung erfolgt vor der Beladung des Fahrzeugs. Das kann die Beladung in einer Mischanlage sein oder in einem Steinbruch. Eine Tarawiegung kann auch nach einer Entladung des Fahrzeugs bei der Anlieferung von Ladung in einer Recyclinganlage sein.
Die Tarawiegung kann auch durch das im Waagensystem oder der Mischanlagensteuerung gespeicherte Eigengewicht des Fahrzeugs oder des Transportmittels ersetzt werden.
Netto-Wiegung
Die Nettowiegung “Netto” gibt das Gewicht der Ware an.
Eine Nettowiegung erfolgt in stationären Anlagen meist durch Errechnung der Differenz aus der Bruttowiegung und der Tarawiegung: Brutto – Tara = Netto.
Eine Nettowiegung “Netto” kann auch durch Wiegevorrichtungen am Beladegerät (Radlader) erfolgen.
Eine Nettowiegung “Netto” kann auch mit einer Durchflussmessung an der Beladeeinrichtung erfolgen.
Der Standard 1Lieferschein steht gemäß den rechtlichen Bestimmungen für eigene gewerbliche Zwecke vollständig kostenlos zur Verfügung. Es fallen seitens der Initiative keine Lizenzgebühren für die Nutzung dieses offenen Standards an.
Wenn an einer Stelle im Prozess kein 1Lieferschein-Dokument vorliegt (z. B. bei einem Papierlieferschein), wird dieses Dokument als Dateianhang (z. B. als Scan) in das darauffolgende 1Lieferschein-Dokument eingebettet.
Technisch wird dabei in der Signatur statt einer UUID ein berechneter Hash der externen Vorgängerdatei eingetragen, um die Verbindung eindeutig zu sichern. So kann der digitale Prozess ab diesem Punkt wieder im Standard fortgeführt werden.
Nein, die UUID ist nicht die Lieferscheinnummer, sondern eine eindeutige technische Kennung, die jedes einzelne Dokument (z.B. eine bestimmte Version eines Lieferscheins) global referenzierbar macht. Die Lieferscheinnummer ist eine Kennung, die zusätzlich aufgeführt wird.
Jedes 1Lieferschein-Dokument erhält eine eindeutige Kennung nach UUIDv4, erzeugt per kryptografisch sicherem Zufall; sie wird empfohlen in Kleinbuchstaben geführt, darf nicht doppelt vorkommen und muss case-insensitive geprüft werden.
Technisch: per Standard-Library (z. B. uuid.uuid4() in Python, crypto.randomUUID() in Node, Guid.NewGuid() in .NET), vor dem Speichern lowercasing, Format per Regex prüfen (/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i) und in der Datenbank einen UNIQUE-Index auf dem UUID-Feld verwenden.
Die Daten werden dezentral bei den jeweiligen Geschäftspartnern gespeichert. Es gibt keinen zentralen Speicherort oder eine Cloud, in der alle Lieferscheindokumente gesammelt werden. Stattdessen wird jedes 1Lieferschein-Dokument direkt in den Systemen der beteiligten Unternehmen (z.B. des Versenders, Transporteur und Empfängers) abgelegt.
Die Übermittlung der Daten erfolgt flexibel und ist an keine bestimmte Technologie gebunden. Die Daten können via NFC, Multipeer Connectivity, E-Mail, EDI, Peppol, DTRANS oder über jedes andere geeignete Verfahren in Echtzeit übertragen werden.
Der 1Lieferschein-Standard definiert sogenannte Profile, die auf verschiedene logistische Anwendungsfälle abgestimmt sind. Ein Profil legt fest, welche Informationen in einem 1Lieferscheindokument verpflichtend aufgeführt sein müssen, um die Anforderungen bestimmter Prozesse zu erfüllen.
Die Profile unterscheiden sich in Umfang und Detailtiefe der benötigten Daten. Ziel ist es, logistische Abläufe optimal zu unterstützen – durch maschinenlesbare und effizient verarbeitbare Informationen.
Verpflichtend ausgefüllte Felder sind nur diejenigen, die im technischen Teil der Spezifikation als solche definiert sind.
Beispiele und Anwendungsfälle findest du unter https://1lieferschein.com. Dort wird auch gezeigt, wie ein konventioneller Papierlieferschein im 1Lieferschein-Format dargestellt wird.
Es gibt aktuell die Profile: Standard, Bulk und Concrete. Die Initiative 1Lieferschein entwickelt den Standard in einem fortlaufenden Prozess stetig weiter, um relevante Anwendungsfälle abzudecken. Nutzer können bei der Initiative Ergänzungen einreichen , welche nach einer Prüfung in den Standard aufgenommen werden können.
Da 1Lieferschein ein Standard ist, gibt es keine App “1Lieferschein”. Es gibt jedoch Entwicklungen wie von der Firma Bobbie, die einen 1Lieferschein ausgeben und verarbeiten kann.
Ja, es ist jederzeit möglich, weitere Informationen aufzunehmen, solange sie den UBL-Standard und den 1Lieferschein-Standard einhalten. Wer möchte, dass solche Erweiterungen dauerhaft in den Standard einfließen, kann Vorschläge bei der Initiative 1Lieferschein einreichen. Diese prüft, ob die Neuerungen übernommen werden.
Der Standard definiert die technische Struktur und den Inhalt des digitalen Lieferscheins (das “Was”), während der Prozess die praktischen Arbeitsschritte beschreibt, in denen dieser Standard angewendet wird (das “Wie” und “Wann”). Jeder Prozessschritt, wie die Disposition oder Lieferannahme, erzeugt oder verarbeitet also ein Informationsobjekt, das den Regeln des Standards folgt.
UBL (Universal Business Language) ist ein internationaler Standard für elektronische Geschäftsdokumente wie Rechnungen, Bestellungen oder Lieferscheine. Die Dokumente werden dabei in XML (Extensible Markup Language) strukturiert, sodass sie sowohl von Menschen lesbar als auch maschinell eindeutig verarbeitet werden können. Durch die XML-Basis ist UBL plattformunabhängig, leicht erweiterbar und besonders geeignet für den automatisierten Datenaustausch zwischen unterschiedlichen IT-Systemen.
Das Format 1Lieferschein nutzt UBL nicht nur am Rande, sondern stützt sich vollständig auf zwei konkrete UBL-Dokumenttypen:
DespatchAdvice (Lieferschein)
ReceiptAdvice (Warenempfang)
Das bedeutet: Wer ein 1Lieferschein-Dokument erzeugen, validieren oder verarbeiten möchte, kommt nicht an den zugrunde liegenden UBL-Strukturen vorbei. Es reicht nicht, einfach XML zu erzeugen – es muss exakt dem jeweiligen UBL-Dokumenttyp entsprechen
UBL-Dokumente folgen einem festen Schema (XSD), das festlegt:
- welche Felder zulässig oder verpflichtend sind,
- wie diese Felder verschachtelt sind,
- welche Datentypen erwartet werden.
1Lieferschein verwendet:
- DespatchAdvice (Versandavis)
- ReceiptAdvice (Warenempfang)
Wer 1Lieferschein-Dokumente erstellen, prüfen oder verarbeiten möchte, muss die zugrunde liegenden UBL-Strukturen verstehen. Es reicht nicht, „irgendwelches XML“ zu erzeugen – das Dokument muss exakt dem passenden UBL-Typ entsprechen.
Hier ein vereinfachtes Beispiel für eine DespatchAdvice:
<DespatchAdvice xmlns="urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2">
<ID>DA-1001</ID>
<IssueDate>2025-07-24</IssueDate>
<DespatchSupplierParty>
<Party>
<PartyName>
<Name>Mein Unternehmen GmbH</Name>
</PartyName>
</Party>
</DespatchSupplierParty>
<DeliveryCustomerParty>
<Party>
<PartyName>
<Name>Musterfirma AG</Name>
</PartyName>
</Party>
</DeliveryCustomerParty>
</DespatchAdvice>
In der Praxis sind vollständige Dokumente deutlich umfangreicher und enthalten z. B. Informationen zu Produkten, Verpackungen, Lieferterminen, Transportmitteln und Bestellreferenzen. Schon kleine Abweichungen können dazu führen, dass ein Dokument ungültig ist.
Am besten in drei Schritten: lesen, üben, vergleichen.
- Grundlagen verstehen – UBL ist ein XML-basiertes Austauschformat, entwickelt von OASIS. Starte mit einem einzigen Dokumenttyp (z. B. DespatchAdvice) und lerne den groben Aufbau, statt alle auf einmal durchzugehen.
- Schemata & Beispiele studieren – Lade das UBL-Schema-Paket von OASIS herunter, öffne ein Beispiel in einem XML-Editor und verfolge die Struktur von oben nach unten.
- Praxis üben – Nimm ein Beispiel, ändere Werte, füge Felder hinzu und validiere es mit Tools wie dem Bobbie-Validierungstool. Fehler helfen, die Regeln zu verstehen.
Für 1Lieferschein empfiehlt es sich, mit einem offiziellen Beispiel zu starten, die tatsächlich genutzten UBL-Elemente zu identifizieren und daraus Schritt für Schritt ein valides Dokument zu bauen.
Nützliche Ressourcen:
- OASIS UBL-Spezifikation: https://docs.oasis-open.org/ubl
- Praxisleitfäden von Peppol oder GS1
Nein. Für den 1LS existiert keine eigene XSD-Datei.
Die technischen UBL-2.4-Schemas für DespatchAdvice und ReceiptAdvice bilden nur die formale Struktur ab. Fachliche Regeln, Logikprüfungen, Plausibilitäten oder UBL-konforme Einschränkungen lassen sich darin nicht abbilden. Daher erfolgt die Validierung ausschließlich auf Basis der offiziellen UBL-XSDs plus zusätzlicher semantischer Prüfungen außerhalb des Schemas.
Um den digitalen Lieferschein zu befüllen, werden die Informationen gemäß der Spezifikation in eine vordefinierte XML-Grundstruktur mit klar definierten Bestandteilen eingetragen. Dabei werden identifizierende Metadaten, Angaben zum Ersteller, logistische Details zur Lieferung sowie die einzelnen Warenpositionen an den jeweils dafür vorgesehenen Stellen in der Datei erfasst.