Eigenes Rechnungsmodul für E-Rechnungen nachrüsten: FileMaker, Access und Datenbanken weiter nutzen

Eigenes Rechnungsmodul für E-Rechnungen nachrüsten: FileMaker, Access und Datenbanken weiter nutzen

Ein selbst entwickeltes Rechnungsmodul ist oft über Jahre mit dem Unternehmen gewachsen. Kundenstammdaten, Preise, Nummernkreise, Freigaben und besondere Abrechnungsregeln funktionieren – nur XRechnung oder ZUGFeRD fehlen. Deshalb muss die vorhandene FileMaker-, Access- oder Datenbanklösung nicht automatisch ersetzt werden.

Der richtige Weg besteht darin, den bewährten Rechnungsprozess um eine klar abgegrenzte E-Rechnungsstrecke zu ergänzen. Das eigene System bleibt für die kaufmännischen Fakten verantwortlich. Eine nachgelagerte Komponente übernimmt die Zuordnung zu einem neutralen Datenmodell, erzeugt das benötigte Format, validiert das Ergebnis und gibt einen eindeutigen Status zurück.

Dabei gibt es drei realistische Integrationswege: strukturierte Daten per API, ein kontrollierter Datei- oder Datenbankexport und die Verarbeitung einer stabilen digitalen PDF-Rechnung. Welcher Weg passt, hängt weniger vom Produktnamen als von Datenqualität, Änderbarkeit, Rechnungsvolumen und Sonderfällen ab.

Die kurze Antwort: Nachrüsten statt neu entwickeln

Ein vorhandenes Rechnungsmodul lässt sich für E-Rechnungen nachrüsten, wenn es die maßgeblichen Rechnungsdaten zuverlässig bereitstellen kann oder zumindest ein stabiles, digitales Rechnungs-PDF erzeugt. Das Bundesfinanzministerium stellt klar, dass ein einfaches PDF allein keine E-Rechnung ist. Die umsatzsteuerrechtlichen Pflichtangaben müssen im strukturierten Teil enthalten sein, damit eine elektronische Weiterverarbeitung möglich ist. Die aktuelle Einordnung finden Sie in der BMF-FAQ zur E-Rechnung.

Für die Nachrüstung bedeutet das:

1. Das eigene System schließt die Rechnung fachlich ab.
2. Rechnungsdaten oder PDF werden an einen definierten Übergabepunkt gegeben.
3. Die Daten werden einem festen fachlichen Modell zugeordnet.
4. XRechnung oder ZUGFeRD wird erzeugt und mit den passenden Regeln geprüft.
5. Nur ein freigegebenes Ergebnis darf versendet oder archiviert werden.
6. Erfolg oder Fehler gehen nachvollziehbar an das Ausgangssystem zurück.

Eine solche Ergänzung ist keine universelle Standardschnittstelle. FileMaker-, Access- und Eigenentwicklungen unterscheiden sich in Tabellen, Skripten, Formularen und Berechtigungen. Ein belastbarer Prozess beginnt deshalb mit dem tatsächlichen Datenmodell und echten Belegvarianten – nicht mit einer pauschalen Zusage anhand des Systemnamens.

Zuerst entscheiden: XRechnung oder ZUGFeRD?

Die Integrationsart und das Ausgabeformat sind zwei getrennte Entscheidungen. Eine API kann XRechnung oder ZUGFeRD liefern. Ebenso kann ein CSV-Export als Quelle für beide Formate dienen.

XRechnung ist ein strukturierter XML-Standard, der besonders im Rechnungsaustausch mit öffentlichen Auftraggebern verwendet wird. XStandards Einkauf beschreibt die Rechnung selbst als XML-Datensatz, dessen Informationen von unterschiedlichen Systemen weiterverarbeitet werden können. Welche aktuelle Spezifikation und welche technischen Komponenten gelten, sollte eine produktive Lösung aus der offiziellen Übersicht der XRechnung und den Versionen und Bundles beziehen.

