Rechnungsdaten in Ihr
Produktionskosten-Tracking-System einspeisen

Die Datenübergabe, über die niemand spricht

Betreten Sie das Kostenrechnungsbüro eines mittelständischen Fertigungsunternehmens und Sie werden ein System zur Verfolgung der Produktionskosten finden. Es könnte sich um ein vollständiges ERP-Modul handeln – einen Epicor Kinetic Cost Rollup, ein Plex Standard Costing Dashboard, einen Dynamics 365-Produktionsauftragsbildschirm. Es könnte sich um eine sorgfältig gepflegte Tabellenkalkulation mit Registerkarten für jeden Auftrag handeln, mit Formeln, die Materialkosten von einem Blatt in ein anderes ziehen, und einer Pivot-Tabelle, die die Monatsend-Abweichungsanalyse speist. So oder so, das System funktioniert. Der Kostenrechner hat es aufgebaut, pflegt es und vertraut ihm.

Was nicht funktioniert, ist das fünfminütige Ritual, das jedem Update vorausgeht. Eine Lieferantenrechnung trifft als PDF ein – Grainger für MRO-Bedarf, MSC Industrial Supply für Schneidwerkzeuge, Fastenal für Verbindungselemente, eine lokale Maschinenbaufirma für Fremdfertigung. Jemand öffnet das PDF. Sie finden die Bestellnummer, das Rechnungsdatum, die Positionen, die Einzelpreise und die Gesamtsummen. Dann tippen sie diese Werte – Zeile für Zeile, Rechnung für Rechnung – in das Kostenverfolgungssystem. Dieses Ritual wiederholt sich vierzigmal im Monat für einen Hersteller mit vierzig aktiven Lieferanten. Bei drei Minuten pro Rechnung verschwinden zwei Stunden pro Monat für das erneute Abtippen von Daten, die bereits in digitaler Form vorliegen.

Dies ist die Datenübergabelücke. Sie sitzt zwischen zwei Dingen, die beide funktionieren: dem Rechnungssystem des Lieferanten (das ein perfekt lesbares PDF erzeugt hat) und dem Kostenverfolgungssystem des Herstellers (das bereit ist, strukturierte Daten aufzunehmen). Die Lücke ist ein reines Formatübersetzungsproblem. Das PDF enthält maschinenlesbare Positionen. Der Kostenverfolger akzeptiert strukturierte Daten. Der einzige Grund, warum ein Mensch in der Mitte sitzt, ist, dass der Übersetzungsschritt – PDF zu strukturierten Zeilen – historisch gesehen eine Person erforderte.

APQC-Benchmarking-Daten beziffern die medianen Kosten für die Verarbeitung einer einzelnen Lieferantenrechnung auf 6,00 $ über alle Branchen hinweg – aber die Fertigungsindustrie liegt konstant über diesem Median, da jede Rechnung über Bestandskonten (13xx → 14xx → 15xx) und nicht über eine einzelne Aufwandszeile fließt. Ardent Partners' Benchmarks 2025 beziffern die Best-in-Class-Kosten auf 2,78 $ gegenüber 12,88 $ für alle anderen – ein 4,6-facher Multiplikator. Für den Hersteller, der 500 Rechnungen pro Monat verarbeitet, macht das den Unterschied zwischen 16.700 $ und 77.300 $ pro Jahr, die ausschließlich für die Datenübersetzung ausgegeben werden. Die vollständige Kostenaufschlüsselung – einschließlich Fehlerkorrektur, Teilabgleich von Lieferungen und der Bestandsbuchungskette – finden Sie in unserer Analyse der tatsächlichen Kosten der manuellen Rechnungsverarbeitung in der Fertigung.

Die Frage, die dieser Artikel behandelt, ist enger gefasst und praktischer als „Sollten Sie die Kreditorenbuchhaltung automatisieren?". Sie lautet: Angenommen, Sie haben bereits ein Kostenverfolgungssystem, dem Sie vertrauen – wie leiten Sie Lieferantenrechnungsdaten ein, ohne sie neu abzutippen – und ohne die nachgelagerten Kostenrollup-Logiken, Abweichungsberichte oder den Monatsabschlussprozess zu beeinträchtigen?

Was ein Produktionskosten-Tracking-System tatsächlich von einer Rechnung benötigt

