E-Invoice Finder
Menu
Länder Software Fristen Leitfäden Check Pflicht prüfen
ENFRDEPLNL
Unabhängiger Software-Abnahmetestplan 2026

So testen Sie E-Reporting-Software für Frankreich vor dem Einführung

Praxisnaher Testplan für französische E-Reporting-Software: B2C-Aggregate, Auslandsumsätze, Zahlungsdaten, Korrekturen, PA-Anbindung und Audit Trail prüfen.

Kurzfazit:
  • Bestehen müssen vollständige Prozessketten, nicht nur vorbereitete Bildschirmmasken.
  • Zahlungsereignisse und Fehlerkorrekturen sind ebenso wichtig wie Transaktionsdaten.
  • Eine exportierbare Ende-zu-Ende-Spur entscheidet über die spätere Prüfbarkeit.
Report ansehenOffizielle Quellen
Zuletzt geprüft: 24. Juli 2026Offizielle QuellenKlare ZusammenfassungPraktische Information, keine Rechtsberatung
Offizielle Quellen priorisiert
Prüfdatum sichtbar
Kostenloser Check ohne Registrierung

Was Sie wissen müssen

Leitfaden

1. Demo-Versprechen in belastbare Nachweise verwandeln

Die französische Reform umfasst drei unterschiedliche Bereiche: inländische B2B-E-Rechnungen, das E-Reporting von Transaktionen außerhalb dieses Rechnungskreises und das E-Reporting von Zahlungseingängen bei Umsätzen, deren VAT bei Vereinnahmung entsteht. Eine Demo muss deshalb zeigen, wie die Lösung einen Geschäftsvorgang klassifiziert, welche Daten sie an eine zugelassene Plattform (plateforme agréée, PA) übergibt und wie Rückmeldungen bis in das führende System gelangen. Ab 1. September 2026 müssen alle Unternehmen E-Rechnungen empfangen können. Große und mittlere Unternehmen müssen ab diesem Datum auch ausstellen und E-Reporting erfüllen; kleine und Kleinstunternehmen erhalten dafür grundsätzlich bis 1. September 2027 Zeit. Diese Stufen ändern nicht die Testmethode: Prüfen Sie frühzeitig den vollständigen Datenfluss zwischen ERP, Billing, POS oder Kassensystem, Buchhaltung, API und PA. Eine lediglich kompatible Lösung darf die regulierten Übermittlungen nicht selbst durchführen, wenn sie dafür keine Zulassung besitzt. Der Anbieter sollte daher klar belegen, ob sein Produkt selbst PA ist, über welche PA es angebunden wird und wer Fehler, Versionsänderungen sowie steuerliche Rückmeldungen betreibt. • Fordern Sie eine Live-Ausführung mit Ihren Testdaten statt einer Folienpräsentation oder eines aufgezeichneten Happy Paths. • Lassen Sie jeden Test vom Ursprungssystem bis zur PA-Rückmeldung und zur Buchhaltungsabstimmung verfolgen. • Verlangen Sie für Behauptungen zu Zulassung oder Registrierung einen aktuellen Verweis auf die DGFiP-Informationen und die Plattformliste. • Bewerten Sie fachliche Richtigkeit, technische Übertragung, Bedienbarkeit und Nachweisführung getrennt.

Leitfaden

2. Vorbereitung vor der Software-Demo

