Kostenfrei testen
Kostenlos testen

Häufig gestellte Fragen

Finden Sie Antworten auf Ihre Fragen zu elektronischen Rechnungen und faktoora

 

Elektronische Rechnung ist ein gesetzeskonformer, maschinenlesbarer XML-Datensatz, der alle Pflichtangaben gemäß EU-Richtlinie 2014/55/EU enthält und automatisiert in ERP-Systeme (z. B. SAP, MS Dynamics) importiert wird. Gängige Formate wie XRechnung (B2G), ZUGFeRD Extended (B2B) und internationale Standards wie Peppol BIS/UBL ermöglichen effiziente Validierung, digitale Signatur (XAdES) und revisionssichere Archivierung nach GoBD (§ 146 AO). Durch OCR- und RPA-gestützte Workflows senken Sie Druck- und Portokosten, minimieren Fehler und steigern Transparenz im Rechnungsworkflow optimieren. Weitere Praxis­tipps zur GoBD-konformen Archivierung und zur EU-Richtlinie finden Sie auf den Seiten der EU-Kommission

Die Formate für elektronische Rechnungen basieren auf dem europäischen Standard EN 16931, der die inhaltlichen Anforderungen definiert. Die eigentlichen technischen Formate sind UBL (Universal Business Language) und CII (Cross Industry Invoice), zwei XML-basierte Datenstrukturen für strukturierte Rechnungsinformationen. Darauf aufbauend gibt es konkrete Anwendungsspezifikationen wie XRechnung und ZUGFeRD in Deutschland, die diese Formate in bestimmten Kontexten standardisieren:

  • XRechnung ist die verpflichtende Spezifikation für elektronische Rechnungen an öffentliche Auftraggeber in Deutschland. Technisch basiert sie auf UBL oder CII.

  • ZUGFeRD ist ein hybrides Format, das ein PDF/A-3 mit einem eingebetteten CII-Datensatz kombiniert. Es wird vor allem im B2B-Umfeld verwendet.

International wird vor allem UBL im Rahmen des Peppol-Netzwerks eingesetzt, einem europaweiten Standard für den strukturierten Austausch von Rechnungsdaten. Weitere Informationen zu Peppol finden Sie unter peppol.org, zu CII unter unece.org.

XRechnung ist die in Deutschland verpflichtende Spezifikation für elektronische Rechnungen an öffentliche Auftraggeber. Sie basiert auf dem europäischen Standard EN 16931 und besteht ausschließlich aus strukturierten XML-Daten. Im Gegensatz zu ZUGFeRD, das zusätzlich ein visuelles PDF enthält, verzichtet XRechnung vollständig auf Layout und Darstellung. Besondere Merkmale der XRechnung sind die verpflichtende Angabe einer Leitweg-ID zur Adressierung der Empfängerbehörde und die Einbettung rechnungsbegründender Anhänge direkt im XML. Eine Übermittlung erfolgt in der Regel über Plattformen wie die zentrale Rechnungseingangsplattform des Bundes per Upload oder Email. XRechnungen sind erforderlich für alle Unternehmen, die Aufträge von öffentlichen Stellen auf Bundes- oder Landesebene abrechnen. Faktoora stellt sicher, dass alle Vorgaben automatisch erfüllt und die jeweils aktuelle Version der XRechnung verwendet wird.

ZUGFeRD ist ein hybrides Rechnungsformat, das ein PDF/A-3 Dokument mit einem eingebetteten XML-Datensatz kombiniert. Es basiert auf dem europäischen Standard EN 16931 und eignet sich besonders für den Austausch elektronischer Rechnungen im B2B-Umfeld. Der visuelle Teil dient zur Anzeige und Archivierung, während die strukturierten XML-Daten maschinell verarbeitet werden können. Im Gegensatz zur rein strukturierten XRechnung erlaubt ZUGFeRD ein anpassbares Rechnungsdesign und erfüllt gleichzeitig die Anforderungen an elektronische Rechnungen. Unterstützt werden verschiedene Profile, zum Beispiel ZUGFeRD Basic oder Extended, abhängig vom gewünschten Detaillierungsgrad. ZUGFeRD wird nicht von öffentlichen Auftraggebern vorgeschrieben, ist aber weit verbreitet in der Privatwirtschaft und wird auch von vielen ERP- und Buchhaltungssystemen unterstützt. Faktoora erstellt automatisch gültige ZUGFeRD-Rechnungen nach dem aktuellen Profil und ermöglicht die Einbettung zusätzlicher rechnungsbegründender Anhänge.

