Jeder Auftrag auf einer Zeitleiste, vom Eingang bis zur bezahlten Rechnung.
Order-to-Cash, Procure-to-Pay und Serviceaufträge bis zur Rechnung laufen durch ERP, CRM, E-Commerce, Lager, Transport und Finanzwesen. Wir verbinden diese Systeme über dokumentierte APIs und Events, geben jedem Auftrag einen einheitlichen Status über alle Systeme hinweg und leiten jede Ausnahme an einen Agenten, der eine Lösung vorbereitet, die ein Mensch freigibt.
Für Unternehmen und öffentliche Auftraggeber in Deutschland, die Aufträge, Bestellungen und Rechnungen über ERP, Webshop, Lager und Transport abwickeln und die E-Rechnungspflicht im B2B umsetzen.
Ein Kundenauftrag, eine Bestellung oder ein Serviceauftrag wird einmal im führenden System erfasst und über dokumentierte APIs und Events an die anderen Systeme verteilt. Statusereignisse ergeben eine Zeitleiste je Auftrag. Schlägt ein Schritt fehl oder liegt er außerhalb der Toleranz, sammelt ein Agent den Kontext und schlägt eine Lösung vor, die ein Mensch freigibt, bevor sie im führenden System ausgeführt wird. Rechnungen werden als strukturierte E-Rechnungen ausgetauscht und abgeglichen, und Prozessverantwortliche prüfen Durchfluss und Zustand der Schnittstellen.
Vorher und nachher
Was sich im Tagesgeschäft ändert
Heute
Mit dem System
Heute
Heute: An jeder Übergabe neu erfasst
Ein Auftrag aus dem Webshop oder vom Vertrieb wird im ERP noch einmal eingetippt, und Liefer- und Rechnungsdaten werden von Hand in Lager-, Transport- und Finanzsysteme übertragen.
Mit dem System
Mit dem System: Einmal erfasst, überall genutzt
Jeder Auftrag, jede Lieferung und jede Rechnung entsteht in dem System, das dafür zuständig ist, und wird als Event veröffentlicht. Andere Systeme abonnieren es, statt es neu einzutippen.
Heute
Heute: Der Stand von gestern
Nächtliche Batch-Schnittstellen führen dazu, dass Kundenservice, Planung und Finanzen jeweils einen anderen, veralteten Stand desselben Auftrags sehen. Wer nach dem Verbleib einer Lieferung fragt, bekommt einen Rückruf.
Mit dem System
Mit dem System: Ein aktueller Status
Jeder Auftrag hat eine Zeitleiste, gebildet aus den Events aller Systeme, die er durchläuft. Kundenservice, Planung und Finanzen sehen dieselben Fakten, ebenso eine Serviceassistenz, die Statusfragen beantwortet.
Heute
Heute: Ausnahmen im Postfach
Fehlbestände, Preisabweichungen, gescheiterte Zustellungen und abgewiesene E-Rechnungen werden per E-Mail und Tabelle geklärt, und hinterher kann niemand sagen, wer was entschieden hat.
Mit dem System
Mit dem System: Ausnahmen kommen mit Vorschlag
Ein Agent sammelt die Daten hinter jeder Ausnahme und schlägt eine Lösung vor. Ein Mensch gibt sie an einem gemeinsamen Klärungsarbeitsplatz frei, ändert sie oder lehnt sie ab, und die Entscheidung wird protokolliert.
Heute
Heute: Stammdaten, die sich widersprechen
Derselbe Kunde, Lieferant, Artikel oder Preis existiert in mehreren Systemen mit unterschiedlichen Werten, und niemand ist dafür zuständig, welcher Wert stimmt.
Mit dem System
Mit dem System: Klare Verantwortung je Datenobjekt
Kunden, Lieferanten, Artikel und Preise haben jeweils ein vereinbartes führendes System und eine benannte verantwortliche Person. Dubletten und Konflikte werden ihr gemeldet, statt nachgelagert stillschweigend korrigiert zu werden.
Heute
Heute: Jede Änderung bringt eine Schnittstelle mehr
Ein neuer Vertriebskanal, ein Marktplatz oder eine neue Gesellschaft bedeutet eine weitere Punkt-zu-Punkt-Verbindung. Nationale E-Rechnungspflichten fügen jedem Prozess zusätzlich ein strukturiertes Format und ein Netzwerk hinzu.
Mit dem System
Mit dem System: Neue Anbindungen nutzen dieselben Schnittstellenverträge
Ein neuer Kanal, eine neue Gesellschaft oder ein E-Rechnungsnetzwerk wird einmal an dokumentierte APIs und Events angebunden, statt an jedes System einzeln.
Workflow
So läuft der Prozess
Sind die Daten sauber, braucht der Hauptpfad keine Handarbeit. Weicht ein Auftrag, eine Lieferung oder eine Rechnung ab, bringt die Ausnahmeschleife den Fall mit Belegen und einem Vorschlag zu einem Menschen, und die freigegebene Korrektur läuft über dieselbe Integrationsschicht zurück.
Beispielhafter Ablauf
7 Schritte · 1 menschliche Prüfung
Legende
System
Agent
Person
Menschliche Prüfung
Ausnahmepfad
Vernetzte Prozesse: beispielhafter Ablauf mit Ausnahmeschleife
Diagramm als Text lesen
Der Hauptpfad führt von der einmaligen Erfassung eines Geschäftsereignisses im führenden System über die Verteilung an die anderen Systeme per APIs und Events und den Aufbau einer Zeitleiste je Auftrag zu Fakturierung, Abgleich und Zahlungsausgleich. Er endet damit, dass Prozessverantwortliche den Durchfluss prüfen und die Ursachen von Ausnahmen beheben.
Schlägt ein Schritt fehl, verspätet er sich oder liegt er außerhalb der Toleranz, verlässt die Ausnahme den Hauptpfad nach dem Zeitleistenschritt. Ein Agent sammelt den Kontext und schlägt eine Lösung vor, und ein Mensch gibt sie frei, ändert sie oder lehnt sie ab. Die freigegebene Aktion wird im führenden System ausgeführt und kehrt als neues Event zum Verteilungsschritt zurück.
Der Freigabeschritt ist der menschliche Kontrollpunkt: Keine Finanzbuchung, keine Änderung von Preis oder Kreditlimit und keine Zusage an Kunden erfolgt ohne einen Menschen.
01
Schritt 1: Ereignis einmal erfassenSystem
Ein Kundenauftrag aus Webshop, Marktplatz, EDI oder Vertrieb, eine Bestellung oder ein Serviceauftrag entsteht in dem System, das dafür zuständig ist. Dieses System veröffentlicht ein Geschäftsereignis in einem CloudEvents-Umschlag, beschrieben in einem AsyncAPI-Vertrag. Aufträge und Lieferantenrechnungen auf Papier oder als PDF durchlaufen zuerst die intelligente Dokumentenverarbeitung.
02
Schritt 2: Über APIs und Events verteilenSystem
Die Integrationsschicht liefert das Ereignis an Lager-, Transport-, Finanz- und CRM-Systeme, jeweils über deren dokumentierte API (OpenAPI). Die Empfänger sind idempotent, sodass eine wiederholte Nachricht nie eine zweite Sendung oder Rechnung erzeugt, und nicht zustellbare Nachrichten warten in einer Fehlerwarteschlange auf die erneute Verarbeitung.
03
Schritt 3: Eine Zeitleiste je Auftrag bildenSystem
Statusereignisse aus allen Systemen (bestätigt, kommissioniert, versandt, zugestellt, fakturiert, bezahlt) werden über die Geschäftsreferenz zu einer Zeitleiste verknüpft. Meilenstein- und Toleranzregeln lösen eine Ausnahme aus, wenn ein Schritt fehlschlägt, sich verspätet oder nicht passt: ein Fehlbestand, ein Preis außerhalb der vereinbarten Toleranz, eine gescheiterte Zustellung, eine abgewiesene E-Rechnung.
04
Schritt 4: Kontext sammeln und vorschlagenAgent
Für jede Ausnahme liest ein Agent, was er aus den beteiligten Systemen braucht: den Auftrag, die Bestände, die Preisvereinbarung, den Sendungsstatus beim Transportdienstleister und die Konditionen des Kunden. Er schlägt eine Lösung mit Begründung und den verwendeten Daten vor, etwa einen Ersatzartikel, einen korrigierten Preis, einen neuen Liefertermin oder eine korrigierte Rechnung.
Ausnahmepfad: Schritt fehlgeschlagen oder außerhalb der Toleranz
05
Schritt 5: Innerhalb von Schwellenwerten freigebenPerson
Eine Person aus Kundenservice, Logistik oder Finanzen sieht Ausnahme, Belege und Vorschlag am Klärungsarbeitsplatz und gibt den Vorschlag frei, ändert ihn oder lehnt ihn ab. Die freigegebene Aktion wird über die API des führenden Systems ausgeführt, das die Änderung als neues Event veröffentlicht.
Ausnahmepfad: Schritt fehlgeschlagen oder außerhalb der Toleranz· Zurück zu Schritt 2
Menschliche Prüfung
Agenten buchen nie Finanztransaktionen, ändern keine Preise oder Kreditlimits und machen Kunden keine Zusagen ohne Freigabe. Schwellenwerte je Aktionsart legen fest, wer freigibt, und jeder Vorschlag und jede Entscheidung wird protokolliert.
06
Schritt 6: Fakturieren, abgleichen und ausgleichenSystem
Ausgangsrechnungen verlassen das ERP als strukturierte E-Rechnungen (Peppol BIS Billing 3.0, EN 16931) über einen Zugangspunkt. Eingehende Lieferantenrechnungen werden mit Bestellungen und Wareneingängen abgeglichen, und der Zahlungsstatus von Bank oder Zahlungsdienstleister schließt die Zeitleiste ab.
07
Schritt 7: Durchfluss prüfen und Ursachen behebenPerson
Prozessverantwortliche und das Integrationsteam prüfen in festem Rhythmus Ausnahmen nach Grund, Schnittstellenfehler und Stammdatenkonflikte. Sie beheben die Ursache dort, wo sie liegt, in einem Stammdatensatz, einer Toleranzregel oder einem Mapping, statt dieselbe Ausnahme immer wieder zu klären.
Komponenten
Was wir bauen würden
01
Ereignisgesteuerte Integrationsschicht
APIs und Events nach dem Contract-first-Prinzip zwischen ERP, CRM, E-Commerce, Lager, Transport und Finanzen, spezifiziert in OpenAPI und AsyncAPI mit CloudEvents-Umschlägen, auf Ihrer bestehenden Integrationsplattform oder cloudnativ gebaut.
Ein vereinbartes führendes System und eine verantwortliche Person je Datenobjekt, Abgleichsregeln für Kunden, Lieferanten und Artikel sowie Berichte über Dubletten und Konflikte für die Verantwortlichen.
Ein Dienst, der Events zu einer Zeitleiste je Auftrag verknüpft, Meilenstein- und Toleranzregeln anwendet und Prozessverantwortlichen Durchfluss und Ausnahmen zeigt.
Eine Warteschlange von Ausnahmen mit dem gesammelten Kontext und dem Vorschlag des Agenten, mit den Aktionen Freigeben, Ändern und Ablehnen und mit Freigabeschwellen je Aktionsart, die dort durchgesetzt werden, wo die Aktion ausgeführt wird.
Rechnungen nach Peppol BIS Billing 3.0 und EN 16931 in UBL, über einen Zugangspunkt versendet und empfangen und vor dem Versand validiert; abgewiesene Rechnungen gehen an den Klärungsarbeitsplatz.
Zustandsüberwachung und Alarmierung je Schnittstelle, Betriebshandbücher für das Betriebsteam und kontrollierte erneute Verarbeitung fehlgeschlagener Nachrichten, bereitgestellt mit Infrastructure as Code in Ihrem Cloud-Mandanten.
Bestellungen und Auftragsbestätigungen von Lieferanten
Serviceaufträge und Außendienstberichte
Sendungsverfolgung und Zustellereignisse von Transportdienstleistern
Peppol-E-Rechnungen und Statusmeldungen
Kontoauszüge und Zahlungsavise
Kern der Lösung
Vernetzte Prozesse
Angebundene Systeme
SAP S/4HANA Vertrieb, Beschaffung und FinanzwesenPlattformSAP
Salesforce Sales Cloud, Service Cloud und Commerce CloudPlattformSalesforce
Odoo Verkauf, Lager, Einkauf und BuchhaltungPlattformOdoo
E-Commerce-Plattformen, Marktplätze und APIs von Transportdienstleistern
Lagerverwaltungs- und Transportmanagementsysteme
Peppol-Zugangspunkt, Banken und Zahlungsdienstleister
Produktinformationsmanagement und Datenplattform
Kontrollen
Eingebaute Kontrollen
Zugriffsgrenzen
Jede Integration und der Agent laufen je System unter einer eigenen Dienstidentität, beschränkt auf die API-Operationen, die sie brauchen. Der Agent darf systemübergreifend lesen, um Kontext zu sammeln, aber nur über eine kurze Liste freigegebener Aktionen schreiben, ausgeführt über die API des führenden Systems und nie über direkten Datenbankzugriff.
Menschliche Prüfung
Freigabeschwellen werden je Aktionsart mit den Prozessverantwortlichen festgelegt: was der Agent nur vorschlagen darf, was ein Teammitglied freigibt und was eine zweite Freigabe braucht. Finanzbuchungen, Änderungen von Preisen und Kreditlimits sowie Zusagen an Kunden warten immer auf einen Menschen. Aktionen mit geringer Tragweite, die sich rückgängig machen lassen, etwa die erneute Zustellung einer fehlgeschlagenen Nachricht, können ohne Freigabe laufen, wenn die Verantwortlichen zustimmen.
Nachvollziehbarkeit
Jedes Event, jeder Vorschlag, jede Freigabe, jede Ablehnung und jede ausgeführte Aktion wird zur Auftragsreferenz protokolliert, mit den Daten, die der Agent verwendet hat, der Modell- und Prompt-Version und der freigebenden Person. Eine strittige Rechnung oder eine Kundenbeschwerde lässt sich Schritt für Schritt nachverfolgen.
Datenschutz
Kontaktdaten von Kunden und Lieferanten fließen nur in die Systeme, die sie brauchen. Die Zeitleiste speichert Geschäftsreferenzen und Status statt vollständiger Datensätze, und Protokolle folgen der Aufbewahrung, die Sie festlegen. Die Verarbeitung bleibt in der vereinbarten Region.
KI-Transparenz
Vorschläge des Agenten sind am Klärungsarbeitsplatz als solche gekennzeichnet, mit Belegen und Begründung daneben. Die führenden Systeme bleiben maßgeblich: Die Zeitleiste zeigt, was sie melden, und überschreibt sie nie.
Kennzahlen
Was wir messen würden
Diese Kennzahlen stimmen wir in der Analysephase mit Ihnen ab und erfassen die Ausgangsbasis aus Ihren aktuellen System- und Schnittstellenprotokollen, bevor sich etwas ändert.
Was wir messen würden
Kennzahl
Warum sie zählt
Wie wir sie messen würden
01Auftragsdurchlaufzeit
Warum sie zähltDie Kennzahl, die Kunden zuerst bemerken, und die, die zeigt, wo Aufträge warten.
Wie wir sie messen würdenZeit vom Auftragseingang bis zur Lieferung und bis zur Zahlung, je Kanal und Gesellschaft, aus den Events der Zeitleiste.
02Aufträge ohne manuellen Eingriff
Warum sie zähltZeigt, wie viel des Durchflusses auf sauberen Daten und vereinbarten Regeln läuft.
Wie wir sie messen würdenAnteil der Aufträge und Serviceaufträge, die ohne manuellen Schritt und ohne Ausnahme bis zum Zahlungsausgleich kommen, aus der Zeitleiste.
03Ausnahmen nach Grund und Klärungszeit
Warum sie zähltZeigt, welche Ursachen Sie zuerst beheben sollten und ob der Klärungsarbeitsplatz mithält.
Wie wir sie messen würdenAnzahl der Ausnahmen je Grundcode und Zeit von der Erkennung bis zur ausgeführten Lösung, aus den Protokollen des Klärungsarbeitsplatzes.
04Ablehnungsquote bei E-Rechnungen
Warum sie zähltAbgewiesene Rechnungen verzögern die Zahlung und deuten meist auf Fehler in Stammdaten oder Mappings hin.
Wie wir sie messen würdenAnteil der versendeten und empfangenen E-Rechnungen, die abgewiesen wurden, nach Grund, aus den Antworten des Zugangspunkts.
05Schnittstellenfehler und Wiederherstellungszeit
Warum sie zähltZeigt, ob die Integrationsschicht zuverlässig ist und ob Fehler schnell bemerkt und behoben werden.
Wie wir sie messen würdenFehlgeschlagene Nachrichten je Schnittstelle und Zeit vom Fehler bis zur erfolgreichen erneuten Verarbeitung, aus dem Integrationsmonitoring.
06Dubletten und Konflikte in Stammdaten
Warum sie zähltDie meisten Ausnahmen gehen auf Daten zurück, die sich zwischen Systemen unterscheiden.
Wie wir sie messen würdenOffene Dubletten und widersprüchliche Werte je Datenobjekt und System, aus den Abgleichsberichten.
Ziele werden erst nach einer Ausgangsmessung festgelegt.
Einführung
So würden wir die Einführung gestalten
Phase 01
Analyse und Prozesslandkarte
Ein Prozess, etwa Order-to-Cash für einen Vertriebskanal, und eine Ausnahmeart. Wir erfassen Systeme, Schnittstellen und Datenverantwortliche und wie Ausnahmen heute geklärt werden.
Abschlusskriterien
Prozess, Systeme und Datenverantwortliche erfasst
Erste Ausnahmeart und Freigabeschwellen vereinbart
Ausgangsbasis aus aktuellen Protokollen erhoben
Phase 02
Integration und Zeitleiste
Dokumentierte APIs und Events für die Systeme im Umfang und eine Zeitleiste, die neben den bestehenden Schnittstellen läuft, ohne sie zu verändern.
Abschlusskriterien
Event-Verträge veröffentlicht und versioniert
Zeitleiste stimmt in Stichproben mit den führenden Systemen überein
Erneute Verarbeitung und Betriebshandbücher getestet
Phase 03
Pilot des Klärungsarbeitsplatzes
Der Agent schlägt Lösungen für die gewählte Ausnahmeart vor, und Menschen geben jeden Vorschlag frei. Wir vergleichen die Vorschläge mit dem, was Mitarbeitende getan hätten.
Abschlusskriterien
Qualität der Vorschläge erfüllt die vereinbarten Kriterien
Schwellenwerte und Freigebende je Aktionsart festgelegt
Prüfpfad von Finanzbereich und interner Kontrolle abgenommen
Phase 04
Ausweiten und ablösen
Weitere Ausnahmearten, Kanäle, Gesellschaften und Prozesse wie Procure-to-Pay, jeweils auf denselben Schnittstellenverträgen. Alte Punkt-zu-Punkt-Schnittstellen werden nacheinander abgeschaltet.
Abschlusskriterien
Jeder neue Fluss auf denselben Verträgen und demselben Monitoring
Auftragsfertigung und Ersatzteilaufträge vom ERP bis zu Lager und Transportdienstleistern, mit Auftragsbestätigungen der Lieferanten und E-Rechnungen, die mit Bestellungen abgeglichen werden.
Anschluss- und Installationsaufträge, verfolgt vom Arbeitsauftrag über den Termin vor Ort bis zur Rechnung, und Material, das über Rahmenverträge beschafft wird.
Instandhaltungsaufträge, Bestellungen bei Auftragnehmern und deren Rechnungen, von der Anforderung bis zur Zahlung verfolgt, für Infrastrukturbetreiber.
Procure-to-Pay mit strukturierten E-Rechnungen an und von öffentlichen Stellen, vor der Zahlung mit Bestellungen und Wareneingängen abgeglichen.
Beispiel zur Veranschaulichung
Ein Maschinenbauer und sein Ersatzteilgeschäft
Ausgangslage
Ein mittelständischer Maschinenbauer verkauft Ersatzteile über ein Kundenportal, per EDI an größere Kunden und über den Außendienst, aus einem Zentrallager. Portalaufträge werden in SAP nachgetippt, Lieferprobleme meldet die Spedition per E-Mail, und für die Ausstellung von E-Rechnungen fehlt noch ein durchgängiger Prozess.
System
Aufträge, Bestände, Lieferungen und Rechnungen fließen als Events zwischen Portal, SAP, Lagerverwaltung und Speditionen, und jeder Auftrag hat eine Zeitleiste. Ausgangsrechnungen werden als XRechnung oder ZUGFeRD erstellt, vor dem Versand validiert und über den mit dem Kunden vereinbarten Kanal übermittelt.
Menschliche Kontrolle
Fehlbestände und Lieferverzögerungen landen am Klärungsarbeitsplatz, wo ein Agent ein Ersatzteil aus einem anderen Bestand oder einen neuen Liefertermin vorschlägt. Der Vertriebsinnendienst gibt jeden Vorschlag frei; Preisänderungen und Gutschriften gibt die Buchhaltung frei.
Was wir messen würden
Anteil der Aufträge ohne manuellen Eingriff je Kanal, Ausnahmen nach Grund und Klärungszeit sowie Ablehnungsquote bei E-Rechnungen.
Deutschland
Die E-Rechnung als Teil des Prozesses
Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen im inländischen B2B-Verkehr empfangen können, etwa im Format XRechnung oder ZUGFeRD. Die Pflicht zur Ausstellung folgt ab dem 1. Januar 2027 für Unternehmen mit einem Vorjahresumsatz über 800.000 Euro und ab dem 1. Januar 2028 für alle. Für innergemeinschaftliche B2B-Lieferungen werden E-Rechnung und digitale Meldung ab dem 1. Juli 2030 Pflicht.
Wir behandeln die E-Rechnung als Event im Prozess: im ERP erstellt, vor dem Versand validiert und bei Ablehnung am Klärungsarbeitsplatz bearbeitet. Eingehende Rechnungen werden mit Bestellung und Wareneingang abgeglichen. Integrationen kommen mit protokolliertem Zugriff und dokumentierten Komponenten für Kunden mit Pflichten nach dem NIS2UmsuCG.
Nein. ERP, CRM, Webshop und Lagerverwaltung erfüllen jeweils ihre eigene Aufgabe. Wir integrieren um diese führenden Systeme herum, vereinbaren, welches System welche Daten führt, und geben dem Prozess eine Zeitleiste über alle hinweg. Wo ein altes Auftrags- oder ERP-System Veränderungen blockiert, stellt die Modernisierung von Altsystemen es zuerst hinter APIs.
02Ersetzen Sie unsere Integrations-Middleware?
Nicht, wenn sie ihre Aufgabe erfüllt. Wir bauen auf der Integrationsplattform oder dem Message Broker auf, den Sie bereits betreiben, und ergänzen Schnittstellenverträge, Monitoring und erneute Verarbeitung, wo sie fehlen. Gibt es keine Plattform, bauen wir cloudnativ. Mehr zu unserer Arbeit an Integrationen & APIs.
03Können Agenten selbstständig handeln?
Nur innerhalb der Schwellenwerte, die Sie je Aktionsart vereinbaren, und nur bei Aktionen mit geringer Tragweite, die sich rückgängig machen lassen, etwa der erneuten Zustellung einer fehlgeschlagenen Nachricht. Finanzbuchungen, Preise, Kreditlimits und Zusagen an Kunden brauchen immer einen Menschen. Lesen Sie, wo KI-Agenten menschliche Freigabe brauchen.
04Wie fügen sich die Pflichten zur E-Rechnung ein?
Nationale E-Rechnungspflichten treten zu unterschiedlichen Terminen in Kraft, und das EU-Paket „Mehrwertsteuer im digitalen Zeitalter“ macht die strukturierte E-Rechnung ab dem 1. Juli 2030 zur Regel für innergemeinschaftliche B2B-Lieferungen. Wir behandeln die E-Rechnung als ein weiteres Event im Prozess: im ERP erstellt, über einen Zugangspunkt versendet und am Klärungsarbeitsplatz bearbeitet, wenn sie abgewiesen wird. Siehe unseren Leitfaden zur E-Rechnung mit Peppol.
05Wie vermeiden Sie ein weiteres fragiles Geflecht aus Punkt-zu-Punkt-Verbindungen?
Systeme veröffentlichen und konsumieren dokumentierte Events und APIs über eine gemeinsame Schicht, nicht über direkte Verbindungen untereinander. Schnittstellenverträge sind versioniert, Empfänger idempotent, fehlgeschlagene Nachrichten lassen sich erneut verarbeiten, und jeder Fluss hat eine benannte verantwortliche Person. Ein neuer Kanal abonniert vorhandene Events, statt eine Verbindung zu jedem System hinzuzufügen.
06Was ist ein sinnvoller erster Umfang?
Ein Prozess und eine Ausnahmeart, zum Beispiel Order-to-Cash für einen Vertriebskanal mit Fehlbeständen als erster Ausnahmeart. Das belegt Events, Zeitleiste und Freigabeablauf, bevor mehr hinzukommt. Mehr über unser Vorgehen.
Sprechen Sie mit uns über Ihre Auftrags- und Rechnungsflüsse
Wählen Sie einen Prozess und die Gesellschaften, in denen er läuft. Wir erfassen mit Ihnen Systeme, Schnittstellen und Ausnahmen und schlagen ein erstes Release vor, das zu Ihrem Zeitplan für die E-Rechnung passt.