ZUGFeRD verbindet eine sichtbare PDF/A-3-Datei mit eingebetteten strukturierten XML-Daten. Diese Kombination ist für viele B2B-Prozesse praktisch, weil Menschen weiterhin ein Rechnungsbild sehen und Buchhaltungssysteme die eingebetteten Daten verarbeiten können. Wichtig ist die fachliche Übereinstimmung beider Bestandteile. Bei Abweichungen ist nach der BMF-Einordnung der strukturierte Teil maßgeblich. Die Spezifikationen und Profile veröffentlicht das Forum elektronische Rechnung Deutschland.

Legen Sie das Format nicht global für alle Rechnungen fest. Ein Empfängerprofil kann beispielsweise XRechnung und eine bestimmte Käuferreferenz verlangen, während ein anderer Empfänger ZUGFeRD bevorzugt. Diese Regel gehört in die Prozesskonfiguration, nicht in eine manuelle Erinnerungsliste.

Drei Wege aus FileMaker, Access oder einer eigenen Datenbank

Weg 1: Strukturierte Übergabe per API

Die API-Anbindung ist meist die stärkste Lösung, wenn Rechnungen regelmäßig oder in größerer Zahl entstehen und die Quelldaten bereits strukturiert vorliegen. Das eigene Rechnungsmodul übermittelt ein definiertes JSON-Objekt oder stellt seine Daten über eine dokumentierte Schnittstelle bereit. Die E-Rechnungsschicht gibt Datei, Validierungsstatus und eine eindeutige Vorgangskennung zurück.

Bei FileMaker kann – abhängig von Hosting, Version, Konfiguration und Berechtigungen – die offizielle FileMaker Data API ein möglicher Zugriffspunkt sein. Claris dokumentiert REST-Aufrufe mit JSON-Daten, Sitzungsauthentifizierung und Operationen zum Lesen, Suchen und Bearbeiten von Datensätzen. Das ist eine technische Möglichkeit, aber noch kein fertiger E-Rechnungs-Connector. Tabellen, Layouts, Feldnamen und Freigabelogik müssen weiterhin für die jeweilige Lösung definiert werden.

Eine E-Rechnung API ist sinnvoll, wenn der Prozess Statusrückgaben, automatische Wiederholungen, mehrere Ausgabeformate oder eine Übergabe an weitere Systeme benötigt. Die API sollte aber nur abgeschlossene Rechnungsstände erhalten. Ein Datensatz, der während der Verarbeitung noch verändert werden kann, führt sonst zu unterschiedlichen Ständen in Buchung, PDF und XML.

Weg 2: Strukturierter Export oder kontrollierter Datenbankzugriff

Nicht jede Eigenentwicklung kann Web-APIs aufrufen. Ein versionierter Export aus einer Abfrage ist dann oft einfacher und ebenso belastbar. Mögliche Übergaben sind CSV, JSON, XML oder ein klar definiertes Datenbank-View. Entscheidend sind stabile Spalten, eindeutige Datentypen, eine unveränderliche Rechnungs-ID und eine dokumentierte Bedeutung jedes Feldes.

Microsoft beschreibt für Access den Export von Tabellen und Abfragen in getrennte oder festbreite Textdateien. Für eine E-Rechnungsstrecke ist eine gespeicherte Abfrage mit festem Exportlayout besser als ein manueller Export wechselnder Bildschirmansichten. Access kann außerdem über ODBC mit externen Datenquellen arbeiten; dafür sind ein passender Treiber sowie eine DSN- oder Verbindungszeichenfolge erforderlich. Diese Technik ist ein Zugriffsweg, kein Ersatz für Datenvertrag, Steuerlogik und Validierung.

Auch FileMaker kann laut Claris-Dokumentation als ODBC- oder JDBC-Datenquelle für kompatible Anwendungen dienen. Ein lesender Zugriff kann sich eignen, wenn eine vorhandene Lösung nicht verändert werden soll. Er sollte jedoch auf einer freigegebenen, stabilen Datenansicht beruhen. Direkte Abfragen auf zufällig beobachtete Tabellen oder berechnete Layoutfelder sind im Betrieb zu fragil.