Stellen Sie vor dem Termin eine kleine, anonymisierte Testdatenbasis zusammen, die Ihre tatsächlichen Systeme und Ausnahmen widerspiegelt. Dazu gehören Mehrwertsteuersätze, Kundentypen, SIREN beziehungsweise ausländische Identifikatoren, Währungen, Leistungsarten, Zahlungsbedingungen, Kassenabschlüsse und typische Korrekturgründe. Der Anbieter sollte diese Daten vor der Demo nicht so stark bereinigen, dass problematische Fälle verschwinden. Dokumentieren Sie für jeden Test den fachlichen Eigentümer, das führende System, die erwartete Klassifikation, die erwarteten Felder, die verantwortliche PA und den akzeptierten Nachweis. Legen Sie außerdem fest, welche Abweichungen einen sofortigen Fehlschlag bedeuten und welche lediglich als offene Konfiguration mit Termin, Eigentümer und Retest akzeptiert werden. Prüfen Sie die aktuelle Spezifikation mit Ihrer Beratung und der vorgesehenen PA. Übermittlungsrhythmus, Pflichtfelder und Datenzuordnung können vom Umsatzsteuerregime, Transaktionstyp, geltenden technischen Stand und der konkreten Plattformkonfiguration abhängen. • Erstellen Sie getrennte Testmandanten für ERP, Fakturierung, POS oder Kasse, Buchhaltung und PA-Sandbox. • Definieren Sie Testkunden für inländische Verbraucher, französische Unternehmen, EU-Unternehmen und Drittlandsunternehmen. • Hinterlegen Sie mehrere Mehrwertsteuersätze sowie steuerfreie, Reverse-Charge- und VAT-on-Debits-Fälle, soweit für Ihr Geschäft relevant. • Bereiten Sie Rechnungen, Kassenumsätze, Anzahlungen, Teilzahlungen, Gutschriften, Stornos und Rückerstattungen vor. • Vereinbaren Sie vorab, welche Protokolle, Payloads, Statushistorien und Exporte der Anbieter zeigen muss. • Entfernen oder pseudonymisieren Sie personenbezogene Echtdaten; für B2C-Aggregate werden grundsätzlich keine persönlichen Kundendaten erwartet. • Erfassen Sie Versionen von Schnittstellen, Mapping, PA-Konnektor und Testumgebung, damit Ergebnisse reproduzierbar bleiben.

Leitfaden

3. Abnahmekriterien für einen belastbaren Pass oder Fail

Ein Test gilt nur dann als bestanden, wenn Eingabe, Klassifikation, Ausgangsdaten, technische Bestätigung und Abstimmung zusammenpassen. Eine korrekte Bildschirmansicht genügt nicht, wenn die an die PA übermittelte Nutzlast unvollständig ist oder eine Ablehnung nicht in ERP beziehungsweise Buchhaltung zurückkehrt. Nutzen Sie drei Ergebnisstufen: bestanden, fehlgeschlagen oder bedingt bestanden. Ein bedingtes Ergebnis benötigt eine präzise Lücke, einen verantwortlichen Eigentümer, einen Zieltermin und einen verpflichtenden Retest. Allgemeine Aussagen wie im Projekt konfigurierbar oder über eine Standardschnittstelle möglich sind kein Abnahmenachweis. • Scope: Der Vorgang wird nachvollziehbar als E-Rechnung, Transaktions-E-Reporting, Zahlungs-E-Reporting oder begründete Ausnahme geroutet. • Daten: Pflicht- und Referenzfelder stimmen mit Quelle, Mapping und aktueller PA-Spezifikation überein. • Übertragung: Die PA bestätigt Annahme, Verarbeitung oder Ablehnung mit korrelierbarer technischer Referenz. • Rückweg: Status und Fehler gelangen ohne manuelles Suchen zum zuständigen Team und möglichst in das Ursprungssystem. • Kontrolle: Summen, VAT-Beträge, Währungen, Zeiträume und Belegbeziehungen sind abstimmbar. • Nachweis: Eingabe, Transformation, Versand, Antwort, Korrektur und finaler Status lassen sich exportieren.

Leitfaden

4. Tests 1 bis 3: B2C-Aggregate und ausländische Geschäftskunden