Bevor Sie die Pipeline aufbauen, müssen Sie wissen, was das Zielsystem erwartet. Ein Produktionskosten-Tracking-System – ob in einem ERP, einem Auftragskostenmodul oder einer Tabellenkalkulation – verarbeitet keine gescannten PDFs. Es verarbeitet Zeilen. Und die benötigten Zeilen sind spezifischer als das, was ein generisches AP-Automatisierungstool liefert.

Mindestens benötigt ein Produktionskosten-Tracker für jede Position einer Lieferantenrechnung:

Die letzten beiden Felder – Sachkontocode und Auftragsnummer – machen das Integrationsproblem schwieriger als bei der Standard-Kreditorenbuchhaltung. Ein generisches AP-Automatisierungstool extrahiert, was auf der Rechnung steht: Lieferantenname, Datum, Summe. Es weiß aber nicht, dass eine Position für „304 SS Blech, 0,125×48×96" das Rohmaterial (1310) belasten sollte, während eine Position für „Kühlschmiermittel, 5 Gallonen" auf derselben Rechnung die Fertigungsgemeinkosten (4350) belasten sollte. Diese Unterscheidung – zwischen direktem Material und indirektem Betriebsstoff – erfordert Fachwissen, das der Kostenbuchhalter im Kopf hat. Die Integrationsherausforderung besteht nicht nur darin, Daten aus einem PDF zu extrahieren. Es geht darum, Daten mit den bereits korrekt zugeordneten Sachkonten in den Kosten-Tracker zu bekommen.

Für öffentliche Auftragnehmer, die FAR 32.905 unterliegen, muss jede Rechnungszahlung durch einen Wareneingangsbericht gestützt werden – das bedeutet, die Verknüpfung zwischen Rechnungspositionen, Buchungskonten und Wareneingangsbelegen ist nicht nur eine Kostenrechnungspräferenz, sondern eine Compliance-Anforderung. Gemäß SOX Section 404 müssen börsennotierte Hersteller dokumentierte interne Kontrollen über die Bestandsbuchhaltungskette aufrechterhalten, einschließlich Funktionstrennung zwischen Bestellung, Wareneingang und Rechnungskodierung. Die Datenübergabelücke ist auch eine Prüfpfadlücke.

Drei Reibungspunkte bei der Integration (und wie man sie beseitigt)

Die Lücke zwischen einer Lieferanten-PDF und einem Kosten-Tracker besteht eigentlich aus drei einzelnen Lücken, die übereinander gestapelt sind. Jede hat eine andere Ursache – und eine andere Strategie zur Beseitigung.

Reibungspunkt #1: Jede Lieferantenrechnung sieht anders aus

Der Posteingang der Kreditorenbuchhaltung eines mittelständischen Herstellers kann PDFs von Grainger, MSC Industrial Supply, Fastenal, McMaster-Carr, einem regionalen Stahlhändler, einem Chemielieferanten und sechs lokalen Maschinenbaubetrieben enthalten. Jeder dieser Lieferanten formatiert seine Rechnung anders. Manche setzen die Bestellnummer in die Kopfzeile. Manche vergraben sie in einem Referenzfeld auf Seite zwei. Manche listen Positionen in einer sauberen Tabelle auf. Manche verwenden Freitext mit Artikelcodes, die durch Bindestriche getrennt sind.

Vorlagenbasierte OCR – die Art, die die meisten ERP-Systeme bündeln – erfordert eine separate Konfiguration für jedes Lieferantenlayout. Wenn Sie einen neuen Lieferanten hinzufügen, erstellen Sie eine neue Vorlage. Wenn Grainger sein Rechnungsformat aktualisiert, bricht die Grainger-Vorlage stillschweigend. Genau dieses Szenario beschrieb ein AP-Profi auf r/Accounting: Sein Team bearbeitet 1.500 bis 2.000 Rechnungen pro Monat, und "das in NetSuite integrierte OCR-Tool scheitert an der Hälfte unserer Rechnungen, weil jede Maschinenbau- und Rohstofflieferantenfirma ihre anders formatiert." Bei vierzig aktiven Lieferanten kann allein die Vorlagenwartung einen erheblichen Teil der Arbeitswoche eines AP-Sachbearbeiters verschlingen – bevor überhaupt Daten extrahiert werden.