Weg 3: Stabile PDF-Rechnung als Brücke

Wenn das System ausschließlich verlässliche digitale PDF-Rechnungen ausgeben kann, ist eine PDF-Brücke der schnellste Einstieg. Das Rechnungsmodul erzeugt das bekannte PDF, die Daten werden kontrolliert ausgelesen und zu XRechnung oder ZUGFeRD ergänzt. Der konkrete ERP-PDF-zu-ZUGFeRD-Prozess zeigt, welche Belege und Pflichtfelder vorab geprüft werden sollten.

Dieser Weg passt vor allem zu einheitlichen, maschinell erzeugten Layouts. Er wird schwächer bei Scans, handschriftlichen Ergänzungen, häufig wechselnden Tabellen, fehlenden Steuerinformationen oder Daten, die nur intern vorhanden sind. Es gibt keine seriöse allgemeine Erkennungsquote für jede Rechnung. Ein Pilot muss deshalb für jedes relevante Layout zeigen, welche Felder sicher gelesen werden und wann eine manuelle Prüfung notwendig ist.

Eine PDF-Brücke kann dauerhaft tragfähig sein, wenn Volumen und Belegvielfalt überschaubar sind und eine kontrollierte Freigabe vorgesehen ist. Bei vielen Sonderfällen oder vollständiger Dunkelverarbeitung ist ein strukturierter Datenweg meist robuster. Der allgemeine Leitfaden Alte Software für E-Rechnungen nachrüsten hilft bei der Abwägung zwischen Weiterbetrieb, Ergänzung und Systemwechsel.

Entscheidungsmatrix: Welcher Integrationsweg passt?

Häufig ist ein gestufter Weg sinnvoll: zunächst PDF-Muster prüfen, parallel den strukturierten Export definieren und erst nach stabilen Abnahmekriterien vollständig automatisieren. Einen produktunabhängigen Überblick bietet ERP zu E-Rechnung.

Der Datenvertrag: Was das eigene Rechnungsmodul liefern muss

Ein Datenvertrag beschreibt nicht die XML-Syntax, sondern die kaufmännische Bedeutung der Eingangsdaten. So bleibt das eigene Modul unabhängig davon, ob am Ende UBL, CII, XRechnung oder ZUGFeRD erzeugt wird.

Mindestens diese Bereiche sollten ausdrücklich definiert sein:

Die offizielle Zuordnung der UStG-Pflichtangaben zur EN 16931 ist eine gute Orientierung für die fachliche Zuordnung. Sie ersetzt jedoch nicht die Prüfung Ihrer Rechnungsarten und Empfängeranforderungen.

Ein vereinfachtes neutrales Übergabeobjekt kann so aussehen:

json
{
  "invoiceId": "RE-2026-00418",
  "issuedAt": "2026-08-18",
  "documentType": "invoice",
  "currency": "EUR",
  "sellerId": "MANDANT-01",
  "buyer": {
    "customerId": "K-1048",
    "name": "Beispiel GmbH",
    "electronicAddress": "rechnung@beispiel.de"
  },
  "references": {
    "buyerReference": "PROJEKT-4711",
    "purchaseOrder": "PO-8852"
  },
  "lines": [
    {
      "position": 1,
      "description": "Wartungsleistung August",
      "quantity": 1,
      "unitCode": "C62",
      "netUnitPrice": 480.00,
      "vatCategory": "S",
      "vatRate": 19.00
    }
  ],
  "totals": {
    "net": 480.00,
    "vat": 91.20,
    "payable": 571.20
  },
  "output": {
    "format": "zugferd",
    "recipientProfile": "b2b-standard"
  }
}

Das Beispiel ist bewusst kein fertiges RechneX-Schnittstellenschema. Es zeigt, welche fachlichen Entscheidungen vor einer technischen Implementierung nötig sind. Insbesondere Steuerbefreiungen, mehrere Steuergruppen, Gutschriften, Abschläge und Schlussrechnungen brauchen zusätzliche Felder und Regeln.

