Frankreich · Zurückweisung, Ablehnung und Ausnahmeprozess

Zurückgewiesene und abgelehnte E-Rechnungen in Frankreich bearbeiten

Unterscheiden Sie technische Zurückweisung und Käuferablehnung, sichern Sie Statusbelege und vermeiden Sie doppelte Einreichungen.

Kurzfazit:
  • Diagnosehinweis: Der Originalgrund und seine Quelle wiegen mehr als das Statusetikett allein.
  • Größtes Risiko: Ein ungeprüfter Neuversand erzeugt konkurrierende Belegversionen.
  • Erste Aktion: Statuspayload sichern und sämtliche Rechnungs- und Transportkennungen abgleichen.
Zuletzt geprüft: 13. August 2026Offizielle QuellenKlare ZusammenfassungPraktische Information, keine Rechtsberatung
Offizielle Quellen priorisiert
Prüfdatum sichtbar
Kostenloser Check ohne Registrierung

Was Sie wissen müssen

Leitfaden

1. Diagnose: „Rejetée“ ist nicht dasselbe wie „Refusée“

Offizieller Fakt: Der Anhang zum Lebenszyklusstatus der externen Spezifikationen v3.2 (Flux 6) führt für das Rechnungsobjekt unter anderem 200 Déposée, 210 Refusée, 212 Encaissée und 213 Rejetée auf. Bei Zurückweisung oder Ablehnung können ein Grundcode und eine Grundbezeichnung mitgegeben werden. Die Spezifikationen v3.2 datieren vom 30. April 2026. Empfohlene Kontrolle: Behandeln Sie 213 Rejetée zunächst als mögliches technisches, syntaktisches oder Routing-Ereignis und 210 Refusée als mögliche geschäftliche Käuferentscheidung – aber nie allein aufgrund dieser Kurzbeschreibung. Verbindlich sind die konkrete PA-Nachricht, der aktuelle Standard, der Vertrag und die fachliche Prüfung. Ein Factur-X-, UBL- oder CII-Fehler kann beispielsweise die technische Verarbeitung verhindern; eine strittige Menge oder Leistung kann dagegen einen Käuferkonflikt auslösen. Das ist operativ entscheidend: Wer einen Streit wie einen Formatfehler automatisch neu sendet, verschärft die Forderungslage; wer einen technischen Fehler als Storno deutet, riskiert fehlende Zustellung. Weder jeder Status Rejetée noch jeder Status Refusée löscht automatisch Forderung oder Ursprungsrechnung. Steuerliche und buchhalterische Folgen müssen fallbezogen beraten werden.

Leitfaden

2. Statusbeleg sichern und Kennungen korrelieren

Empfohlene Kontrolle: Frieren Sie vor jeder Änderung den Originalbeleg ein. Speichern Sie den vollständigen PA-Status mit Zeitstempel, Statusquelle, Statusnummer, Grundcode, Grundtext, technischer Message-ID, Rechnungsnummer, interner ERP-ID, Sender- und Empfängerkennung sowie SIREN/SIRET- und Routingbezug, soweit vorhanden. Ergänzen Sie Payload-Hash, Format, Version und Korrelations-ID. Stimmen Kennungen nicht überein, wird vor jeder Änderung recherchiert. Messbarer Nachweis: Für 100 % der negativen Ereignisse lässt sich innerhalb eines Vorgangs zeigen, welche Rechnung, welche Payload und welcher Empfänger betroffen waren. Offizieller Fakt: AFNOR XP Z12-012 betrifft Formate für Rechnung und Lebenszyklusstatus, XP Z12-013 die APIs und XP Z12-014 B2B-Anwendungsfälle. Diese Standards und die aktuelle PA-Dokumentation sind die Referenz für die technische Interpretation. PPF-Verzeichnisinformationen können beim Routing relevant sein; die konkrete Herkunft und Bedeutung des Ereignisses bleibt dennoch anhand der Nachricht zu prüfen.