Die Alternative: Extraktion, die Daten nach Bedeutung statt nach Position lokalisiert. Anstatt dem System beizubringen "die Rechnungsnummer befindet sich an den Koordinaten (x, y) auf Graingers Vorlage", geben Sie die gewünschten Spaltennamen an – "Rechnungsnummer", "Bestellnummer", "Artikelbeschreibung", "Menge", "Einzelpreis" – und die KI liest jedes Lieferantendokument, um diese Werte zu finden, wo immer sie erscheinen. Die Ausgabe sind identische strukturierte Zeilen, unabhängig davon, ob die Quelle eine formatierte Grainger-PDF, eine gescannte Fastenal-Rechnung oder ein Handyfoto eines handschriftlichen Lieferscheins eines lokalen Lieferanten war. Dies ist der Mechanismus hinter der benutzerdefinierten Spaltenextraktion: Sie geben die Feldnamen vor, und das Vision-Modell lokalisiert jeden Wert, indem es versteht, was er bedeutet, nicht wo er auf der Seite sitzt. Im Gegensatz zur vorlagenbasierten OCR, die auf Pixelpositionen trainiert, behandelt dieser Ansatz jede Lieferantenrechnung als neues zu lesendes Dokument – keine Einrichtung pro Lieferant, keine Vorlagenbrüche bei Formatänderungen.

Reibungspunkt #2: SKR-Kontierung erfordert Fachwissen

Der zweite Reibungspunkt wird von den meisten AP-Automatisierungstools völlig ignoriert. „Artikelbeschreibung“ und „Einzelpreis“ aus einer PDF zu extrahieren ist ein Problem der Datenextraktion. Die richtige Sachkontonummer jeder Position zuzuweisen ist eine Entscheidung der Kostenrechnung – und sie hängt davon ab, was gekauft wurde, nicht davon, was auf der Rechnung steht.

Der Kauf von Edelstahlblech 304 ist ein direktes Material – Soll Rohmaterialbestand (1310). Der Kauf von Kühlschmiermittel vom selben Lieferanten auf derselben Rechnung ist ein indirekter Betriebsstoff – Soll Fertigungsgemeinkosten (4350). Der Kauf von Schutzhandschuhen für die Werkstatt sind ebenfalls Gemeinkosten. Der Kauf von Verpackungsmaterial kann Gemeinkosten oder direktes Material sein, wenn die Verpackung Teil des Fertigprodukts ist. Diese Unterscheidungen sind nirgendwo auf der Rechnung kodiert. Sie leben im Verständnis des Kostenrechners über den Produktionsprozess.

Der Schlüssel zur Beseitigung dieses Reibungspunkts ist, die SKR-Kontierungsentscheidung nach vorne zu verlagern – in den Extraktionsschritt selbst. Anstatt Positionen zu extrahieren und sie danach zu kontieren (zwei getrennte Durchläufe), definieren Sie während der Extraktion eine Spalte, die die KI auffordert, die Klassifizierungsentscheidung spontan zu treffen. Zum Beispiel eine Spalte namens "SKR-Konto (Optionen: 1310-Rohstoffe, 1410-UNF, 1510-Fertigerzeugnisse, 4350-Fertigungsgemeinkosten)" – dies ist eine abgeleitete Spalte, in der die KI die Artikelbeschreibung liest und bestimmt, zu welcher Kategorie sie gehört, obwohl die Rechnung selbst keine SKR-Konten enthält. Die KI liest „304 SS Blech, 0,125×48×96“ und weist 1310 zu. Sie liest „Kühlschmiermittel, 5 Gallonen“ und weist 4350 zu. Die Klassifizierungen erscheinen als Spalte in der Ausgabetabelle – der Kostenrechner prüft sie einmal, korrigiert etwaige Grenzfälle, und die Daten sind bereit für die Kostenverfolgung.

Das ersetzt nicht das Urteilsvermögen des Kostenrechners. Es verlagert seine Tätigkeit von einer Tippübung (Daten eingeben, dann kontieren) zu einer Prüfübung (KI-vorgeschlagene Konten scannen und die Randfälle korrigieren). Das Ergebnis sind Zeilen mit bereits zugewiesenen SKR-Konten, bereit für den Import.

Reibungspunkt #3: Ihr Kosten-Tracker akzeptiert nur ein bestimmtes Format

Der dritte Reibungspunkt ist die Formatkompatibilität. Ein System zur Erfassung von Produktionskosten – ob ERP-Modul oder Tabellenkalkulation – erwartet Daten in einer bestimmten Struktur. Die Spalten müssen in der richtigen Reihenfolge sein. Das Datumsformat muss stimmen. Der Sachkontocode muss im Kontenplan gültig sein. Die Auftragsnummer muss im System existieren.