Die ersten Tests prüfen, ob die Software einzelne operative Daten korrekt in meldefähige Transaktionsdaten überführt. Bei B2C-Verkäufen werden Daten grundsätzlich täglich und nach Mehrwertsteuersatz aggregiert; personenbezogene Kundendaten werden dabei nicht erwartet. Der Test muss dennoch die genaue Quelle, den Geschäftstag, Rückerstattungen und die Abstimmung mit POS oder Buchhaltung sichtbar machen. Bei ausländischen Geschäftskunden darf das Datenmodell nicht blind eine französische SIREN verlangen. Je nach Fall kann eine ausländische VAT- oder Unternehmensidentifikation verwendet werden. Währung, Umrechnung und steuerliche Klassifikation müssen getrennt geprüft werden, weil ein technisch akzeptiertes Feld noch keine fachlich korrekte Behandlung beweist. • Test 1 – Inländisches B2C-Tagesaggregat über mehrere Mehrwertsteuersätze. Eingabe: POS-Umsätze eines Geschäftstags mit mindestens zwei Mehrwertsteuersätzen und einer Rückerstattung. Erwartet: nach Mehrwertsteuersatz getrennte Tagesaggregate mit korrektem Netto-, VAT- und Bruttobezug sowie eindeutiger Periodenreferenz. Nachweis: Kassenjournal, Mapping, PA-Payload, Annahmestatus und Summenabgleich. • Test 2 – B2C-Verkäufe ohne Einzelrechnung. Eingabe: Kassen- oder Commerce-Totals, für die keine Kundenrechnung erstellt wurde. Erwartet: meldefähiges Aggregat ohne erfundene Rechnungsnummer und ohne persönliche Kundendaten; fehlende oder verspätete Quellsummen müssen sichtbar blockieren oder gewarnt werden. Nachweis: Tagesabschluss, Transformationsprotokoll, Warnungen, Übertragungsreferenz und Buchhaltungsabgleich. • Test 3 – Ausländischer B2B-Kunde mit Fremdwährung. Eingabe: Geschäftskunde ohne SIREN, aber mit ausländischer VAT- oder Unternehmensidentifikation, Rechnung in Fremdwährung und dokumentiertem Umrechnungskurs. Erwartet: akzeptierte ausländische Identifikation, erhaltene Originalwährung und nachvollziehbare Berichtswerte. Nachweis: Stammdatensatz, Quelldokument, Kursquelle beziehungsweise Konfiguration, Nutzlast, PA-Antwort und Export.

Leitfaden

5. Tests 4 bis 6: Export, Leistungsumsatz und Teilzahlungen

Ausfuhr- und innergemeinschaftliche Vorgänge benötigen eine belastbare Klassifikation, damit sie nicht versehentlich als inländische B2B-E-Rechnung oder als gewöhnlicher B2C-Umsatz verarbeitet werden. Testen Sie deshalb nicht nur das Ergebnis, sondern auch die Regeln, Belege und Stammdaten, welche die Zuordnung steuern. Zahlungs-E-Reporting greift unabhängig vom Kundentyp, wenn VAT bei Vereinnahmung entsteht, typischerweise bei bestimmten Dienstleistungen ohne Wahl der VAT-on-Debits-Regel und ohne einschlägiges Reverse Charge. Die DGFiP nennt insbesondere Datum und vereinnahmten Betrag, aufgeteilt nach Mehrwertsteuersatz; bei einer E-Rechnung kann ein Status wie encaissée, also eingegangen beziehungsweise bezahlt, die Rechnung ergänzen. • Test 4 – Export und innergemeinschaftliche Lieferung oder Leistung. Eingabe: je ein plausibler EU- und Drittlandsfall mit Zielland, ausländischer Identifikation, VAT-Behandlung und Belegreferenzen. Erwartet: unterschiedliche, begründete Klassifikation und korrektes E-Reporting-Routing statt eines pauschalen Auslandscodes. Nachweis: Entscheidungsregel, Stammdaten, Ausgangsdatensatz, PA-Status und fachliche Freigabe. • Test 5 – Inländische Dienstleistungsrechnung mit VAT bei Vereinnahmung. Eingabe: französischer Leistungsumsatz ohne VAT-on-Debits-Wahl und ohne Reverse Charge, anschließend vollständiger Zahlungseingang. Erwartet: korrekte Transaktionsbehandlung plus separates Zahlungsereignis mit Einzugsdatum und Betrag je Mehrwertsteuersatz oder ergänzendem encaissée-Status. Nachweis: Rechnung, Steuerkennzeichen, Bank- oder Debitorenbuchung, Zahlungspayload und Rückmeldung. • Test 6 – Teilzahlungen an verschiedenen Tagen. Eingabe: eine offene Dienstleistungsrechnung, die in mindestens zwei Beträgen an unterschiedlichen Daten beglichen wird. Erwartet: zwei getrennte Zahlungsereignisse ohne vorzeitige Vollbezahlt-Markierung; Restbetrag und VAT-Aufteilung bleiben nachvollziehbar. Nachweis: Offene-Posten-Historie, Zahlungszuordnung, beide Nutzlasten, PA-Referenzen und finaler Saldo.

Leitfaden

