E-Rechnung empfangen: Kurzantwort und klare Abgrenzung
Empfang bedeutet mehr als das Öffnen eines Anhangs. Der Prozess muss auch XML-Dateien ohne sichtbares PDF, hybride ZUGFeRD-Dateien, Portalabrufe, Dubletten, Korrekturen und verdächtige Bankänderungen beherrschen. Verantwortliche benötigen eine Arbeitsansicht, dürfen aber das strukturierte Original dabei nicht verändern oder durch einen Screenshot ersetzen.
Die allgemeine Rechnungsverarbeitung ist der End-to-End-Hub für alle Eingangsbelege. Dieser Beitrag fokussiert den Eintritt einer E-Rechnung und die Übergabe in die Prüfung. Das reine Darstellen erklärt E-Rechnung lesen, die Regeltiefe E-Rechnung validieren.
Entscheidungsmatrix für E-Rechnung empfangen
| Situation | Prüffrage | Entscheidung | Nachweis |
|---|---|---|---|
| E-Mail-Eingang | Lieferant sendet XML oder ZUGFeRD an die vereinbarte Rechnungsadresse. | Ein überwachte Funktionspostfach nimmt an und führt Anhänge kontrolliert weiter. | Mail-Header, Originalanhang, Empfangszeit und Virenprüfung. |
| Portalabruf | Die Rechnung liegt nur im Lieferanten- oder Auftraggeberportal bereit. | Abrufverantwortung, Frist und unveränderter Download werden festgelegt. | Portalprotokoll, Originaldatei und Abrufzeitpunkt. |
| Peppol oder Netzwerk | Sender überträgt über registrierte Teilnehmerkennungen. | Access Point und Routing werden vor Produktivstart getestet. | Transportquittung, Participant ID und Nutzdatenhash. |
| Unbekanntes Format | Datei lässt sich nicht sicher als vereinbartes E-Rechnungsformat identifizieren. | Sie wird isoliert, nicht freigegeben und beim Absender geklärt. | Sicherheitsbefund, Dateitypprüfung und Lieferantenkommunikation. |
E-Mail-Eingang
Lieferant sendet XML oder ZUGFeRD an die vereinbarte Rechnungsadresse. Für den Themenbereich E-Rechnung empfangen folgt daraus eine klare Arbeitsentscheidung: Ein überwachte Funktionspostfach nimmt an und führt Anhänge kontrolliert weiter. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Mail-Header, Originalanhang, Empfangszeit und Virenprüfung. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.
Portalabruf
Die Rechnung liegt nur im Lieferanten- oder Auftraggeberportal bereit. Für den Themenbereich E-Rechnung empfangen folgt daraus eine klare Arbeitsentscheidung: Abrufverantwortung, Frist und unveränderter Download werden festgelegt. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Portalprotokoll, Originaldatei und Abrufzeitpunkt. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.
Peppol oder Netzwerk
Sender überträgt über registrierte Teilnehmerkennungen. Für den Themenbereich E-Rechnung empfangen folgt daraus eine klare Arbeitsentscheidung: Access Point und Routing werden vor Produktivstart getestet. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Transportquittung, Participant ID und Nutzdatenhash. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.
Unbekanntes Format
Datei lässt sich nicht sicher als vereinbartes E-Rechnungsformat identifizieren. Für den Themenbereich E-Rechnung empfangen folgt daraus eine klare Arbeitsentscheidung: Sie wird isoliert, nicht freigegeben und beim Absender geklärt. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Sicherheitsbefund, Dateitypprüfung und Lieferantenkommunikation. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.
E-Rechnung empfangen Schritt für Schritt umsetzen
- Kanäle definierenBestimme Funktionspostfach, Portal und gegebenenfalls Netzwerk mit Vertretung.
- Original sichernSpeichere Transportdaten und Datei unverändert mit Hash.
- Sicherheit prüfenUntersuche Dateityp, Container, Anhänge, Links und Schadsoftware.
- Identität zuordnenVergleiche Absender, Verkäuferdaten, Bestellung und Bankverbindung.
- Format validierenErkenne Profil und prüfe Struktur, Regeln, Summen und Darstellungsabgleich.
- Fachlich freigebenGleiche Leistung, Menge, Preis, Steuer und Zahlung mit Auftrag und Empfang ab.
- ArchivierenVerbinde Original, Visualisierung, Bericht, Freigabe und Korrespondenz.
Kanäle definieren
Bestimme Funktionspostfach, Portal und gegebenenfalls Netzwerk mit Vertretung. Der Schritt ist abgeschlossen, sobald kein Eingang nur von einer privaten Mailbox abhängt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Unangekündigte Kanäle werden beobachtet, aber nicht still zum Standard. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Original sichern
Speichere Transportdaten und Datei unverändert mit Hash. Der Schritt ist abgeschlossen, sobald spätere Bearbeitung vom erhaltenen Original getrennt bleibt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Gefährliche Anhänge werden quarantänisiert statt gelöscht. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Sicherheit prüfen
Untersuche Dateityp, Container, Anhänge, Links und Schadsoftware. Der Schritt ist abgeschlossen, sobald nur technisch sichere Inhalte in die Fachverarbeitung gelangen. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Passwortgeschützte oder ausführbare Inhalte werden separat geklärt. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Identität zuordnen
Vergleiche Absender, Verkäuferdaten, Bestellung und Bankverbindung. Der Schritt ist abgeschlossen, sobald Lieferant und wirtschaftlicher Vorgang eindeutig feststehen. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Stammdatenänderungen werden über bekannten Kontakt bestätigt. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Format validieren
Erkenne Profil und prüfe Struktur, Regeln, Summen und Darstellungsabgleich. Der Schritt ist abgeschlossen, sobald ein nachvollziehbarer technischer Status vorliegt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Technische Fehler führen zur Beanstandung und nicht zur manuellen Buchung. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Fachlich freigeben
Gleiche Leistung, Menge, Preis, Steuer und Zahlung mit Auftrag und Empfang ab. Der Schritt ist abgeschlossen, sobald Zahlungsfreigabe von berechtigten Rollen erteilt wurde. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Streitige Positionen werden mit Sperrgrund dokumentiert. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
Archivieren
Verbinde Original, Visualisierung, Bericht, Freigabe und Korrespondenz. Der Schritt ist abgeschlossen, sobald der komplette Lebenszyklus auffindbar und unverändert bleibt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung empfangen ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Ein lokales Arbeits-PDF ersetzt die eingegangene XML nicht. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.
- Empfangsbereit: Funktionspostfach und Vertretung getestet
- XML-fähig: Dateien können ohne PDF visualisiert werden
- Sicher: Container und Anhänge landen vor Öffnung in der Prüfung
- Zugeordnet: Bestellung, Lieferant und Bankdaten werden abgeglichen
- Nachweisbar: Original, Hash, Prüfbericht und Freigabe bleiben verbunden
- Reaktionsfähig: Lieferanten erhalten einen klaren Ablehnungsgrund
Praxisbeispiele für E-Rechnung empfangen
UBL-XML per E-Mail
Ein Lieferant sendet nur eine XML ohne lesbare PDF-Ansicht. Die verantwortliche Person entscheidet deshalb: Das Postfach sichert das Original, der Viewer erzeugt eine Arbeitsansicht und der Validator prüft UBL. Im Ergebnis kann die Fachabteilung den Inhalt kontrollieren, ohne die XML zu ersetzen. Das Beispiel zeigt, dass E-Rechnung empfangen nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.
Geänderte Bankverbindung
Die E-Rechnung ist formal valide, nennt aber erstmals eine neue IBAN. Die verantwortliche Person entscheidet deshalb: Die Zahlung wird gesperrt und die Änderung über den bekannten Lieferantenkontakt bestätigt. Im Ergebnis verhindert die Identitätskontrolle eine Fehlzahlung jenseits technischer Validierung. Das Beispiel zeigt, dass E-Rechnung empfangen nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.
Doppelte Portal- und Mailrechnung
Dieselbe Belegnummer erreicht das Unternehmen über zwei Kanäle. Die verantwortliche Person entscheidet deshalb: Hash, Rechnungsnummer, Lieferant und Betrag werden als Dublettenmerkmale geprüft. Im Ergebnis entsteht nur ein prüfbarer Vorgang und keine doppelte Zahlung. Das Beispiel zeigt, dass E-Rechnung empfangen nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.
Typische Fehler bei E-Rechnung empfangen
Nur PDF-Anhänge akzeptieren
Eine reine XRechnung kann ohne PDF eintreffen und wird sonst fälschlich abgewiesen. Die fachliche Korrektur lautet: Der Eingang verarbeitet zulässige strukturierte XML. Als dauerhafte Kontrolle wird Formatmatrix und Testdateien regelmäßig geprüft. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung empfangen erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.
Persönliche Mailbox verwenden
Urlaub, Austritt oder Löschung unterbricht Nachweis und Fristen. Die fachliche Korrektur lautet: Ein Funktionskanal mit Vertretung wird eingerichtet. Als dauerhafte Kontrolle wird tägliches Monitoring und Eskalation protokolliert. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung empfangen erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.
Original in Viewer-Datei umwandeln
Das strukturierte empfangene Dokument geht als maßgeblicher Nachweis verloren. Die fachliche Korrektur lautet: Visualisierung bleibt abgeleitet und mit Original verbunden. Als dauerhafte Kontrolle wird Hash und Dateityp im Archiv sichtbar gehalten. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung empfangen erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.
Portalannahme mit Freigabe verwechseln
Technischer Eingang beweist weder Leistung noch richtige Bankdaten. Die fachliche Korrektur lautet: Technische und fachliche Status bleiben getrennt. Als dauerhafte Kontrolle wird Zahlung erst nach berechtigter Rechnungsfreigabe möglich. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung empfangen erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.
Freigabe-Checkliste: E-Rechnung empfangen
- Rechtsträger und Empfängerrolle eindeutig
- Rechnungs- und Leistungsdatum plausibel
- Bestell-, Vertrags- und Projektreferenzen vorhanden
- Steuerkategorie, Satz und Befreiungsgrund konsistent
- Summen auf Positions-, Steuer- und Dokumentebene stimmig
- Format, Profil und Syntax vom Empfänger akzeptiert
- aktuelle Validierungsartefakte verwendet
- Originaldatei, Prüfbericht und Versandnachweis verbunden
Die Checkliste wird nicht erst am Ende eines Monats abgearbeitet. Sie gehört an den einzelnen Vorgang, solange Rückfragen noch ohne aufwendige Rekonstruktion beantwortet werden können. Pflichtfelder verhindern einfache Lücken; fachliche Ausnahmen brauchen zusätzlich eine kurze Begründung. So bleibt E-Rechnung empfangen auch dann kontrollierbar, wenn mehrere Personen Eingang, Prüfung, Freigabe und Versand übernehmen.
Ein Vier-Augen-Prinzip ist besonders bei neuen Geschäftsfällen, geänderten Stammdaten und rechtlich sensiblen Entscheidungen sinnvoll. Wiederkehrende Standardfälle können nach dokumentierter Freigabe stärker automatisiert werden. Die Automatisierung übernimmt jedoch nur die freigegebene Regel. Sie darf eine fehlende Information nicht still durch einen plausibel wirkenden Standardwert ersetzen.
Dokumentation, Verantwortlichkeit und regelmäßige Pflege
Für E-Rechnung empfangen werden Eingangsdaten, Entscheidung, Ergebnis und Nachweis als zusammenhängender Vorgang geführt. Eine reine Dateiablage zeigt zwar das Endprodukt, aber nicht zwingend den Entscheidungsweg. Deshalb erhält jede Ausnahme einen Owner, einen Status und einen nächsten Schritt. Änderungen werden ergänzt oder versioniert; sie werden nicht durch stilles Überschreiben unsichtbar gemacht.
Die zugrunde liegende Arbeitsanweisung nennt außerdem ein Prüfdatum. Rechtliche Schwellen, technische Standards, externe Portale und interne Produktfunktionen können sich ändern. Bei der turnusmäßigen Kontrolle werden Primärquelle, tatsächlicher Prozess und veröffentlichte Aussage miteinander verglichen. Ändert sich nur eine Zahl, wird derselbe Intent-Owner aktualisiert; eine neue Jahres-URL ist dafür nicht erforderlich.
Nach dem Eingang folgen Validierung, Rechnungsprüfung und Freigabe. Die langfristige Originalerhaltung vertieft E-Rechnung archivieren.
E-Rechnung empfangen und die Produktgrenzen von Invoify
Invoify erzeugt Ausgangsrechnungen als PDF, XRechnung und ZUGFeRD. Strukturierte Exporte werden mit Mustang beziehungsweise den einschlägigen KoSIT-Regeln validiert. Die Belegbox kann manuell hochgeladene XRechnung-XML und ZUGFeRD-Dateien technisch prüfen und ausgewählte Kernwerte ohne OCR oder Sprachmodell auslesen. Ein überwachter Lieferanten-Eingang, eine Peppol-Zustellung, eine automatische fachliche Buchung und eine Zahlungsfreigabe eingehender E-Rechnungen sind dagegen nicht als Produktfunktion belegt.
Eine Funktion wird in diesem Leitfaden nur dann als Invoify-Funktion bezeichnet, wenn sie in der aktuellen Produktdokumentation belegt ist. Steuerliche Würdigung, rechtliche Einzelfallprüfung und externe Behördenverfahren bleiben bei den verantwortlichen Personen beziehungsweise deren Beratung. Diese Trennung verhindert, dass ein formal erzeugter Beleg mit einer fachlich freigegebenen Entscheidung verwechselt wird.
Offizielle Quellen und Prüfstand
Maßgeblich sind § 14 UStG, die BMF-FAQ zur E-Rechnung mit Stand März 2026 und das aktualisierte BMF-Schreiben zur obligatorischen E-Rechnung. Technische Referenzen liefern KoSIT/XStandards Einkauf, FeRD zu ZUGFeRD und die EU-Kommission zu EN 16931. Stand der Prüfung: 5. August 2026. Technische Regelstände und neue Format-Releases werden spätestens im Januar 2027 erneut geprüft.
E-Rechnung empfangen: E-Mail reicht gesetzlich, aber nicht als vollständiger Prozess
Das BMF-FAQ mit Stand März 2026 nennt keinen allgemeinen Pflichtkanal. E-Mail, Schnittstelle, zentraler Speicher, Datenträger oder Portal kommen in Betracht; der konkrete Übermittlungsweg wird zwischen den Parteien geklärt. Seit 1. Januar 2025 müssen inländische Unternehmen grundsätzlich E-Rechnungen empfangen können. Besondere B2G-Vorgaben und der nichtunternehmerische Bereich bleiben separat zu prüfen.
| Ebene | Gesetzliches beziehungsweise technisches Minimum | Belastbarer Betriebsstandard | Nachweis |
|---|---|---|---|
| Adresse | erreichbares E-Mail-Postfach kann genügen | Funktionsadresse mit Rollen, Vertretung und täglicher Kontrolle | Testmail, Zuständigkeit und Eskalationsregel |
| Datei | strukturierte Rechnung kann empfangen werden | Original vor Ansicht oder Bearbeitung sichern und hashen | Originaldatei, Mail-Header und Empfangszeit |
| Lesbarkeit | keine Pflicht zur komfortablen Bildansicht aus der XRechnung | freigegebener Viewer für UBL, CII und ZUGFeRD | reproduzierbare Sicht und Viewerstand |
| Prüfung | Empfang allein ist noch keine Anerkennung | Sicherheits-, Format-, Sach-, Steuer- und Zahlungsprüfung trennen | Statusfolge und verantwortliche Rollen |
| Fehler | keine automatische Annahmezusage | strukturierte Rückmeldung mit Regel-ID und Korrekturweg | Ablehnung, Kommunikation und neue Fassung |
| Aufbewahrung | strukturierter Teil unversehrt in ursprünglicher Form | Original, Prüfbericht, Freigabe und Korrekturbezug verbunden | Prüferexport und Wiederherstellungstest |
30-Minuten-Test für den E-Rechnungsempfang
Vor dem Serienbetrieb wird der gesamte Weg mit künstlichen Testdaten geprüft. Der Test enthält keine echten Kunden-, Lieferanten- oder Bankdaten. Er beantwortet nicht nur, ob eine Datei ankommt, sondern ob sie vom Eingang bis zur dokumentierten Entscheidung unverändert und auffindbar bleibt.
- Reine UBL-XRechnung sendenEine gültige XML an die vereinbarte Funktionsadresse schicken und Empfang, Originalspeicherung, Viewer sowie Validator protokollieren.
- CII-Ausprägung prüfenEine zweite gültige XRechnung in der unterstützten CII-Syntax einspielen und denselben Ablauf ohne manuelle Sonderroute durchlaufen.
- ZUGFeRD testenEin gültiges PDF/A-3 empfangen, eingebettete XML erkennen und Kernwerte zwischen XML und Sichtteil vergleichen.
- Fehlerdatei einspielenEine XML mit bekannter Regelverletzung verwenden; sie darf nicht als fachlich freigegeben oder zahlbar erscheinen.
- Dublettenweg testenDieselbe Datei über E-Mail und Portal simulieren und sicherstellen, dass nicht zwei Zahlungsvorgänge entstehen.
- Bankänderung simulierenFormal valide Datei mit neuer IBAN einspielen und die Rückfrage über einen bekannten Lieferantenkontakt auslösen.
- Export durchführenOriginale, Hashes, Berichte, Status und Kommunikation aus dem Testvorgang vollständig wieder ausgeben.
| Testfall | Erwartetes Ergebnis | Abbruchkriterium |
|---|---|---|
| gültige XML | technisch erkannt, visualisiert und in Sachprüfung übergeben | Datei wird nur als Download ohne prüfbare Sicht abgelegt |
| ungültige XML | gesperrt und mit konkretem Befund versehen | grüner Status trotz blockierendem Fehler |
| ZUGFeRD | Container und strukturierter Teil bleiben verbunden | nur Viewer-PDF oder Ausdruck wird erhalten |
| Dubletten | ein Vorgang mit zwei Transportnachweisen | zweite Zahlungsfreigabe entsteht |
| neue IBAN | manuelle Rückbestätigung über bekannten Kanal | Validatorerfolg löst Zahlung aus |
E-Rechnung in der Invoify-Belegbox manuell übernehmen
Die Invoify-Belegbox akzeptiert manuell hochgeladene PDF- und XML-Dateien. Dateisignatur und deklarierter Typ werden abgeglichen; byte-identische Uploads können über einen SHA-256-Hash als Dublette erkannt werden. Bei standalone UBL oder CII sowie bei ZUGFeRD extrahiert der technische Pfad nach erfolgreicher Validierung ausgewählte Kernwerte wie Rechnungsnummer, Aussteller, Betrag, Steuerbetrag, Währung und Rechnungsdatum ohne OCR oder Sprachmodell.
Diese Funktion ist ein manueller Ablage- und Erkennungsschritt. Invoify überwacht kein Lieferantenpostfach, ruft kein Portal ab, betreibt keinen Peppol-Empfang, ordnet keine Bestellung vollständig automatisch zu und bucht oder bezahlt die Rechnung nicht. Sicherheitsprüfung außerhalb des Uploads, sachliche Leistungskontrolle, Steuerentscheidung und Freigabe bleiben im Unternehmensprozess. ${REVIEW}
Häufige Fragen
Muss jedes Unternehmen E-Rechnungen empfangen können?
Für inländische B2B-Umsätze besteht seit 1. Januar 2025 grundsätzlich Empfangsbereitschaft; Ausnahmen und der konkrete Anwendungsbereich sind nach § 14 UStG und BMF-Verwaltung zu prüfen.
Reicht ein E-Mail-Postfach für den Empfang?
Technisch kann E-Mail genügen, wenn nichts anderes vereinbart ist. Organisatorisch braucht es zusätzlich Überwachung, Sicherheit, Zuordnung, Validierung, Prüfung und Archivierung.
Darf ich die XML in eine PDF umwandeln?
Eine Visualisierung für Menschen ist zulässig und hilfreich. Das eingegangene strukturierte Original muss jedoch erhalten und mit der Darstellung verbunden bleiben.
Empfängt Invoify Lieferanten-E-Rechnungen automatisch?
Ein spezialisierter Eingangskanal mit automatischer Lieferantenbuchung oder Peppol-Empfang ist nicht als aktuelle Invoify-Funktion belegt.
Muss eine E-Rechnung über Peppol empfangen werden?
Nein, das Umsatzsteuerrecht schreibt keinen allgemeinen Übertragungsweg vor. E-Mail, Schnittstelle, gemeinsamer Speicher oder Portal können in Betracht kommen. Öffentliche Auftraggeber oder Vertragspartner können für ihren Prozess jedoch einen konkreten Kanal verlangen.