Architektur: Vom freigegebenen Beleg zur geprüften E-Rechnung

Ein verständlicher Zielablauf sieht so aus:

text
FileMaker / Access / eigene Datenbank
        ↓ Rechnung fachlich abschließen
Unveränderlicher Rechnungsstand mit eindeutiger ID
        ↓ API, Export, ODBC/JDBC oder PDF
Normalisierung in ein neutrales Rechnungsmodell
        ↓
Feldmapping + Summen-, Steuer- und Empfängerregeln
        ↓ bei Fehler: sperren und gezielt zurückmelden
XRechnung oder ZUGFeRD erzeugen
        ↓
Formatspezifisch validieren
        ↓ bei Erfolg: freigeben
Download / Versand / Archivübergabe + Statusrückgabe

Die wichtigste Grenze liegt direkt nach dem Rechnungsabschluss. Die E-Rechnungsstrecke sollte einen unveränderlichen Snapshot erhalten. Ändert die Buchhaltung danach Betrag, Empfänger oder Positionen, muss eine neue Version beziehungsweise eine fachlich korrekte Berichtigung erzeugt werden. Das verhindert, dass PDF, XML und Buchung unterschiedliche Wahrheiten enthalten.

Validierung auf drei Ebenen

Eine erzeugte Datei ist noch kein belastbares Ergebnis. Prüfen Sie drei Ebenen getrennt:

1. Quelldaten: Ist der Datensatz tatsächlich eine Ausgangsrechnung? Sind Belegart, Empfänger, Positionen und Summen vollständig und fachlich freigegeben?
2. Datenzuordnung: Wurde jedes Quellfeld der richtigen Bedeutung zugeordnet? Eine interne Kundennummer darf nicht versehentlich als Steuerkennung oder Käuferreferenz ausgegeben werden.
3. Zielformat: Besteht die Datei die geltenden technischen und fachlichen Regeln für XRechnung beziehungsweise ZUGFeRD?

XStandards Einkauf stellt für XRechnung normative und technische Komponenten sowie eine Validator-Konfiguration bereit. Da technische Artefakte und Codelisten fortgeschrieben werden, muss die eingesetzte Prüfversion im Betrieb nachvollziehbar sein. Für einen schnellen Dateicheck können Sie den XRechnung-Validator nutzen. Hybride Rechnungen benötigen zusätzlich eine passende Prüfung von XML, Profil und Einbettung; dafür gibt es den ZUGFeRD-Validator.

Eine erfolgreiche Validierung bestätigt nicht, dass die Leistung wirklich erbracht wurde, der Empfänger fachlich stimmt oder eine Steuerbefreiung sachlich berechtigt ist. Diese Verantwortung bleibt im Rechnungsprozess. Umgekehrt sollte ein technischer Fehler den Versand immer blockieren.

Fehlerbehandlung: Im Zweifel stoppen, nicht raten

In realen Eigenentwicklungen sehen Dokumente häufig ähnlicher aus, als ihre fachliche Bedeutung vermuten lässt. Eine Ausgangsrechnung, ein interner Buchungsbeleg und eine Korrektur können dasselbe Grundlayout verwenden. Ebenso können Summen sichtbar widersprüchlich sein oder interne Identifikatoren wie eine offizielle Kennung aussehen. Deshalb braucht die Nachrüstung eine strikte Sperrlogik.

Typische blockierende Fehler sind:

• unbekannte oder nicht freigegebene Dokumentart
• fehlende Rechnungsnummer oder nicht eindeutige Vorgangs-ID
• widersprüchliche Positions-, Steuer- und Gesamtsummen
• fehlende Steuerkategorie oder unpassende Kombination aus Kategorie und Steuersatz
• fehlende Käuferreferenz bei einem Empfängerprofil, das sie verlangt
• unsichere Feldzuordnung, etwa zwischen Kundennummer, Vertragsnummer und Steuerkennung
• Abweichung zwischen sichtbarem ZUGFeRD-PDF und strukturierten Daten
• Validierungsfehler im Zielformat