6. Tests 7 bis 10: Anzahlungen, Korrekturen, Ausnahmen und Fehlerresistenz

Die meisten Demo-Systeme wirken im geradlinigen Rechnungsfall überzeugend. Größere Risiken entstehen bei Anzahlungen, rückwirkenden Korrekturen, Ausschlussregeln und technischen Wiederholungen. Diese Fälle sollten mit denselben Belegen und Referenzen getestet werden, die später im Tagesgeschäft zur Ursachenanalyse benötigt werden. Für den letzten Test sollte der Anbieter absichtlich eine Ablehnung erzeugen und anschließend sowohl Korrektur als auch sichere Wiederholung zeigen. Entscheidend ist, dass ein erneuter API-Aufruf oder Batch-Restart keine doppelte Meldung erzeugt und dass der finale Datenbestand vollständig mit den Quellen abgestimmt und exportiert werden kann. • Test 7 – Anzahlung oder Vorauszahlung. Eingabe: Zahlung vor endgültiger Rechnung, danach Schlussrechnung mit eindeutiger Verrechnung. Erwartet: richtige Behandlung von Zahlungsdatum, Betrag, Mehrwertsteuersätzen und Belegbeziehung ohne Doppelzählung in Transaktions- oder Zahlungsdaten. Nachweis: Anzahlungsbeleg, Bankbuchung, Schlussrechnung, Verknüpfungen, PA-Payloads und Abstimmung. • Test 8 – Gutschrift, Rückerstattung und Storno. Eingabe: ursprünglicher Umsatz, Teilgutschrift, Geldrückzahlung und separater vollständiger Stornofall. Erwartet: korrekte Referenzen zum Ursprungsbeleg, Vorzeichen, VAT-Auswirkung und unterscheidbare Statusfolgen. Nachweis: Belegkette, Buchungen, Korrekturdatensätze, PA-Antworten und aktualisierte Summen. • Test 9 – VAT on debits und Reverse Charge. Eingabe: ein Umsatz mit wirksamer VAT-on-Debits-Konfiguration sowie ein Reverse-Charge-Fall. Erwartet: Zahlungsereignisse werden nicht allein wegen eines Zahlungseingangs fälschlich in den Vereinnahmungsprozess geschickt; die alternative Behandlung ist regelbasiert dokumentiert. Nachweis: Steuerkennzeichen, Entscheidungslog, Ausgangsdatensatz oder begründete Nichtübermittlung und fachliche Freigabe. • Test 10 – Abgelehnter, korrigierter und erneut gesendeter Batch. Eingabe: Batch mit absichtlich ungültigem Feld, danach Korrektur, erneuter Versand und Wiederholung desselben API-Aufrufs. Erwartet: verständliche Ablehnung, gezielte Korrektur, idempotente Verarbeitung ohne Duplikat sowie vollständige Abstimmung. Nachweis: Fehlercode, Nutzerbenachrichtigung, Versionshistorie, technische Korrelations- und Idempotenzschlüssel, finaler PA-Status, Abstimmbericht und exportierbarer Audit Trail.

Leitfaden

7. Illustratives Zahlenbeispiel für Tagesumsatz und Zahlung

Angenommen, ein POS meldet für einen Geschäftstag 1.200 Euro brutto zu 20 Prozent VAT und 550 Euro brutto zu 10 Prozent VAT. Zusätzlich wird ein früherer Verkauf zu 20 Prozent mit 120 Euro brutto erstattet. Rein illustrativ ergäbe die operative Testgrundlage für den 20-Prozent-Bereich 1.080 Euro brutto nach Erstattung und für den 10-Prozent-Bereich 550 Euro brutto. Die Software muss zeigen, wie sie daraus die nach Mehrwertsteuersatz getrennten Berichtswerte bildet und Rundungen behandelt. Für einen separaten Dienstleistungsfall nehmen wir eine Rechnung über 1.200 Euro brutto an, deren VAT bei Vereinnahmung entsteht. Der Kunde zahlt beispielhaft 600 Euro am 8. Oktober und 600 Euro am 22. Oktober. Erwartet werden zwei zuordenbare Zahlungsvorgänge und kein vollständiger encaissée-Status nach der ersten Zahlung. Diese Zahlen dienen nur als Testdaten und bestimmen nicht universell die rechtliche Behandlung, Berechnungsbasis oder Meldefrist. Lassen Sie VAT-Regeln, Umrechnung, Rundung, Berichtsfrequenz und endgültiges Mapping anhand Ihrer tatsächlichen Fälle, der aktuellen DGFiP-Dokumentation und der vorgesehenen PA validieren. • Stimmen Sie POS-Bruttosumme, Rückerstattung und E-Reporting-Aggregat auf denselben Geschäftstag ab. • Prüfen Sie, ob Netto- und VAT-Werte aus den Quelldaten stammen oder transparent berechnet werden. • Kontrollieren Sie Rundungsdifferenzen auf Einzel-, Mehrwertsteuersatz- und Tagesebene. • Ordnen Sie jede Teilzahlung eindeutig der Rechnung und dem tatsächlichen Einzugsdatum zu. • Exportieren Sie Ursprungswerte, Transformation, PA-Bestätigung und Abstimmung als ein zusammenhängendes Beweispaket.

