Ihr Rechnungsworkflow endet bei PDF? Ein Output-Audit zeigt Datenlücken, Layout-Risiken, Sonderfälle und den nächsten Schritt zur E-Rechnung.
Viele Rechnungsprozesse sehen auf den ersten Blick digital aus. Angebote, Aufträge, Leistungen, Preise und Kundendaten werden in Systemen gepflegt. Die Rechnung wird erzeugt. Dann passiert der entscheidende Schritt: Export als PDF.
Ab diesem Moment ist oft unklar, was aus den Daten geworden ist. Waren sie bis eben noch strukturierte Informationen im System, liegen sie jetzt vielleicht nur noch als sichtbares Dokument vor. Für Menschen ist das bequem. Für E-Rechnungsprozesse kann genau hier die Lücke entstehen.
Dieser Artikel zeigt, wie Sie diese Output-Lücke systematisch prüfen, ohne sofort ein Großprojekt zu starten.
Die meisten Unternehmen diskutieren E-Rechnung zuerst auf Systemebene: ERP, CRM, Billing, Shop, DMS, Schnittstellen. Das ist verständlich, aber oft zu grob.
Die konkrete Lücke entsteht häufig am Übergang vom System zum Dokument:
● beim PDF-Export,
● im Rechnungstemplate,
● bei gehosteten Rechnungen,
● im Portaldownload,
● bei E-Mail-Anhängen,
● in manuellen Ablagen,
● bei nachträglichen Änderungen am Dokument.
Genau dort kann strukturierte Information verloren gehen. Was im System als Feld existiert, erscheint im PDF nur noch als Text, Tabelle, Linie oder optische Anordnung. Eine E-Rechnung braucht aber verarbeitbare Struktur.
Der Output-Audit fragt deshalb nicht zuerst: „Welches System nutzen wir?“ Sondern: „Was kommt am Ende wirklich heraus?“
Starten Sie nicht mit einem idealen Muster. Sammeln Sie reale Rechnungen aus dem laufenden Prozess.
Nützlich sind mindestens:
● eine Standardrechnung (mehrere Seiten),
● eine Rechnung mit mehreren Positionen,
● eine Gutschrift oder Stornorechnung,
● eine Rechnung mit Rabatt,
● eine Rechnung mit abweichender Liefer- oder Leistungsadresse,
● eine Rechnung mit Leistungszeitraum,
● eine Rechnung mit besonderer Steuerlogik,
● eine Rechnung aus jedem relevanten Template oder jeder Geschäftseinheit.
Der häufigste Fehler ist, nur die schönste Beispielrechnung zu prüfen. Sie zeigt, was möglich ist, aber nicht, was im Alltag passiert.
Erstellen Sie eine einfache Feldliste. Prüfen Sie, ob die Informationen im PDF sichtbar, eindeutig und stabil vorhanden sind.
Wichtige Felder sind unter anderem:
● Verkäuferdaten,
● Käuferdaten,
● Rechnungsnummer,
● Rechnungsdatum,
● Leistungsdatum oder Leistungszeitraum,
● Positionen,
● Mengen und Einheiten,
● Einzelpreise,
● Rabatte,
● Steuersätze,
● Steuerbeträge,
● Netto- und Bruttosummen,
● Zahlungsbedingungen,
● Referenzen wie Bestellung, Projekt oder Kundennummer.
Dabei reicht „steht irgendwo“ nicht aus. Für einen strukturierten Output muss klar sein, welches Feld welche Bedeutung hat. Wenn eine Information nur in einem Freitextsatz versteckt ist, kann das für Menschen funktionieren und für Maschinen problematisch sein.
Wiederkehrende Verarbeitung braucht wiederkehrende Muster. Prüfen Sie deshalb, ob das Rechnungsbild über mehrere Dokumente stabil bleibt.
Fragen Sie:
● Wandern wichtige Felder je nach Textlänge?
● Gibt es unterschiedliche Templates je Land, Marke oder Kundengruppe?
● Werden Positionstabellen bei längeren Rechnungen anders dargestellt?
● Enthalten manche Rechnungen zusätzliche Seiten oder Anlagen?
● Ändern Teams das PDF nach dem Export manuell?
● Gibt es gescannte oder bildbasierte PDFs?
Ein stabiler Output ist leichter zu aktivieren. Ein wechselnder Output ist nicht unmöglich, aber er braucht mehr Prüfung und oft klare Prozessregeln.
Viele E-Rechnungsprojekte scheitern nicht an der Standardrechnung. Sie scheitern an den Sonderfällen.
Typische Sonderfälle sind:
● Gutschriften,
● Abschlags- und Schlussrechnungen,
● Sammelrechnungen,
● Reverse-Charge-Szenarien,
● innergemeinschaftliche Leistungen,
● Reisekosten oder Nebenkosten,
● mehrere Steuersätze,
● Währungsfälle,
● Anlagen und Leistungsnachweise,
● Projekt- oder Bestellreferenzen.
Diese Fälle sollten früh gesammelt werden. Wenn sie erst nach dem Go-live auftauchen, fühlt sich der Prozess schnell wie ein Türsteher an, der nur Stammgäste kennt.
Der Output endet nicht bei der Datei. Fragen Sie, was nach der Erstellung passieren soll.
Muss der Empfänger XRechnung erhalten? Wird ZUGFeRD akzeptiert? Soll die Datei nur heruntergeladen werden? Muss sie in ein Buchhaltungssystem, ERP, DMS, Kundenportal oder anderes Zielsystem übergeben werden?
Diese Fragen sollten nicht die erste Diskussion dominieren, aber sie gehören in den Audit. Denn das gewünschte Zielformat und der Folgeweg beeinflussen, welche Daten im Output besonders kritisch sind.
Ein einfacher Score hilft, die Lage einzuordnen.
Das PDF ist textbasiert, enthält alle relevanten Rechnungsdaten, das Layout ist stabil und Sonderfälle sind überschaubar. Nächster Schritt: PDF-Test und Zielformat prüfen.
Einige Daten sind unklar, Felder wandern, Sonderfälle fehlen im Muster oder mehrere Templates sind im Einsatz. Nächster Schritt: zusätzliche Muster sammeln, Template-Logik prüfen, gegebenenfalls Layout-Aktivierung vorbereiten.
Pflichtdaten fehlen, Rechnungen werden manuell nachbearbeitet, Scans dominieren, Steuerlogik ist unklar oder wichtige Informationen stehen nur in Anlagen. Nächster Schritt: Quellsystem, Template oder Prozess korrigieren, bevor ein wiederkehrender E-Rechnungsprozess geplant wird.
Ein Output-Audit ist keine Rechtsberatung und keine finale Compliance-Freigabe. Er beantwortet eine operativere Frage: Ist der heutige Rechnungsoutput eine brauchbare Grundlage für strukturierte Verarbeitung?
Das ist bewusst kleiner als ein komplettes E-Rechnungsprojekt. Aber es ist auch konkreter. Statt über hypothetische Zielarchitekturen zu sprechen, prüft das Team echte Dokumente.
Das Ergebnis ist ein Maßnahmenpfad:
● direkt testen,
● Zielformat klären,
● Layout aktivieren,
● Template anpassen,
● Quellsystemdaten ergänzen,
● Sonderfälle separat behandeln,
● Zielsystemübergabe später planen.
ValiMesh kann mit einem echten PDF-Output starten. Die Datei wird nicht als hübsches Dokument betrachtet, sondern als Ausgangspunkt für strukturierte Verarbeitung.
Dabei geht es um Fragen wie:
● Sind relevante Daten vorhanden?
● Lassen sie sich eindeutig erkennen?
● Ist das Layout wiederkehrend?
● Gibt es Warnungen oder Korrekturbedarf?
● Braucht das Layout Aktivierung?
● Welches Zielformat ist realistisch?
So wird der Output-Audit handlungsorientiert. Nicht „wir haben ein PDF-Problem“, sondern „wir wissen, was am Output fehlt und was als Nächstes zu tun ist“.
E-Rechnung scheitert selten daran, dass Unternehmen gar keine Rechnungsdaten haben. Häufig sind die Daten vorhanden, aber der letzte Prozessschritt macht daraus ein reines Sichtdokument.
Genau deshalb ist ein Output-Audit so wertvoll. Er zeigt, ob der heutige PDF-Output als Grundlage für XRechnung oder ZUGFeRD taugt, ob ein Layout aktiviert werden kann oder ob zuerst Daten und Templates verbessert werden müssen.
Bevor Sie also über Systemwechsel, Integrationslandschaft oder Zielsystemübergabe sprechen: Sammeln Sie echte Rechnungen und prüfen Sie den Output. Dort beginnt oft der schnellste Weg zur Lösung.

Wann passt XRechnung, wann ZUGFeRD? Der Artikel zeigt Formatwahl, Datenanforderungen und Grenzen der PDF-zu-E-Rechnung-Konvertierung.

Einfaches PDF oder strukturierte E-Rechnung? Der Leitfaden zeigt Unterschiede, Formate, Übergangslogik und nächste Schritte für PDF-first Unternehmen.

Muss wegen E-Rechnung ein neues ERP her? Prüfen Sie zuerst, ob HubSpot, Stripe, Shopify & Co. geeigneten Rechnungsoutput liefern.