E-Rechnung in Business Central – die Anleitung, die tatsächlich funktioniert

So richtest du die E-Rechnung in Business Central ein, dass ZUGFeRD-Rechnungen automatisch per E-Mail rausgehen. Die offizielle Anleitung widerspricht sich an genau der Stelle, an der die meisten hängen bleiben, und sie ist an einer weiteren bereits überholt.

Business Central bringt seit Version 26.3 alle drei in Deutschland relevanten E-Rechnungsformate mit: XRechnung, Peppol BIS 3.0 DE und ZUGFeRD. Die Einrichtung ist überschaubar – wenn man weiß, in welcher Reihenfolge man vorgehen muss und welche Felder die Dokumentation verschweigt.

Wer der Microsoft-Doku Schritt für Schritt folgt, bekommt kein ZUGFeRD per E-Mail. Das liegt nicht an mangelndem Verständnis, sondern an einem Widerspruch in der Anleitung selbst.

Kurz zur Orientierung: Diese Anleitung richtet sich an Anwender und Berater gleichermaßen. Die grau hinterlegten Codeblöcke sind Belege für Berater und Entwickler – wenn du nur einrichten willst, kannst du sie gefahrlos überspringen. Alles Wichtige steht auch im Fließtext.

Alle Aussagen sind gegen Business Central 28.3.52162 geprüft, und zwar am Quellcode statt an der Dokumentation: Base Application, E-Document Core und E-Document for Germany.

---

Was am Ende herauskommt

---

Teil 1: Stammdaten – die unterschätzte Hürde

Der größte Teil der Fehlversuche scheitert nicht an der Einrichtung, sondern an Stammdaten. Business Central prüft beim Export eine ganze Kette von Feldern, und kaum eines davon steht in der Dokumentation.

Der Grund: Das ZUGFeRD-Format führt seine eigenen Prüfungen aus und reicht dann an die klassische PEPPOL-Validierung der Base Application weiter.

// ZUGFeRD Format.Check - Business Central 28.3
CheckCompanyInfoMandatory(CompanyInformation);
CheckBankAccountIBANMandatory(SourceDocumentHeader, CompanyInformation);
EDocumentDEHelper.CheckBuyerReferenceMandatory(EDocumentService, SourceDocumentHeader);
EDocPEPPOLValidationDE.SetSkipVATRegNoCheck(EDocumentDEHelper.HasRoutingNo(SourceDocumentHeader));
BindSubscription(EDocPEPPOLValidationDE);
EDocPEPPOLBIS30.Check(SourceDocumentHeader, EDocumentService, EDocumentProcessingPhase);
UnbindSubscription(EDocPEPPOLValidationDE);

Unternehmensdaten

if CompanyInfo.IBAN = '' then
    CompanyInfo.TestField("Bank Account No.");
CompanyInfo.TestField("Bank Branch No.");
CompanyInfo.TestField("SWIFT Code");

Beachte: Bankleitzahl und SWIFT-Code werden immer auf den Unternehmensdaten geprüft, auch wenn der Beleg ein Firmenbankkonto verwendet. Nur die IBAN darf vom Bankkonto kommen.

Verkäufer/Einkäufer

Name, Telefonnr. und E-Mail. Steht auf der Rechnung kein Verkäufercode, greifen stattdessen Kontaktperson, Telefonnr. und E-Mail aus den Unternehmensdaten. Die Telefonnummer ist dabei der Türsteher für die gesamte Verkäufer-Kontaktgruppe – mehr dazu im Fehlerteil.

Weitere Stammdaten

• Länder/Regionen: ISO-Code gefüllt und genau zwei Zeichen lang – für Firmenland, Rechnungsempfängerland und Lieferland
• Währungen: Währungscode dreistellig; bei Belegen ohne Währung gilt der Mandantenwährungscode aus der Finanzbuchhaltungseinrichtung
• MwSt.-Buchungsmatrix: Feld Steuerkategorie in jeder verwendeten Kombination gefüllt
• Verantwortlichkeitscenter (falls verwendet): Name, Adresse, Ort, PLZ, Länder-/Regionscode

Einheiten: die internationalen Codes

Pflichtfelder auf dem Beleg