PDF/A ist ein ISO-standardisiertes Format zur langfristigen Archivierung digitaler Dokumente. Es stellt sicher, dass alle Inhalte wie Schriften, Farben oder Bilder vollständig eingebettet sind und das Dokument jederzeit unverändert dargestellt werden kann. Dadurch bleibt eine Rechnung auch nach vielen Jahren lesbar und rechtlich verwertbar. Für elektronische Rechnungen ist PDF/A besonders bei ZUGFeRD relevant. Hier wird das Format PDF/A-3 genutzt, das zusätzlich eine XML-Datei im selben Dokument enthält. So ist die Rechnung sowohl visuell lesbar als auch maschinell auswertbar. PDF/A erfüllt die Anforderungen der GoBD und ist für eine revisionssichere Archivierung geeignet.

EN 16931 ist die europäische Norm für elektronische Rechnungen im B2G- und B2B-Umfeld. Sie legt fest, welche Daten eine elektronische Rechnung enthalten muss, in welcher Struktur sie übermittelt wird und welche Prüfregeln anzuwenden sind. Ziel ist ein einheitlicher, maschinenlesbarer Standard für den Rechnungsaustausch innerhalb der EU. Die Norm definiert ein sogenanntes semantisches Datenmodell, das unabhängig vom technischen Format ist. Auf dieser Basis wurden technische Umsetzungen wie UBL und CII entwickelt. Nationale Anwendungsspezifikationen wie XRechnung oder ZUGFeRD sind sogenannte CIUS (Core Invoice Usage Specifications), die EN 16931 auf konkrete rechtliche und organisatorische Anforderungen einzelner Länder oder Branchen anpassen. XRechnung ist die CIUS für den öffentlichen Sektor in Deutschland und basiert technisch auf UBL oder CII. ZUGFeRD ist eine weitere CIUS, die in Deutschland vor allem im B2B-Umfeld verwendet wird und auf CII aufbaut. Beide Formate setzen die Vorgaben von EN 16931 um, unterscheiden sich aber im Aufbau und im Anwendungsbereich.

Peppol ist ein international genutztes Netzwerk für den sicheren und standardisierten Austausch strukturierter Geschäftsdokumente wie elektronische Rechnungen, Bestellungen oder Lieferscheine. Es wurde ursprünglich von der EU initiiert und hat sich inzwischen weltweit etabliert, unter anderem in Deutschland, den Niederlanden, Norwegen, Australien, Singapur und Japan. Peppol basiert auf einheitlichen Datenformaten wie UBL und einem definierten Transportprotokoll. Jeder Teilnehmer ist über eine eindeutige Peppol-ID erreichbar und kommuniziert über zertifizierte Access Points. Die Übertragung erfolgt verschlüsselt, nachvollziehbar und systemübergreifend. Ein weiterer Bestandteil ist das Peppol SMP (Service Metadata Publisher), das die Erreichbarkeit von Empfängern verwaltet.

Ein großer Vorteil von Peppol ist die globale Interoperabilität ohne bilaterale Schnittstellen. Unternehmen und Behörden können strukturierte Rechnungen weltweit direkt austauschen. Peppol ist zudem ein zentraler technischer Baustein für kommende EU-Vorgaben wie ViDA (VAT in the Digital Age), das auf verpflichtende E-Rechnungen und transaktionsbasierte Meldungen abzielt.

Faktoora ist zertifizierter Peppol-Provider und ermöglicht so den nahtlosen Empfang und Versand über das Peppol-Netzwerk.

Seit dem 1. Januar 2025 gilt in Deutschland die Pflicht, elektronische Rechnungen im B2B-Bereich empfangen zu können. Diese Regelung betrifft alle inländischen Unternehmen – unabhängig von Größe, Branche oder Rechtsform. Auch Freiberufler, Personengesellschaften und wirtschaftlich tätige Vereine sind eingeschlossen, sofern sie unternehmerisch tätig sind und Umsatzsteuer im Inland schulden oder als Leistungsempfänger zum Vorsteuerabzug berechtigt sind. Die gesetzliche Grundlage ist § 14 UStG in der Fassung des Wachstumschancengesetzes. Damit wird die bestehende Pflicht zur elektronischen Rechnung im öffentlichen Bereich, wie sie bereits 2020 durch die E-Rechnungsverordnung eingeführt wurde (für XRechnung im B2G), nun auf den B2B-Bereich erweitert. Die Pflicht zur Ausstellung elektronischer Rechnungen wird gestaffelt umgesetzt. Seit 2025 ist nur der Empfang verpflichtend. Die Pflicht zur Ausstellung gilt ab 2026 für große Unternehmen und wird bis 2028 auf alle ausgedehnt. Übergangsregelungen existieren für Rechnungen, die nicht elektronisch ausgestellt werden müssen, zum Beispiel:

  • Kleinbetragsrechnungen unter 250 Euro (§ 33 UStDV)

  • Fahrkarten und ähnliche Belege (§ 34 UStDV)

  • Ausnahmen bei Barumsätzen und Leistungen an Privatpersonen (B2C)