Leitfaden

3. Entscheidungsbaum nach Fehlerklasse

Empfohlene Kontrolle: Klassifizieren Sie zuerst, handeln Sie danach. Syntax/Format: Prüfen Sie Schema, Pflichtfelder, Profil, Zeichensätze, Summen und eingebettete Daten bei Factur-X; korrigieren Sie nur den belegten Defekt. Identität/Routing: Vergleichen Sie Käuferkennung, SIREN/SIRET, Verzeichniseintrag, Empfangsadresse und PA-Zuordnung; bei Abweichung bestätigen Kunde oder Stammdatenverantwortliche das richtige Ziel. Duplikat: Suchen Sie nach gleicher Rechnungsnummer, Geschäftsschlüssel, Betrag, Datum, Payload-Hash und PA-Korrelation; liegt bereits eine verarbeitete Einreichung vor, stoppen Sie jeden Neuversand. Geschäftlicher Streit: Geben Sie den Fall an Debitoren, Vertrieb oder Vertragsverantwortliche und klären Sie Bestellung, Lieferung, Preis, Steuerangaben und Abnahme. Unbekannter Grund: Kein Raten und kein Auto-Retry; eröffnen Sie ein PA-Ticket mit Originalstatus und Korrelationsdaten. Entscheidungskriterien sind belegte Ursache, Statusquelle, Zustand der ersten Einreichung, zulässiger Übergang und fachliche Freigabe. Risiko: Eine falsche Klasse erzeugt Doppelbelege oder unkontrollierte Buchungsänderungen.

Leitfaden

4. Korrigieren oder erneut einreichen – mit Freigabesperre

Empfohlene Kontrolle: Definieren Sie ein Vier-Augen-Gate vor jeder Folgeaktion. Erstens muss der Zustand der ursprünglichen Übertragung geklärt sein. Zweitens wird dokumentiert, welche Felder oder geschäftlichen Angaben falsch sind. Drittens bestimmt die zuständige Fachrolle gemeinsam mit Steuer- oder Rechnungswesen, welches Korrekturinstrument im konkreten Fall zulässig ist. Viertens bestätigt die PA-Dokumentation die erlaubte technische Methode und den Bezug zum Original. Schreiben Sie daher weder pauschal „einfach erneut senden“ noch generell eine Gutschrift vor. Je nach Ursache, Vertragslage und Beratung sind mögliche Instrumente unterschiedlich zu behandeln. Offizieller Fakt: Die Spezifikationen definieren Formate, APIs und Anwendungsfälle; daraus folgt kein universeller Korrekturweg für jeden Geschäftsfall. Messbarer Nachweis: Jeder Folgebeleg enthält eine genehmigte Ursachenanalyse, den Bezug zum Ursprung, den Verantwortlichen und die Entscheidung „korrigieren“, „anfechten“, „nicht erneut senden“ oder „weiter untersuchen“. Die ehemalige Bezeichnung PDP sollte nur historisch verwendet werden; aktuell heißt der Dienstleister plateforme agréée (PA).

Leitfaden

5. Doppelungen durch Idempotenz und Abstimmung verhindern

Empfohlene Kontrolle: Setzen Sie im ERP und an der PA-Schnittstelle einen stabilen Geschäftsschlüssel ein, etwa aus Verkäufer, Käufer, Rechnungsnummer und Belegart, ergänzt um eine technische Idempotenz-ID je beabsichtigtem Übertragungsvorgang. Ein Timeout darf keinen blinden zweiten Versand auslösen. Fragen Sie zunächst den PA-Status über die vorhandene Korrelations-ID ab und gleichen Sie Versandjournal, PA-Ereignisse und Debitorenbuchung ab. Payload-Hashes erkennen identische Dateien, ersetzen aber nicht die fachliche Duplikatprüfung. Sperren Sie parallele Wiederholungen aus ERP, Middleware und Portal. Beispiel: Das ERP erhält keine synchrone Antwort, die PA hat den Beleg aber bereits angenommen. Ein automatischer Neuversand mit neuer Message-ID könnte zwei technische Vorgänge erzeugen. Die sichere Reaktion ist Statusklärung, nicht Wiederholung. Kennzahlen: Zahl blockierter Duplikatversuche, negative Ereignisse ohne Korrelation, Fälle mit mehreren aktiven Versionen und Zeit bis zur Abstimmung. Zielwerte sollten intern risikobasiert festgelegt werden; es gibt hier keine erfundene universelle interne Reaktionsfrist oder automatische Wiederholungsregel.