Die Fehlermeldung sollte Vorgangs-ID, Feld, Fehlercode, verständliche Beschreibung und möglichen Korrekturweg enthalten. „Konvertierung fehlgeschlagen“ reicht nicht. Nach einer Korrektur muss derselbe Vorgang wiederholbar sein, ohne versehentlich zwei Rechnungen zu versenden. Dafür sind idempotente Verarbeitung, eindeutige Statuswerte und ein Versandnachweis wichtiger als komplizierte Automatik.

Sensible Rechnungsdaten sicher behandeln

Rechnungen können personenbezogene, vertragliche oder andere besonders schützenswerte Angaben enthalten. Übertragen und speichern Sie deshalb nur Daten, die für Erzeugung, Prüfung und vereinbarten Folgeprozess erforderlich sind.

Ein tragfähiges Schutzkonzept umfasst mindestens:

• anonymisierte oder wirksam pseudonymisierte Belege in Entwicklung und Pilot, soweit der Testzweck das erlaubt
• getrennte Test- und Produktivzugänge
• minimale, rollenbasierte Berechtigungen für Datenbank, Exportordner und API
• verschlüsselte Übertragung und geschützte Zugangsdaten
• keine Rechnungsinhalte, Personenkennzeichen oder kompletten API-Nutzdaten in normalen Anwendungsprotokollen
• festgelegte Aufbewahrungs- und Löschregeln für Zwischenstände und Fehlervorgänge
• ausdrückliche Freigabe des Versandwegs und des Empfängers
• dokumentierter Umgang mit Supportzugriffen und Sicherheitsvorfällen

Wenn Rechnungen besondere Datenkategorien oder branchenspezifische Geheimnisse enthalten, reicht eine Standardanbindung möglicherweise nicht. Dann sollten Datenumfang, Unterauftragnehmer, Versand, Löschung und Freigaben vor dem Pilot ausdrücklich vereinbart werden. Die Enterprise-Lösung ist der passende Einstieg für solche individuellen Anforderungen.

Pilot und Abnahme: Nicht mit der einfachsten Rechnung aufhören

Ein einzelner erfolgreicher Export beweist nur, dass genau dieser Beleg funktioniert. Der Pilot braucht einen repräsentativen Querschnitt:

• normale Rechnung mit einer Position und Standardsatz
• Rechnung mit mehreren Positionen und Rundung
• mehrere Steuergruppen oder steuerfreier Fall, sofern tatsächlich verwendet
• Gutschrift, Storno oder Berichtigung
• Abschlags- und Schlussrechnung, falls Teil des Geschäftsmodells
• Rechnung mit Rabatt, Zuschlag, Versandkosten oder kostenloser Position
• öffentlicher Empfänger mit geforderten Referenzen
• ZUGFeRD mit kontrollierter Übereinstimmung von PDF und XML
• bewusst fehlerhafte Fälle, die zuverlässig gesperrt werden müssen

Vor dem Start sollten messbare Abnahmekriterien feststehen. Dazu gehören vollständige Feldzuordnung, rechnerisch identische Summen, bestandene Validierung, korrekte Empfängersteuerung, nachvollziehbare Fehlertexte und ein geprüfter Wiederanlauf. Bei PDF-Verarbeitung kommt hinzu: Jede freigegebene Layoutvariante muss mit realistischen Rechnungen getestet werden.

Automatisieren Sie erst nach der fachlichen Abnahme. Zu Beginn ist eine menschliche Freigabe wertvoll, weil sie falsche Annahmen im Mapping sichtbar macht. Später können eindeutig erfolgreiche Standardfälle automatisch laufen, während Sonderfälle in einer Prüfliste bleiben.

Checkliste für die Nachrüstung

Ausgangssystem und Verantwortliche

• [ ] Produkt, Version, Hosting und technische Betreuung sind dokumentiert.
• [ ] Tabellen, Abfragen, Skripte und PDF-Ausgabe sind bekannt.
• [ ] Es gibt einen fachlich verantwortlichen Ansprechpartner für Rechnungs- und Steuerlogik.
• [ ] Der Zeitpunkt des endgültigen Rechnungsabschlusses ist eindeutig.