Die Integrationslösung hängt davon ab, was das Zielsystem akzeptiert:

• CSV- oder Excel-Import. Die meisten ERP-Systeme – SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Epicor Kinetic, Plex – akzeptieren CSV- oder Excel-Importe für Buchungsbelege, Rechnungserfassungen oder Kostenumlagen. Das Extraktionstool liefert eine strukturierte Tabelle – immer dieselben Spalten, dieselbe Reihenfolge – unabhängig davon, welches Lieferanten-PDF eine bestimmte Zeile erzeugt hat. Export als CSV. Import ins ERP. Das Format ändert sich nie, weil die von Ihnen bei der Extraktion definierten Spaltennamen in jeder Ausgabedatei zu den Spaltenüberschriften werden.
• Kopieren und Einfügen in eine Tracking-Tabelle. Für Kostenrechner, die ihre eigene Auftragskalkulationsmappe pflegen – und das sind viele – ist die Ausgabe bereits eine Tabelle. Kopieren Sie die extrahierten Zeilen, fügen Sie sie in die Tracking-Mappe ein. Die Spalten passen, weil Sie sie so definiert haben, dass sie übereinstimmen.
• API-Integration. Für Teams mit Entwicklungsressourcen kann eine strukturierte Ausgabe (JSON, CSV) direkt in die API eines ERP-Systems eingespeist werden. Dies ist der Weg zur Vollautomatisierung – Extraktion → strukturierte Daten → API-Post → ERP-Kostenmodul – erfordert aber IT-Beteiligung für die API-Anbindung. Der Extraktionsschritt selbst ändert sich nicht, unabhängig davon, ob die Übergabe manuell per Import oder per API erfolgt.

Die entscheidende Erkenntnis: Der schwierigste Weg ist der, den die meisten Hersteller gehen – Daten aus einem PDF manuell in den Kosten-Tracker abzutippen. Der einfachste Weg, der den bestehenden Kosten-Tracker erhält, ist der Tabellenexport → Import. Der Weg mit dem höchsten Automatisierungsgrad ist die API. Alle drei Wege beginnen mit demselben Extraktionsergebnis. Sie können mit dem manuellen Import starten und später auf API umsteigen, ohne den vorgelagerten Extraktionsschritt zu ändern.

Die Pipeline von der Rechnung bis zum Kosten-Tracker, Schritt für Schritt

Hier ist der vollständige Workflow für einen Kostenrechner in der Fertigung, der eine Charge von Lieferantenrechnungen verarbeitet und die Daten in ein Produktionskosten-Tracking-System einspeist – etwa zwei Stunden Abtippen werden auf rund zehn Minuten Hochladen und Prüfen verkürzt.

Für den Schritt des Bestellabgleichs vor der Kostenzuordnung – Vergleich von Bestelltem und Berechnetem – siehe unsere Schritt-für-Schritt-Anleitung zum Abgleich von Lieferantenrechnungen mit Bestellungen in der Fertigung. Dieser Artikel beschreibt das Drei-Dokumenten-Abstimmungsframework (Bestellung, Rechnung, Wareneingang), das geprüfte Mengen und Preise für den hier beschriebenen Kostenzuordnungsschritt liefert.

Was nach der Integration gleich bleibt

Das größte Hindernis für die Workflow-Integration ist nicht technischer Natur. Es ist die Angst – oft unausgesprochen –, dass eine Änderung der Dateneingabe nachgelagerte Prozesse stört. Der Kostenrechner, der die Tracking-Tabelle über drei Jahre Monatsabschlüsse aufgebaut hat, sorgt sich, dass die Automatisierung eine Formel überschreibt oder eine Referenzkette unterbricht. Der Controller, der Abweichungsberichte freigibt, sorgt sich, dass automatisch gebuchte Kontierungen Fehler einführen, die erst eine Prüfung aufdeckt.

Diese Ängste sind berechtigt – und der hier beschriebene Integrationsansatz bewahrt den nachgelagerten Workflow unverändert.