Leitfaden

8. Entscheidungsmatrix für die Anbieterbewertung

Bewerten Sie jede Frage mit bestanden, fehlgeschlagen, bedingt oder nicht anwendbar und verknüpfen Sie die Bewertung mit dem konkreten Testnachweis. Gewichten Sie Muss-Kriterien wie PA-Anbindung, korrekte Zahlungsereignisse, Fehlerbehandlung und Exportfähigkeit höher als Komfortfunktionen. Ein Anbieter sollte offenlegen, welche Funktionen im demonstrierten Produkt verfügbar sind, welche erst konfiguriert oder entwickelt werden und welche von der PA oder einem Integrationspartner abhängen. Die frühere Bezeichnung PDP kann in Verträgen und Produktunterlagen noch erscheinen; für die aktuelle Bewertung sollte die Rolle als zugelassene Plattform beziehungsweise PA eindeutig sein. Die Entscheidungsmatrix ist kein abstrakter Softwarevergleich. Sie soll zeigen, ob Ihre Organisation die Lösung mit vertretbarem Aufwand betreiben, kontrollieren und bei regulatorischen oder technischen Änderungen anpassen kann. • Scope-Klassifikation – Kann die Lösung jeden Testfall regelbasiert als E-Rechnung, Transaktions-E-Reporting, Zahlungs-E-Reporting oder begründete Ausnahme einordnen? • PA-Verbindung – Ist die verwendete PA aktuell nachvollziehbar, sind Verantwortungsgrenzen dokumentiert und funktioniert der Rückkanal für Status und Fehler? • Daten-Mapping – Sind SIREN, ausländische Identifikatoren, Mehrwertsteuersätze, Währungen, Belegbeziehungen und Quellfelder versioniert und bis zum Zielwert verfolgbar? • Zahlungsereignisse – Beherrscht die Lösung vollständige Zahlung, Teilzahlung, Anzahlung, Erstattung und den Ausschluss bei VAT on debits oder Reverse Charge? • Korrekturen und Ablehnungen – Können Nutzer Fehler verstehen, korrigieren, kontrolliert erneut senden und den endgültigen Annahmestatus erkennen? • Abstimmung, Sicherheit und Export – Gibt es rollenbasierte Berechtigungen, nachvollziehbare Änderungen, geschützte Schnittstellen, Summenabgleich und einen ohne Anbieterabhängigkeit nutzbaren Export des Audit Trails? • Umsetzung und Support – Sind Eigentümer für ERP, POS, Buchhaltung, API, PA, Steuerthemen und Betrieb benannt sowie Reaktionszeiten, Releasepflege, Testunterstützung und Eskalation vertraglich geklärt?

Leitfaden

9. Häufige Risiken und konkrete nächste Schritte