Daten und Formate

• [ ] Alle Pflichtangaben liegen strukturiert vor oder können zuverlässig ergänzt werden.
• [ ] Belegarten, Empfängerprofile und Ausgabeformat sind ausdrücklich definiert.
• [ ] Summen werden aus der Quelle übernommen und unabhängig gegengeprüft.
• [ ] PDF und XML stimmen bei hybriden Rechnungen fachlich überein.
• [ ] Aktuelle Format- und Validierungsregeln werden versioniert eingesetzt.

Betrieb und Sicherheit

• [ ] Fehler blockieren den Versand und werden verständlich zurückgegeben.
• [ ] Wiederholungen erzeugen keine doppelten Ausgaben oder Sendungen.
• [ ] Testdaten, Protokolle, Zugänge und Löschfristen sind geregelt.
• [ ] Versand, Archivübergabe und Statusrückgabe sind geprüft.
• [ ] Änderungen am Quellschema oder Beleglayout lösen einen Regressionstest aus.

Häufige Fragen zum eigenen Rechnungsmodul und zur E-Rechnung

Muss ein selbst entwickeltes Rechnungsprogramm ersetzt werden?

Nein. Wenn das Programm die kaufmännischen Daten zuverlässig verwaltet und einen stabilen Übergabepunkt bietet, kann eine ergänzende E-Rechnungsstrecke wirtschaftlicher sein. Ein Ersatz wird interessant, wenn bereits grundlegende Datenqualität, Wartbarkeit oder Sicherheitsanforderungen nicht mehr erfüllt werden – nicht allein wegen des fehlenden Ausgabeformats.

Gibt es einen fertigen RechneX-Connector für FileMaker oder Access?

Eine pauschale native Schnittstelle lässt sich für individuell entwickelte Datenbanken nicht seriös versprechen. Tabellen, Abfragen, Skripte und Belegarten unterscheiden sich. RechneX kann einen abgestimmten Prozess über strukturierte Daten, Export, PDF oder API ermöglichen, nachdem Datenmodell und Beispielbelege geprüft wurden.

Kann FileMaker Rechnungsdaten per API bereitstellen?

Ja, die FileMaker Data API kann bei passend gehosteten und konfigurierten Lösungen Daten über REST und JSON zugänglich machen. Ob sie für Ihren Prozess der beste Weg ist, hängt von Version, Hosting, Berechtigungen und dem vorhandenen Datenmodell ab. Alternativ kommen ODBC/JDBC, Exportdateien oder eine PDF-Brücke infrage.

Kann eine Access-Datenbank ohne Web-API angebunden werden?

Ja. Häufig reicht eine fest definierte Abfrage, die ihre Ergebnisse als strukturierte Textdatei ausgibt. Je nach Architektur kann auch ein kontrollierter ODBC-Zugriff sinnvoll sein. Wichtig sind stabile Feldnamen, Datentypen, Rechnungsstände und Rückmeldungen – nicht die Bezeichnung der Übertragungstechnik.

Reicht das vorhandene Rechnungs-PDF als Datenquelle?

Für stabile digitale Layouts kann es als Brücke reichen. Alle Pflichtangaben müssen aber im erzeugten strukturierten Teil stehen. Fehlende oder uneindeutige Werte benötigen eine Ergänzung oder Freigabe. Scans, Handschrift, wechselnde Tabellen und widersprüchliche Summen sind keine geeignete Grundlage für eine ungeprüfte Vollautomatisierung.

Sollte das eigene Modul XRechnung oder ZUGFeRD erzeugen?

Das hängt vom Empfängerprozess ab. Öffentliche Auftraggeber verlangen häufig XRechnung und zusätzliche Referenzen. Im B2B-Bereich kann ZUGFeRD praktisch sein, wenn ein sichtbares PDF und maschinenlesbare Daten gemeinsam benötigt werden. Die Integrationsschicht kann beide Formate bedienen, wenn das neutrale Datenmodell vollständig ist.