Elektronische Rechnungen im Sinne des Gesetzes müssen dem Standard EN 16931 entsprechen, also etwa als XRechnung oder ZUGFeRD mit strukturierter XML-Datei.

Seit 2025 reicht das einfache Versenden von PDF-Rechnungen im B2B-Bereich in Deutschland nicht mehr aus. Laut § 14 UStG müssen elektronische Rechnungen dem EN 16931 Standard entsprechen, also z. B. im Format XRechnung oder ZUGFeRD mit strukturierten XML-Daten erstellt sein. Ein PDF ohne strukturierte Daten erfüllt diese Vorgabe nicht und ist in diesem Kontext nicht zulässig. Eine Papierrechnung hingegen ist formal keine elektronische Rechnung und bleibt daher in bestimmten Ausnahmefällen zulässig, etwa bei Kleinbetragsrechnungen oder während der Übergangsfristen für die Ausstellungspflicht. Das bedeutet: Papier kann erlaubt sein, wo PDF ausdrücklich nicht mehr anerkannt wird.

Wir stellen sicher, dass alle Rechnungen, die Sie mit Faktoora erstellen, den gesetzlichen Anforderungen entsprechen. Sie wählen das Format, wir kümmern uns um Struktur, Validierung und Konformität.

Ja. Die E-Rechnungspflicht gilt auch für Kleinunternehmen, sofern sie unternehmerisch tätig sind und Leistungen an andere Unternehmen in Deutschland erbringen. Entscheidend ist nicht die Unternehmensgröße, sondern ob eine B2B-Leistung im Inland erbracht wird. Damit betrifft die Pflicht zur elektronischen Rechnung auch Kleinunternehmer nach § 19 UStG, sobald sie Rechnungen an andere Unternehmen stellen.

Kleinunternehmer sind nicht von der Empfangspflicht ausgenommen und müssen seit 2025 elektronische Rechnungen im strukturierten Format (z. B. XRechnung oder ZUGFeRD) annehmen können. Für die Ausstellung gilt eine Übergangsregelung bis spätestens 2028. Wer jedoch frühzeitig umstellt, profitiert von weniger Medienbrüchen und automatisierten Abläufen.

Nein. PDF-Dateien können nicht automatisch in gültige elektronische Rechnungen umgewandelt werden, da sie keine strukturierten Daten enthalten. Eine Umwandlung per OCR (Texterkennung) ist technisch möglich, aber nicht zuverlässig genug, um die Anforderungen nach EN 16931 zu erfüllen. OCR erkennt Inhalte rein visuell, kann jedoch keine semantische Zuordnung zu Pflichtfeldern wie BT-20 oder BT-126 vornehmen. Zudem lassen sich Validierungsregeln oder steuerliche Pflichtangaben nicht sicher ableiten. Für die Erstellung elektronischer Rechnungen sind strukturierte Ausgangsdaten erforderlich, etwa aus einem ERP-System oder über eine direkte Eingabe in Faktoora. Der Versuch, PDFs per OCR zu verarbeiten, ist keine nachhaltige Digitalisierungsstrategie, sondern ein fehleranfälliger Workaround.

UBL (Universal Business Language) und CII (Cross Industry Invoice nach UN/CEFACT) sind zwei XML-basierte Formate zur Darstellung strukturierter elektronischer Rechnungen. Beide erfüllen die Anforderungen der Norm EN 16931 und dienen als technisches Fundament für nationale Rechnungsstandards wie XRechnung oder Peppol BIS. Der Unterschied liegt in der Herangehensweise:

  • UBL ist offener, einfacher aufgebaut und stärker verbreitet im nord- und westeuropäischen Raum. Es wird zum Beispiel in den Niederlanden, Dänemark oder im Peppol-Netzwerk genutzt.

  • CII ist semantisch strenger und stammt von UN/CEFACT. Es legt mehr Wert auf formale Klarheit, ist dafür komplexer in der Umsetzung. Deutschland setzt bei der XRechnung teilweise auf CII, ebenso ZUGFeRD.