Ein typischer Fehler ist, die E-Rechnungsfunktion mit vollständiger Frankreich-Readiness gleichzusetzen. Factur-X, UBL und CII sind relevante strukturierte Ansätze; eine gewöhnliche PDF-Datei per E-Mail ist jedoch keine konforme elektronische Rechnung. Selbst eine korrekt erzeugte strukturierte Rechnung beweist außerdem noch nicht, dass B2C-, Auslands- und Zahlungsdaten richtig behandelt werden. Weitere Risiken sind manuell gepflegte SIREN-Nummern oder Umsatzsteuer-Identifikationsnummern, einheitliche Auslandscodes, fehlende Zahlungsreferenzen, stille Ablehnungen, unkontrollierte Wiederholungen und nicht exportierbare Anbieterprotokolle. Auch eine kompatible Lösung ist nicht mit einer PA gleichzusetzen, wenn sie die regulierte Übermittlung nur über eine angebundene zugelassene Plattform durchführen kann. Führen Sie nach der Demo keinen sofortigen Produktentscheid herbei. Schließen Sie zuerst die Nachweislücken, wiederholen Sie fehlgeschlagene Muss-Tests in derselben Umgebung und lassen Sie fachliche Annahmen durch Ihre Beratung, die PA und die aktuelle DGFiP-Dokumentation bestätigen. Danach können Aufwand, Risiko, Supportmodell und Umsetzungseigentum belastbar verglichen werden. • Erstellen Sie innerhalb von zwei Arbeitstagen ein Befundprotokoll mit Nachweislink, Schweregrad und Eigentümer je Test. • Verwerfen Sie Ergebnisse, die nur auf Screenshots ohne Payload, PA-Antwort und Quelldatenabgleich beruhen. • Fordern Sie für offene Konfigurationen einen konkreten Lösungsvorschlag, Aufwand, Termin und Retest. • Prüfen Sie die PA-Rolle und den aktuellen Zulassungsstatus unmittelbar vor Vertragsabschluss erneut. • Planen Sie einen Pilotbetrieb mit repräsentativen Volumen, Monatswechsel und realistischen Fehlerquoten. • Legen Sie Überwachung, Eskalation, Korrekturrechte, Aufbewahrung und Audit-Export vor dem Einführung fest. • Aktualisieren Sie den Testkatalog bei Änderungen der DGFiP-Spezifikation, Ihrer VAT-Regeln oder Ihrer Systemlandschaft.

Checkliste

Die zehn Testszenarien sind mit anonymisierten, realistischen Quelldaten vorbereitet.

Für jeden Fall sind erwarteter Scope, VAT-Behandlung, Zielsystem und PA festgelegt.

ERP-, Billing-, POS-, Buchhaltungs- und API-Verantwortliche nehmen an der relevanten Demo teil.

Der Anbieter zeigt live die verwendeten Mappingregeln und deren Version.

PA-Status, technische Antworten und fachliche Rückmeldungen werden im Rückkanal demonstriert.

Teilzahlungen, Anzahlungen, Gutschriften, Stornos und Erstattungen sind getrennt testbar.

Ablehnung, Korrektur, erneuter Versand und Duplikatschutz werden absichtlich ausgelöst.

Alle Summen lassen sich gegen Kasse, Debitoren, Hauptbuch und Zahlungsdaten abstimmen.

Berechtigungen, Änderungsprotokolle und exportierbarer Audit Trail erfüllen die internen Kontrollanforderungen.

Jede Abweichung besitzt Eigentümer, Zieltermin, Akzeptanzentscheidung und geplanten Retest.

Häufige Fragen

Wie teste ich E-Reporting-Software für Frankreich statt nur ihre Benutzeroberfläche?

Beginnen Sie mit realistischen Datensätzen und verfolgen Sie jeden Vorgang vom ERP, Billing oder POS über Mapping und API bis zur PA-Antwort und Buchhaltungsabstimmung. Ein Test ist erst belastbar, wenn Klassifikation, übertragene Werte, Rückmeldungen, Korrekturen und exportierbare Nachweise zusammenpassen. Vorgefertigte Masken oder Screenshots ohne technische und fachliche Beweiskette reichen nicht aus.

Welche Zahlungsszenarien gehören zwingend in die Software-Demo?

Testen Sie mindestens vollständige Zahlung, Teilzahlungen an verschiedenen Tagen, Anzahlung, Verrechnung mit der Schlussrechnung, Rückerstattung und Zahlung nach Gutschrift oder Storno. Ergänzen Sie einen Fall mit VAT on debits sowie einen Reverse-Charge-Fall, damit die Lösung nicht jeden Geldeingang fälschlich als meldepflichtiges Vereinnahmungsereignis behandelt. Prüfen Sie jeweils Einzugsdatum, Betrag je Mehrwertsteuersatz, Rechnungsbezug und Statusfolge.