Was passiert, wenn PDF und ZUGFeRD-XML voneinander abweichen?

Das ist ein blockierender Qualitätsfehler. Nach der BMF-Einordnung ist bei einer hybriden E-Rechnung der strukturierte Teil führend. Deshalb müssen Beträge, Steuerangaben, Empfänger und Positionen vor der Freigabe zwischen sichtbarer Darstellung und XML abgeglichen werden.

Darf die Integration widersprüchliche Summen automatisch korrigieren?

Nein. Eine technische Komponente sollte keine kaufmännischen Quelldaten erfinden oder stillschweigend passend rechnen. Stimmen Positionen, Steuer und Gesamtbetrag nicht überein, muss der Vorgang gesperrt und im führenden System korrigiert werden.

Reicht eine bestandene Validierung für den automatischen Versand?

Nicht allein. Die Validierung prüft definierte Format- und Geschäftsregeln, aber nicht den zugrunde liegenden Geschäftsvorgang. Empfänger, Leistung, Steuerfall und Freigabe müssen fachlich stimmen. Erst ein vollständig geprüfter Status darf den Versand auslösen.

Wie werden sensible Inhalte in der Anbindung geschützt?

Durch Datenminimierung, verschlüsselte Übertragung, getrennte Umgebungen, enge Rollen, reduzierte Protokolle und festgelegte Löschfristen. Bei besonders schützenswerten Inhalten sollte der gesamte Prozess einschließlich Support und Versand individuell geprüft werden, bevor Echtdaten fließen.

Wie viele Beispielrechnungen braucht ein Pilot?

Nicht die Anzahl allein ist entscheidend, sondern die Abdeckung. Jede tatsächlich verwendete Belegart, Steuerkonstellation, Empfängergruppe und Layoutvariante sollte vertreten sein. Hinzu kommen bewusst fehlerhafte Belege, um Sperr- und Rückmeldelogik zu testen.

Kann der Versand nach der Umwandlung vollständig automatisch erfolgen?

Ja, sobald Formatwahl, Empfänger, Validierung, Wiederholungsverhalten und Fehlerbehandlung abgenommen sind. In der Einführungsphase empfiehlt sich eine Freigabe. Auch später sollten unbekannte oder fehlerhafte Fälle automatisch gestoppt und einer zuständigen Person vorgelegt werden.

Fazit: Das eigene Rechnungsmodul bleibt, die Ausgabe wird erweitert

FileMaker, Access und individuelle Datenbanken können häufig weiter genutzt werden. Entscheidend ist ein sauberer Übergang vom fachlich abgeschlossenen Beleg zu einem neutralen Datenvertrag, einer eindeutigen Feldzuordnung und einer formatspezifischen Prüfung.

Die API ist stark für wiederkehrende, automatisierte Abläufe. Ein strukturierter Export eignet sich für bewährte Datenbanklösungen ohne moderne Web-Schnittstelle. Eine PDF-Brücke ermöglicht einen schnellen Einstieg, wenn das Rechnungsbild stabil und eine kontrollierte Prüfung vorgesehen ist. In jedem Weg gilt: Widersprüche werden gesperrt, nicht geraten; PDF und XML müssen zusammenpassen; die Freigabe erfolgt erst nach erfolgreicher Validierung.

Quellen und weiterführende Informationen

• Bundesfinanzministerium: Fragen und Antworten zur E-Rechnung
• XStandards Einkauf: Standard XRechnung
• XStandards Einkauf: Pflichtangaben nach UStG in der EN 16931
• XStandards Einkauf: Versionen und Bundles der XRechnung
• Forum elektronische Rechnung Deutschland: ZUGFeRD
• Claris: FileMaker Data API Guide
• Claris: FileMaker als ODBC- oder JDBC-Datenquelle
• Microsoft: Daten aus Access in eine Textdatei exportieren
• Microsoft: ODBC-Datenquellen in Access verwalten