Einstellungen auf Systemebene #

Nach der Installation wird das Xfacture-Plugin unter “Zubehör” konfiguriert. Dies erfolgt über die Seite “Einstellungen” im Abschnitt “Plugin” unter “Xfacture”.

Hier lassen sich die globalen Einstellungen für die elektronische Rechnungsstellung festlegen, die für alle Benutzer des Systems gelten.

Allgemeines #

Allgemeine Plugin-Einstellungen

Standardmäßig ist das Xfacture-Plugin so vorkonfiguriert, dass es das Format ZUGFeRD verwendet. Welches Format ein Kunde bekommt, legen Sie unter “Format” fest, systemweit hier und je Kunde in seinen Einstellungen.

Zusätzlich gibt es einen kundenspezifischen Konfigurations-Dialog im Kunden-Modul. Dieser ist über das Menü “Erweitert” erreichbar, siehe Einstellungen auf Kundenebene. Dort wählen Sie auch das Empfängerprofil, die festen Notizen und die Mitgliedsnummer eines Kunden.

Dialog zur Konfiguration #

Systemweite Einstellungen

Nach der Installation wird das Xfacture-Plugin über “Zubehör” → “Einstellungen” im Abschnitt “Plugin” unter “Xfacture” konfiguriert.

Der Dialog gliedert sich in Formate, Ausgaben, E-Mail, Sonstiges, Erweitert, Peppol (B2Brouter), Peppol Sandbox, Datev, Yuki und Diagnose. Die Abschnitte sind unten in dieser Reihenfolge beschrieben.

Feldhilfe und Standardwerte #

In der Regel kann der Dialog in seiner Voreinstellung belassen werden. Viele Felder zeigen den Wert "*Standard*", was bedeutet, dass die systemweite Vorgabe genutzt wird.

Um die tatsächlichen Standardwerte einzusehen, fahren Sie mit der Maus über die Feldnamen – die aktuellen Werte werden dann kurz eingeblendet.

Hinweis: Die Einstellungen im Kunden-Modul überschreiben die systemweiten Einstellungen.

Formate #

Format #

Vier Formate stehen zur Wahl:

• ZUGFeRD: PDF mit eingebettetem XML im Profil EXTENDED, nach ZUGFeRD 2.5 (Factur-X 1.09). Der übliche Weg zwischen Unternehmen.
• ZUGFeRD EN 16931: dasselbe PDF, das XML aber im Profil EN 16931. Für Empfänger, deren Prüfprogramm nur die Norm kennt (ab Xfacture 3.128).
• XRechnung: reines XML (CII) nach XRechnung 3.0, für Behörden und Empfänger, die XRechnung verlangen.
• UBL: reines XML nach Peppol BIS Billing 3.0, siehe Peppol Billing 3.0.

Eine Versionswahl gibt es nicht mehr: Xfacture schreibt immer die aktuelle Fassung des Formats. Legt das Empfängerprofil eines Kunden das Format fest, gilt das Profil.

Voreinstellung: Format = ZUGFeRD

PDF als Anlage (XRechnung, UBL) #

Ab Xfacture 3.132 mit EulandaXtools 1.0.412: Bei XRechnung und UBL geht die normale Rechnungs-PDF (ohne eingebettetes XML) als erste Anlage im XML mit. So hat der Empfänger neben dem Datensatz auch das Rechnungsbild. Maßgeblich bleibt der XML-Datensatz; die Anlage trägt die Beschreibung „Rechnung (Sichtfassung, maßgeblich ist der XML-Datensatz)“ und heißt wie die Datei nach der Dateimaske.

• Bei ZUGFeRD entfällt die Einstellung, dort ist die PDF selbst der Träger des XML.
• Die Schlussrechnung führt ihr Formular mit der Aufstellung der Abschläge ohnehin als Anlage mit und bekommt keine zweite PDF.
• Die PDF zählt zur Grenze von 15 MB für alle Anlagen, siehe AE-X-20 Anlagen.
• Für den Versand über Peppol gilt weiter der eigene Schalter PDF einbetten im Abschnitt Peppol (B2Brouter).
• Stört sich ein Empfänger an der PDF, schalten Sie sie an seiner Adresse ab. Legt sein Empfängerprofil den Wert fest, gilt das Profil.

Voreinstellung: PDF als Anlage = Ja

Ausgaben #

Das Xfacture-Modul kann mehrere Ausgabearten gleichzeitig unterstützen:

• Datei
• E-Mail
• Archivierung im DMS

Archiv #