Die Existenz beider Formate ist historisch und politisch bedingt. Die EU wollte mit EN 16931 einheitliche Inhalte vorgeben, hat aber bewusst zwei technische Varianten zugelassen, damit nationale Standards flexibel darauf aufbauen können.

Peppol ist kein klassisches EDI wie EDIFACT oder ANSI X12, sondern eine moderne Infrastruktur für den strukturierten Dokumentenaustausch über offene Standards. Während traditionelles EDI meist auf proprietären Formaten, bilateralen Verbindungen und individuellen Schnittstellen basiert, nutzt Peppol standardisierte Formate wie UBL sowie ein offenes, europaweit vernetztes System mit eindeutigen Peppol-IDs.

EDI bietet Vorteile wie hohe Prozessautomatisierung, direkte Systemintegration und schnellen Datenaustausch. Es ist jedoch häufig teuer in der Einrichtung, wartungsintensiv und wenig interoperabel. Genau hier setzt Peppol an: Es reduziert Komplexität, senkt Integrationskosten und ist interoperabel zwischen Unternehmen, Behörden und Ländern.

Peppol kann klassisches EDI in vielen Anwendungsfällen vollständig ersetzen, insbesondere bei der Übertragung strukturierter Rechnungen im B2B und B2G Bereich. Für hochindividuelle EDI-Szenarien in der Industrie bleibt klassisches EDI teils relevant, Peppol bietet aber eine zukunftssichere, standardisierte Alternative für alle, die interoperabel, gesetzeskonform und kosteneffizient Rechnungen digital austauschen möchten.

Nein. Nach EN 16931 müssen Rechnungen immer mit Nettopreisen erstellt werden. Die Umsatzsteuer ist separat auszuweisen. Eine Darstellung mit Bruttopreisen ohne Aufschlüsselung ist nicht zulässig, da strukturierte elektronische Rechnungen maschinell verarbeitet und steuerlich eindeutig geprüft werden müssen.

Diese Vorgabe gilt unabhängig vom verwendeten Format, ob XRechnung, ZUGFeRD oder ein anderes EN 16931 konformes Schema. Auch wenn im PDF-Teil von ZUGFeRD zusätzliche Informationen enthalten sind, gelten für die maschinenlesbare XML-Datei die Nettopreisregelungen verbindlich.

Ein Sicherheitseinbehalt muss in einer elektronischen Rechnung strukturiert und nachvollziehbar ausgewiesen werden. Der Betrag darf nicht einfach vom Gesamtwert abgezogen oder nur als Freitext erwähnt werden. Stattdessen wird der Einbehalt als eigene Rechnungsposition mit negativer Menge und positivem Einzelpreis dargestellt. Beispiel: „Sicherheitseinbehalt 5 Prozent gemäß Vertrag“, Menge minus eins, Einzelpreis 500 Euro. Der Einbehalt reduziert so den Zahlbetrag sichtbar und entspricht den Vorgaben der EN 16931. In der Schlussrechnung wird diese Position nicht erneut aufgeführt, der zurückgehaltene Betrag wird dann vollständig zur Zahlung fällig. Negative Einzelpreise sind in der XRechnung nicht erlaubt, nur negative Mengen sind zulässig. Diese Modellierung ist maschinenlesbar, validierungsfähig und wird auch von öffentlichen Auftraggebern wie der Deutschen Bahn akzeptiert.

Eine Stornorechnung wird in der elektronischen Rechnungsstellung durch den TypeCode 381 gekennzeichnet. Dieser Typ steht für eine Gutschrift und wird verwendet, wenn eine bereits ausgestellte Rechnung ganz oder teilweise storniert werden soll. Die Beträge werden dabei als negative Werte dargestellt, typischerweise über negative Mengen. Eine Referenz auf die ursprüngliche Rechnung, etwa über die Rechnungsnummer und das Ausstellungsdatum, ist empfohlen, um die Zuordnung maschinell nachvollziehbar zu machen.

Im Unterschied dazu steht der TypeCode 384 für eine Rechnung mit negativem Gesamtbetrag. Diese wird verwendet, wenn zum Beispiel ein Guthaben oder ein nachträglicher Preisnachlass abgerechnet wird, ohne dass eine bestehende Rechnung storniert wird. Es handelt sich dabei um eine neue Rechnung mit negativer Wirkung, nicht um eine klassische Stornorechnung.