Leitfaden

6. Debitorenprozess: Kunde, Forderung und Eskalation steuern

Empfohlene Kontrolle: Weisen Sie jedem Ausnahmefall genau eine verantwortliche Person zu. Technik verantwortet Transport- und Schemaanalyse, Debitoren die Forderungsakte, Vertrieb oder Vertragsmanagement die Kundenklärung und Steuer-/Rechnungswesen die fachliche Behandlung. Interne Reaktionsuhren sind sinnvolle Kontrollen, aber keine behaupteten gesetzlichen Fristen: zum Beispiel „innerhalb eines Arbeitstags triagieren“ oder „ungeklärte Käuferablehnung nach zwei Arbeitstagen eskalieren“, angepasst an Ihr Risiko. Die Kundenanfrage nennt Rechnungsnummer, Streitpunkt und benötigte Belege, ohne die Forderung vorschnell als erledigt darzustellen. Halten Sie Zustell-, Streit- und Buchungsstatus getrennt fest. Messbarer Nachweis: Verantwortliche, nächste Aktion, internes Zieldatum, letzte Kundenkommunikation und Entscheidung sind im Ticket sichtbar. Risiko: Wenn der Vertrieb außerhalb des Vorgangs eine neue Datei verspricht, während Debitoren bereits eine Korrektur vorbereiten, entstehen widersprüchliche Versionen. Der kontrollierte Prozess erlaubt auch eine begründete Anfechtung einer Refusée-Meldung, sofern Vertrag, Leistung und Nachweise dies tragen; er unterstellt aber keine automatische Wirkung auf die Schuld.

Leitfaden

7. Kreditorenprozess: Ablehnung nachvollziehbar begründen

Empfohlene Kontrolle: Käufer sollten Refusée nicht als allgemeine Rückfragetaste verwenden. Vor einer Ablehnung prüft die zuständige Rolle, ob der Grund tatsächlich geschäftlich ist, ob Bestellung, Wareneingang, Leistung, Preis, Steuerdaten oder Vertragsreferenz abweichen und ob ein weniger einschneidender Klärungsweg vorgesehen ist. Die Begründung muss konkret genug sein, damit der Lieferant den Streitpunkt versteht, darf aber keine vertraulichen Daten unnötig offenlegen. Erfassen Sie Prüfer, Beleggrundlage, Grundtext, Zeitpunkt und PA-Korrelation. Eine technisch nicht lesbare Rechnung gehört zunächst in die technische Diagnose; ein lesbarer Beleg mit bestrittenem Leistungsumfang in die fachliche Prüfung. Offizieller Fakt: Flux 6 erlaubt bei Ablehnung oder Zurückweisung Grundcode und Grundbezeichnung; daraus ergibt sich nicht, dass jeder frei formulierte Grund zulässig oder jeder Statusübergang möglich ist. Prüfen Sie deshalb aktuelle Spezifikationen, PA-Regeln und Vertrag. Messbarer Nachweis: Stichproben zeigen, dass jede Käuferablehnung durch Bestellung, Wareneingang, Vertrag, Korrespondenz oder fachliche Freigabe gestützt ist. Risiko: pauschale Texte wie „Rechnung falsch“ verlängern die Klärung und erschweren eine spätere Prüfung.