• Falls das EULANDA® DMS-Modul vorhanden ist, kann die elektronische Rechnung automatisch archiviert werden.
• Die Rechnung wird dann im Dokumentenordner des Kunden gespeichert.

Voreinstellung: Archiv = Nein

E-Mail #

• Prüfen Sie vorab, ob der Versand von Rechnungen per E-Mail über den Druckdialog funktioniert, da Xfacture denselben Mechanismus nutzt.
• Falls kein E-Mail-Versand eingestellt ist, kann dies unter “Zubehör” → “Einstellungen” → “Kommunikation” konfiguriert werden.

Wichtig: Microsoft hat den klassischen Outlook-Desktop-Client durch die Cloud-basierte Version „Neues Outlook" ersetzt. Damit ist ein lokaler E-Mail-Versand über MAPI nicht mehr möglich. Alternativ kann Thunderbird genutzt werden, das weiterhin MAPI unterstützt.

Falls Sie nur einen Web-Mailer verwenden (z. B. Gmail über den Browser), ist eine direkte Übergabe nicht möglich.

Voreinstellung: E-Mail = Nein

Datei #

• Rechnungen können immer in eine Datei ausgegeben werden.
• Der Speicherort kann im Feld “Ausgabe” definiert werden.
• Standardmäßig wird die Datei auf den Desktop gespeichert.

Voreinstellung: Datei = Ja

Peppol, Datev und Yuki #

• Peppol: Die Rechnung geht als UBL über den Gateway B2Brouter in das Peppol-Netz; Zugangsdaten im Abschnitt Peppol (B2Brouter) unten.
• Datev: Die Rechnung landet als ZUGFeRD-PDF im Belegtransfer-Ordner des DATEV-Programms, siehe AE-X-10 ZUGFeRD und DATEV.
• Yuki: Die Rechnung geht über die Schnittstelle oder per E-Mail an die Buchhaltung Yuki; Zugangsdaten im Abschnitt Yuki unten.

Voreinstellung: jeweils Nein

E-Mail-Einstellungen #

E-Mail öffnen #

• Falls aktiviert, öffnet sich vor dem Versand der E-Mail-Versanddialog (sofern vom System unterstützt).
• Dies ist nicht bei allen E-Mail-Treibern möglich – z. B. SMTP kann keinen Dialog öffnen.

Voreinstellung: E-Mail öffnen = Ja

Betreff #

• Standardmäßig wird der Betreff automatisch generiert.
• Der Text kann Variablen enthalten, die in den Berichts-Designer-Vorlagen hinterlegt sind.
• Falls ein individueller Betreff gewünscht ist, kann dieser hier eingetragen werden.

Voreinstellung: Betreff = (leer)

Mailtext #

• Der Mailtext wird automatisch aus drei Bereichen zusammengebaut:
  1. Globale E-Mailsignatur (Zubehör → Einstellungen → Kommunikation)
  2. Benutzerspezifische Signatur
  3. Berichts-Designer Vorlage

Falls ein komplett eigener Text gewünscht ist, gibt es zwei Möglichkeiten:

• Eigene Rechnungsformular-Vorlage für E-Rechnungen erstellen.
• Direkt einen individuellen Mailtext eintragen.

Falls Sie die Standardvorlage nutzen, aber zusätzlichen Text einfügen möchten, können Sie die Variable $$body$$ verwenden. Der Text wird dann an dieser Stelle mit den vorhandenen Signaturen kombiniert.

Voreinstellung: Mailtext = (leer)

Erweiterte Einstellungen #

Ab Xfacture 3.110 stehen die Schalter, die bisher nur über die SQL-Registry unter \Modules\Grundwerte\Xfacture gesetzt werden konnten (siehe Anwendungsempfehlungen), im Abschnitt Erweitert des Dialogs. Standard bedeutet jeweils: der Wert fehlt, es gilt die Vorgabe des Moduls.

Ab Xfacture 3.125 stehen Gutschriften (381), Korrekturrechnungen (384) und XML-Kommentare nicht mehr in diesem Dialog. Sie hängen vom Empfänger ab und kommen aus dem Empfängerprofil der Adresse; dort sind auch ihre Werte beschrieben. Was hier vor 3.125 eingestellt war, gilt weiter, solange an der Adresse kein Profil gewählt ist. Hier bleiben die Schalter, die Ihr Geschäft beschreiben und für alle Empfänger gelten. Die Kennung des Kunden gehört dazu und steht ab Xfacture 3.126 wieder hier.

Kennung des Kunden #