In der Praxis gilt: Wenn du eine Rechnung korrigieren oder zurücknehmen willst, nutze TypeCode 381. Wenn du ein Guthaben abrechnen möchtest, ohne einen Bezug zu einer konkreten Rechnung herzustellen, ist TypeCode 384 die richtige Wahl. Beide Varianten sind EN 16931 konform und werden von XRechnung und ZUGFeRD unterstützt.

Fiskalisch relevant sind bei einer elektronischen Rechnung ausschließlich die strukturierten XML-Daten. Das gilt sowohl für XRechnung als auch für ZUGFeRD. Das PDF dient bei ZUGFeRD lediglich der visuellen Darstellung, hat aber keine steuerliche oder rechtliche Relevanz im Sinne der GoBD oder des Umsatzsteuergesetzes. Maßgeblich für die maschinelle Verarbeitung, die Prüfung durch den Rechnungsempfänger und die Archivierung ist der XML-Datensatz nach EN 16931.

Auch bei einer hybriden Rechnung wie ZUGFeRD ist allein die XML-Komponente entscheidend für die steuerliche Gültigkeit. Unternehmen sollten daher sicherstellen, dass ausschließlich die XML-Daten korrekt, vollständig und unveränderbar archiviert werden.

Nach GoBD müssen alle steuerlich relevanten Unterlagen vollständig, unveränderbar, maschinell auswertbar und nachvollziehbar archiviert werden. Bei elektronischen Rechnungen bedeutet das: Es ist der strukturierte XML-Datensatz zu archivieren, nicht nur das visuelle PDF. Das gilt unabhängig davon, ob es sich um eine XRechnung oder um eine ZUGFeRD-Rechnung handelt.

Bei ZUGFeRD enthält das PDF zwar die visuelle Darstellung, doch archiviert werden muss das gesamte PDF/A-3 mit eingebettetem XML-Anteil, da nur so die Anforderungen an Vollständigkeit und maschinelle Auswertbarkeit erfüllt sind. Bei XRechnung ist allein die XML-Datei maßgeblich und muss im Originalzustand gespeichert werden.

Zusätzlich müssen alle zugehörigen Informationen, wie Prüfprotokolle, Freigabevermerke und Eingangsbestätigungen, ebenfalls nachvollziehbar und sicher aufbewahrt werden. Die Aufbewahrungsfrist beträgt grundsätzlich zehn Jahre.

Beim Empfang einer elektronischen Rechnung muss in erster Linie der strukturierte XML-Datensatz nach EN 16931 verarbeitet werden. Dieser enthält alle steuerlich relevanten Inhalte wie Rechnungsbetrag, Steuersätze, Positionen, Lieferdaten, Rechnungssteller und Empfänger. Das visuelle Layout, etwa ein beigefügtes PDF, ist nicht entscheidend.

Das empfangende System muss die XML-Daten maschinell einlesen, prüfen und archivieren können. Dazu gehört auch die Validierung auf technische Korrektheit, z. B. ob Pflichtfelder wie Rechnungsnummer oder Steuersatz vorhanden und korrekt befüllt sind. Fehlerhafte Rechnungen müssen abgelehnt oder mit einem Prüfvermerk versehen werden. Zusätzlich sollten optional eingebettete Dokumente wie Leistungsnachweise oder Aufmaße ausgewertet oder archiviert werden.

Für eine GoBD-konforme Verarbeitung ist auch sicherzustellen, dass der Prüfverlauf, etwa durch Freigabevermerke oder Kommentare, dokumentiert wird. Nur so ist die Nachvollziehbarkeit im Rahmen einer Betriebsprüfung gewährleistet.

Für die XRechnung gilt stets die von der Koordinierungsstelle für IT-Standards (KoSIT) freigegebene aktuelle Version. Welche Version aktuell verpflichtend ist, legt die KoSIT zentral fest. Nur Rechnungen, die diesem gültigen Standard entsprechen, werden von öffentlichen Auftraggebern akzeptiert. Ältere Versionen verlieren regelmäßig ihre Gültigkeit und dürfen dann nicht mehr verwendet werden. Faktoora stellt sicher, dass automatisch immer die jeweils zulässige Version verwendet wird. Die aktuell gültige XRechnung-Version finden Sie direkt bei der KoSIT.

In vielen Branchen ist die prozentuale Abrechnung gängige Praxis, etwa bei Abschlagsrechnungen im Bauwesen, im Anlagenbau oder bei Planungsleistungen nach HOAI. Dabei werden erbrachte Teilleistungen als Prozentsatz abgerechnet, zum Beispiel 80 Prozent einer Position. Elektronische Rechnungen nach EN 16931  (also im Format ZUGFeRD oder XRechnung) unterstützen jedoch keine direkte Prozentangabe. Die Norm verlangt eine konkrete Mengenangabe und einen Einheitspreis pro Position. Eine Angabe wie „80 Prozent“ ist daher nicht zulässig.

