E-Rechnung und Liquidität: Mein Versandcheck gegen vermeidbare Zahlungsschleifen

13. Oktober 2026 | Freiberufler Ratgeber

Die Leistung ist fertig, die Rechnung verschickt und der erwartete Zahlungseingang steht im Liquiditätsplan. Dann kommt eine Rückfrage: falscher Empfänger, fehlender Bestellbezug oder ein Format, das der Kunde nicht verarbeiten kann. Ich bin Alex und sehe solche Schleifen als eigenes Planungsrisiko. Ein zusätzliches Kreditangebot beantwortet nicht die Frage, warum eine Rechnung noch nicht durch den Freigabeprozess kommt.

Mein Ansatz ist ein Versandcheck, der technische Verarbeitung, sachliche Prüfung und Zahlung getrennt sichtbar macht. Welche Rechnungsregeln und Übergangsbestimmungen für den konkreten Umsatz gelten, lasse ich bei Bedarf steuerlich klären. Hier geht es um die praktische Organisation rund um eine bereits sauber erstellte Rechnung.

Ein PDF ist nicht automatisch eine strukturierte E-Rechnung

Im umsatzsteuerlichen Sinn ermöglicht eine E-Rechnung durch ein strukturiertes elektronisches Format die elektronische Verarbeitung. Ein gewöhnliches PDF allein erfüllt diese Definition nicht schon deshalb, weil es per E-Mail kommt. Ich prüfe daher, welches Format mein Programm tatsächlich erzeugt und welchen Weg der Empfänger für diesen Auftrag vorgesehen hat.

Gleichzeitig behaupte ich nicht, dass jeder Freiberufler für jeden Kunden bereits dieselbe Ausstellungspflicht hat. Umsatzart, Empfänger und geltende Ausnahmen oder Übergangsregeln müssen zur konkreten Situation passen. Eine pauschale Aussage in der Software ersetzt diese Prüfung nicht.

Meine drei Rückfragen vor der ersten Rechnung

Ich kläre den zuständigen Rechnungsempfänger, den vorgesehenen Übermittlungsweg und die benötigte Zuordnung zum Auftrag. Der Ansprechpartner aus dem Projekt kann ein anderer sein als die Buchhaltung. Eine korrekt adressierte Nachricht an den falschen internen Prozess bleibt möglicherweise liegen.

Bestellnummern, Projektkennungen oder besondere Portalfelder können für die Verarbeitung des Kunden wichtig sein. Ich unterscheide diese organisatorischen Anforderungen von gesetzlichen Pflichtangaben. Nicht jedes vom Kunden gewünschte Feld ist automatisch eine gesetzliche Voraussetzung; trotzdem lohnt sich die Klärung vor dem Versand.

Eine kurze Empfängerkarte genügt oft

Meine eigene Empfängerkarte enthält Name der abrechnenden Einheit, Rechnungsadresse, Kontakt für Rückfragen, Versandweg und vereinbarten Bestellbezug. Dazu kommt ein Datum der letzten Bestätigung. Ich übernehme solche Daten nicht ungeprüft aus einer alten Rechnung, wenn ein Unternehmen seine Abläufe geändert hat.

Was ich beim Versand dokumentiere

Ich ordne der Rechnung den Leistungsnachweis, die vereinbarte Abrechnung und den versandten Datenstand zu. Danach notiere ich den Zeitpunkt der Übermittlung und vorhandene Empfangs- oder Portalrückmeldungen. Eine Datei im Ordner „Gesendet“ belegt zunächst meinen Versand, nicht die vollständige Freigabe beim Kunden.

Bei einer technischen Fehlermeldung sichere ich den Wortlaut und kläre den Grund. Ich versende nicht wahllos neue Varianten mit neuen Rechnungsnummern. Sonst kann eine Rechnung im System des Empfängers mehrfach auftauchen, während unklar bleibt, welches Dokument gelten soll.

Mein fiktives Beispiel für die Liquiditätsplanung

Eine frei erfundene Projektabrechnung beträgt 4.000 Euro. Ich habe den Eingang für Ende des Monats eingeplant. Wegen einer fehlenden Projektkennung fordert die Buchhaltung eine Klärung an. Der Betrag ist dadurch nicht automatisch verloren, aber der ursprüngliche Eingangstermin ist nun unsicher.

In meinem Plan kennzeichne ich die 4.000 Euro als offenen Eingang mit Klärungsbedarf. Zusätzlich rechne ich einen späteren Zahlungstermin durch. Die Differenz am niedrigsten Kontostand zeigt, wie viel Reserve gebraucht werden könnte. Ich unterstelle weder eine garantierte Verzögerung noch eine sofortige Überbrückungszusage der Bank.

Technisch akzeptiert heißt noch nicht bezahlt

Ich verwende getrennte Status: versandt, technisch angenommen, sachlich in Prüfung und bezahlt. Diese Einteilung ist meine Arbeitsroutine, kein allgemeiner Standard. Sie verhindert, dass eine positive Portalmeldung versehentlich als Zahlungseingang behandelt wird.

Rückfragen sachlich und mit Versionsklarheit lösen

Bei einer Korrekturanfrage kläre ich zuerst, ob es um Format, Stammdaten, Leistung oder einen strittigen Betrag geht. Anschließend stimme ich das richtige Berichtigungsverfahren mit Buchhaltung oder steuerlicher Beratung ab. Eine neue Datei mit gleichem Namen kann sonst den Eindruck erwecken, der ursprüngliche Inhalt habe sich unbemerkt verändert.

Parallel frage ich nach dem erwarteten weiteren Ablauf. Eine konkrete Rückmeldung ist hilfreicher als tägliches erneutes Senden. Im Liquiditätsplan bleibt die Unsicherheit sichtbar, bis ein belastbarer Termin oder der tatsächliche Eingang vorliegt.

Mein Vorschlag für diese Woche

Nimm deine drei wichtigsten Rechnungsempfänger und bestätige Versandweg, Format und Auftragsbezug. Teste anschließend mit einem zulässigen Verfahren, ob deine Software den vorgesehenen Datenstand erzeugt. Ergänze die offenen Rechnungen um ihren tatsächlichen Bearbeitungsstatus. So lässt sich ein möglicher Finanzierungsbedarf aus dem Zahlungsablauf erklären, statt nur eine offene Gesamtsumme an die Bank zu schicken.