Aus welchem Feld der Adresse die Kennung des Käufers (BT-46) und der Lieferanschrift (BT-71) in der E-Rechnung gebildet wird: Debitorenkonto (Vorgabe) oder Matchcode. Gemeint ist Ihre eigene Kundennummer, unter der Sie die Adresse führen; welcher der beiden Felder sie trägt, hängt davon ab, wie Sie Ihre Adressen pflegen, und ist deshalb für alle Empfänger gleich. Eine Nummer, die der Empfänger vergibt, gehört nicht hierher; dafür gibt es die Lief.Nr. und die Mitgliedsnummer. Hintergrund in der Anwendungsempfehlung Matchcode statt Debitorenkonto. Bis Xfacture 3.125 stand die Einstellung im Empfängerprofil; ab 3.126 übergeht Xfacture sie dort mit einem Hinweis. Registry-Wert PartyIdField (FibuKonto, Match).

Gutschriftverfahren (389) #

Rechnet der Mandant Provisionen oder andere Leistungen anstelle des Empfängers ab (Gutschriftverfahren nach § 14 Abs. 2 Satz 2 UStG), steht hier Ja: Gutschriften ohne Bezug gehen dann als 389 (Self-billed invoice) hinaus, Verkäufer ist der Empfänger mit seiner USt-IdNr. oder Steuernummer und seiner Bankverbindung aus dem Adressstamm, Käufer der eigene Firmenstamm, die Beträge positiv, der Hinweistext zum Gutschriftverfahren als Notiz. Nein (Vorgabe): Gutschriften ohne Bezug bleiben 381. Der Schalter gilt nur mandantenweit, weil er sagt, was die Gutschriften ohne Bezug dieses Mandanten sind; ab Xfacture 3.115 mit EulandaXtools 1.0.396. Hintergrund im Kapitel Gutschriftverfahren. Registry-Wert SelfBilling (0, 1).

Belegcodes Abschlag #

Welche Codes Abschlags- und Schlussrechnungen in der E-Rechnung tragen: Bau (875/877) (Vorgabe, die Codes der XRechnung für Bauleistungen nach VOB/B) oder Allgemein (326/380) für Betriebe außerhalb des Baus, die Abschläge ohne Bauvertrag stellen. Ab Xfacture 3.111 mit EulandaXtools 1.0.388 gibt es außerdem Anzahlung (386/380) für Rechnungen vor der Leistung, etwa Vorkasse oder Materialeinkauf; die E-Rechnung trägt dann den Hinweis, dass eine Anzahlung abgerechnet wird. Registry-Wert InvoiceTypeCoding (construction, general, advance).

PZN im Barcodefeld #

Wie das Barcodefeld des Artikels gelesen wird. Standard: GTIN, nur Artikel mit dem Merkmal PZN im Barcodefeld liefern eine PZN. Barcode: immer GTIN. PZN: Mischbetrieb, die PZN wird an Länge und Prüfziffer erkannt. Standard und Barcode ab EulandaXtools 1.0.387; ein von Hand gesetzter Altwert 1 gilt als PZN. Einzelheiten in der Anwendungsempfehlung AE-X-15 PZN im Barcodefeld. Registry-Wert PznMixedMode.

Sonstige Einstellungen #

Dateimaske #

• Definiert den Namen der erstellten Dateien für Zwischenspeicherung, PDF und XML.
• Standard: YYYY-MM-DD-$$title$$-$$invoicenumber$$

Erklärung der Variablen:

• $$title$$ → Wird zu “Rechnung” oder “Gutschrift”
• $$invoicenumber$$ → Wird zur Rechnungsnummer
• Dateiendung: .pdf für ZUGFeRD, .xml für XRechnung

Hinweis: Vermeiden Sie Großbuchstaben in der Dateimaske, da sie für interne Platzhalter verwendet werden (z. B. YY für Jahr, HH für Stunde). Eine Liste der möglichen Platzhalter finden Sie im Abschnitt “Filemask” im Anhang.

Voreinstellung: Dateimaske = (leer)

Datei öffnen #

• Falls aktiviert, wird die Datei nach dem Speichern automatisch geöffnet.
• Voraussetzung: Die Dateiendung muss mit einer Anwendung in Windows verknüpft sein.
• Standardverhalten von Windows:
  • PDFs werden meist im Browser geöffnet.
  • XML-Dateien werden in Edge oder einem anderen Web-Browser geöffnet.

Voreinstellung: Datei öffnen = Nein

Berichtsvorlage #

• Das Standard-Formular für die Rechnungsstellung ist das in EULANDA® definierte Hauptformular.
• Im Berichts-Designer wird dieses durch fettgedruckte Markierung hervorgehoben.

Berichts-Designer