Die Lösung: Die prozentuale Leistung wird rechnerisch über die Menge dargestellt. Beispiel: Für 80 Prozent einer Position mit der Einheit „Stück“ erfassen Sie die Menge 0.8. So bleibt die Rechnung normkonform, maschinenlesbar und automatisiert prüfbar.

Rechnungsbegründende Unterlagen wie Aufmaße oder Leistungsnachweise können direkt in der Rechnungsmaske hochgeladen werden. Faktoora bettet diese Dateien grundsätzlich in das XML ein – unabhängig vom Format. Sowohl bei XRechnung als auch bei ZUGFeRD werden Anhänge base64-kodiert im XML mitgeführt. Das entspricht der Vorgabe bei XRechnung und ist bei ZUGFeRD eine bewährte Praxis, um sicherzustellen, dass alle relevanten Informationen vollständig, maschinenlesbar und revisionssicher übermittelt und archiviert werden. Externe Verlinkungen sind nicht nötig und werden von vielen Empfängersystemen ohnehin nicht unterstützt.

BT-Felder (Business Terms) sind klar definierte Datenfelder im EN16931 Standard, der die Grundlage für XRechnung und ZUGFeRD bildet. Jedes BT-Feld gibt präzise vor, welche Information in welchem Format in das jeweilige Feld eingetragen werden muss, zum Beispiel BT-20 für das Rechnungsdatum oder BT-126 für den Gesamtbetrag. Diese eindeutige Struktur ermöglicht die maschinelle Prüfung und automatisierte Verarbeitung elektronischer Rechnungen. Gleichzeitig vereinfacht sie die Abstimmung zwischen den Beteiligten, da klar ist, wo welche Angaben erwartet werden.

Ja. Mit Faktoora können Sie Baurechnungen mit den Rechnungstypen 875 (Abschlagsrechnung), 876 (Teilrechnung) und 877 (Schlussrechnung) erstellen. Diese Typecodes sind Teil des EN16931 Standards und kennzeichnen den jeweiligen Rechnungszweck. Für eine vollständige und prüfbare Baurechnung können Sie erforderliche Unterlagen wie Aufmaße oder Leistungsnachweise direkt in der Rechnungsmaske hochladen. Diese werden automatisch als Anhang im XML eingebettet. Bei Schlussrechnungen müssen alle vorhergehenden Abschlagszahlungen korrekt angegeben werden, um die elektronische Rechnung vollständig und nachvollziehbar zu machen.

Ja. In Faktoora können Sie Rechnungen erstellen, die alle relevanten GS1-Daten enthalten. Sie können GLNs sowohl für den Warenempfänger als auch für den Rechnungsempfänger angeben, Ihre eigene GLN hinterlegen und auf Positionsebene GTINs zuordnen. Diese Funktionen erfüllen zentrale Anforderungen des Einzelhandels und des GS1-Standards und sind besonders wichtig im Retail-Umfeld, wo klare Identifikation von Produkten und Geschäftspartnern erforderlich ist. Faktoora unterstützt diese Angaben vollständig im Rahmen von ZUGFeRD und XRechnung.

Ja. Sie können Faktoora komplett ohne Softwareanbindung nutzen. Über das browserbasierte Webinterface erstellen Sie elektronische Rechnungen direkt online, ohne Installation oder Schnittstelle. Die Plattform ist eigenständig nutzbar und bietet alle Funktionen zur Erstellung, Validierung und Archivierung von XRechnung oder ZUGFeRD konformen Rechnungen. Alternativ steht eine REST API für die Systemintegration zur Verfügung.

Faktoora bietet drei klar strukturierte Tarife, passend für jede Unternehmensgröße und jeden Anwendungsfall. Jeder Kunde startet mit einer kostenlosen einmonatigen Testphase, ganz ohne Abo-Falle. Die Testphase endet automatisch, es ist keine Kündigung nötig.

Der Einstiegstarif ab 9,00 € netto pro Monat richtet sich an Selbstständige und kleine Dienstleister, die einfache Rechnungen über das Webinterface erstellen möchten – ideal für B2C-Geschäftsmodelle ohne elektronische Rechnungen.