Feld	Anmerkung
Rech.-an Name, Adresse, Ort, PLZ, Länder-/Regionscode
Lieferadresse, -ort, -PLZ, -land
Lieferdatum	bei Rechnung und Auftrag
Fälligkeitsdatum
E-Mail (Verkauf an)	deutsche Zusatzprüfung, undokumentiert
Anwendung auf Belegnr.	bei Gutschriften mit Anwendung auf Rechnung
Debitor: GLN oder USt-IdNr.	entfällt, wenn eine Leitweg-ID vorliegt
Ihre Referenz	wird in Deutschland nie geprüft

Die letzten drei Zeilen kommen aus einem eigenen deutschen Prüf-Subscriber:

codeunit 13921 "EDoc PEPPOL Validation DE"
{
    [EventSubscriber(..., 'OnCheckSalesDocumentOnBeforeCheckYourReference', ...)]
    local procedure SkipCheckOnCheckSalesDocumentOnBeforeCheckYourReference(var IsHandled: Boolean)
    begin
        IsHandled := true;                        // "Ihre Referenz" wird nie geprüft
    end;

    [EventSubscriber(..., 'OnAfterCheckSalesDocument', ...)]
    local procedure OnAfterCheckSalesDocument(SalesHeader: Record "Sales Header")
    begin
        SalesHeader.TestField("Sell-to E-Mail");  // zusätzlich Pflicht
    end;
}

Pro Rechnungszeile

• Beschreibung darf nicht leer sein
• MwSt.-Produktbuchungsgruppe gesetzt
• Einheit mit internationalem Standardcode
• Steuerkategorie-Plausibilität: Standardsatz (S) verlangt einen MwSt.-Satz größer null, Nullsatz und „nicht steuerbar“ verlangen null; für die Kategorie O darf nur eine Aufschlüsselung entstehen
• Negative Verkaufspreise bei Artikeln lösen eine Rückfrage aus

---

Teil 2: Die Einrichtung in fünf Schritten

Schritt 1: E-Belegdienst anlegen

Im Bereich Parameter findest du den Schalter Käuferreferenz erforderlich. Der ist optional; für Rechnungen an öffentliche Auftraggeber mit Leitweg-ID ist er sinnvoll.

Wichtig: Lege den Dienst zuerst an. Solange kein E-Belegdienst existiert, ist im Belegsendeprofil das Feld „Elektronischer Beleg“ komplett unsichtbar. Wer in der anderen Reihenfolge arbeitet, sucht vergeblich nach einem Feld, das schlicht ausgeblendet ist.

Die Käuferreferenz hat sich geändert

Die deutsche Microsoft-Dokumentation beschreibt an dieser Stelle ein Auswahlfeld, in dem man zwischen „Ihre Referenz“ und „Debitorenreferenz“ wählt. Dieses Feld ist in Business Central 28.3 ausgeblendet und funktionslos. Der Grund steht im Code:

field("Buyer Reference"; Rec."Buyer Reference")
{
    ObsoleteState = Pending;
    ObsoleteReason = 'Buyer Reference is resolved automatically via priority chain: Document field > Customer E-Invoice Routing No. > Your Reference.';
    ObsoleteTag = '29.0';
    Visible = false;
}

Blende es nicht über Personalisieren wieder ein – es wird nirgends mehr gelesen und verschwindet mit Business Central 29 vollständig.

Stattdessen gibt es ein Käuferreferenz-Feld direkt auf dem Beleg, das beim Setzen des Rechnungsempfängers automatisch aus der E-Rechnungs-Arbeitsplannummer des Debitors vorbelegt wird. Beim Export wird der Wert über eine Prioritätskette ermittelt:

1. Beleg-Feld Käuferreferenz – aber nur, wenn es eine strukturell gültige Leitweg-ID ist
2. E-Rechnungs-Arbeitsplannummer des Rechnungsempfängers
3. Beleg-Feld Käuferreferenz, auch wenn es keine gültige Leitweg-ID ist
4. Ihre Referenz

Der Schalter „Käuferreferenz erforderlich“ bricht das Buchen nur ab, wenn diese Kette komplett leer bleibt.

Neu ist außerdem eine echte Strukturprüfung der Leitweg-ID: Gesamtlänge 5 bis 46 Zeichen, zwei oder drei Segmente mit Bindestrich getrennt, Grobadressierung nur Ziffern mit Länge 2, 3, 5, 8, 9 oder 12, die ersten beiden Ziffern ein gültiger Bundesland-Code 01 bis 16 oder der Bund-Code 99, Feinadressierung 1 bis 30 alphanumerische Zeichen, Prüfziffer zweistellig nach Mod 97-10.