Es kann vorkommen, dass mehrere Berichtsvorlagen fett markiert sind. In diesem Fall erscheint vor dem Ausdruck eine Formularauswahl.

Da ein solcher Auswahldialog im Modul Xfacture nicht möglich ist, muss in solchen Fällen das gewünschte Formular explizit angegeben werden.

Das Modul Xfacture erkennt automatisch alle relevanten Rechnungsformulare und stellt diese im Xfacture-Dialog zur Auswahl.

Standardverhalten: Falls kein Formular explizit angegeben wird, verwendet das System eine eigene Auswahl, das ist standardmäßig “user.Rechnung.Rechnung”.

Voreinstellung: Berichtsvorlage = (leer)

Abschlags- und Schlussrechnung #

Abschlags- und Schlussrechnungen werden mit der Berichtsvorlage gerendert, wie jede andere Rechnung. Das Standardformular „Rechnung“ druckt ab EULANDA® 2026.115 Rechnung, Gutschrift, Storno, Abschlag und Schlussrechnung selbst, mit Projektsumme, geleisteten Abschlägen und Umlagen. Bei XRechnung und UBL geht das Formular einer Schlussrechnung zusätzlich als Anlage mit, damit der Empfänger die Absetzung der Abschläge auch als Bild erhält.

Arbeiten Sie mit einer eigenen Kopie des Rechnungsformulars, muss sie diesen Abschlagsblock enthalten, sonst zeigt die Schlussrechnung die Abschläge als gewöhnliche Positionen. Am einfachsten ersetzen Sie die Kopie durch das Standardformular.

Von Xfacture 3.110 bis 3.122 gab es hier die Einstellungen Vorlage Abschlagsrechnung und Vorlage Schlussrechnung. Ab Xfacture 3.123 sind sie entfallen: Ein dort eingetragenes älteres Formular, etwa „Schlussrechnung“ aus dem Plugin, würde bei neuen Schlussrechnungen die Abschläge falsch zeigen. Ein früherer Eintrag wird nicht mehr ausgewertet und verschwindet beim nächsten Speichern der Einstellungen.

Briefkopf #

Ab Xfacture 3.110: Der Briefkopf (das Briefpapier) für die E-Rechnung lässt sich hier unabhängig vom Druck wählen. Wer auf vorgedrucktem Papier druckt und für die E-Rechnung dennoch einen Briefkopf braucht, wählt hier den passenden Eintrag aus den Briefköpfen von EULANDA®; der Umweg über eine eigene Druckergruppe entfällt damit.

Ab Xfacture 3.123 lässt sich der Briefkopf außerdem je Adresse übersteuern, passend zu einer abweichenden Bankverbindung, siehe Einstellungen auf Kundenebene.

Voreinstellung: Briefkopf = Standard

Briefkopf abfragen #

Ab Xfacture 3.124. Steht hier Ja, fragt Xfacture bei Xfacture ausgeben vor jeder Rechnung nach dem Briefkopf. Vorgewählt ist der Briefkopf, der ohnehin gälte: der der Adresse, sonst der aus dieser Einstellung. Ein Klick auf OK gibt die Rechnung also wie gewohnt aus; nur im Ausnahmefall wählen Sie einen anderen. Abbrechen bricht die Ausgabe ab.

Gedacht ist das für Ausnahmen, die sich weder global noch je Kunde festlegen lassen. Ein Beispiel: Zwei Filialen, Frankfurt und Limburg, haben je ein Lager. Bestellt ein Kunde in Limburg, und die Ware liegt nur in Frankfurt, schickt Frankfurt das Paket und die Rechnung. Damit der Kunde nicht stutzt, trägt diese eine Rechnung den Limburger Briefkopf.

Bei Xfacture ausgeben - Ohne Dialog und bei der Ausgabe als Serie über die Trefferliste fragt Xfacture nie; dort gilt der Briefkopf der Adresse, sonst der aus dieser Einstellung.

Die Briefköpfe gehören zur Datenbank. Arbeiten die Filialen mit zwei Mandanten, braucht jeder Mandant die Briefköpfe der anderen Filiale ebenfalls, sonst stehen sie nicht in der Liste.

Voreinstellung: Briefkopf abfragen = Nein

Ausgabeordner #

• Standardmäßig wird die ZUGFeRD- oder XRechnung-Datei auf dem Desktop gespeichert.
• Falls ein individueller Speicherort gewünscht ist, kann dieser hier definiert werden.

Standardvorgabe: $$desktopfolder$$

Voreinstellung: Ausgabeordner = (leer)

Rechtstext #

Eine XRechnung benötigt neben den üblichen Rechnungsangaben auch zusätzliche geschäftliche Pflichtangaben für die Verbuchung und Eingangskontrolle.