Wie prüft man Teilzahlungen und Gutschriften ohne Doppelmeldungen?

Verwenden Sie eine Rechnung mit zwei Teilzahlungen und erzeugen Sie anschließend eine klar referenzierte Teilgutschrift. Die Lösung muss jeden Betrag nur einmal, mit tatsächlichem Datum und korrektem Restsaldo verarbeiten. Wiederholen Sie danach denselben API-Aufruf oder Batch: Idempotenzschlüssel, Belegreferenzen, PA-Status und Abstimmung müssen zeigen, dass kein Duplikat entstanden ist.

Braucht das ERP selbst eine zugelassene Plattform für Frankreich?

Das ERP muss nicht zwingend selbst PA sein, benötigt für die regulierte Übertragung aber eine funktionierende Verbindung zu einer zugelassenen Plattform. Eine als kompatibel bezeichnete Lösung kann Daten vorbereiten oder austauschen, darf die regulierten Übermittlungen jedoch nicht allein durchführen, wenn ihr die entsprechende Zulassung fehlt. Lassen Sie Plattformrolle, aktuelle Registrierung, Vertragskette und Verantwortlichkeit für Fehler ausdrücklich nachweisen.

Wie prüft man tägliche B2C-Aggregate über mehrere Mehrwertsteuersätze?

Stellen Sie einen Geschäftstag mit mehreren Mehrwertsteuersätzen, Rückerstattung und gegebenenfalls mehreren Kassen bereit. Vergleichen Sie Kassenjournal und Buchhaltung mit den je Mehrwertsteuersatz erzeugten Tageswerten und kontrollieren Sie Geschäftstagsgrenzen, Rundung und Vorzeichen. Das Ergebnis sollte keine unnötigen persönlichen Kundendaten enthalten und durch PA-Payload, Annahmereferenz und Abstimmbericht belegt sein.

Welche Nachweise muss der Softwareanbieter nach jedem Test liefern?

Bewahren Sie Quelldatensatz, Mappingversion, transformierte Nutzlast, technische Korrelationsreferenz, PA-Antwort, Statushistorie, Nutzerwarnungen, Korrekturen und finalen Abstimmbericht auf. Für Zahlungsfälle kommen Zahlungszuordnung und Offene-Posten-Historie hinzu. Der Audit Trail sollte in einem lesbaren und maschinenverarbeitbaren Format exportierbar sein, damit die Prüfung nicht dauerhaft von der Anbieteroberfläche abhängt.

Sind PDF-Rechnungen per E-Mail oder Factur-X, UBL und CII gleichwertig?

Nein. Eine gewöhnliche PDF-Rechnung per E-Mail ist im Reformkontext keine konforme elektronische Rechnung, weil ihr die erforderliche strukturierte Verarbeitung fehlt. UBL und CII sind strukturierte Formate; Factur-X kombiniert eine lesbare PDF-Darstellung mit strukturierten Daten. Die Formatunterstützung allein genügt dennoch nicht: Übertragung über die vorgesehene PA, Datenqualität, Statusrücklauf und E-Reporting-Fälle müssen separat getestet werden.

Wie oft müssen Transaktions- und Zahlungsdaten übermittelt werden?

Für B2C werden Transaktionsdaten grundsätzlich täglich nach Mehrwertsteuersatz aggregiert, doch die konkrete Übermittlungsfrequenz und Feldbelegung kann vom Umsatzsteuerregime, Transaktionstyp, aktuellen Spezifikationsstand und der PA-Konfiguration abhängen. Zahlungsdaten benötigen insbesondere das tatsächliche Einzugsdatum und den vereinnahmten Betrag nach Mehrwertsteuersatz. Bestätigen Sie die für Ihr Unternehmen geltenden Rhythmen und Mappings mit Ihrer Beratung, Ihrer PA und der aktuellen DGFiP-Dokumentation.

Wichtige Regeln, Formate und Begriffe

Europäische KommissionEN 16931Richtlinie 2014/55/EUstrukturierte elektronische RechnungDemo- und Abnahmetestplan 2026/2027 für französische E-Reporting-SoftwareFrankreich

Weiterlesen

Offizielle Quellen

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