# Kapitel 9 – Lieferantenabrechnung (Supplier Usage Data)
## Ziel dieses Kapitels
Neben der Kundenabrechnung unterstützt die ERPNext-Lösung auch die automatisierte Abrechnung gegenüber den Betreibern der Ladeinfrastruktur beziehungsweise den Lieferanten.
Während **Customer Usage Data** alle abrechnungsrelevanten Ladevorgänge aus Kundensicht zusammenfasst, aggregiert **Supplier Usage Data** dieselben Ladevorgänge aus Sicht des jeweiligen Lieferanten.
Der Supplier Usage Data Doctype bildet damit die Grundlage für die spätere Lieferantenabrechnung und stellt sicher, dass Betreiber entsprechend der vertraglichen Vereinbarungen vergütet werden.
Historisch lief das als Gutschrift (Sales Invoice Credit Note). Ziel ist die Nutzung der Purchase Invoice mit dem Druckformat BCH Einkaufsrechnung mit Anhang Supplier Usage Detail BCH Einkaufsrechnung.
## 9.1 Fachlicher Hintergrund
Bei jedem Ladevorgang entstehen grundsätzlich zwei kaufmännische Betrachtungsweisen:
- die Kundenabrechnung, bei der dem Kunden die Nutzung der Ladeinfrastruktur in Rechnung gestellt wird,
- und die Lieferantenabrechnung, bei der der Betreiber beziehungsweise Lieferant für die bereitgestellte Leistung vergütet wird.
Diese beiden Prozesse basieren auf denselben Gridware Usages, werden jedoch unabhängig voneinander verarbeitet.
Der Supplier Usage Data Doctype bündelt hierfür sämtliche abrechnungsrelevanten Ladevorgänge eines Lieferanten innerhalb einer Billing Period.
## 9.2 Schritt für Schritt
1. Öffne die becharged settings
2. Klicke auf den Button "Supplier Usage Data"
3. Filtere nach Abrechnungszeitraum und Lieferant
4. Zusammenfassung aller Transaktionen aus allen Verträgen wird für den Lieferanten erstellt in Form von Supplier Usage Data
5. Klicke auf den Button "Create Purchase Invoice"
6. Rechnung mit den Summen pro Vertrag wird erstellt
7. Im Druckformat befindet sich die Rechnung sowie der Anhang mit Transaktionen kategorisiert pro Vertrag
[](https://becharged.phamos.eu/uploads/images/gallery/2026-08/supplier-usage-data.gif)
### Dienstwagen-Ausnahmefall:
Datensätze werden mit dem Hinweis "is reimbursement" markiert und werden gesondert von anderen Lieferanten Transaktionen ausgewiesen.
[](https://becharged.phamos.eu/uploads/images/gallery/2026-08/supplier-usage-data-reimbursement.gif)
## 9.3 Warum wurde Supplier Usage Data entwickelt?
Die Lieferantenabrechnung unterscheidet sich fachlich von der Kundenabrechnung.
Ein Lieferant kann:
- mehrere Verträge besitzen,
- mehrere Ladepunkte betreiben,
- Ladevorgänge für unterschiedliche Kunden bereitstellen,
- unterschiedliche Vergütungsmodelle verwenden.
Eine direkte Verarbeitung einzelner Ladevorgänge wäre weder wirtschaftlich noch übersichtlich.
Deshalb werden sämtliche relevanten Gridware Usages zunächst zu Supplier Usage Data aggregiert.
Dadurch entsteht pro Lieferant und Abrechnungszeitraum ein kaufmännischer Datensatz, der anschließend als Grundlage für die Lieferantenabrechnung dient.
## 9.4 Rolle innerhalb der Systemarchitektur
Supplier Usage Data bildet die kaufmännische Verarbeitungsebene auf der Lieferantenseite.
Der Prozess lässt sich vereinfacht wie folgt darstellen:
```
Gridware Usage
↓
Supplier Usage Data
↓
Purchase Invoice
↓
Payment Entry
```
Während Customer Usage Data zur Erstellung von Sales Invoices führt, bildet Supplier Usage Data die Grundlage für die Erstellung von Purchase Invoices.
## 9.5 Aggregationslogik
Die Aggregation erfolgt auf Basis der Gridware Usages.
Hierbei werden sämtliche Ladevorgänge eines Lieferanten innerhalb einer Billing Period zusammengeführt.
Die Zusammenfassung erfolgt unter anderem anhand folgender Kriterien:
- Supplier
- Billing Period
- Contract
- Contract Type
- Company
- Is Reimbursement
Dadurch entsteht ein zentraler Abrechnungsdatensatz für den jeweiligen Lieferanten.
## 9.6 Aufbau des Supplier Usage Data Doctypes
Der Supplier Usage Data Doctype enthält sämtliche Informationen, die für die spätere Lieferantenabrechnung benötigt werden.
| Bereich | Inhalt |
|---|
| Header | Supplier, Billing Period, Company, Is Reimbursement |
| Usage Details | Vertragstyp, Artikel, kWh, Preise, Gridware Usage ID |
| Totals / Cost Breakdown | analog CUD |
| Status | siehe 9.7 |
| Verknüpfung | Purchase Invoice |
## 9.7 Status
Während seiner Verarbeitung durchläuft ein Supplier Usage Data Datensatz verschiedene Bearbeitungsstufen.
Ein möglicher Ablauf ist:
Uninvoiced
↓
Draft Invoice
↓
Invoiced
Zusätzlich: Cancelled Invoice.
Die tatsächlichen Status richten sich nach der implementierten Prozesslogik.
## 9.8 Aktueller Entwicklungsstand
Die Lieferantenabrechnung befindet sich derzeit im Ausbau und wird parallel zur Kundenabrechnung weiterentwickelt.
Ziel ist es, den Prozess vollständig zu automatisieren und denselben Automatisierungsgrad wie bei der Kundenabrechnung zu erreichen.
Hierzu gehören insbesondere:
- automatische Erstellung von Supplier Usage Data,
- automatische Erstellung der Purchase Invoices,
- Integration in den monatlichen Abrechnungsprozess,
- vollständige Nachvollziehbarkeit der zugrunde liegenden Gridware Usages.
## 9. 9 Besonderheiten
Die Lieferantenabrechnung muss verschiedene Vertragsmodelle und Betreiberstrukturen berücksichtigen.
Insbesondere sind folgende Aspekte relevant:
- Ein Vertrag besitzt genau einen Contract Giver beziehungsweise Supplier.
- Mehrere Kunden können demselben Lieferanten zugeordnet sein.
- Die Vergütung richtet sich nach den im Gridware Contract definierten Bedingungen.
- Die Lieferantenabrechnung ist unabhängig von der Kundenabrechnung, basiert jedoch auf denselben technischen Ladevorgängen.
- Offene Purchase Invoices können über SEPA Credit Transfer gesammelt werden
- Alte BCH Gutschrift auf Sales Invoice: Storno einer Gutschrift erzeugt in ERPNext keinen eigenen Stornobeleg – daher der Wechsel auf Purchase Invoice
## 9.11 Zusammenfassung
Supplier Usage Data bildet das Gegenstück zur Customer Usage Data.
Während Customer Usage Data die Grundlage für die Kundenrechnung darstellt, bündelt Supplier Usage Data die abrechnungsrelevanten Ladevorgänge eines Lieferanten und bereitet diese für die Erstellung der Purchase Invoice vor.
Gemeinsam bilden beide Doctypes die zentrale kaufmännische Verarbeitungsebene der ERPNext-Lösung und schaffen die Grundlage für eine transparente und nachvollziehbare Abrechnung zwischen Kunden, becharged und den Betreibern der Ladeinfrastruktur.