Da es in der XRechnung-Formatbeschreibung bislang keine speziellen Einzelfelder für diese Angaben gibt, müssen sie als Vortext hinterlegt werden.

Pflichtangaben für eine XRechnung:

• Rechtsform der Gesellschaft
• Sitz der Gesellschaft
• Registergericht des Sitzes
• Handelsregisternummer
• Angaben zum Geschäftsführer oder Inhaber

Hinweis:

• Komma (,) und Semikolon (;) können nicht verwendet werden.
• Falls ein Trennzeichen notwendig ist, sollten Bindestrich (-) oder Doppelpunkt (:) zur Strukturierung genutzt werden.

Rechtstext als Beispiel

Der Rechtstext setzt sich aus mehreren Zeilen zusammen. Eine Trennung mit Bindestrichen ist beispielsweise in der Anschrift gemacht worden. Der Feldname ist mit einem Doppelpunkt vom Feldinhalt getrennt.

Rechtstext und WEEE-Nummer #

Der Rechtstext geht als Notiz mit dem Code REG (regulatorische Angaben) in die E-Rechnung. Hersteller und Händler von Elektrogeräten haben außerdem eine WEEE-Registrierungsnummer der stiftung ear, die das Elektrogesetz auf Rechnungen verlangt. Sie gehört wie die USt-IdNr. zum Firmenstamm und geht ebenfalls als Notiz mit dem Code REG hinaus, als „WEEE-Nummer: DE12345678“. Beide Notizen stehen dann nebeneinander in der Rechnung; die Norm erlaubt mehrere Notizen mit demselben Code.

Einzelne Empfänger, etwa Eurobaustoff, lesen unter REG nur die WEEE-Nummer. Für sie setzt ihr Empfängerprofil den Rechtstext auf einen anderen Code (AAI), damit REG allein der WEEE-Nummer gehört. Sie stellen dafür nichts ein.

Sie tragen die Nummer im Firmenstamm ein: Systemverwaltung, Firmenstamm, Feld WEEE-Reg.-Nr. unter Registernummer und Registergericht, ab EULANDA 2026.10.118.12000; Xfacture liest sie ab EulandaXtools 1.0.403. Für Formulare steht sie als Platzhalter %grundwerte.firmenstamm.WeeeRegNr% bereit. Mehrere Notizen mit demselben Code sind gleichberechtigt; das Programm des Empfängers unterscheidet sie nur am Text. Deshalb hat die WEEE-Nummer immer die feste Form „WEEE-Nummer: …“. Xfacture selbst hält die Quellen auseinander:

Steht eine eigene Notiz mit REG und Text an der Adresse, im Profil oder unter F9, ersetzt sie die WEEE-Nummer. Den Rechtstext selbst schalten Sie auf diesem Weg nie ab, denn er ist Pflicht. Im Normalfall trägt eine Rechnung also höchstens zwei Notizen mit REG: den Rechtstext und die WEEE-Nummer, jede an ihrem Text eindeutig zu erkennen.

Peppol (B2Brouter) und Peppol Sandbox #

• Automatisch zustellen: Ja schickt die Rechnung nach dem Hochladen sofort ins Peppol-Netz; Nein lädt sie nur hoch, Sie stellen sie im Portal von B2Brouter zu.
• PDF einbetten: hängt die Rechnungs-PDF an die Peppol-Rechnung. Der Schalter gilt nur für den Peppol-Versand; für die Datei- und E-Mail-Ausgabe gilt PDF als Anlage unter Formate.
• API-Key und Konto-Id: die Zugangsdaten Ihres Kontos bei B2Brouter.
• Sandbox verwenden mit eigenem API-Key und eigener Konto-Id: schickt alles an die Testumgebung von B2Brouter, nichts erreicht einen Empfänger.

Den Zustellstatus und Antworten des Empfängers sehen Sie im Portal von B2Brouter, siehe Peppol Billing 3.0.

Datev #

• Belegtransfer-Ordner: der Ordner, den das DATEV-Programm Belegtransfer überwacht.
• ZIP-Dateimaske: Name der ZIP-Datei, wenn Belege gebündelt übergeben werden.

Yuki #

• Methode: API (Schnittstelle mit Access Key, Administration Id und Domain Id) oder E-Mail (an die Sammel-E-Mail der Yuki-Verwaltung).

Diagnose #

• Simulation: Ja zeigt, was Xfacture mit den wirksamen Einstellungen tun würde, und exportiert und versendet nichts. Für die Fehlersuche gedacht, danach wieder auf Nein stellen.