Achtung: Eine Leitweg-ID, die diese Prüfung nicht besteht, wird nicht abgelehnt. Sie rutscht nur auf Priorität 3 und wird trotzdem exportiert.

Schritt 2: Workflow anlegen und aktivieren

Einen zusätzlichen Exportschritt brauchst du nicht. Der Sendeschritt exportiert selbst, falls noch kein Export vorliegt:

// E-Document WorkFlow Processing.DoSend
if (EDocServiceStatus.Status = Enum::"E-Document Service Status"::Exported) then
    Sent := EDocIntMgt.Send(EDocument, EDocumentService, SendContext, IsAsync)
else
    if EDocExport.ExportEDocument(EDocument, EDocumentService) then
        Sent := EDocIntMgt.Send(EDocument, EDocumentService, SendContext, IsAsync);

Getrennte Export- und Sendeschritte werden erst in mehrstufigen Abläufen nötig, etwa wenn eine Behörde die Rechnung vorab freigeben muss.

Schritt 3: Belegsendeprofil – auf die Reihenfolge achten

Setzt du die E-Mail-Anlage zuerst, bricht Business Central mit einer Fehlermeldung ab. Der Workflow muss zu diesem Zeitpunkt bereits existieren und aktiviert sein:

// tableextension 6100 "E-Document Sending Profile"
local procedure ValidateThatEDocumentWorkflow()
begin
    Rec.TestField("Electronic Document", Rec."Electronic Document"::"Extended E-Document Service Flow");
    Rec.Validate("Electronic Service Flow");
    Workflow.Get(Rec."Electronic Service Flow");
    Workflow.TestField(Enabled, true);
end;

Warum du die Option „Erweiterter E-Beleg-Serviceablauf“ nicht findest

Die Microsoft-Dokumentation nennt die zu wählende Option „Extended E-Document Service Flow“. In der Oberfläche steht dort aber E-Beleg-Workflow. Technischer Name und Anzeigetext unterscheiden sich:

enumextension 6101 "E-Doc. Send. Profile Elec. Doc" extends "Doc. Sending Profile Elec.Doc."
{
    value(6102; "Extended E-Document Service Flow")
    {
        Caption = 'E-Document Workflow';
    }
}

Wer nach dem Wortlaut aus der Doku sucht, findet nichts.

Schritt 4: Profil zuordnen

Schritt 5: Rechnungsbericht prüfen

Suche → Berichtsauswahl Verkauf → Verwendung Rechnung. Dort muss Standard Sales – Invoice stehen.

Das ist keine Empfehlung, sondern Bedingung. Die XML-Datei wird über Erweiterungen auf genau vier Microsoft-Berichte eingebettet – Verkaufsrechnung, Verkaufsgutschrift, Servicerechnung und Servicegutschrift:

