Schritt‑für‑Schritt‑Plan für eine Vendor‑Invoice‑Web‑App: Rechnungen erfassen, Genehmigungen routen, Zahlungsstatus verfolgen, Erinnerungen senden und Ausgaben sicher berichten.
Bevor Sie Tools auswählen oder Bildschirme entwerfen, klären Sie genau, welches Problem Sie für wen lösen. Eine Lieferantenrechnungs‑App kann sehr unterschiedliche Bedürfnisse bedienen, je nachdem, wer sie täglich nutzt.
Nennen Sie die Kernnutzergruppen:
Gestalten Sie Ihr MVP um die kleinstmögliche Nutzergruppe, die Wert freisetzt – meist AP + Genehmigende.
Wählen Sie die drei wichtigsten Ergebnisse. Gängige Optionen sind:
Schreiben Sie diese Ergebnisse auf; sie werden zu Ihren Abnahmekriterien.
Teams meinen oft Verschiedenes mit „bezahlt“. Legen Sie Ihre offiziellen Status früh fest, z. B.:
Definieren Sie auch, was einen Statuswechsel auslöst (Genehmigung, Export zur Buchhaltung, Bankbestätigung etc.).
Für ein MVP streben Sie an: Rechnungsaufnahme, Basisvalidierung, Genehmigungsrouting, Status‑Tracking und einfache Berichte. Schieben Sie fortgeschrittene Punkte (OCR, Lieferantenportal, tiefe ERP‑Syncs, komplexe Ausnahmen) auf eine „später“‑Liste mit klarer Begründung.
Bevor Sie Bildschirme oder Tabellen bauen, schreiben Sie den realen Weg auf, den eine Rechnung in Ihrer Firma nimmt – vom Eingang bis zur Zahlungsbestätigung. Das wird die Quelle der Wahrheit für Status, Benachrichtigungen und Berichte.
Erfassen Sie, wo Rechnungen eingehen (E‑Mail‑Inbox, Lieferantenportal, Post‑Scan, Mitarbeiter‑Upload) und wer sie als Nächstes bearbeitet. Interviewen Sie AP und mindestens einen Genehmigenden; oft finden Sie inoffizielle Schritte (Neben‑E‑Mails, Tabellenprüfungen), die unterstützt oder bewusst entfernt werden müssen.
Die meisten Invoice‑to‑Payment‑Flows haben einige Pflicht‑Gates:
Schreiben Sie jeden Checkpoint als Statuswechsel mit klarem Besitzer und Input/Output. Beispiel: „AP kontiert Rechnung → Rechnung wird ‘Ready for approval’ → Genehmigender genehmigt oder fordert Änderungen an.“
Listen Sie Edge‑Cases auf, die den einfachen Happy‑Path unterbrechen:
Bestimmen Sie Zeiterwartungen pro Schritt (z. B. Genehmigung innerhalb von 3 Arbeitstagen, Zahlung innerhalb der Netto‑Frist) und was passiert, wenn diese verpasst werden: Erinnerungen, Eskalation an einen Manager oder automatische Umleitung. Diese Regeln steuern später Benachrichtigungen und Reporting‑Design.
Ein klares Datenmodell hält Ihre App konsistent, wenn Rechnungen von Upload bis Zahlung wandern. Starten Sie mit einer kleinen Menge an Entitäten, die Sie später erweitern können.
Mindestens modellieren Sie diese als separate Tabellen/Sammlungen:
Halten Sie Geldfelder als Ganzzahlen (z. B. Cent), um Rundungsfehler zu vermeiden.
Machen Sie für das Absenden obligatorisch: Lieferant, Rechnungsnummer, Rechnungsdatum, Währung und Gesamtbetrag. Fügen Sie Fälligkeitsdatum, Steuern und PO‑Nummer hinzu, wenn Ihr Prozess davon abhängt.
Definieren Sie einen einzelnen Status auf der Rechnung, damit alle dieselbe Wahrheit sehen:
Fügen Sie eine Unique‑Constraint auf (vendor_id, invoice_number) hinzu. Das ist der einfachste, wirkungsvollste Schutz gegen Doppelerfassung – besonders wenn Sie später Upload und OCR hinzufügen.
Zugriffskontrolle entscheidet, ob Ihre App ordentlich bleibt oder zum Chaos wird. Definieren Sie eine kleine Menge an Rollen und seien Sie explizit, was jede Rolle darf.
Halten Sie Berechtigungen handlungsbasiert (nicht bildschirmbasiert): view, create/upload, edit, approve, override, export, manage settings. Viele Teams erlauben z. B. AP Clerks, Header‑Felder (Lieferant, Betrag, Fälligkeitsdatum) zu bearbeiten, aber nicht Bankdetails oder Steuer‑IDs.
Wenn mehrere Geschäftseinheiten dasselbe System nutzen, schränken Sie den Zugriff nach Lieferant oder Lieferantengruppe ein. Typische Regeln:
Das verhindert versehentliche Daten‑Offenlegung und hält Postfächer fokussiert.
Unterstützen Sie Delegation mit Start/End‑Daten und einem Audit‑Hinweis („Genehmigt von Stellvertreter im Auftrag von X“). Fügen Sie eine einfache Seite „Wer deckt wen ab“ hinzu und verlangen Sie, dass Delegationen von AP Admins (oder dem Manager) erstellt werden, um Missbrauch zu vermeiden.
Eine gute AP‑App wirkt selbsterklärend beim ersten Öffnen. Ziel: wenige Bildschirme, die dem Arbeitsfluss entsprechen: Rechnungen finden, verstehen, was passiert, genehmigen, was wartet, und prüfen, was fällig ist.
Machen Sie die Standardansicht zu einer Tabelle, die schnelles Scannen und schnelle Entscheidungen unterstützt.
Fügen Sie Filter für Status, Lieferant und Fälligkeitsdatum hinzu, plus Suche nach Rechnungsnummer und Betrag. Ergänzen Sie Massenaktionen wie „Owner zuweisen“, „Info anfordern“ oder „Als bezahlt markieren“ (mit Berechtigungsprüfungen). Speichern Sie einen Filter wie „Fällig in 7 Tagen“ für wöchentliche Reviews.
Der Detailbildschirm sollte beantworten: Was ist diese Rechnung, wo hängt sie und was ist der nächste Schritt?
Fügen Sie eine klare Timeline (erhalten → validiert → genehmigt → geplant → bezahlt), einen Notiz‑Thread für Kontext und Anhänge (Original‑PDF, E‑Mails, Supporting Docs) hinzu. Platzieren Sie Hauptaktionen (Genehmigen, Ablehnen, Änderungen anfordern) oben, damit sie nicht vergraben sind.
Erstellen Sie eine dedizierte Queue, die nur zeigt, was Aktion benötigt. Unterstützen Sie Genehmigen/Ablehnen mit Kommentar und ein schnelles „Wesentliche Felder anzeigen“‑Panel, um Klicks zu sparen. Halten Sie die Navigation zurück zur Liste, damit Manager in kurzen Sessions arbeiten können.
Bieten Sie eine vereinfachte Ansicht für „Was ist fällig und was ist überfällig?“ Gruppieren Sie nach Fälligkeitsdatum (überfällig, diese Woche, nächste Woche) und machen Sie Status visuell unterscheidbar. Verlinken Sie jede Zeile zur Rechnungs‑Detailseite.
Halten Sie die Navigation konsistent: ein Linkes Menü mit Invoices, Approvals, Payments und Reports (/reports), und Breadcrumbs auf Detailseiten.
Die Erfassung ist der Punkt, an dem die reale, unordentliche Welt in Ihr System gelangt. Machen Sie sie menschlich freundlich, aber streng bei Datenqualität. Starten Sie mit einigen verlässlichen Aufnahmewegen, dann schichten Sie Automatisierung drauf.
Unterstützen Sie mehrere Wege, eine Rechnung ins System zu bringen:
Halten Sie die erste Version einfach: jeder Weg sollte zum selben Ergebnis führen — ein Draft‑Rechnungsdatensatz mit angehängter Quelldatei.
Akzeptieren Sie mindestens PDF und gängige Bildformate (JPG/PNG). Wenn Lieferanten strukturierte Dateien schicken, fügen Sie einen separaten CSV‑Import mit Vorlage und klaren Fehlermeldungen hinzu.
Speichern Sie die Originaldatei unverändert, damit die Finanzabteilung stets die Quelle prüfen kann.
Validieren Sie beim Speichern und beim Absenden zur Genehmigung:
OCR kann Felder aus PDFs/Bildern vorschlagen, behandeln Sie es aber als Vorschlag. Zeigen Sie Vertrauens‑Indikatoren und verlangen Sie, dass ein Mensch extrahierte Werte bestätigt oder korrigiert, bevor die Rechnung weitergeht.
Genehmigungen machen aus einer Liste einen echten AP‑Prozess. Ziel: die richtigen Personen prüfen die richtigen Rechnungen, Entscheidungen werden aufgezeichnet und Änderungen nach Genehmigung werden kontrolliert.
Starten Sie mit einer Regeln‑Engine, die Nicht‑Technikern leicht zu erklären ist. Gängige Routing‑Regeln:
Halten Sie die erste Version vorhersehbar: ein primärer Genehmigender pro Schritt und eine klare nächste Aktion.
Jede Entscheidung sollte einen unveränderlichen Log‑Eintrag erzeugen: invoice ID, Step‑Name, Actor, Action (approved/rejected/sent back), Timestamp und Kommentar. Halten Sie dieses Log getrennt von editierbaren Rechnungsfeldern, damit Sie immer beantworten können: „Wer hat wann was genehmigt?".
Rechnungen brauchen oft Korrekturen (fehlende PO, falsche Kontierung, Duplikat). Unterstützen Sie „Zurück an AP“ mit verpflichtenden Rework‑Gründen und optionalen Anhängen. Bei Ablehnungen erfassen Sie standardisierte Gründe (Duplikat, falscher Betrag, nicht konform) plus Freitext.
Nach Genehmigung sollten Bearbeitungen eingeschränkt sein. Zwei praktikable Optionen:
Das verhindert stille Änderungen und erhält die Aussagekraft von Genehmigungen.
Sobald Rechnungen genehmigt sind, sollte die App vom „wer muss unterschreiben?“‑Modus in den „was ist die Zahlungsrealität?“‑Modus wechseln. Behandeln Sie Zahlungen als erstklassige Datensätze, nicht als simples Häkchen.
Speichern Sie pro Rechnung eine oder mehrere Zahlungseinträge mit:
Das liefert eine prüfungsfreundliche Historie ohne freie Textpflichtfelder.
Modellieren Sie Zahlungen als One‑to‑Many: Invoice → Payments. Berechnen Sie Totale so:
Der Status sollte die Realität widerspiegeln: Unpaid, Partially paid, Paid und Overpaid (kommt bei Gutschriften oder Doppelzahlungen vor).
Fügen Sie einen Scheduled‑Zustand für geplante Zahlungen mit geplantem Zeitstempel (und optionalem erwarteten Valutadatum) hinzu. Wenn Geld tatsächlich abgeht, wechseln Sie zu Paid und erfassen finalen Zeitstempel und Referenz‑ID.
Bauen Sie Match‑Workflows, die Zahlungen mit externen Belegen verbinden:
Benachrichtigungen sind der Unterschied zwischen einer ordentlichen Queue und Rechnungen, die leise überfällig werden. Behandeln Sie sie als Workflow‑Feature, nicht als Add‑on.
Starten Sie mit zwei Typen von Erinnerungen: anstehende Fälligkeiten und überfällige Rechnungen. Ein einfacher Standard funktioniert gut (z. B. 7 Tage vor Fälligkeit, 1 Tag vor Fälligkeit, dann alle 3 Tage überfällig), aber machen Sie ihn konfigurierbar pro Firma.
Lassen Sie Erinnerungen intelligent genug sein, um Rechnungen zu überspringen, die Paid, Canceled oder On Hold sind, und pausieren Sie bei Streitfällen.
Genehmigende sollen eine Erinnerung erhalten, wenn eine Rechnung in ihre Queue kommt, und erneut, wenn sie nach einer definierten SLA noch wartet.
Eskalationen sollen explizit sein: wenn innerhalb von (z. B.) 48 Stunden nichts passiert, benachrichtigen Sie den nächsten Genehmigenden oder einen Finance‑Admin und markieren die Rechnung als Escalated, damit sie in der UI auffällt.
Geben Sie Nutzern Kontrolle über:
Für In‑App‑Alerts reicht meist ein Benachrichtigungszentrum mit Badge‑Zähler.
Digests reduzieren Lärm, halten aber Verantwortlichkeit. Enthalten Sie eine kurze Zusammenfassung: Rechnungen, die auf den Nutzer warten, Items, die Fällig werden, und alles, was eskaliert ist. Verlinken Sie direkt zu gefilterten Views wie /invoices?status=pending_approval oder /invoices?due=overdue.
Protokollieren Sie jede versendete Benachrichtigung (und Snooze/Unsubscribe‑Aktionen) zur Unterstützung von Troubleshooting und Audits.
Integrationen sparen Zeit, bringen aber Komplexität (Auth, Rate‑Limits, unsauberes Mapping). Behandeln Sie sie als optional, bis Ihr Kernworkflow steht. Ein gutes MVP liefert viel Wert mit sauberen Exporten, die die Buchhaltung importieren kann.
Liefern Sie zuerst einen zuverlässigen CSV‑Export – filterbar nach Datum, Lieferant, Status oder Payment‑Batch. Enthalten Sie stabile IDs, sodass Re‑Exporte keine Duplikate in einem anderen System erzeugen.
Beispiel‑Exportfelder: invoice_number, vendor_name, invoice_date, due_date, total_amount, currency, approval_status, payment_status, internal_invoice_id.
Wenn Sie bereits eine API haben, kann ein JSON‑Export‑Endpoint später leichte Automatisierung unterstützen.
Bevor Sie QuickBooks/Xero/NetSuite/SAP‑Connectoren bauen, notieren Sie:
Ein kleines „Integration Settings“‑Panel hilft: externe IDs, Standardkonten, Steuerbehandlung und Exportregeln speichern. Verlinken Sie es von /settings/integrations.
Bei Zwei‑Wege‑Sync erwarten Sie Teilfehler. Verwenden Sie eine Queue mit Retries und zeigen Sie den Leuten, was passiert ist:
Protokollieren Sie jede Sync‑Versuch mit Timestamp und Payload‑Zusammenfassung, damit Finance Änderungen auditieren kann.
Sicherheit ist kein Nice‑to‑Have in Accounts Payable. Rechnungen enthalten Bankdaten, Steuer‑IDs, Preise und interne Genehmiger‑Notizen – genau die Daten, die Schaden anrichten können, wenn sie geleakt oder manipuliert werden.
Behandeln Sie das Audit‑Log als Kernfeature, nicht als Debug‑Tool. Protokollieren Sie unveränderliche Events für Momente, die zählen: Rechnungsabsendungen, OCR/Import‑Ergebnisse, Feld‑Edits, Genehmigungsentscheidungen, Neu‑Zuweisungen, Exceptions, Zahlung‑Updates.
Ein nützlicher Audit‑Eintrag enthält: wer es getan hat, was sich geändert hat (alt → neu), wann es geschah und woher es kam (UI, API, Integration). Speichern Sie es append‑only, damit es nachträglich nicht überschrieben werden kann.
Nutzen Sie TLS für allen Traffic (auch interne Service‑Calls). Verschlüsseln Sie sensible Daten at‑rest in DB und Objektspeicher (PDFs/Bilder). Wenn Sie Bankdaten oder Steuer‑IDs speichern, erwägen Sie Feld‑Level‑Verschlüsselung, damit die sensibelsten Werte geschützt sind, selbst wenn ein DB‑Snapshot geleakt würde.
Beschränken Sie zudem, wer Originaldateien herunterladen darf; oft brauchen weniger Leute Datei‑Zugriff als Status‑Sichtbarkeit.
Starten Sie mit sicherer Authentifizierung (E‑Mail/Passwort mit starker Hashing‑Strategie oder SSO, wenn Kunden es erwarten). Fügen Sie Session‑Kontrollen hinzu: kurzlebige Sessions, sichere Cookies, CSRF‑Schutz und optionale MFA für Admins.
Erzwingen Sie Principle of Least Privilege, besonders für Aktionen wie Bearbeiten genehmigter Rechnungen, Zahlungsstatus ändern oder Daten exportieren.
Definieren Sie Aufbewahrungsfristen für Rechnungen, Logs und Anhänge sowie das Vorgehen bei Löschanfragen. Richten Sie regelmäßige Backups ein und testen Sie Wiederherstellungen, damit Recovery nach Fehlern oder Ausfällen vorhersehbar ist.
Reporting verwandelt tägliche Rechnungs‑Updates in Klarheit für Finance und Budgetverantwortliche. Starten Sie mit einigen hochsignifikanten Views, die die Fragen beantworten, die beim Monatsabschluss auftauchen.
Bauen Sie zuerst 3–4 zentrale Berichte, dann erweitern Sie anhand echter Nutzung:
Fügen Sie Saved Filters wie „Diese Woche fällig“, „Unapproved > $10k“ und „Rechnungen ohne PO“ hinzu. Machen Sie jede Tabelle exportierbar (CSV/XLSX) mit konsistenten Spalten, damit Buchhalter Templates wiederverwenden können.
Halten Sie Diagramme simpel: Status‑Counts, stehende Fälligkeiten‑Summen und ein kleines „At‑Risk“‑Panel (überfällig + hoher Wert). Ziel ist schnelle Triage, nicht tiefgehende Analytics.
Stellen Sie sicher, dass Reports RBAC‑Konform sind: Nutzer sehen nur Rechnungen für ihre Abteilung/Einheiten, und Exporte erzwingen dieselben Regeln, um Datenlecks zu vermeiden.
Eine Lieferantenrechnungs‑App braucht kein exotisches Setup, um zuverlässig zu sein. Optimieren Sie auf schnelle Lieferung, Wartbarkeit und Hiring‑Fähigkeit — erhöhen Sie Komplexität erst, wenn nötig.
Wählen Sie eine verbreitete, gut unterstützte Option:
Alle genannten Optionen können Rechnungserfassung, Genehmigungen und Zahlungsstatus‑Tracking gut abbilden.
Wenn Sie die erste Version noch schneller bauen wollen, kann eine vibe‑coding‑Plattform wie Koder.ai helfen, eine React‑UI und Backend‑Workflows schnell aus einer Chat‑basierten Spezifikation hochzufahren — danach iterieren Sie an Regeln, Rollen und Reports.
Starten Sie mit einer Web‑App + einer Datenbank (z. B. Postgres). Trennen Sie sauber UI, API und DB‑Layer, aber deployen Sie initial als eine Einheit. Microservices nur bei echtem Skalierungsbedarf.
OCR, Bank/ERP‑Importe, Erinnerungen und PDF‑Generierung sind langsam oder unbeständig. Führen Sie sie via Job‑Queue aus (Sidekiq/Celery/BullMQ), damit die App responsiv bleibt und Fehler automatisch retrybar sind.
Rechnungen und Belege sind zentral. Speichern Sie Dateien in Cloud Object Storage (S3‑kompatibel) statt auf dem Webserver. Ergänzen Sie:
Das hält das System zuverlässig, ohne zu überengineeren.
Eine Invoice‑App wirkt nur „einfach“, wenn sie vorhersehbar ist. Behandeln Sie Tests und Deployments als Produktfeatures.
Konzentrieren Sie Tests auf Regeln, die Rechnungs‑Outcomes beeinflussen:
Fügen Sie einige End‑to‑End‑Tests hinzu, die echte Arbeitsszenarien nachstellen: Upload, Routing, Zahlungsstatus‑Update, Audit‑Trail‑Verifikation.
Legen Sie Beispieldaten und Scripts für Demos/QA an: ein paar Lieferanten, Rechnungen in verschiedenen Status und ein paar „Problem‑Rechnungen“ (fehlende PO, Duplikat, falsche Summen). So können Support, Sales und QA Probleme ohne Eingriff in Produktion reproduzieren.
Planen Sie Deployment mit Staging + Production, Environment‑Variablen und Logging ab Tag eins. Staging sollte Prod‑Einstellungen spiegeln, damit der Workflow vor Release gleich läuft.
Plattformen wie Koder.ai bieten Snapshots und Rollbacks, die helfen, Workflow‑Änderungen sicher zu testen und bei Bedarf schnell zurückzusetzen.
Liefern Sie iterativ: Erst das MVP (Erfassung, Genehmigungen, Zahlungsstatus‑Tracking), dann ERP/Accounting‑Integrationen, dann fortgeschrittene Automatisierung wie Erinnerungen und Eskalationen. Verbinden Sie jedes Release mit einem messbaren Ziel (weniger verspätete Zahlungen, weniger Ausnahmen, schnellere Genehmigungen).
Starten Sie mit AP‑Mitarbeitern + Genehmigenden. Dieses Duo bildet den Kernzyklus: Rechnungen werden erfasst, validiert, genehmigt und bis zur Zahlung nachverfolgt.
Fügen Sie Finanz‑Admins, Berichtsempfänger und ein Lieferantenportal erst hinzu, wenn der Workflow stabil ist und die Akzeptanz nachgewiesen wurde.
Wählen Sie 3 messbare Ziele und nutzen Sie diese als Abnahmekriterien, z. B.:
Wenn ein Feature keines dieser Ziele verbessert, schieben Sie es auf die „später“‑Liste.
Schreiben Sie eine offizielle Statuskette und den Auslöser für jede Änderung auf, z. B.:
Vermeiden Sie mehrdeutige Zustände wie „processed“, es sei denn, Sie definieren genau, was damit gemeint ist.
Minimale praktische Tabellen/Sammlungen:
Behalten Sie Geldbeträge als Ganzzahlen (Cent), um Rundungsfehler zu vermeiden, und bewahren Sie die Originalrechnung unverändert auf.
Setzen Sie eine Unique‑Constraint auf (vendor_id, invoice_number). Bei Bedarf ergänzen Sie eine sekundäre Prüfung (Betrag/Datum‑Fenster) für Lieferanten, die Nummern wiederverwenden.
Zeigen Sie in der UI eine klare „möglicher Duplikat“‑Warnung mit Links zu passenden Rechnungen, damit AP das schnell klären kann.
Verwenden Sie eine kleine Rollenauswahl und handlungsorientierte Berechtigungen:
Verknüpfen Sie Berechtigungen mit Aktionen wie view, edit, approve, export statt mit einzelnen Bildschirmen.
Unterstützen Sie Delegation mit:
Stellen Sie außerdem eine einfache Seite bereit, die aktive Delegationen anzeigt, damit die Abdeckung sichtbar ist.
Betrachten Sie Validierung als Tor beim Speichern und beim Absenden:
Alle Aufnahmewege (manuell, Upload, E‑Mail) sollen das gleiche Ergebnis liefern: eine .
Behandeln Sie Zahlungen als erstklassige Datensätze mit:
Berechnen Sie:
Das macht Teilzahlungen und Abstimmung einfach und vermeidet „Checkbox‑Buchhaltung“.
Machen Sie die erste Integrationsstufe MVP‑freundlich:
Zwei‑Wege‑Sync erst hinzufügen, wenn der interne Workflow verlässlich und auditiert ist.