Der Business-Tarif ab 29,00 € pro Monat ermöglicht den Versand und Empfang normkonformer elektronischer Rechnungen nach ZUGFeRD oder XRechnung. Damit ist er optimal für mittelständische Unternehmen mit B2B-Fokus, die rechtssicher und effizient abrechnen wollen.

Für Unternehmen mit hohem Volumen, komplexen Anforderungen oder ERP-Systemen bietet der Enterprise-Tarif ab 129,00 € pro Monat die vollständige Spezifikation nach EN 16931. Inklusive API-Anbindung, Anhängen, komplexer Typcodes und automatisierter Verarbeitung.

Alle Funktionen und Preise finden Sie hier

Testen Sie Faktoora 30 Tage kostenlos –  keine Kündigung notwendig.

Ja. Faktoora bietet eine leistungsfähige REST API zur automatisierten Erstellung, dem Versand und dem Empfang elektronischer Rechnungen nach EN 16931. Die Schnittstelle ist speziell auf hohe Rechnungsvolumen und einfache Integration in bestehende Systeme ausgelegt, etwa in ERP oder Dokumentenmanagementlösungen. Auch die Verarbeitung ganzer Rechnungsstapel per Batch ist möglich. Faktoora ist damit ideal für Unternehmen, die ihre Rechnungsprozesse skalierbar und effizient digitalisieren möchten. Die vollständige API-Dokumentation finden Sie hier: https://docs.faktoora.com/

Ja. Faktoora unterstützt strukturierte Freigabeprozesse sowohl beim Erstellen als auch beim Empfangen von Rechnungen. Ausgangsrechnungen können zum Beispiel nach dem Vier-Augen-Prinzip erstellt werden, bei dem etwa ein Projektverantwortlicher die Rechnung vorbereitet und die Buchhaltung die finale Freigabe erteilt. Für Eingangsrechnungen stehen regelbasierte Prüfmechanismen zur Verfügung, mit denen Rechnungen automatisch oder manuell akzeptiert oder abgelehnt werden können. Zusätzlich können weitere Freigabestufen definiert werden, um individuelle Compliance-Anforderungen abzubilden. Faktoora legt besonderen Fokus auf smarte Workflows, die sich flexibel an bestehende Abläufe anpassen lassen und für Transparenz und Kontrolle im gesamten Rechnungsprozess sorgen.

Weitere Informationen zu dem Rechnungseingangsprozess finden sie u.a. hier: https://faktoora.com/wissensdatenbank/eingangsrechnungspruefung/

Rechnungen können mit Faktoora flexibel versendet werden. Der Versand ist per E-Mail über unseren Mailserver, über einen eigenen SMTP-Server oder über das Peppol-Netzwerk möglich. Alternativ kann die fertige elektronische Rechnung auch heruntergeladen und manuell versendet werden. Der passende Versandweg richtet sich nach den Anforderungen des Empfängers und Ihren internen Prozessen. Eine Anleitung zur Einrichtung des SMTP-Versands finden Sie in unserer Wissensdatenbank unter SMTP einstellen und versenden.

Rechnungen können mit Faktoora flexibel versendet werden. Der Versand ist per E-Mail über unseren Mailserver, über einen eigenen SMTP-Server oder über das Peppol-Netzwerk möglich. Alternativ kann die fertige elektronische Rechnung auch heruntergeladen und manuell versendet werden. Der passende Versandweg richtet sich nach den Anforderungen des Empfängers und Ihren internen Prozessen. Eine Anleitung zur Einrichtung des SMTP-Versands finden Sie in unserer Wissensdatenbank unter SMTP einstellen und versenden.

Ja. Faktoora unterstützt den Empfang elektronischer Rechnungen im EN16931 Format, also sowohl ZUGFeRD als auch XRechnung. Der Empfang ist möglich per E-Mail, Upload oder über das Peppol-Netzwerk. E-Mails können an ein Faktoora-Postfach gesendet oder über ein eigenes IMAP-Konto empfangen werden. Eingehende Rechnungen werden automatisch verarbeitet, strukturell und inhaltlich validiert und visuell aufbereitet. Bei Fehlern erhält der Absender unmittelbar einen detaillierten Fehlerbericht. Zusätzlich können nur autorisierte Absender über Whitelisting zugelassen werden. Nach erfolgreicher Prüfung lassen sich Rechnungen manuell ablehnen, freigeben oder direkt über die Bankintegration bezahlen. Weitere Informationen finden Sie unter Eingangsrechnungsprüfung.

