BAAN-ERP-Ausgaben kontrolliert als XRechnung oder ZUGFeRD weiterführen

Viele gewachsene BAAN-ERP-Umgebungen erzeugen verlässliche kaufmännische Belege, aber noch keinen strukturierten Datensatz, der zum gewünschten Empfängerprozess passt. Genau hier setzt RechneX an: Der bestehende Rechnungslauf bleibt führend, während die Ausgabe nachgelagert in eine XRechnung oder eine ZUGFeRD-Rechnung überführt wird. Damit lässt sich ein konkreter Handlungsbedarf lösen, ohne zuerst ein umfassendes ERP-Migrationsprojekt abzuschließen.

Eine solche Brückenlösung beginnt nicht mit einer pauschalen Zusage für jede BAAN-Version. Programmstand, Branchenlösung, individuelle Reports, Drucklogik und vorhandene Exporte können sich deutlich unterscheiden. RechneX prüft deshalb eine anonymisierte Musterrechnung, die erreichbaren Daten und den realen Übergabepunkt. Erst daraus entsteht ein verbindliches Zielbild für Pilot und Regelbetrieb.

Ein digitales BAAN-PDF kann ein sinnvoller Übergabepunkt sein, wenn Layout und Inhalte reproduzierbar sind. Als normales PDF ist es jedoch noch keine maschinenlesbare E-Rechnung. Für ZUGFeRD müssen strukturierte XML-Daten fachlich zum Sichtbeleg passen und in einen geeigneten PDF/A-3-Träger eingebettet werden. Für XRechnung wird ein eigenständiger strukturierter XML-Datensatz benötigt.

Liefert BAAN ERP einen geeigneten strukturierten Export, werden belegte Kopf-, Positions-, Steuer- und Referenzdaten bevorzugt daraus übernommen. Fehlen einzelne Werte im Export, können abgestimmte Stammdaten oder Empfängerregeln ergänzen. PDF-Erkennung bleibt dort eine mögliche Hilfe, wo keine bessere Quelle existiert; kritische Angaben wie Steuerkennungen, Bankdaten, elektronische Adressen und Summen sollten aber nicht ungeprüft aus dem Druckbild in den Regelbetrieb gelangen.

Industrielle BAAN-Rechnungen enthalten häufig mehr als Rechnungsnummer, Positionen und Gesamtbetrag. Kundenbestellnummer, interner Verkaufsauftrag, Lieferscheinnummer, Lieferdatum, Zahlungsreferenz, Fracht oder Bearbeitungskosten können für die automatische Verarbeitung beim Empfänger entscheidend sein. Diese Informationen werden nicht in ein gemeinsames Freitextfeld gedrängt, sondern entsprechend ihrer fachlichen Bedeutung zugeordnet.

Besondere Aufmerksamkeit gilt Belegen, bei denen ein Betrag sowohl als Position als auch zusammengefasst im Summenbereich erscheint. Ohne eindeutige Regel könnte daraus versehentlich eine doppelte Belastung entstehen. RechneX gleicht deshalb Positionen, Zu- und Abschläge, Steueraufschlüsselung sowie Netto-, Steuer- und Bruttosummen gegeneinander ab und leitet unklare Fälle in einen definierten Prüfweg.

Welches Format passt, bestimmt der Empfänger: XRechnung ist ein strukturierter XML-Standard und wird besonders häufig von öffentlichen Auftraggebern und Portalen verlangt. ZUGFeRD verbindet strukturierte Rechnungsdaten mit einer lesbaren PDF-Darstellung und kann deshalb gut zu etablierten B2B-E-Mail- und Archivabläufen passen. Ein vorhandenes BAAN-PDF kann als Sichtkomponente erhalten bleiben, sofern es technisch geeignet ist und inhaltlich mit der XML übereinstimmt.

Das Mapping trennt gemeinsame Rechnungslogik von empfängerbezogenen Vorgaben. So lassen sich Buyer Reference oder Leitweg-ID, Bestellbezug, elektronische Adresse, Zielformat und Versandweg regelbasiert behandeln. Vor der Übergabe werden Pflichtfelder, Codes, Geschäftsregeln und Beträge geprüft. Eine Datei, die die vereinbarten Prüfungen nicht besteht, wird nicht stillschweigend versendet.

Infor ordnet die Entstehung von Infor LN historisch der Baan Corporation zu. Eine vorhandene BAAN-Installation ist dadurch jedoch nicht automatisch eine aktuelle Infor-LN-Umgebung: Datenmodell, Version, Anpassungen und verfügbare Integrationswege müssen jeweils eigenständig betrachtet werden. Für Infor LN bietet RechneX deshalb eine separate Lösungsseite mit einem eigenen Prüf- und Integrationsansatz.

Wenn BAAN ERP perspektivisch durch Infor LN oder ein anderes ERP-System abgelöst wird, sollte die Übergangslösung keine neue Sackgasse schaffen. RechneX kapselt deshalb Feldmapping, Empfängerregeln, Validierung und Fehlerprozess möglichst außerhalb individueller Drucklogik. Beim Systemwechsel wird dann vor allem die Datenquelle neu angebunden, während bewährte Zielformate und Qualitätsregeln weiterverwendet werden können.