Die Kostenrechnungslogik ändert sich nicht. Ob Ihr System Standardkosten (geschätzte Kosten auf Ist-Menge, mit Abweichungen in separaten Sachkonten) oder Istkosten (Kosten pro Fertigungsauftrag mit Lohn-, Material- und Gemeinkostenverrechnung auf Auftragsebene) verwendet – die Berechnungslogik liegt in Ihrem Kosten-Tracker, nicht im Extraktionsschritt. Der Extraktionsschritt erzeugt strukturierte Zeilen. Ihr Kosten-Tracker verarbeitet sie und führt dieselben Formeln, dieselben Zusammenfassungen, dieselbe Abweichungsanalyse aus. Das Eingabeformat hat sich von „von Hand getippt" zu „aus einer Tabelle importiert" geändert. Die Verarbeitungslogik bleibt unberührt.

Der Monatsabschluss verschiebt sich nicht. Die Daten treffen am selben Tag im Kosten-Tracker ein, an dem die Rechnungen eingehen – nicht am Monatsende, wenn die Buchhaltung unter Zeitdruck steht. Das ändert nicht den Abschlussprozess. Es ändert, wann die Daten dafür bereit sind.

Die Prüfkette bleibt erhalten – und wird in mancher Hinsicht besser. Jede Zeile in der Extraktionsausgabe trägt den Quelldateinamen – Grainger_052026.pdf, MSC_PO5531_052026.pdf. Das verknüpft jeden Kosteneintrag mit seinem Ursprungsdokument, was stärker ist als der aktuelle Zustand vieler Hersteller, bei denen das Original-PDF in einem gemeinsamen Posteingang liegt und der Kosteneintrag im ERP nur eine manuelle Buchungsnummer referenziert. Nach ISO 9001:2015 Klausel 8.4 ist die Überprüfung, ob gekaufte Produkte die festgelegten Anforderungen erfüllen, für zertifizierte Hersteller verpflichtend – und ein quellenattribuierter Extraktions-zu-Kosten-Fluss bietet eine dokumentierte Kette von der Lieferantenrechnung bis zur Sachkontenbuchung, die ein manuelles Abtippen nicht erreichen kann.

Das Urteilsvermögen des Kostenrechners bleibt im Spiel. Die KI schlägt Sachkonten vor. Der Kostenrechner prüft und passt an. Die KI extrahiert Mengen und Preise. Der Kostenrechner prüft gegen Bestellung und Wareneingang beim Drei-Wege-Abgleich. Die Fähigkeiten, die einen guten Kostenrechner ausmachen – zu wissen, welche Materialien direkt und welche indirekt sind, Preisabweichungen zu erkennen, die untersucht werden müssen, zu verstehen, wie sich eine Änderung der Lieferantenpreise auf die Standardkosten auswirkt – sind dieselben Fähigkeiten, die die Rolle schon immer erforderte. Die einzige Fähigkeit, die automatisiert wird, ist das Tippen.

Aus den strukturellen Gründen, warum der Drei-Wege-Abgleich in der Fertigung im großen Maßstab scheitert – einschließlich Teillieferungen, Maßeinheitsabweichungen und organisatorischer Silos – finden Sie in unserer Analyse warum der Drei-Wege-Abgleich die Kreditorenbuchhaltung in der Fertigung mehr belastet, als Teams zugeben. Diese Diagnose liefert den Kontext dafür, warum der hier behandelte Extraktionsschritt die Voraussetzung für einen zuverlässigen Abgleich bei hohem Volumen ist.

Häufig gestellte Fragen

Funktioniert das auch, wenn mein Kostenverfolgungssystem eine Tabellenkalkulation und kein ERP ist?

Ja – und in vielerlei Hinsicht sogar besser. Ein kostenverfolgendes Tabellenblatt hat keine Importbeschränkungen, keine Feldvalidierungsregeln und keine IT-Freigabekette. Die Extraktionsausgabe ist bereits ein Tabellenblatt. Kopieren Sie die Zeilen aus der Extraktionsausgabe und fügen Sie sie in Ihre Arbeitsmappe ein. Die von Ihnen während der Extraktion definierten Spaltennamen werden zu den Spaltenüberschriften in der Ausgabe. Solange Sie Spalten definieren, die den Erwartungen Ihres Tabellenblatts entsprechen, ist der Einfügevorgang eine einzige Aktion. Für Hersteller, die anspruchsvolle Excel-Kostenmodelle entwickelt haben – mit Datentabellen, die Pivot-Tabellen speisen, die wiederum Abweichungs-Dashboards speisen – füllt der Extraktionsschritt einfach die Eingabetabelle schneller.

Was ist, wenn mein ERP bestimmte Feldformate erfordert, die von der extrahierten Ausgabe abweichen?

