AE-X-17 Matchcode statt Debitorenkonto #

EN16931 – ZUGFeRD – XRechnung – PEPPOL – EULANDA® Warenwirtschaft

Jede elektronische Rechnung trägt eine Kennung des Käufers. Der Empfänger nutzt sie, um die Rechnung automatisch dem richtigen Konto in seinem System zuzuordnen. In der Norm EN16931 heißt dieses Feld BT-46, beim Warenempfänger entsprechend BT-71.

Xfacture füllt dieses Feld standardmäßig aus dem Fibukonto der Adresse, also aus dem Debitorenkonto der Finanzbuchhaltung. Für die meisten Betriebe ist das genau richtig, denn dort ist das Debitorenkonto gleichzeitig die Nummer, unter der der Kunde geführt wird.

Wann Sie diese Empfehlung betrifft #

Manche Betriebe führen ihre Kundennummer nicht im Fibukonto, sondern im Matchcode der Adresse. Der Matchcode ist in EULANDA® ein eindeutiger, sprechender Suchbegriff zu jeder Adresse. Viele Betriebe verwenden ihn als Kundennummer, das Fibukonto ist dann eine davon unabhängige Nummer der Buchhaltung.

In diesem Fall entsteht ein Widerspruch:

• Auf dem gedruckten Beleg steht die Nummer aus dem Matchcode.
• In der elektronischen Rechnung steht das Debitorenkonto.

Da für die Prüfung und Verarbeitung ausschließlich die XML-Daten maßgeblich sind, arbeitet der Empfänger mit der Nummer, die er nicht kennt. Im ungünstigsten Fall ist Ihr Debitorenkonto zufällig die gültige Nummer eines anderen Ihrer Kunden. Dann schlägt die Zuordnung nicht fehl, sondern sie führt auf den falschen Kunden, und das fällt erst spät auf.

Ob Sie betroffen sind, sehen Sie in der Adressverwaltung: Tragen Matchcode und Fibukonto derselben Adresse unterschiedliche Werte, dann ja. Wer es für den gesamten Bestand wissen will, kann in der Datenbank abfragen, bei wie vielen Adressen die Werte auseinandergehen:

SELECT COUNT(*) FROM Adresse
WHERE ISNULL(LTRIM(RTRIM(Match)), '') <> ISNULL(LTRIM(RTRIM(CAST(FibuKonto AS VARCHAR(20)))), '')

Vorher prüfen: ist Ihr Matchcode die richtige Nummer? #

Der Matchcode ist ein Suchbegriff und muss keine Nummer sein. Er darf auch Buchstaben enthalten, etwa MUELLER-01. Für die elektronische Rechnung ist das erlaubt, BT-46 ist ein Textfeld und keine Zahl. Wir haben es gegengeprüft: eine Rechnung mit einem solchen Matchcode in BT-46 wird von den üblichen Prüfprogrammen als vollständig valide bewertet.

Entscheidend ist eine andere Frage: Kennt Ihr Kunde diese Nummer? Die Kennung nützt nur, wenn der Empfänger sie in seinem System wiederfindet. Steht in Ihrem Matchcode ein interner Suchbegriff und im Fibukonto die Nummer, die auch Ihr Kunde verwendet, dann bleiben Sie beim Fibukonto. Umgekehrt gilt: Steht im Matchcode die Nummer, die auf Ihren Belegen erscheint und die Ihr Kunde bei Rückfragen nennt, dann ist die Umstellung richtig.

Die Umstellung einschalten #

Ab EulandaXtools 1.0.167, ausgeliefert mit Xfacture 3.94, können Sie wählen, aus welchem Feld die Kennung gebildet wird. Die Einstellung ist standardmäßig unverändert, es bleibt also beim Fibukonto. Für alle Anwender, die bisher zufrieden waren, ändert sich dadurch nichts.

Zum Umstellen wird in der SQL-Registry unter

\Modules\Grundwerte\Xfacture

der Zeichenfolge-Wert PartyIdField mit dem Inhalt Match angelegt.

Den Editor der SQL-Registry erreichen Sie auf zwei Wegen:

• über die Systemverwaltung und dort den Punkt SQL-Registry
• über den SQL-Designer, den Sie im rechten Mausmenü des Startmenüs von EULANDA® finden

Eine Bedienoberfläche im Einstellungsdialog von Xfacture gibt es für diesen Wert bewusst noch nicht. Auf Wunsch übernehmen wir das Setzen des Wertes als Supportleistung. Nach der Änderung muss EULANDA® neu gestartet werden, siehe AE-X-08. Wird die Rechnung über ein eigenes PowerShell-Skript erzeugt, ist kein Neustart nötig, dort wird der Wert bei jedem Lauf frisch gelesen.

Was sich dadurch ändert #

• BT-46, die Kennung des Käufers, trägt den Matchcode.
• BT-71, die Kennung des Lieferorts, trägt ihn ebenfalls. Beide Felder werden gemeinsam umgestellt, damit Rechnungsempfänger und Warenempfänger nicht mit unterschiedlichen Nummernkreisen beschrieben werden.
• Die Anzeige der E-Rechnung im Anzeigeprogramm zeigt unter „Kennung" denselben Wert. Beleg, Anzeige und XML sagen damit dasselbe.

Was unverändert bleibt #

• Die Übergabe an die Finanzbuchhaltung arbeitet weiter mit dem Debitorenkonto. Das gilt für den DATEV-Weg ebenso wie für die GoBD-Auswertungen. Die Einstellung wirkt ausschließlich auf die elektronische Rechnung.
• Kunden mit GLN sind nicht betroffen. Liegt eine GLN vor, wird sie als globale Kennung übergeben, und BT-46 entfällt. Das ist eine Vorgabe der Norm, die pro Partei nur eine Kennung zulässt.
• Der Matchcode selbst wird nicht verändert. Xfacture liest ihn nur.

Grenzfälle #

• Ist Match eingestellt und der Matchcode einer Adresse leer, dann bleibt die Kennung in der Rechnung weg. Es wird bewusst nicht auf das Fibukonto zurückgefallen, denn eine falsche Kennung ist schlechter als keine.
• Die Rechnung übernimmt den Matchcode zum Zeitpunkt der Rechnungsschreibung. Bereits geschriebene Rechnungen ändern sich durch eine spätere Pflege der Adresse nicht. Das ist beabsichtigt, denn die elektronische Rechnung soll den Stand des Belegs abbilden.
• Die Einstellung gilt für den gesamten Mandanten, nicht je Kunde. Sie beschreibt, wie Ihr Betrieb seine Adressen führt, und das ist keine Eigenschaft des einzelnen Empfängers.

Woran Sie die Einstellung später wiedererkennen #

Die von Xfacture erzeugte Roh-XML führt im Kopfbereich den Eintrag PARTYIDFIELD mit dem verwendeten Feld. An einer archivierten Datei ist damit auch Jahre später nachvollziehbar, welche Einstellung beim Erzeugen galt.