Fakturierung in der Entsorgung: Einmal erfasst, dreifach genutzt

Ausgangslage

Eine Eingangsrechnung bei einem Büromateriallieferanten ist einfach: Artikelnummer, Bezeichnung, Menge, Preis. Jeder Lieferant hält sich an dasselbe Muster.

Eine Eingangsrechnung in der Entsorgungswirtschaft ist etwas anderes. Entsorgungsunternehmen und Containerdienste rechnen in unterschiedlichen Einheiten ab: Tonnen, Kilogramm, Kubikmeter, Stück, Pauschalpreise, Tagessätze. Sie benennen identische Abfallarten mit unterschiedlichen Bezeichnungen, Abkürzungen und internen Kürzeln. Rechnungen und Entsorgungsnachweise werden häufig als ein gemeinsames mehrseitiges Dokument geliefert. Digitale Daten werden gescannt, ausgedruckt, wieder gescannt. Und AVV-Nummern tauchen mal explizit, mal implizit, mal gar nicht auf.

Für jeden, der Entsorgungsleistungen in größerem Umfang einkauft und weiterverarbeitet, ob als Entsorgungsmakler, Containerdienst oder interner Entsorger mit Weiterberechnung, ist diese Heterogenität keine Randnotiz. Sie ist das tägliche Kerngeschäft. Und sie ist der Grund, warum Standardsoftware hier regelmäßig scheitert: nicht weil die Tools schlecht sind, sondern weil die Branchenlogik in keinem generischen Datenmodell abgebildet ist.

Ein zusätzlicher Aspekt, der in der Praxis entscheidend ist: Viele Containerdienste und Entsorger arbeiten bereits mit eigenen Datenbanken und ERP-Systemen, insbesondere für die Verwiegung. Die Wiegedaten entstehen direkt an der Waage und müssen nahtlos in den Fakturierungsprozess einfließen. Wer diesen Bruch zwischen Waage und Rechnung nicht schließt, hat eine manuelle Fehlerquelle, die sich mit jedem Auftrag multipliziert.

Das Problem hat eine zweite Dimension, die oft übersehen wird. Wer Entsorgungsleistungen nicht nur einkauft, sondern auch bilanziert und weiterberechnet, braucht dieselben Daten mehrfach: für die Fakturierung, für Kundenreportings und für das interne Controlling. In den meisten Unternehmen passiert das mehrfach separat, mit entsprechendem Aufwand und entsprechenden Fehlerquellen.

Unser Ansatz

Der erste und entscheidendste Schritt war keine Technologieentscheidung, sondern eine konzeptionelle: Rechnungspositionen einzeln erfassen.

Das klingt nach Mehraufwand und das war es zunächst auch. Das Dokumentenmanagementsystem war bereits im Einsatz, Rechnungsprüfung und Freigabe liefen dort. Was nicht erfasst wurde: die einzelnen Positionen. Die Frage, die wir gemeinsam beantworten mussten, war: Warum sollte das Team jetzt zusätzlich jede Rechnungsposition einzeln erfassen?

Die Antwort: Weil alle nachgelagerten Prozesse auf Positionsebene arbeiten. Um einem Kunden sagen zu können, wie viele Tonnen eines bestimmten Abfallstroms im letzten Quartal auf seiner Baustelle angefallen sind, braucht es genau diese Positionen. Sauber normalisiert, korrekt zugeordnet. Und wenn diese Daten ohnehin erfasst werden müssen, lassen sie sich gleichzeitig für Kalkulation, Weiterberechnung und Reporting nutzen.

Einmal erfassen, mehrfach verwenden. Das war die Grundlage, auf der der Mehraufwand sich auflöste.

Die Lösung: Schritt für Schritt

Schritt 1: Stammdaten als Rückgrat

Bevor eine Automatisierung läuft, braucht es ein Datenmodell, das die Wirklichkeit des Unternehmens abbildet. Bei einem Entsorgungsdienstleister ist diese Wirklichkeit mehrdimensional: Subunternehmer und Lieferanten, Kunden, Baustellen, Aufträge und Rechnungen, die alles verbinden.