Die meisten ERP-Systeme akzeptieren CSV-Importe mit konfigurierbaren Feldzuordnungen. Der Schlüssel liegt darin, Ihre Extraktionsspalten so zu definieren, dass sie mit der ERP-Importvorlage übereinstimmen – gleiche Spaltennamen, gleiche Reihenfolge. Wenn Ihr ERP "Vendor_Code" erwartet, Ihre Extraktionsausgabe aber "Lieferantenname" sagt, haben Sie zwei Optionen: Benennen Sie die Extraktionsspalte in "Vendor_Code" um, um sie an das ERP anzupassen (die KI kümmert sich nicht darum, wie Sie die Spalte nennen – sie findet den Wert auf der Rechnung unabhängig davon), oder passen Sie die Feldzuordnung während des Imports an. Die einmalige Einrichtung der Spaltenbenennung ist die einzige Konfiguration, die dieser Workflow erfordert.

Wie verarbeitet die KI handschriftliche Lieferscheine oder Handyfotos von Rechnungen?

Die Extraktions-Engine ist ein Vision-Modell – es liest Dokumente so, wie ein Mensch sie liest, indem es visuelle Inhalte semantisch versteht, anstatt Pixelmuster abzugleichen. Eine formatierte PDF von Grainger und ein Handyfoto eines handschriftlichen Lieferscheins von einem lokalen Lieferanten sind beides Bilder, die Text enthalten. Das Vision-Modell liest beide. Die Extraktionsqualität bei Handschrift und Handyfotos ist geringer als bei sauberen PDFs – Sie sollten mit mehr leeren Zellen und gelegentlichen Fehlablesungen rechnen – aber die Spaltenstruktur bleibt über den gesamten Batch hinweg intakt. Entscheidend ist, dass das Tool jedes Dokument unabhängig verarbeitet. Wenn Rechnungsnummer 12 ein unscharfes Foto eines Lieferscheins ist, liefern die anderen 19 Rechnungen im Batch dennoch vollständige Zeilen. Die Philosophie der Batch-Fehlerisolierung wird in unserem Artikel über die Stapelverarbeitung von Rohmaterialrechnungen behandelt.

Kann ich diesen Workflow nutzen, wenn ich staatliche Aufträge mit spezifischen Kostenrechnungsstandards habe?

Der hier beschriebene Workflow ersetzt nicht Ihr Kostenrechnungssystem – er speist es. Wenn Ihre staatlichen Aufträge die Einhaltung von FAR 32.905 (Zahlung von Rechnungen gestützt auf Wareneingangsmeldungen) oder FAR Teil 31 (Kostengrundsätze für öffentliche Aufträge) erfordern, werden diese Compliance-Anforderungen von Ihrem Kostenverfolgungssystem und Ihren internen Kontrollen durchgesetzt – nicht vom Extraktionsschritt. Der Extraktionsschritt erzeugt strukturierte Daten mit Quellenangabe. Ihr Compliance-Rahmenwerk konsumiert diese. Die Extraktionsausgabe enthält den Quelldateinamen für jede Zeile, was eine dokumentierte Kette von der Lieferantenrechnung bis zum Kosteneintrag liefert – eine Kontrolle, die manuelles Abtippen möglicherweise nicht bietet.

Was ist der Unterschied zwischen diesem Ansatz und dem bloßen Kauf eines AP-Automatisierungstools, das „in mein ERP integriert"?

Die meisten AP-Automatisierungstools für die Fertigung – Rillion, Medius, MakersHub und andere – sind für den Workflow der Kreditorenbuchhaltung konzipiert: Rechnung erfassen, mit Bestellung abgleichen, zur Genehmigung weiterleiten, zur Zahlung buchen. Ihre „ERP-Integration" bedeutet, dass die genehmigten Rechnungsdaten als Verbindlichkeit in die Hauptbuchhaltung gebucht werden – nicht, dass positionsbezogene Kostendaten mit Sachkonten, Auftragsnummern und Kostenkategorien in das Produktionskostenmodul fließen. Die Lücke, die dieser Artikel adressiert, ist speziell die Übergabe an die Produktionskostenrechnung: einzelne Positionen auf Bestandskonten zu buchen und in Kostenkalkulationen, Abweichungsanalysen und Auftragskostenberichte einzuspeisen. Diese Lücke besteht unabhängig davon, ob Ihre Kreditorenbuchhaltung ein Automatisierungstool verwendet.

Mit eigenen Lieferantenrechnungen testen