reportextension 13918 "Posted Sales Invoice" extends "Standard Sales - Invoice"
{
    trigger OnPreRendering(var RenderingPayload: JsonObject)
    ...
        if not ExportZUGFeRDDocument.IsZUGFeRDPrintProcess() then exit;
        ExportZUGFeRDDocument.CreateAndAddXMLAttachmentToRenderingPayload(Header, RenderingPayload);

Steht in der Berichtsauswahl ein eigenes Layout, erzeugt Business Central eine ganz normale PDF ohne eingebettete XML – und meldet dabei keinen Fehler. Du bekommst eine hübsche Rechnung, die keine E-Rechnung ist.

Prüfe auch die kundenspezifische Berichtsauswahl, die überschreibt die allgemeine.

---

Teil 3: Testen

---

Teil 4: Häufige Fehler

„Datei anzeigen“ bringt einen Fehler mit Postennr. = 0

Meldung: ‚E-Beleg – Datenspeicher‘ ist nicht vorhanden. Identifizierende Felder und Werte: Postennr.=’0′

Diese Aktion funktioniert für ausgehende Belege prinzipbedingt nicht. Sie liest ein Feld, das nur beim Empfang einer Datei gefüllt wird – und wird trotzdem angeboten, weil ihr im Gegensatz zu den Nachbaraktionen die Sichtbarkeitseinschränkung fehlt.

procedure ViewSourceFile()
begin
    EDocDataStorage.Get(Rec."Unstructured Data Entry No.");   // bei ausgehenden Belegen: 0

Lösung: Nicht „Datei anzeigen“ verwenden, sondern den Weg über Protokolle → Datei exportieren.

Die E-Mail kommt an, aber ohne ZUGFeRD

Auf der gebuchten Rechnung gibt es zwei völlig verschiedene Aktionen, die beide nach E-Mail aussehen.

action(Email)
{
    trigger OnAction()
    begin
        SalesInvHeader.EmailRecords(true);   // kennt das E-Beleg-Framework nicht
    end;
}

Das Feld „Elektronischer Beleg“ ist gar nicht da

Es wird ausgeblendet, solange kein E-Belegdienst existiert.

Lösung: E-Belegdienst zuerst anlegen, dann das Belegsendeprofil öffnen.

Buchen bricht mit einer Feldprüfung ab

Dann fehlt eines der Felder aus Teil 1. Die Meldung nennt Feld und Tabelle, aber nicht den Zusammenhang zur E-Rechnung, weshalb sie zunächst rätselhaft wirkt.

Am häufigsten sind SWIFT-Code und Bankleitzahl in den Unternehmensdaten, der internationale Standardcode an einer Einheit, eine fehlende Steuerkategorie in der MwSt.-Buchungsmatrix und die E-Mail-Adresse auf dem Verkaufsbeleg.

Lösung: Die Stammdatenliste aus Teil 1 der Reihe nach abarbeiten.

Validator meldet: SELLER CONTACT (BG-6) fehlt

Der häufigste Validierungsfehler überhaupt. Die Verkäufer-Kontaktgruppe wird nur geschrieben, wenn eine Telefonnummer vorhanden ist. Fehlt sie, entfällt auch der Name, selbst wenn er gepflegt ist.

if SellerPhoneNumber <> '' then begin
    ContactElement := XmlElement.Create('DefinedTradeContact', XmlNamespaceRAM);
    ContactElement.Add(XmlElement.Create('PersonName', XmlNamespaceRAM, SellerContactName));
    ContactElement.Add(XmlElement.Create('TelephoneUniversalCommunication', ...));
    if SellerEmailAddress <> '' then
        ContactElement.Add(XmlElement.Create('EmailURIUniversalCommunication', ...));
    SellerTradePartyElement.Add(ContactElement);
end;

Woher die Daten kommen: Steht auf der gebuchten Rechnung ein Verkäufercode, gewinnt der Verkäufer-Datensatz – und zwar auch dann, wenn dessen Felder leer sind. Es gibt keinen Rückfall auf die Unternehmensdaten.

Lösung: Beim Verkäufer/Einkäufer Name, Telefonnr. und E-Mail füllen. Zusätzlich in den Unternehmensdaten Kontaktperson, Telefonnr. und E-Mail pflegen, dann sind beide Wege abgedeckt. XRechnung 3.0 verlangt alle drei Angaben.

Nach dem Korrigieren ändert sich nichts

Das ist kein Folgefehler, sondern der häufigste Trugschluss beim Testen. Die exportierte Datei liegt als Momentaufnahme im Protokoll. Stammdatenänderungen wirken erst, wenn der E-Beleg neu erzeugt wird.

Lösung: Auf der E-Beleg-Seite die Aktion Neu erstellen ausführen. Das legt einen zusätzlichen Protokolleintrag an, der alte bleibt stehen. Anschließend unbedingt die Zeile mit dem jüngsten Zeitstempel herunterladen.

Neu buchen ist nicht nötig. Nur der Verkäufercode steckt im gebuchten Beleg; Name, Telefon und E-Mail liest der Export zur Laufzeit aus den Stammdaten.

Es passiert überhaupt nichts, ohne Fehlermeldung

Wenn keine Datei zum Anhängen gefunden wird, geht die Mail trotzdem raus – ohne Abbruch, ohne Meldung:

// E-Document Emailing.CreateAttachmentsBlob
if GlobalTempBlobList.IsEmpty() then
    exit(TempBlob);          // leerer Blob, Dateiname bleibt leer

Die Anlagen stammen aus dem Protokolleintrag mit Status Exportiert, ermittelt über den Workflow – nicht über das Sendeprofil.

Lösung: Prüfen, ob zum Beleg ein E-Beleg existiert und ob dort eine Protokollzeile mit Status Exportiert steht. Fehlt sie, hakt es vor dem Versand.

---

Was du über das Format wissen solltest

Ein Punkt, der in Projekten für Diskussionen sorgt und den man vor dem Start mit dem Kunden klären sollte.

Business Central nennt das Format „ZUGFeRD“. Die tatsächlich eingebettete XML-Datei ist aber ein XRechnung-CII-3.0-Profil. Profil-Kennung und Dateiname sind im Export fest hinterlegt:

GuidelineSpecifiedDocumentContextParameterElement.Add(
    XmlElement.Create('ID', XmlNamespaceRAM,
        'urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0'));
...
Name := 'xrechnung.xml';

Klassisches ZUGFeRD erwartet demgegenüber eine Datei namens factur-x.xml und eine andere Profilangabe. Validatoren erkennen die Datei korrekt als XRechnung CII Invoice 3.0; strenge ZUGFeRD-Prüfer bemängeln zusätzlich die Versionsangabe in den XMP-Metadaten des PDF.

Praktisch heißt das: Für alle Empfänger, die XRechnung verarbeiten – und das sind in Deutschland faktisch alle Systeme nach EN 16931 – ist die Datei einwandfrei. Wer explizit ZUGFeRD im engeren Sinn verlangt, bekommt formal etwas anderes.

Ein zweites Detail für die Ablage: Als Rechnungsdatum (BT-2) exportiert Business Central das Buchungsdatum, nicht das Belegdatum. Weichen die beiden voneinander ab, weicht die XML vom Ausdruck ab.

IssueDateTimeElement.Add(XmlElement.Create('DateTimeString', XmlNamespaceUDT,
    XmlAttribute.Create('format', '102'), FormatDate(SalesInvoiceHeader."Posting Date")));

Wenn ZUGFeRD als Anforderung im Lastenheft steht, sprich das früh an. Es ist kein Fehler in deiner Einrichtung.

---

Checkliste zum Abhaken

Für den nächsten Kunden, in genau dieser Reihenfolge:

• Apps E-Document Core und E-Documents for Germany installiert
• E-Mail-Konto eingerichtet
• Unternehmensdaten: Name, Adresse, Ort, PLZ, Länder-/Regionscode, GLN oder USt-IdNr., E-Mail, IBAN, Bankleitzahl, SWIFT-Code
• Länder/Regionen: ISO-Codes gefüllt
• Einheiten: internationale Standardcodes gefüllt
• MwSt.-Buchungsmatrix: Steuerkategorien gefüllt
• Verkäufer/Einkäufer: Name, Telefonnr., E-Mail
• Debitoren: E-Mail, GLN oder USt-IdNr. beziehungsweise E-Rechnungs-Arbeitsplannummer
• Berichtsauswahl Verkauf, Rechnung = Standard Sales – Invoice
• E-Belegdienst mit Belegformat ZUGFeRD angelegt
• Workflow angelegt und aktiviert
• Belegsendeprofil in der Reihenfolge Elektronischer Beleg → Workflow → E-Mail → Anlage
• Profil als Standard gesetzt oder Debitoren zugeordnet
• Testrechnung über Buchen und Senden
• Exportierte Datei validiert, null fehlgeschlagene Regeln

---

Fazit

Die Einrichtung selbst ist keine Raketenwissenschaft. Sie ist nur an drei Stellen unbarmherzig: bei der Reihenfolge im Belegsendeprofil, beim richtigen Rechnungsbericht und bei Stammdaten, die niemand als Pflichtfelder erwartet.

Wenn es nicht funktioniert, liegt es fast nie am Verständnis – sondern daran, dass Business Central an mehreren Stellen still scheitert, statt einen Fehler zu melden. Wer weiß, wo er hinschauen muss, ist in zwanzig Minuten durch.

Alle Aussagen und Codeausschnitte sind gegen Business Central 28.3.52162 geprüft: Base Application, E-Document Core und E-Document for Germany. Bei anderen Versionen kann das Verhalten abweichen, insbesondere rund um die Käuferreferenz, die sich zwischen den Versionen deutlich verändert hat.