Leitfaden

8. Beispielvorfall: vom Alarm bis zum Abschluss

Beispiel: Um 09:12 meldet die PA für Rechnung FR-8472 den Status 213 Rejetée mit Grundtext und Korrelations-ID. Das Monitoring eröffnet automatisch einen Fall, versendet aber keine zweite Rechnung. Um 09:25 sichert der technische Verantwortliche Statuspayload, UBL-Datei, Hash, Message-ID und ERP-ID. Die Korrelation zeigt eindeutig auf FR-8472; in der PA-Historie existiert keine erfolgreich weiterverarbeitete Parallelversion. Um 10:05 weist eine Validierung einen konkreten Formatfehler nach. Debitoren bestätigen, dass kein kaufmännischer Kundenstreit gemeldet wurde. Rechnungswesen bewertet anhand des Buchungsstands und mit zuständiger Beratung, welche fachliche Korrektur erforderlich ist; Technik prüft die von der PA vorgesehene Übertragungsmethode. Nach Vier-Augen-Freigabe wird genau eine kontrollierte Folgeaktion ausgeführt. Anschließend werden neuer Status, Verknüpfung zum Ursprung und Empfangsnachweis gespeichert. Der Fall wird erst geschlossen, nachdem ERP, Versandjournal und PA-Historie übereinstimmen. Abschlussbelege: Originalstatus, Fehlernachweis, Freigabe, Versionen, Folgekorrelation, finaler Status und Abstimmungsprotokoll. Wäre stattdessen 210 Refusée mit einem Preisstreit eingegangen, hätte der Verantwortliche nicht die XML-Datei repariert, sondern Vertrag und Bestellung mit dem Käufer geklärt. Dieses Beispiel ist eine empfohlene Arbeitsweise, keine Aussage über universelle Statusfolgen oder steuerliche Wirkung.

Leitfaden

9. Dashboard, Runbook, Tests und Sieben-Tage-Plan

Offizieller Fakt: Betroffene Unternehmen müssen nach DGFiP-Angaben ab 1. September 2026 eine plateforme agréée nutzen, um E-Rechnungen zu senden und zu empfangen sowie Transaktions- und Zahlungsdaten zu übermitteln; der konkrete Reformkalender ist auf den offiziellen Seiten zu prüfen. Empfohlene Kontrolle: Das Dashboard trennt Rejetée und Refusée, zeigt Alter, Verantwortliche, Ursache, fehlende Korrelation, Duplikatrisiko und Abschlussbeleg. Stufen Sie Fälle intern etwa als kritisch bei Doppelbuchungsrisiko oder massenhaftem Routingausfall, hoch bei blockierter umsatzrelevanter Rechnung und normal bei kontrollierter Einzelklärung ein; dies sind keine offiziellen Schweregrade. Das Runbook enthält Entscheidungsbaum, Rollen, Beweisliste, PA-Eskalation und Wiederanlauf-Gate. Produktivstart-Tests umfassen ungültiges Schema, falsche Identität, unbekanntes Routing, Timeout nach Annahme, identischen Wiederholungsversuch, Käuferstreit und unbekannten Grund. Häufige Fehler sind blindes Resenden, Vermischung von Technik und Streit, Überschreiben des Originals und Schließen ohne Abstimmung. Sieben-Tage-Plan: Tag 1 Statusquellen und Rollen inventarisieren; Tag 2 Kennungen und Journalfelder mappen; Tag 3 Klassifikation und Freigaben definieren; Tag 4 Idempotenz und Sperren testen; Tag 5 PA-, ERP- und Fachtests durchführen; Tag 6 Dashboard, Alarmierung und Stichproben einrichten; Tag 7 einen Tischtest mit Debitoren, Kreditoren, Technik und Beratung durchführen und Lücken dokumentiert schließen.

Leitfaden

So nutzen Sie diese Seite