Die Stammdaten bilden das Rückgrat:

Lieferanten und Subunternehmer tragen neben Kontaktdaten die buchhalterisch relevanten Informationen: Nummernkreise, Zahlungsziele und Fälligkeitslogik. Das System weiß nicht nur, wer dieser Lieferant ist, sondern auch wann seine Rechnung bezahlt werden muss und wie er im Buchhaltungssystem geführt wird.

Kundenstammdaten bilden die Komplexität ab, die in der Praxis entsteht: Industriekunden mit mehreren Standorten und Niederlassungen. Die Standortlogik ist explizit im Modell hinterlegt, nicht implizit in Tabellennamen.

Das Datenmodell verbindet diese Stammdaten mit den operativen Entitäten: Rechnungen, Positionen, Stoffe, Aufträge, Baustellen. Eine Rechnungsposition gehört zu einer Rechnung, ist einem klassifizierten Stoff zugeordnet und wird mit einem Auftrag verknüpft, der zu einer Baustelle und damit zu einem Kunden gehört. Diese Kette ist der Grund, warum Weiterberechnung und Reporting ohne Doppelarbeit funktionieren.

Schritt 2: Die Stofftabelle: Branchenexpertise als Datenbasis

Herzstück des Systems ist die Stofftabelle. Wer sie zum ersten Mal sieht, unterschätzt sie. Sie wirkt wie eine einfache Lookup-Tabelle. Tatsächlich ist sie komprimiertes Branchenwissen in maschinenlesbarer Form.

Die Abfallverzeichnis-Verordnung (AVV) definiert über 800 Abfallarten, jeweils mit einer sechsstelligen AVV-Nummer. Nicht alle davon sind für jeden Entsorgungsdienstleister relevant. Die Stofftabelle enthält die tatsächlich verwendeten Fraktionen und zu jeder Fraktion die Informationen, die das System für seine Entscheidungen braucht:

AVV-Nummer und Bezeichnung: Die offizielle Klassifikation als Anker für die spätere Erkennung.

Getrennte Erfassung nach GewAbfV: Steuert, wie der Abfallstrom in nachgelagerten Reportings behandelt wird und welche Hinweise der Kunde erhält.

Gefährlichkeitsstatus: Ob ein Stoff als gefährlicher Abfall eingestuft ist, hat direkte Konsequenzen für Nachweispflichten, Entsorgungswege und die Darstellung in Kundenberichten.

Umrechnungsfaktoren: Basierend auf Branchenstandards, ergänzt durch betriebliche Erfahrungswerte. Hier fließen auch die Verwiegungsdaten ein: Wer eine eigene Waage betreibt, hat präzise Ist-Werte, die als Referenz für die Umrechnungslogik dienen.

Diese Tabelle liegt im System und kann eigenständig gepflegt und erweitert werden. Das Team, das die Domäne kennt, kann das System selbst weiterentwickeln, ohne auf externe Entwicklungsarbeit angewiesen zu sein.

Schritt 3: Dokumente trennen

Wenn eine neue Eingangsrechnung eintrifft, startet die Pipeline im Dokumentenmanagementsystem. Standard-OCR liest klassische Rechnungsfelder aus: Lieferant, Datum, Fälligkeitsdatum, Gesamtbetrag. Neu hinzu kommen die tabellarischen Positionen mit Mengen, Einheiten und Bezeichnungen.

Entsorgungsunternehmen liefern häufig Rechnungen und Entsorgungsnachweise in einem gemeinsamen PDF. Begleitscheine, Lieferscheine, Übernahmescheine, alles in einem Dokument. Ein LLM-Aufruf übernimmt die Trennung: Das Modell entscheidet, an welcher Seite das Dokument getrennt werden muss. Was vorher ein manueller Sortierschritt war, entfällt vollständig.

Schritt 4: AVV-Klassifikation mit vierstufiger Konfidenz

Für jede Rechnungsposition versucht das System, den passenden AVV-Schlüssel aus der Stofftabelle zu ermitteln. Dafür gibt es eine klare Hierarchie:

