Jede gebuchte Rechnung landet automatisch dort, wo sie hingehört – benannt nach Regel, auffindbar über den Beleg, ohne dass jemand etwas exportiert.
Der Beleg selbst ist sauber in Business Central gebucht. Das PDF, das der Kunde bekommen hat und das die Buchhaltung aufbewahren muss, ist etwas anderes: Es entsteht erst, wenn jemand es erzeugt, und es liegt danach dort, wo diese Person es hingespeichert hat.
Meistens ist das der richtige Ordner mit einem brauchbaren Namen. Manchmal ist es der Desktop, der Postausgang oder ein Ordner, den es seit der letzten Umstrukturierung eigentlich nicht mehr geben sollte.
Jede Suche nach einem Beleg dauert für sich genommen nur ein paar Minuten. Es sind die Rückfragen daneben, die teuer werden: Wer sucht, findet nichts, fragt jemanden, und jetzt sind zwei Leute beschäftigt – oft jemand aus der Buchhaltung und jemand aus dem Vertrieb.
Bei einer Betriebsprüfung ist nicht die Frage, ob Ihr die Belege habt, sondern ob Ihr sie vollständig und geordnet vorlegen könnt. Eine Ablage, deren Regel im Kopf einer Person steht, ist genau dann schwer zu erklären – und die Nacharbeit fällt zu einem Zeitpunkt an, den Ihr nicht bestimmt.
Solange die Ablage Konvention statt Regel ist, hängt sie an denen, die die Konvention kennen. Ein Wechsel in der Buchhaltung heißt dann nicht nur Einarbeitung, sondern eine Übergangszeit, in der niemand ganz sicher ist, wo etwas hingehört – und die Belege aus dieser Zeit sind später die, die man nicht findet.
Bei fünfzig Rechnungen im Monat trägt die Disziplin. Bei fünfhundert trägt sie an guten Tagen. Genau in der Phase, in der mehr Umsatz durchgeht, mehr Leute mitarbeiten und weniger Zeit für Sorgfalt bleibt, wird die Ablage unzuverlässig – also dann, wenn es am meisten kostet.
Sobald eine Rechnung gebucht ist, erzeugt AutoFlow das PDF aus demselben Bericht, den der Kunde bekommt, benennt es nach einer Regel, die Du einmal festlegst, und legt es in den Ordner, der sich aus dem Beleg selbst ergibt: Jahr, Mandant, Debitor – was immer bei Euch die Struktur bestimmt.
Der Schritt, der den Unterschied macht, ist der letzte: Der Link landet zurück am gebuchten Beleg. Ohne ihn hättest Du eine saubere Ablage, die niemand findet.
Der Ablauf hängt am Buchen, nicht am Drucken – es gibt also keinen Beleg, der durchrutscht.
Aus dem Bericht, den auch der Kunde bekommt, mit einem Namen nach Deiner Regel statt nach Tagesform.
Der Pfad ergibt sich aus dem Beleg selbst – Jahr, Mandant, Debitor, was immer bei Euch gilt.
Damit niemand mehr sucht: Wer den Beleg offen hat, hat das Dokument.
Der Ablauf ist an einem Tag gebaut, inklusive der Verbindung zu SharePoint. Danach gilt dieselbe Regel für jede Rechnung, unabhängig davon, wer bucht, wie voll der Tag ist und ob gerade jemand in Urlaub ist.
Wer den Beleg in BC offen hat, hat das PDF einen Klick entfernt. Das Suchen entfällt, nicht nur das Ablegen.
Alles mit einer Upload-Schnittstelle funktioniert. SharePoint ist nur der Fall, den die meisten ohnehin lizenziert haben.
Antwortet SharePoint nicht, steht das im Protokoll und geht als Meldung raus – die Buchung selbst blockiert es nicht.
Einkaufsrechnungen, Lieferscheine, Auftragsbestätigungen: derselbe Ablauf, anderer Bericht und anderer Zielordner.
Die Frage „kannst Du mir kurz die Rechnung raussuchen“ hört auf. Rechne einmal zusammen, wie oft sie pro Woche fällt und wie viele Leute sie jeweils beschäftigt – die Zahl ist meistens unangenehmer als erwartet, und sie fällt ab dem ersten Tag weg.
Rechnung buchen, PDF erzeugen, nach SharePoint hochladen, den Link am Beleg hinterlegen. Geht der Upload schief, geht eine Mail an die IT statt einer Meldung an niemanden.
Der Flow liefert die Voraussetzung: Jeder Beleg wird nach derselben Regel benannt, am selben Ort abgelegt und ist über den Beleg auffindbar – lückenlos und nachvollziehbar. Ob die Ablage insgesamt GoBD-konform ist, entscheiden aber die Aufbewahrungs-, Versionierungs- und Berechtigungseinstellungen Deiner SharePoint-Bibliothek, nicht AutoFlow. Das ist eine Frage an die Konfiguration dort – und eine, die Ihr ohnehin beantworten müsst.
Der Ablauf selbst ist an einem Tag fertig. Der Teil, der Zeit kostet, ist meistens nicht technisch: Ihr müsst Euch darauf einigen, wie der Ordnerpfad und der Dateiname künftig aussehen. Der Flow kann jede Regel abbilden, aber er kann sich keine ausdenken.
Für den Ablauf nicht – der wird grafisch gebaut. Einmal braucht es aber jemanden mit Administrationsrechten: Für den Zugriff auf SharePoint wird eine Registrierung in Entra ID mit Schreibrechten auf die Zielbibliothek eingerichtet. Das ist eine halbe Stunde IT-Arbeit, keine Entwicklung.
Nichts. Es gibt keine Objekterweiterung, die neu kompiliert werden müsste. Wenn sich etwas ändert, dann eher auf der anderen Seite – wenn Ihr die SharePoint-Struktur umbaut, passt Du den Pfad im Flow an, und das ist ein Feld, kein Ticket.
Die holt dieser Ablauf nicht nach, weil er am Buchen hängt. Für den Bestand baust Du einen zweiten Flow, der über einen Zeitraum läuft und dieselbe Ablagelogik nutzt. Das ist derselbe Aufwand noch einmal, aber es ist ein einmaliger.
Sollte sie nicht, und in unserem Aufbau tut sie es nicht. Die Rechnung ist richtig – es fehlt nur die Kopie. Der fehlgeschlagene Schritt wird protokolliert und gemeldet, damit ihn jemand nacharbeiten kann. Ein Ablauf, der das Buchen anhält, weil ein fremdes System langsam ist, wird nach der zweiten Störung abgeschaltet.
In der Sandbox kannst Du unbegrenzt bauen und testen, so lange Du willst. Und im Produktivmandanten bleiben zwei aktive Flows dauerhaft kostenlos – kein Testzeitraum, der abläuft.
Fällt der Lagerbestand unter den Meldebestand, prüft AutoFlow offene Bestellungen und erstellt automatisch die passende Einkaufsbestellung.
Anwendungsfall lesen
Ein Ticket im Fremdsystem erzeugt per Webhook einen Serviceauftrag in Business Central – mit Zuordnung des Debitors und Prüfung des Vertrags.
Anwendungsfall lesen