Nutzen Sie diese Seite, um zu entscheiden, ob Workflow für zurückgewiesene oder vom Käufer abgelehnte französische E-Rechnungen Ihren Frankreich-Workflow betrifft und welche Nachweise noch fehlen. Beginnen Sie mit französische Empfangs- und Ausgabefristen, zugelassene Plattform, Factur-X, UBL oder CII und testen Sie eine strukturierte Rechnung empfangen und eine Kundenrechnung ausstellen, bevor Sie Software vergleichen.

Leitfaden

Daten, Entitäten und Begriffe

Für Workflow für zurückgewiesene oder vom Käufer abgelehnte französische E-Rechnungen sind Workflow für zurückgewiesene oder vom Käufer abgelehnte französische E-Rechnungen, Frankreich, französische Empfangs- und Ausgabefristen, zugelassene Plattform, Factur-X, UBL oder CII, E-Reporting, SIREN- und Umsatzsteuerdaten wichtig. Bereinigen Sie diese Felder in Kunden-, Lieferanten-, Steuer- und Buchhaltungsdaten vor dem Rollout.

Leitfaden

Software-Nachweis verlangen

Bitten Sie Anbieter, den vollständigen Workflow mit Ihren Rechnungsbeispielen, Nutzerrollen und Ausnahmen demonstrieren mit Ihren Beispielen zu zeigen. Die Demo sollte eine strukturierte Rechnung empfangen, eine Kundenrechnung ausstellen, einen E-Reporting-Fall testen, eine Gutschrift korrigieren abdecken und erklären, wer Fehler, Korrekturen, Archiv und Buchhaltung übergibt.

Leitfaden

Nachweise vor dem Rollout

Speichern Sie offizielle Quellen, Screenshots, Testrechnungen und Entscheidungsgrund für Workflow für zurückgewiesene oder vom Käufer abgelehnte französische E-Rechnungen. Die Akte sollte zeigen, wie französische Empfangs- und Ausgabefristen, zugelassene Plattform, Factur-X, UBL oder CII, E-Reporting geprüft wurden.

Leitfaden

Entscheidungspunkt

Schließen Sie das Thema erst ab, wenn jemand die operative Vorbereitung dieses Themas für Frankreich erklären, den Workflow-Verantwortlichen nennen, ein getestetes Rechnungsszenario zeigen und den Fehler sich auf eine allgemeine Compliance-Zusage zu verlassen, ohne den realen Workflow zu testen vermeiden kann.

Checkliste

Originale PA-Statusnachricht samt Zeitstempel, Grund und Quelle unverändert archivieren.

Rechnungsnummer, ERP-ID, Message-ID, Korrelations-ID und Empfängerkennung eindeutig verbinden.

Rejetée und Refusée in Monitoring, Tickets und Verantwortlichkeiten getrennt führen.

Ursache als Format, Identität/Routing, Duplikat, Geschäftsstreit oder unbekannt klassifizieren.

Vor jeder Folgeaktion den Verarbeitungszustand der ersten Einreichung bei der PA klären.

Korrekturweg durch Rechnungswesen und gegebenenfalls Steuer- oder Rechtsberatung freigeben lassen.

Blindes Auto-Retry durch Idempotenzschlüssel, Sperren und Statusabfrage verhindern.

Kunden- oder Lieferantenkommunikation mit Belegen, Verantwortliche und nächstem Termin dokumentieren.

ERP-Journal, PA-Historie und Buchungsstand vor dem Schließen vollständig abstimmen.

Runbook mit negativen Tests, unbekannten Gründen und Duplikatszenarien regelmäßig proben.

Häufige Fragen

Was ist der praktische Unterschied zwischen Rejetée und Refusée?

Rejetée kann auf ein technisches, syntaktisches oder Routingproblem hindeuten; Refusée kann eine geschäftliche Ablehnung durch den Käufer bezeichnen. Das ist nur eine Diagnosehilfe. Maßgeblich sind Originalnachricht, Grund, Statusquelle, aktuelle Spezifikationen, PA-Regeln und Geschäftskontext.