Ja. Faktoora bietet eine direkte Integration in DATEV Unternehmen Online über den DATEV Rechnungsdatenservice. Sowohl Eingangs- als auch Ausgangsrechnungen können automatisiert an den Steuerberater übergeben werden. Dabei werden alle buchhaltungsrelevanten Daten im richtigen Format übermittelt, inklusive Belegdaten und Anhängen. Die Anbindung spart manuellen Aufwand und sorgt für eine saubere Übergabe in die Finanzbuchhaltung. Faktoora ist offiziell gelisteter Schnittstellenpartner im DATEV Marktplatz unter https://www.datev.de/web/de/marktplatz/datev-schnittstellen-anbieter/

Ja. Neben dem Standardlayout bietet Faktoora die Möglichkeit, individuelle Rechnungsvorlagen bereitzustellen. Diese Funktion ist optional und kostenpflichtig und richtet sich an Unternehmen, die besonderen Wert auf ein eigenes Rechnungsdesign legen. Technisch ist dies vor allem bei ZUGFeRD relevant, da dort ein gestaltetes PDF zusammen mit den strukturierten XML-Daten versendet wird. Bei reinen XRechnungen hingegen wird nur die XML-Datei übermittelt, das Layout spielt dabei keine Rolle mehr, da ausschließlich die strukturierten Daten für die Verarbeitung und Prüfung verwendet werden.

Ja. Ab dem Enterprise-Tarif können mehrere Nutzer mit individuellen Berechtigungen angelegt werden. So lassen sich Rollen gezielt steuern, etwa für Erfassung, Prüfung oder Freigabe von Rechnungen. Das ist besonders relevant für Unternehmen mit definierten Freigabeprozessen oder Compliance-Anforderungen. Alle Aktionen werden audit-sicher protokolliert. Grundsätzlich ist es auch möglich, dass sich mehrere Personen ein Login teilen, zum Beispiel bei Urlaubsvertretungen. Bei gleichzeitiger Nutzung eines Benutzerkontos durch mehrere Mitarbeitende übernimmt Faktoora jedoch keine Haftung für eventuelle Dateninkonsistenzen.

Ja. Faktoora unterstützt die Erstellung elektronischer Rechnungen mit ausländischer Steuernummer oder internationaler VAT ID sowohl für Rechnungsaussteller als auch für Rechnungsempfänger. Sie können grenzüberschreitende Rechnungen nach EN 16931 erstellen, zum Beispiel bei innergemeinschaftlichen Lieferungen oder Leistungen an ausländische Geschäftskunden. Ob in einem konkreten Fall eine Pflicht zur elektronischen Rechnung in Deutschland besteht, hängt von den steuerlichen Rahmenbedingungen ab. Bei Fragen zur Verwendung einer ausländischen Steuernummer oder zur richtigen Rechnungsstellung ins Ausland beraten wir Sie gerne. Nutzen Sie dafür unser Kontaktformular unter https://faktoora.com/kontakt/

Die Integrationsdauer der faktoora eInvoicing API hängt stark vom angebundenen System, der Integrationstiefe, den verfügbaren Entwicklungsressourcen und der internen Datenstruktur ab. In der Praxis sollte für eine vollständige Umsetzung bis zum produktiven Go-Live mit 4 bis 8 Wochen gerechnet werden. Wir setzen bewusst auf bewährte und bekannte Konzepte und bieten eine klare, gut dokumentierte Schnittstelle für eine einfache Integration. Eine technische Übersicht zu Abläufen und Datenfeldern finden Sie unter https://docs.faktoora.com/docs/getting-started. Bei Fragen zur Integration oder Abstimmung von Datenfeldern beraten wir Sie gerne direkt unter faktoora.com/kontakt.

Elektronische Rechnungen werden bei Faktoora GoBD-konform und revisionssicher archiviert. Im revisionssicheren Modus sind Rechnungen nach der Erstellung nicht mehr veränderbar, um die Unveränderbarkeit nach GoBD sicherzustellen. Ein Export der Daten ist jederzeit durch den Nutzer möglich, zum Beispiel für die eigene Archivierung oder externe Backups. Alle Daten werden datenschutzkonform auf unseren Servern gespeichert. Weitere Informationen zu unserer Datensicherheit finden Sie in unserem SLA: https://faktoora.com/dokumente/service-level-agreement/

Allgemein

Funktionen

Rechtlich

© by faktoora.com. Die Online Rechnungssoftware für den Mittelstand.

E-Rechnungs-Check

Wer muss umstellen – wer nicht? Erhalten Sie in nur 30 Sekunden Klarheit, ob auch Ihr Unternehmen betroffen ist und welche Schritte jetzt nötig sind.

🚀 Kostenlosen Check starten