Direktes Matching: Enthält die Positionsbezeichnung eine explizite AVV-Nummer, ist das Ergebnis eindeutig. Kein LLM-Aufruf notwendig. Konfidenzstufe: automatisch bestätigt.

LLM-Klassifikation: Enthält die Position keine explizite AVV-Nummer (der häufigere Fall), übernimmt ein LLM-Aufruf. Das Modell bekommt die Positionsbezeichnung und die Stofftabelle als Lookup-Kontext und gibt eine Klassifikation mit einer von vier Konfidenzstufen zurück: automatisch bestätigt, hohe Konfidenz, mittlere Konfidenz, niedrige Konfidenz.

Diese Abstufung ist kein Selbstzweck. LLM-Ausgaben sind stochastisch, also wahrscheinlichkeitsbasiert und nicht deterministisch. Das System macht das sichtbar, statt es zu verstecken. Wer Kundenberichte erstellt, auf die Kunden und Behörden vertrauen, braucht diese Transparenz.

Die Notwendigkeit für mehrstufige Klassifikation entsteht direkt aus der Branchenrealität: AVV 170904 (gemischte Bau- und Abbruchabfälle) taucht in Eingangsrechnungen als „BMA", „Baustellenabfälle" oder als interne Kurzbezeichnung auf. Das Synonymwörterbuch in der Stofftabelle, das diese Varianten zusammenführt, ist iterativ entstanden, auf Basis echter Rechnungen aus dem Tagesgeschäft.

Schritt 5: Einheitenprüfung: Wo Menschen besser sind als Algorithmen

Einheiten sind in der Entsorgungswirtschaft eine eigene Fehlerquelle. Lieferanten rechnen in Tonnen, Kubikmetern, Stück, Pauschalpreisen und zeitbezogenen Einheiten. Derselbe Abfallstrom kann bei unterschiedlichen Subunternehmern in unterschiedlichen Einheiten fakturiert werden. Wer Verwiegungsdaten direkt aus dem Wägesystem übernimmt, hat hier einen Vorteil: Die Ist-Menge von der Waage ist eindeutig und ersetzt die fehleranfällige manuelle Übernahme.

Das System normalisiert, wo es kann. Aber es gibt Grenzfälle, die ein Algorithmus nicht zuverlässig auflösen kann. Wenn eine Rechnungsposition eine Masse von 14.000 ausweist, stellt sich die Frage: Kilogramm oder Tonnen? Beides ist syntaktisch valide. Nur jemand, der den Auftrag, den Lieferanten und die typischen Mengenordnungen kennt, kann das sicher beurteilen.

Deshalb gibt es einen expliziten manuellen Prüfschritt. Das System markiert drei Kategorien auffälliger Positionen:

Null-Werte: Könnte OCR-Fehler, fehlender Wert oder echter Nullposten sein.

Implausible Mengen: Oberhalb eines konfigurierbaren Schwellwerts. Klassisches Fehlerbild: Kilogramm und Tonnen verwechselt, Faktor 1000.

Einheitenabweichungen: Erkannte Einheit passt nicht zur erwarteten Einheit für diesen Abfallstrom.

Das ist keine Schwäche des Systems. Es ist die richtige Architekturentscheidung: Dort, wo Domänenwissen und Kontextkenntnis gefragt sind, ist der Mensch der bessere Prüfer. Das System übernimmt die Masse, der Mensch übernimmt die Ausnahmen.

Schritt 6: Standardisierte Ausgangsbezeichnungen

Wer Ausgangsrechnungen stellt, hat eine Wahl: Die Positionsbezeichnungen der Eingangsrechnung direkt durchreichen, oder eigene, standardisierte Bezeichnungen verwenden. Ersteres ist einfach. Letzteres ist besser.

Der Grund ist praktisch: Wenn derselbe Kunde dieselbe Leistung von zwei verschiedenen Subunternehmern berechnet bekommt, liest er auf der Ausgangsrechnung zweimal dasselbe, nur anders geschrieben. Konsistente Bezeichnungen machen Rechnungen lesbarer, reduzieren Rückfragen und sind ein stilles Signal für Professionalität.