Darf eine zurückgewiesene E-Rechnung sofort erneut gesendet werden?

Nicht blind. Klären Sie zuerst, ob die PA die ursprüngliche Einreichung verarbeitet hat, welcher Fehler belegt ist und welche Folgeaktion erlaubt ist. Ein Timeout oder negativer Status allein rechtfertigt keine unkontrollierte zweite Einreichung.

Ist die Forderung bei Refusée oder Rejetée automatisch storniert?

Nein, eine solche pauschale Aussage wäre unsicher. Status, zivilrechtliche Forderung, steuerliche Behandlung und Buchungsstand sind getrennt zu bewerten. Prüfen Sie Vertrag, Nachweise und den konkreten Fall mit den zuständigen Beratern.

Wo finde ich den konkreten Fehlergrund?

Suchen Sie in der vollständigen PA-Statusnachricht nach Grundcode und Grundbezeichnung und verknüpfen Sie diese mit Korrelations- und Rechnungskennung. Fehlt eine verständliche Erklärung, eröffnen Sie ein PA-Ticket mit Originalpayload und technischen Referenzen, statt den Grund zu erraten.

Wer sollte einen negativen Status bearbeiten?

Eine benannte fallverantwortliche Person koordiniert. Technik analysiert Schema und Transport, Debitoren oder Kreditoren führen den Belegprozess, Vertragsverantwortliche klären Streitpunkte und Rechnungswesen beziehungsweise Beratung entscheidet über die fachliche und steuerliche Behandlung.

Wie verhindern ERP und PA doppelte Rechnungen?

Nutzen Sie stabile Geschäftsschlüssel, technische Idempotenz-IDs, Payload-Hashes, Versandsperren und eine Statusabfrage vor Wiederholung. Stimmen Sie ERP, Middleware und PA-Historie ab, da ein fehlendes synchrones Ergebnis nicht beweist, dass die erste Übertragung gescheitert ist.

Welche Nachweise gehören in einen abgeschlossenen Ausnahmefall?

Mindestens Originalstatus, Rechnungsversion und Hash, relevante Kennungen, Ursachenanalyse, fachliche Freigabe, Kommunikation, ausgeführte Folgeaktion, finaler PA-Nachweis und die Abstimmung mit dem ERP. So bleibt die Entscheidung auch später rekonstruierbar.

Welche Standards sind für Status und Schnittstellen relevant?

DGFiP nennt AFNOR XP Z12-012 für Rechnungs- und Lebenszyklusstatusformate, XP Z12-013 für APIs und XP Z12-014 für B2B-Anwendungsfälle. Arbeiten Sie mit der aktuellen Fassung und der Dokumentation Ihrer plateforme agréée; die frühere Bezeichnung PDP ist nur noch ein historisches Synonym.

Was zuerst für Workflow für zurückgewiesene oder vom Käufer abgelehnte französische E-Rechnungen testen?

Beginnen Sie mit eine strukturierte Rechnung empfangen, eine Kundenrechnung ausstellen, einen E-Reporting-Fall testen, weil diese Szenarien die Praxistauglichkeit zeigen.

Was ist das Hauptrisiko?

Das Hauptrisiko ist sich auf eine allgemeine Compliance-Zusage zu verlassen, ohne den realen Workflow zu testen.

Wichtige Regeln, Formate und Begriffe

Europäische KommissionEN 16931Richtlinie 2014/55/EUstrukturierte elektronische RechnungWorkflow für zurückgewiesene oder vom Käufer abgelehnte französische E-RechnungenFrankreich

Weiterlesen

Offizielle Quellen

Wir priorisieren offizielle Regierungs- und EU-Quellen, soweit verfügbar, und zeigen Prüfdatumsangaben sichtbar an.