VBA-Wissensvermittlung - Schritt für Schritt von Bernd Held, Autor von 140 Computerbüchern, Trainer und Auftrags-Programmierer. Excel-Automatisierung Unsere Internetpräsenz: held-office.de
Viele kleine Unternehmen schreiben ihre Rechnungen seit 20 Jahren mit Excel.
Und plötzlich heißt es überall:
👉 E-Rechnungspflicht.
👉 ZUGFeRD.
👉 XRechnung.
Die erste Reaktion ist oft:
„Dann brauchen wir wohl ein neues System.“
ERP.
Cloud-Software.
Neue Prozesse.
Aber stimmt das wirklich?
In vielen Fällen lautet die überraschende Antwort:
Nein.
Denn wenn Rechnungen heute bereits mit Excel erstellt werden, kann man daraus auch E-Rechnungen erzeugen.
Wir haben dafür eine Lösung entwickelt, mit der sich aus einer normalen Excel-Rechnung automatisch eine ZUGFeRD- oder XRechnung-Datei erzeugen lässt.
Der Ablauf ist bewusst einfach:
• bestehende Excel-Rechnung weiter nutzen
• Felder einmal zuordnen
• E-Rechnung per Klick erzeugen
• optional direkt per Outlook versenden
Gerade für kleinere Unternehmen, die seit Jahren mit Excel arbeiten, kann das ein sehr pragmatischer Einstieg sein – ohne sofort ein neues System einzuführen.
🎥 Ich zeige das live in einem kurzen Webinar
📅 Freitag, 20.03.2026
🕔 17:00 Uhr
👉 Teilnahme:
us02web.zoom.us/j/8071735115 Wenn Sie Interesse haben, schreiben Sie einfach „E-Rechnung“ in die Kommentare oder kommen Sie direkt dazu.
Ich zeige Schritt für Schritt, wie das funktioniert.
e-Mail-Anhänge automatisch beim Empfangen von e-Mails ablegen
Neulich kam mein Nachbar auf mich zu und fragte mich, ob es denn möglich sein, dass Outlook automatisch die Anhänge aus eingehenden E-Mails speichert.
Er bekommt regelmäßig Rechnungen und Dokumente per Mail – und jedes Mal läuft der Ablauf gleich ab:
1. Mail öffnen
2. Anhang speichern
3. Ordner auswählen
4. Datei ablegen
Das funktioniert natürlich – aber wenn man das mehrmals am Tag macht, summiert sich der Aufwand schnell.
Meine Antwort war deshalb recht kurz:
„Ja, das geht. Outlook kann das automatisch.“
Viele wissen nicht, dass sich Outlook genauso wie Excel mit VBA automatisieren lässt.
Mit einem kleinen Makro kann Outlook nämlich einfach überwachen, wenn neue Mails eintreffen. Sobald eine E-Mail im Posteingang landet, prüft das Makro, ob Anhänge vorhanden sind – und speichert diese automatisch in einem gewünschten Ordner.
Der Ablauf ist dann plötzlich ganz simpel:
📩 Mail kommt an
📎 Anhang wird erkannt
💾 Datei wird automatisch gespeichert
Ohne Klick. Ohne manuelles Speichern.
Das folgende VBA-Makro macht genau das:
Private WithEvents PostfachItems As Outlook.Items
Private Sub Application_Startup()
Dim ns As Outlook.NameSpace
Dim Postfach As Outlook.Folder
Dim Zielordner As Outlook.Folder
Set ns = Application.GetNamespace("MAPI")
'Postfach auswählen
Set Postfach = ns.Folders("b.held@held-office.de")
'Ordner überwachen (z.B. Posteingang)
Set Zielordner = Postfach.Folders("Posteingang")
Set PostfachItems = Zielordner.Items
End Sub
Private Sub PostfachItems_ItemAdd(ByVal Item As Object)
Dim Mail As Outlook.MailItem
Dim Anhang As Outlook.Attachment
Dim Speicherpfad As String
Der Clou daran ist:
Outlook reagiert automatisch auf neue E-Mails. Das Makro läuft im Hintergrund und speichert jeden Anhang sofort im definierten Ordner.
Gerade in Unternehmen kann das sehr hilfreich sein, zum Beispiel wenn:
• Rechnungen automatisch abgelegt werden sollen
• Dokumente zentral gesammelt werden
• Anhänge aus bestimmten Postfächern archiviert werden sollen
• Dateien für eine Weiterverarbeitung bereitstehen müssen
Mit ein paar zusätzlichen Zeilen Code könnte man sogar noch weitergehen, etwa:
• nur bestimmte Dateitypen speichern (z. B. PDF)
• nur Anhänge bestimmter Absender speichern
• die Dateien automatisch in Jahres- oder Monatsordner sortieren
Viele denken bei Automatisierung sofort an große Systeme.
Oft reicht aber schon ein kleines VBA-Makro, um einen Prozess deutlich einfacher zu machen.
Und genau solche kleinen Automatisierungen sparen im Alltag erstaunlich viel Zeit.
Viele Unternehmen beschäftigen sich gerade intensiv mit dem Thema E-Rechnung.
Spätestens seit 2025 müssen Unternehmen im B2B-Bereich in der Lage sein, elektronische Rechnungen zu empfangen – und mittelfristig auch zu erstellen.
Oft lautet die erste Reaktion:
Neue Software anschaffen, neues System einführen, Prozesse komplett umbauen.
Dabei übersehen viele eine einfache Möglichkeit:
👉 E-Rechnungen lassen sich auch direkt aus Excel erzeugen.
Wir haben dafür eine Lösung entwickelt, mit der sich ZUGFeRD- und XRechnung-Dateien direkt aus einer Excel-Rechnung erstellen lassen. Die relevanten Felder werden über eine Mapping-Tabelle zugeordnet, und per Klick erzeugt die Engine die fertige E-Rechnung.
Das Ganze funktioniert erstaunlich pragmatisch:
• vorhandene Excel-Rechnung weiter nutzen
• Felder einmal zuordnen
• E-Rechnung per Klick erzeugen
• optional direkt per Outlook versenden
Für viele kleinere Unternehmen oder Fachabteilungen kann das ein sehr schneller Einstieg in das Thema E-Rechnung sein – ohne sofort ein neues ERP- oder Cloud-System einzuführen.
👉 Wer sich das einmal live anschauen möchte:
Ich biete dazu ein kurzes kostenloses Webinar an, in dem ich die Lösung Schritt für Schritt zeige.
Wenn euch das interessiert, schreibt einfach „E-Rechnung“ in die Kommentare oder schickt mir eine kurze Nachricht – dann schicke ich euch die Infos zum Webinar.
Rechnungen automatisch aus ZUGFeRD-PDFs nach Excel importieren
Viele Unternehmen erhalten heute Rechnungen im ZUGFeRD-Format.
Das ist eigentlich eine gute Sache, denn diese PDFs enthalten neben der sichtbaren Rechnung auch strukturierte XML-Daten.
Das Problem:
In der Praxis landen diese Rechnungen trotzdem oft einfach nur im Ordner – und die relevanten Daten werden manuell in Excel oder die Buchhaltung übertragen.
Rechnungsnummer.
Datum.
Lieferant.
Betrag.
Alles wird abgeschrieben. Dabei steckt die Information längst in der Datei.
Die Idee: Excel liest die Rechnungen selbst
Ich habe ein kleines Excel-Tool gebaut, das ZUGFeRD-Rechnungen automatisch aus PDFs liest.
Wenn jemand Interesse hat – ich stelle es gerne kostenlos zur Verfügung.
Der Ablauf ist simpel:
1️⃣ Rechnungen liegen als ZUGFeRD-PDF im Ordner
2️⃣ Ein Button in Excel startet das Tool
3️⃣ Ein Python-Skript liest die XML-Daten aus der PDF
4️⃣ Die Rechnungsdaten werden automatisch nach Excel importiert
Ohne manuelle Eingabe.
Welche Daten werden ausgelesen?
Zum Beispiel:
>Rechnungsnummer
>Rechnungsdatum
>Lieferant
>Kunde
>Netto- und Bruttobetrag
>Zahlungsziel
Excel erhält sofort eine strukturierte Tabelle.
Der technische Hintergrund
ZUGFeRD-PDFs enthalten eine eingebettete XML-Datei mit allen Rechnungsdaten.
Das Tool:
>öffnet die PDFs
>extrahiert die XML-Daten
>liest die relevanten Felder
>schreibt sie direkt in eine Excel-Tabelle
Der Start erfolgt bequem über einen Excel-Button.
Excel bleibt also die Oberfläche – Python übernimmt nur die Verarbeitung im Hintergrund.
Ein schönes Beispiel dafür, wie Excel und Automatisierung zusammenpassen.
Excel bleibt das zentrale Werkzeug, nur die manuellen Tätigkeiten verschwinden Schritt für Schritt.
In letzter Zeit stolpere ich immer wieder über Beiträge, die anfangen mit:
„Jetzt mal ehrlich …“
„Hand aufs Herz …“
„Jetzt mal Spaß beiseite …“
Und meistens weiß ich dann schon, was kommt:
Excel ist das Problem. ERP ist die Rettung.
Ich frage mich ehrlich: Welche Wahrheit soll da eigentlich transportiert werden?
Dass Excel per se schlecht ist?
Dass jedes Unternehmen dringend migrieren muss?
Aus Unternehmersicht fühlt sich das oft anders an.
Wenn ich höre, eine ERP-Einführung dauert mehrere Monate, bindet Ressourcen, kostet Geld und Nerven – dann überlegt man sich das nicht leichtfertig.
Und in der Zeit läuft das Geschäft ja weiter.
Ich erlebe in der Praxis eher Folgendes:
Nicht Excel macht Probleme.
Unklare Prozesse machen Probleme.
Ein unsauberes Datenmodell bleibt unsauber – egal ob in Excel oder im ERP.
Natürlich gibt es Szenarien, in denen ein ERP absolut Sinn macht.
Aber Excel grundsätzlich schlechtzureden, greift mir zu kurz.
Die spannendere Frage ist doch:
Liegt das Problem wirklich am Tool – oder an der Struktur dahinter?
Mich würde interessieren:
Wann war bei Ihnen wirklich das System der Engpass – und wann eher die Organisation?
Nicht auswertbare Formate – warum „links Konto, rechts Monate“ kein Datenmodell ist
In vielen Kanzleien gehören Summen- und Saldenlisten, BWA-Übersichten oder Jahresauswertungen mit nebeneinanderstehenden Monatswerten zum Standard.
Optisch sind diese Berichte klar strukturiert:
links Konto und Bezeichnung, rechts Januar bis Dezember – häufig getrennt nach Soll und Haben.
Für die manuelle Betrachtung funktioniert das.
Für weiterführende Auswertungen jedoch nur eingeschränkt bzw. gar nicht.
Das strukturelle Problem
Aus Sicht der Datenverarbeitung liegt hier kein auswertbares Datenmodell vor.
Typische Merkmale solcher Formate:
• Monate stehen als Spalten statt als Werte.
• Soll- und Haben-Beträge sind getrennt statt logisch zusammengeführt.
• Überschriften sind mehrzeilig.
• Zwischen- oder Gesamtsummen unterbrechen die Struktur.
• Layout-Elemente dominieren gegenüber Datenlogik.
Diese Struktur verhindert oder erschwert:
• flexible Pivot-Auswertungen
• Zeitreihenvergleiche
• automatisierte Berichte
• Mandantenübergreifende Analysen
• systematische Weiterverarbeitung (z. B. BI-Anbindung)
Excel arbeitet datenbasiert – nicht layoutbasiert.
Ein Bericht ist noch kein Datenmodell.
Das Prinzip der Auswertbarkeit
Ein auswertbares Format folgt einem einfachen Grundsatz:
Eine Zeile entspricht einem eindeutigen Datensatz.
Beispiel für eine geeignete Struktur:
• Mandant
• Konto
• Bezeichnung
• Jahr
• Monat
• Wert
• Postenart (z. B. Soll/Haben oder Vorzeichenlogik)
In dieser Form entstehen:
• saubere Pivot-Tabellen
• konsistente Zeitachsen
• konsolidierte Mandantenauswertungen
• automatisierbare Reports
Erst diese Struktur ermöglicht eine systematische Weiterverarbeitung.
Vom Bericht zur Datengrundlage
In der Praxis liegt das Problem selten bei Excel selbst.
Es liegt im Format der gelieferten Daten.
Mit einem gezielt entwickelten VBA-Makro lassen sich solche Listen automatisiert:
• entpivotieren (Monatsspalten in Zeilen umwandeln),
• Soll/Haben logisch konsolidieren,
• nicht relevante Layout-Elemente entfernen,
• einheitliche Feldstrukturen herstellen,
• als Tabelle standardisieren.
Der manuelle Aufwand entfällt vollständig. Was zuvor eine statische Darstellung war, wird damit zur strukturierten Datengrundlage.
Excel + Python: Konkurrenz oder logische Partnerschaft?
Gestern habe ich einen Short veröffentlicht, in dem ich gezeigt habe, wie Python Rohdaten verarbeitet und Excel am Ende die fertige Auswertung übernimmt.
www.linkedin.com/posts/bernd-held-95989b2a2_excel-…
Die Reaktionen waren interessant.
Zwischen „Excel reicht doch“ und „VBA ist tot“ war alles dabei.
Und genau deshalb lohnt sich der Blick auf das Zusammenspiel.
Excel ist nicht das Problem
Excel ist in den meisten Unternehmen nicht deshalb so stark, weil es perfekt ist.
Sondern weil es verfügbar ist. Verstanden wird. Und nah am Fachbereich arbeitet.
Controlling, Kanzlei, Projektgeschäft – die Fachlogik entsteht dort, wo Excel steht.
Was Excel allerdings nicht gut kann:
• Millionen Datensätze performant transformieren
• Komplexe Text- oder Datenbereinigungen skalierbar durchführen
• Datenquellen außerhalb der Office-Welt sauber orchestrieren
Und genau hier kommt Python ins Spiel.
Python ist kein Ersatz – sondern ein Motor
Python ist exzellent, wenn es um:
• große Datenmengen
• strukturierte Transformation
• Automatisierung außerhalb von Excel
• reproduzierbare Datenpipelines
geht.
Aber: Python ersetzt keine Fachlogik im Tagesgeschäft.
Python ersetzt kein interaktives Reporting.
Und es ersetzt schon gar nicht die Excel-Denke in Unternehmen.
Die saubere Trennung
In meinen Projekten zeigt sich immer häufiger ein klares Muster:
Python übernimmt:
• Datenbereinigung
• Transformation
• Aggregation
• Vorberechnung
Das Ergebnis:
Stabilität im Backend. Flexibilität im Frontend.
Und was bedeutet das für VBA?
VBA bleibt relevant.
Nicht als Big-Data-Engine – sondern als Orchestrator.
Excel kann:
• Python-Skripte starten
• Ergebnisse einlesen
• Reports automatisieren
• Prozesse triggern
Das ist keine Entweder-oder-Frage.
Es ist eine Architekturfrage.
Excel und Python stehen nicht in Konkurrenz.
Excel ist die Oberfläche.
Python ist die Verarbeitung.
Und wer beides kombiniert, bekommt:
✔ Performance
✔ Automatisierung
✔ Transparenz
✔ Fachnähe
Mich interessiert:
Wie nutzt ihr Python im Zusammenspiel mit Excel?
Oder ist Excel für euch weiterhin das alleinige Werkzeug?
Excel vs. ERP – warum die Diskussion oft zu einfach geführt wird
In letzter Zeit höre ich immer wieder denselben Satz:
„Excel ist gefährlich.“
Und im gleichen Atemzug:
„Mit einem ERP-System passiert so etwas nicht.“
Ganz ehrlich – ich halte diese Gegenüberstellung für zu simpel.
Natürlich sind ERP-Systeme wichtig. Sie sorgen für strukturierte Abläufe, revisionssichere Buchungen, klare Prozesse und eine zentrale Datenbasis. Wenn es um Transaktionen geht, um Mehrbenutzerfähigkeit oder um saubere Prozessketten, führt an einem ERP kein Weg vorbei.
Aber trotzdem sehe ich in fast jedem ERP-geführten Unternehmen weiterhin Excel-Dateien. Teilweise ziemlich viele.
Warum?
Nicht, weil die Mitarbeitenden „rückständig“ sind. Sondern weil Excel etwas kann, was viele Systeme nur eingeschränkt leisten: flexibel denken.
Sobald es um kurzfristige Analysen, Sonderauswertungen, Forecast-Szenarien oder Management-Dashboards geht, wird oft exportiert – und in Excel weitergearbeitet.
Nicht aus Trotz. Sondern aus Pragmatismus.
Das eigentliche Problem ist deshalb nicht Excel.
Und auch nicht das ERP.
Problematisch wird es erst, wenn Excel beginnt, eine Datenbank zu ersetzen oder kritische Prozesse zu steuern, für die es nie gedacht war. Dann entstehen Versionenchaos, Intransparenz und Abhängigkeiten von einzelnen Personen.
Genauso problematisch wird es aber, wenn man glaubt, ein ERP könne alles lösen. Wenn jede kleine fachliche Anpassung ein IT-Projekt wird. Wenn Fachbereiche ihre Geschwindigkeit verlieren, weil sie für jede Idee ein Ticket schreiben müssen. Dann entstehen „Schatten-Excels“ – nicht aus Nachlässigkeit, sondern aus dem Bedürfnis nach Handlungsfähigkeit.
Die wirklich gut aufgestellten Unternehmen trennen sauber:
Das ERP ist das System der verbindlichen Daten.
Excel ist das Werkzeug für Analyse, Szenarien und Entscheidungen.
Nicht Gegenspieler. Sondern Ergänzung.
Vielleicht geht es weniger um „Excel oder ERP“ –
sondern um die Frage, ob jedes Werkzeug dort eingesetzt wird, wo es seine Stärke hat.
Mich würde interessieren:
Wo erlebt ihr in der Praxis mehr Frust – im Excel oder im ERP?
Diese Frage höre ich regelmäßig.
Python?
C#?
Java?
Power Platform?
Low-Code?
No-Code?
Meine ehrliche Antwort nach 35 Jahren Programmiererfahrung:
Die beste Programmiersprache ist die, die du wirklich beherrschst.
Ich programmiere seit über drei Jahrzehnten mit VBA.
Und ich habe damit alles umgesetzt, was ich umsetzen wollte:
• komplexe Controlling-Systeme
• automatisierte Reportings
• PDF-Serienprozesse
• Schnittstellen zu Datenbanken
• individuelle Benutzeroberflächen
• Prozessautomatisierungen in Kanzleien
• komplette Auswertungssysteme
War VBA dabei immer das modernste Tool?
Nein.
War es leistungsfähig genug?
Absolut.
Das eigentliche Problem ist nicht die Sprache.
Ich sehe oft Entwickler, die fünf oder zehn Technologien „kennen“.
Aber nichts davon wirklich tief.
Das Ergebnis:
-Halbe Lösungen.
-Unsaubere Architektur.
-Abhängigkeiten.
-Komplexität ohne Klarheit.
Tiefe schlägt Breite.
Eine Sprache wirklich zu verstehen bedeutet:
• sauber modellieren können
• Wartbarkeit mitdenken
• Performance einschätzen
• Fehlerquellen vermeiden
• Prozesse strukturiert abbilden
Das hat weniger mit Syntax zu tun.
Und viel mehr mit Denkweise.
Die falsche Diskussion
Oft wird diskutiert:
„Ist VBA noch zeitgemäß?“
„Sollte man nicht alles in Python neu bauen?“
„Ist Low-Code die Zukunft?“
Meine Erfahrung:
Die meisten Probleme entstehen nicht durch die Wahl der Sprache.
Sie entstehen durch fehlende Struktur, schlechte Architektur und mangelnde Prozessklarheit.
Ein gutes System bleibt gut – egal ob es in VBA, C# oder Python geschrieben wurde.
Ein schlecht konzipiertes System bleibt schlecht – auch in der modernsten Umgebung.
Meine persönliche Haltung
Ich glaube nicht daran, jede neue Technologie sofort lernen zu müssen.
Ich glaube daran, ein Werkzeug wirklich zu beherrschen.
Denn am Ende entscheidet nicht die Sprache über die Qualität.
Sondern der Entwickler.
Deshalb meine Frage an euch:
Setzt ihr lieber auf technologische Vielfalt oder auf echte Tiefe in einem Bereich?
Excel & VBA mit Bernd Held
Ich bin jetzt seit 4 Monaten auf Social Media (LinkedIn, TikTok und YotuTube) aktiv.
Und ganz ehrlich:
Was ich in dieser Zeit an „Grabsteinen“ gesehen habe, würde für einen ganzen Friedhof reichen.
Auf vielen dieser Grabsteine steht ein Name:
Excel.
💀 „Excel ist tot.“
💀 „Excel gehört abgeschafft.“
💀 „Excel ist das Problem.“
Ich frage mich dabei immer öfter:
Ist das eigentlich noch fair?
Denn das Muster ist fast immer das gleiche:
👉 Erst wird Excel schlechtgeredet
👉 Dann wird es symbolisch „beerdigt“
👉 Und anschließend wird die eigene Lösung präsentiert
ERP, PIM, Tool XY…
natürlich immer als die bessere Alternative.
Ist Excel wirklich das Problem?
Oder ist Excel einfach nur das Werkzeug,
das einspringt, wenn andere Systeme nicht liefern?
1 month ago | [YT] | 5
View 6 replies
Excel & VBA mit Bernd Held
Viele kleine Unternehmen schreiben ihre Rechnungen seit 20 Jahren mit Excel.
Und plötzlich heißt es überall:
👉 E-Rechnungspflicht.
👉 ZUGFeRD.
👉 XRechnung.
Die erste Reaktion ist oft:
„Dann brauchen wir wohl ein neues System.“
ERP.
Cloud-Software.
Neue Prozesse.
Aber stimmt das wirklich?
In vielen Fällen lautet die überraschende Antwort:
Nein.
Denn wenn Rechnungen heute bereits mit Excel erstellt werden, kann man daraus auch E-Rechnungen erzeugen.
Wir haben dafür eine Lösung entwickelt, mit der sich aus einer normalen Excel-Rechnung automatisch eine ZUGFeRD- oder XRechnung-Datei erzeugen lässt.
Der Ablauf ist bewusst einfach:
• bestehende Excel-Rechnung weiter nutzen
• Felder einmal zuordnen
• E-Rechnung per Klick erzeugen
• optional direkt per Outlook versenden
Gerade für kleinere Unternehmen, die seit Jahren mit Excel arbeiten, kann das ein sehr pragmatischer Einstieg sein – ohne sofort ein neues System einzuführen.
🎥 Ich zeige das live in einem kurzen Webinar
📅 Freitag, 20.03.2026
🕔 17:00 Uhr
👉 Teilnahme:
us02web.zoom.us/j/8071735115
Wenn Sie Interesse haben, schreiben Sie einfach „E-Rechnung“ in die Kommentare oder kommen Sie direkt dazu.
Ich zeige Schritt für Schritt, wie das funktioniert.
2 months ago | [YT] | 3
View 0 replies
Excel & VBA mit Bernd Held
e-Mail-Anhänge automatisch beim Empfangen von e-Mails ablegen
Neulich kam mein Nachbar auf mich zu und fragte mich, ob es denn möglich sein, dass Outlook automatisch die Anhänge aus eingehenden E-Mails speichert.
Er bekommt regelmäßig Rechnungen und Dokumente per Mail – und jedes Mal läuft der Ablauf gleich ab:
1. Mail öffnen
2. Anhang speichern
3. Ordner auswählen
4. Datei ablegen
Das funktioniert natürlich – aber wenn man das mehrmals am Tag macht, summiert sich der Aufwand schnell.
Meine Antwort war deshalb recht kurz:
„Ja, das geht. Outlook kann das automatisch.“
Viele wissen nicht, dass sich Outlook genauso wie Excel mit VBA automatisieren lässt.
Mit einem kleinen Makro kann Outlook nämlich einfach überwachen, wenn neue Mails eintreffen. Sobald eine E-Mail im Posteingang landet, prüft das Makro, ob Anhänge vorhanden sind – und speichert diese automatisch in einem gewünschten Ordner.
Der Ablauf ist dann plötzlich ganz simpel:
📩 Mail kommt an
📎 Anhang wird erkannt
💾 Datei wird automatisch gespeichert
Ohne Klick. Ohne manuelles Speichern.
Das folgende VBA-Makro macht genau das:
Private WithEvents PostfachItems As Outlook.Items
Private Sub Application_Startup()
Dim ns As Outlook.NameSpace
Dim Postfach As Outlook.Folder
Dim Zielordner As Outlook.Folder
Set ns = Application.GetNamespace("MAPI")
'Postfach auswählen
Set Postfach = ns.Folders("b.held@held-office.de")
'Ordner überwachen (z.B. Posteingang)
Set Zielordner = Postfach.Folders("Posteingang")
Set PostfachItems = Zielordner.Items
End Sub
Private Sub PostfachItems_ItemAdd(ByVal Item As Object)
Dim Mail As Outlook.MailItem
Dim Anhang As Outlook.Attachment
Dim Speicherpfad As String
If TypeOf Item Is Outlook.MailItem Then
Set Mail = Item
Speicherpfad = "C:\Users\VBAhe\Desktop\Anhänge\"
If Mail.Attachments.Count > 0 Then
For Each Anhang In Mail.Attachments
Anhang.SaveAsFile Speicherpfad & _
Format(Now, "yyyy.mm.dd_hhnnss_") & Anhang.FileName
Next Anhang
End If
End If
End Sub
Der Clou daran ist:
Outlook reagiert automatisch auf neue E-Mails. Das Makro läuft im Hintergrund und speichert jeden Anhang sofort im definierten Ordner.
Gerade in Unternehmen kann das sehr hilfreich sein, zum Beispiel wenn:
• Rechnungen automatisch abgelegt werden sollen
• Dokumente zentral gesammelt werden
• Anhänge aus bestimmten Postfächern archiviert werden sollen
• Dateien für eine Weiterverarbeitung bereitstehen müssen
Mit ein paar zusätzlichen Zeilen Code könnte man sogar noch weitergehen, etwa:
• nur bestimmte Dateitypen speichern (z. B. PDF)
• nur Anhänge bestimmter Absender speichern
• die Dateien automatisch in Jahres- oder Monatsordner sortieren
Viele denken bei Automatisierung sofort an große Systeme.
Oft reicht aber schon ein kleines VBA-Makro, um einen Prozess deutlich einfacher zu machen.
Und genau solche kleinen Automatisierungen sparen im Alltag erstaunlich viel Zeit.
2 months ago | [YT] | 0
View 0 replies
Excel & VBA mit Bernd Held
E-Rechnungen erstellen – direkt aus Excel?
Viele Unternehmen beschäftigen sich gerade intensiv mit dem Thema E-Rechnung.
Spätestens seit 2025 müssen Unternehmen im B2B-Bereich in der Lage sein, elektronische Rechnungen zu empfangen – und mittelfristig auch zu erstellen.
Oft lautet die erste Reaktion:
Neue Software anschaffen, neues System einführen, Prozesse komplett umbauen.
Dabei übersehen viele eine einfache Möglichkeit:
👉 E-Rechnungen lassen sich auch direkt aus Excel erzeugen.
Wir haben dafür eine Lösung entwickelt, mit der sich ZUGFeRD- und XRechnung-Dateien direkt aus einer Excel-Rechnung erstellen lassen. Die relevanten Felder werden über eine Mapping-Tabelle zugeordnet, und per Klick erzeugt die Engine die fertige E-Rechnung.
Das Ganze funktioniert erstaunlich pragmatisch:
• vorhandene Excel-Rechnung weiter nutzen
• Felder einmal zuordnen
• E-Rechnung per Klick erzeugen
• optional direkt per Outlook versenden
Für viele kleinere Unternehmen oder Fachabteilungen kann das ein sehr schneller Einstieg in das Thema E-Rechnung sein – ohne sofort ein neues ERP- oder Cloud-System einzuführen.
👉 Wer sich das einmal live anschauen möchte:
Ich biete dazu ein kurzes kostenloses Webinar an, in dem ich die Lösung Schritt für Schritt zeige.
Wenn euch das interessiert, schreibt einfach „E-Rechnung“ in die Kommentare oder schickt mir eine kurze Nachricht – dann schicke ich euch die Infos zum Webinar.
2 months ago | [YT] | 4
View 0 replies
Excel & VBA mit Bernd Held
Rechnungen automatisch aus ZUGFeRD-PDFs nach Excel importieren
Viele Unternehmen erhalten heute Rechnungen im ZUGFeRD-Format.
Das ist eigentlich eine gute Sache, denn diese PDFs enthalten neben der sichtbaren Rechnung auch strukturierte XML-Daten.
Das Problem:
In der Praxis landen diese Rechnungen trotzdem oft einfach nur im Ordner – und die relevanten Daten werden manuell in Excel oder die Buchhaltung übertragen.
Rechnungsnummer.
Datum.
Lieferant.
Betrag.
Alles wird abgeschrieben.
Dabei steckt die Information längst in der Datei.
Die Idee: Excel liest die Rechnungen selbst
Ich habe ein kleines Excel-Tool gebaut, das ZUGFeRD-Rechnungen automatisch aus PDFs liest.
Wenn jemand Interesse hat – ich stelle es gerne kostenlos zur Verfügung.
Der Ablauf ist simpel:
1️⃣ Rechnungen liegen als ZUGFeRD-PDF im Ordner
2️⃣ Ein Button in Excel startet das Tool
3️⃣ Ein Python-Skript liest die XML-Daten aus der PDF
4️⃣ Die Rechnungsdaten werden automatisch nach Excel importiert
Ohne manuelle Eingabe.
Welche Daten werden ausgelesen?
Zum Beispiel:
>Rechnungsnummer
>Rechnungsdatum
>Lieferant
>Kunde
>Netto- und Bruttobetrag
>Zahlungsziel
Excel erhält sofort eine strukturierte Tabelle.
Der technische Hintergrund
ZUGFeRD-PDFs enthalten eine eingebettete XML-Datei mit allen Rechnungsdaten.
Das Tool:
>öffnet die PDFs
>extrahiert die XML-Daten
>liest die relevanten Felder
>schreibt sie direkt in eine Excel-Tabelle
Der Start erfolgt bequem über einen Excel-Button.
Excel bleibt also die Oberfläche – Python übernimmt nur die Verarbeitung im Hintergrund.
Ein schönes Beispiel dafür, wie Excel und Automatisierung zusammenpassen.
Excel bleibt das zentrale Werkzeug, nur die manuellen Tätigkeiten verschwinden Schritt für Schritt.
💡 Mich würde interessieren:
Arbeitet ihr bereits mit ZUGFeRD-Rechnungen –
oder werden Rechnungsdaten noch manuell erfasst?
2 months ago | [YT] | 3
View 0 replies
Excel & VBA mit Bernd Held
Jetzt mal ehrlich …“ – aber worüber eigentlich?
In letzter Zeit stolpere ich immer wieder über Beiträge, die anfangen mit:
„Jetzt mal ehrlich …“
„Hand aufs Herz …“
„Jetzt mal Spaß beiseite …“
Und meistens weiß ich dann schon, was kommt:
Excel ist das Problem. ERP ist die Rettung.
Ich frage mich ehrlich: Welche Wahrheit soll da eigentlich transportiert werden?
Dass Excel per se schlecht ist?
Dass jedes Unternehmen dringend migrieren muss?
Aus Unternehmersicht fühlt sich das oft anders an.
Wenn ich höre, eine ERP-Einführung dauert mehrere Monate, bindet Ressourcen, kostet Geld und Nerven – dann überlegt man sich das nicht leichtfertig.
Und in der Zeit läuft das Geschäft ja weiter.
Ich erlebe in der Praxis eher Folgendes:
Nicht Excel macht Probleme.
Unklare Prozesse machen Probleme.
Ein unsauberes Datenmodell bleibt unsauber – egal ob in Excel oder im ERP.
Natürlich gibt es Szenarien, in denen ein ERP absolut Sinn macht.
Aber Excel grundsätzlich schlechtzureden, greift mir zu kurz.
Die spannendere Frage ist doch:
Liegt das Problem wirklich am Tool – oder an der Struktur dahinter?
Mich würde interessieren:
Wann war bei Ihnen wirklich das System der Engpass – und wann eher die Organisation?
2 months ago | [YT] | 3
View 0 replies
Excel & VBA mit Bernd Held
Nicht auswertbare Formate – warum „links Konto, rechts Monate“ kein Datenmodell ist
In vielen Kanzleien gehören Summen- und Saldenlisten, BWA-Übersichten oder Jahresauswertungen mit nebeneinanderstehenden Monatswerten zum Standard.
Optisch sind diese Berichte klar strukturiert:
links Konto und Bezeichnung, rechts Januar bis Dezember – häufig getrennt nach Soll und Haben.
Für die manuelle Betrachtung funktioniert das.
Für weiterführende Auswertungen jedoch nur eingeschränkt bzw. gar nicht.
Das strukturelle Problem
Aus Sicht der Datenverarbeitung liegt hier kein auswertbares Datenmodell vor.
Typische Merkmale solcher Formate:
• Monate stehen als Spalten statt als Werte.
• Soll- und Haben-Beträge sind getrennt statt logisch zusammengeführt.
• Überschriften sind mehrzeilig.
• Zwischen- oder Gesamtsummen unterbrechen die Struktur.
• Layout-Elemente dominieren gegenüber Datenlogik.
Diese Struktur verhindert oder erschwert:
• flexible Pivot-Auswertungen
• Zeitreihenvergleiche
• automatisierte Berichte
• Mandantenübergreifende Analysen
• systematische Weiterverarbeitung (z. B. BI-Anbindung)
Excel arbeitet datenbasiert – nicht layoutbasiert.
Ein Bericht ist noch kein Datenmodell.
Das Prinzip der Auswertbarkeit
Ein auswertbares Format folgt einem einfachen Grundsatz:
Eine Zeile entspricht einem eindeutigen Datensatz.
Beispiel für eine geeignete Struktur:
• Mandant
• Konto
• Bezeichnung
• Jahr
• Monat
• Wert
• Postenart (z. B. Soll/Haben oder Vorzeichenlogik)
In dieser Form entstehen:
• saubere Pivot-Tabellen
• konsistente Zeitachsen
• konsolidierte Mandantenauswertungen
• automatisierbare Reports
Erst diese Struktur ermöglicht eine systematische Weiterverarbeitung.
Vom Bericht zur Datengrundlage
In der Praxis liegt das Problem selten bei Excel selbst.
Es liegt im Format der gelieferten Daten.
Mit einem gezielt entwickelten VBA-Makro lassen sich solche Listen automatisiert:
• entpivotieren (Monatsspalten in Zeilen umwandeln),
• Soll/Haben logisch konsolidieren,
• nicht relevante Layout-Elemente entfernen,
• einheitliche Feldstrukturen herstellen,
• als Tabelle standardisieren.
Der manuelle Aufwand entfällt vollständig. Was zuvor eine statische Darstellung war, wird damit zur strukturierten Datengrundlage.
2 months ago | [YT] | 2
View 4 replies
Excel & VBA mit Bernd Held
Excel + Python: Konkurrenz oder logische Partnerschaft?
Gestern habe ich einen Short veröffentlicht, in dem ich gezeigt habe, wie Python Rohdaten verarbeitet und Excel am Ende die fertige Auswertung übernimmt.
www.linkedin.com/posts/bernd-held-95989b2a2_excel-…
Die Reaktionen waren interessant.
Zwischen „Excel reicht doch“ und „VBA ist tot“ war alles dabei.
Und genau deshalb lohnt sich der Blick auf das Zusammenspiel.
Excel ist nicht das Problem
Excel ist in den meisten Unternehmen nicht deshalb so stark, weil es perfekt ist.
Sondern weil es verfügbar ist. Verstanden wird. Und nah am Fachbereich arbeitet.
Controlling, Kanzlei, Projektgeschäft – die Fachlogik entsteht dort, wo Excel steht.
Was Excel allerdings nicht gut kann:
• Millionen Datensätze performant transformieren
• Komplexe Text- oder Datenbereinigungen skalierbar durchführen
• Datenquellen außerhalb der Office-Welt sauber orchestrieren
Und genau hier kommt Python ins Spiel.
Python ist kein Ersatz – sondern ein Motor
Python ist exzellent, wenn es um:
• große Datenmengen
• strukturierte Transformation
• Automatisierung außerhalb von Excel
• reproduzierbare Datenpipelines
geht.
Aber: Python ersetzt keine Fachlogik im Tagesgeschäft.
Python ersetzt kein interaktives Reporting.
Und es ersetzt schon gar nicht die Excel-Denke in Unternehmen.
Die saubere Trennung
In meinen Projekten zeigt sich immer häufiger ein klares Muster:
Python übernimmt:
• Datenbereinigung
• Transformation
• Aggregation
• Vorberechnung
Excel übernimmt:
• Visualisierung
• Pivot-Analysen
• Fachprüfung
• Management-Reporting
Das Ergebnis:
Stabilität im Backend. Flexibilität im Frontend.
Und was bedeutet das für VBA?
VBA bleibt relevant.
Nicht als Big-Data-Engine – sondern als Orchestrator.
Excel kann:
• Python-Skripte starten
• Ergebnisse einlesen
• Reports automatisieren
• Prozesse triggern
Das ist keine Entweder-oder-Frage.
Es ist eine Architekturfrage.
Excel und Python stehen nicht in Konkurrenz.
Excel ist die Oberfläche.
Python ist die Verarbeitung.
Und wer beides kombiniert, bekommt:
✔ Performance
✔ Automatisierung
✔ Transparenz
✔ Fachnähe
Mich interessiert:
Wie nutzt ihr Python im Zusammenspiel mit Excel?
Oder ist Excel für euch weiterhin das alleinige Werkzeug?
3 months ago | [YT] | 2
View 1 reply
Excel & VBA mit Bernd Held
Excel vs. ERP – warum die Diskussion oft zu einfach geführt wird
In letzter Zeit höre ich immer wieder denselben Satz:
„Excel ist gefährlich.“
Und im gleichen Atemzug:
„Mit einem ERP-System passiert so etwas nicht.“
Ganz ehrlich – ich halte diese Gegenüberstellung für zu simpel.
Natürlich sind ERP-Systeme wichtig. Sie sorgen für strukturierte Abläufe, revisionssichere Buchungen, klare Prozesse und eine zentrale Datenbasis. Wenn es um Transaktionen geht, um Mehrbenutzerfähigkeit oder um saubere Prozessketten, führt an einem ERP kein Weg vorbei.
Aber trotzdem sehe ich in fast jedem ERP-geführten Unternehmen weiterhin Excel-Dateien. Teilweise ziemlich viele.
Warum?
Nicht, weil die Mitarbeitenden „rückständig“ sind. Sondern weil Excel etwas kann, was viele Systeme nur eingeschränkt leisten: flexibel denken.
Sobald es um kurzfristige Analysen, Sonderauswertungen, Forecast-Szenarien oder Management-Dashboards geht, wird oft exportiert – und in Excel weitergearbeitet.
Nicht aus Trotz. Sondern aus Pragmatismus.
Das eigentliche Problem ist deshalb nicht Excel.
Und auch nicht das ERP.
Problematisch wird es erst, wenn Excel beginnt, eine Datenbank zu ersetzen oder kritische Prozesse zu steuern, für die es nie gedacht war. Dann entstehen Versionenchaos, Intransparenz und Abhängigkeiten von einzelnen Personen.
Genauso problematisch wird es aber, wenn man glaubt, ein ERP könne alles lösen. Wenn jede kleine fachliche Anpassung ein IT-Projekt wird. Wenn Fachbereiche ihre Geschwindigkeit verlieren, weil sie für jede Idee ein Ticket schreiben müssen. Dann entstehen „Schatten-Excels“ – nicht aus Nachlässigkeit, sondern aus dem Bedürfnis nach Handlungsfähigkeit.
Die wirklich gut aufgestellten Unternehmen trennen sauber:
Das ERP ist das System der verbindlichen Daten.
Excel ist das Werkzeug für Analyse, Szenarien und Entscheidungen.
Nicht Gegenspieler. Sondern Ergänzung.
Vielleicht geht es weniger um „Excel oder ERP“ –
sondern um die Frage, ob jedes Werkzeug dort eingesetzt wird, wo es seine Stärke hat.
Mich würde interessieren:
Wo erlebt ihr in der Praxis mehr Frust – im Excel oder im ERP?
3 months ago | [YT] | 2
View 0 replies
Excel & VBA mit Bernd Held
Welche Programmiersprache ist die Beste?
Diese Frage höre ich regelmäßig.
Python?
C#?
Java?
Power Platform?
Low-Code?
No-Code?
Meine ehrliche Antwort nach 35 Jahren Programmiererfahrung:
Die beste Programmiersprache ist die, die du wirklich beherrschst.
Ich programmiere seit über drei Jahrzehnten mit VBA.
Und ich habe damit alles umgesetzt, was ich umsetzen wollte:
• komplexe Controlling-Systeme
• automatisierte Reportings
• PDF-Serienprozesse
• Schnittstellen zu Datenbanken
• individuelle Benutzeroberflächen
• Prozessautomatisierungen in Kanzleien
• komplette Auswertungssysteme
War VBA dabei immer das modernste Tool?
Nein.
War es leistungsfähig genug?
Absolut.
Das eigentliche Problem ist nicht die Sprache.
Ich sehe oft Entwickler, die fünf oder zehn Technologien „kennen“.
Aber nichts davon wirklich tief.
Das Ergebnis:
-Halbe Lösungen.
-Unsaubere Architektur.
-Abhängigkeiten.
-Komplexität ohne Klarheit.
Tiefe schlägt Breite.
Eine Sprache wirklich zu verstehen bedeutet:
• sauber modellieren können
• Wartbarkeit mitdenken
• Performance einschätzen
• Fehlerquellen vermeiden
• Prozesse strukturiert abbilden
Das hat weniger mit Syntax zu tun.
Und viel mehr mit Denkweise.
Die falsche Diskussion
Oft wird diskutiert:
„Ist VBA noch zeitgemäß?“
„Sollte man nicht alles in Python neu bauen?“
„Ist Low-Code die Zukunft?“
Meine Erfahrung:
Die meisten Probleme entstehen nicht durch die Wahl der Sprache.
Sie entstehen durch fehlende Struktur, schlechte Architektur und mangelnde Prozessklarheit.
Ein gutes System bleibt gut – egal ob es in VBA, C# oder Python geschrieben wurde.
Ein schlecht konzipiertes System bleibt schlecht – auch in der modernsten Umgebung.
Meine persönliche Haltung
Ich glaube nicht daran, jede neue Technologie sofort lernen zu müssen.
Ich glaube daran, ein Werkzeug wirklich zu beherrschen.
Denn am Ende entscheidet nicht die Sprache über die Qualität.
Sondern der Entwickler.
Deshalb meine Frage an euch:
Setzt ihr lieber auf technologische Vielfalt oder auf echte Tiefe in einem Bereich?
Ich bin gespannt auf eure Erfahrungen.
3 months ago | [YT] | 5
View 6 replies
Load more