Nach der AVV-Klassifikation werden Positionsbezeichnungen gegen ein Synonymwörterbuch abgeglichen und in Standardbezeichnungen überführt. Ein Beispiel aus der Praxis: CO₂-Aufschläge, die aus dem Brennstoffemissionshandelsgesetz (BEHG) resultieren, tauchen in Eingangsrechnungen auf verschiedene Weisen auf. Auf der Ausgangsrechnung steht immer dasselbe: CO₂-Zuschlag (BEHG). Was auf der Ausgangsrechnung steht, hat das Unternehmen selbst festgelegt, nicht der Lieferant, nicht der Rohdatenfluss.

Diese Bezeichnungen entstehen nicht am Schreibtisch. Sie entstehen iterativ im Einsatz: Rechnungen gestellt, Inkonsistenzen bemerkt, Synonymtabelle erweitert. Das ist ko-produzierte Expertise: Branchenwissen, das sich mit jedem Rechnungslauf schärft.

Schritt 7: Von der Freigabe zur Ausgangsrechnung

Sobald eine Rechnungsposition geprüft und mit einem Auftrag verknüpft ist, sind alle Informationen im System: Subunternehmer, Kunde, Baustelle, klassifizierter Stoff, normalisierte Bezeichnung, Einkaufspreis, kalkulierter Aufschlag.

Ein Button startet die Weiterberechnung. Das System erstellt die kalkulierte Ausgangsrechnung mit standardisierten Positionsbezeichnungen und übergibt sie direkt an das Buchhaltungssystem. Dort erscheint die neue Ausgangsrechnung vorausgefüllt, konsistent, bereit zum Versand.

Was auf der Ausgangsrechnung steht, ist nicht das, was auf der Eingangsrechnung stand. Es ist das, was das Unternehmen seinen Kunden mitteilen möchte: in ihrer Sprache, in einheitlicher Form, unabhängig davon, welcher Subunternehmer die Leistung erbracht hat.

Ergebnisse

Was sich daraus ergeben hat

Die Fakturierungspipeline ist das Fundament, auf dem alles andere aufbaut. Die strukturierten Positionsdaten sind gleichzeitig die Grundlage für Kundenreportings, interne Auswertungen und weitere Ausbaustufen. Einmal erfasst, mehrfach verwendet.

Wer Branchenwissen konsequent in eine maschinenlesbare Datenbasis übersetzt, löst nicht nur ein Automatisierungsproblem. Er schafft die Infrastruktur, auf der alle nachgelagerten Prozesse aufbauen können. Ohne Doppelarbeit, ohne Datenbrüche, ohne linearen Personalaufwand. Und er tut das nicht mit Spezialsoftware, die das Unternehmen in eine Abhängigkeit zwingt, sondern mit einem System, das das Team selbst versteht, pflegt und weiterentwickelt.

Die Gesamtgeschichte dieser Digitalisierung beschreibt die Case Study mit Trade Waste International.

Dasselbe Problem, andere Branche

Die Pipeline wurde für einen Entsorgungsmakler gebaut. Das Grundproblem ist branchenübergreifend identisch.

Containerdienste stehen vor derselben Herausforderung: Wiegedaten aus dem eigenen System, Eingangsrechnungen von Subunternehmern in unterschiedlichen Formaten, Weiterberechnung an den Endkunden mit eigenem Aufschlag. Der Bruch zwischen Waage, Rechnung und Buchhaltung kostet jeden Tag Zeit.

Bauunternehmen, die Entsorgungsleistungen für ihre Baustellen einkaufen und an Bauherren weiterberechnen, kennen das Problem aus der anderen Richtung: Dutzende Entsorgungsnachweise pro Projekt, unterschiedliche Lieferanten, unterschiedliche Formate, und am Ende die Frage, ob die Weiterberechnung vollständig ist.

Der Ansatz ist übertragbar, weil er nicht auf einer bestimmten Branchensoftware aufsetzt, sondern auf dem Prinzip: Positionsdaten einmal sauber erfassen und dann für alle nachgelagerten Prozesse wiederverwenden.