Rechnungen für deine Lovable-App

Lovable baut die App, aber nicht die Rechnung

Mit Lovable baust du in Stunden einen Shop oder eine SaaS und schaltest über Stripe Checkout Zahlungen frei (Lovable-Doku zur Stripe-Integration). Was danach fehlt, merkst du erst, wenn das Finanzamt oder deine Steuerkanzlei fragt: Lovable erzeugt eine Zahlung, aber keine Rechnung im deutschen Rechtssinn. Kein strukturierter Beleg nach EN 16931, kein GoBD-Archiv, keine Umsatzsteuerlogik nach Land, kein DATEV-Export. Das alles selbst in deiner App nachzubauen, ist genau die Arbeit, die man mit einem KI-Baukasten eigentlich vermeiden wollte.

Genau diese Lücke schließt Rechnungskit, und zwar dort, wo deine App den Kauf ohnehin verarbeitet: in einer Edge Function. Ein API-Aufruf meldet die Bestellung, die Zahlung kommt aus deinem verbundenen Stripe-Konto, und aus dem Verkauf wird eine ZUGFeRD-Rechnung mit deinem Nummernkreis, revisionssicher archiviert und fertig für die DATEV-Buchung.

Warum das mit Lovable gut zusammenpasst

Eine Lovable-App bringt schon mit, was die Anbindung braucht. Standardmäßig läuft sie auf dem eingebauten Backend Lovable Cloud mit Edge Functions und Secrets, wahlweise auf einem eigenen Supabase-Projekt (Lovable-Doku). Über Edge Functions ruft man eine externe API sauber auf: nicht aus dem Browser, sondern serverseitig, mit dem Schlüssel in den Secrets. Auch Lovables Stripe-Integration nutzt sie (Lovable-Doku).

Einen Webhook richtet Lovable dabei standardmäßig nicht ein. Deine App fragt den Zahlungsstatus direkt bei Stripe ab. Für Rechnungskit ist das kein Problem, denn die Zahlung holt sich Rechnungskit über dein verbundenes Stripe-Konto selbst. Deine App muss nur die Bestellung melden, und dafür gibt es zwei Stellen:

• Beim Start des Checkouts. In der Edge Function, die die Checkout-Session anlegt, meldest du die Bestellung mit deiner Bestellnummer und trägst dieselbe Nummer als order_no in payment_intent_data.metadata ein. Bricht der Käufer ab, kommt keine Zahlung, und es entsteht keine Rechnung.
• Nach der Zahlung. In der Funktion, die den Zahlungsstatus prüft, oder in einem Webhook, wenn du Lovable einen einrichten lässt, meldest du die Bestellung mit der Stripe-Zahlungsreferenz als paymentRef. Läuft diese Funktion nur, wenn der Käufer auf deine Erfolgsseite zurückkehrt, kann eine Bestellung fehlen, wenn er das Fenster vorher schließt. Dann zeigt Rechnungskit die Zahlung als Aufgabe „Zahlung ohne Zuordnung“, und du ordnest sie von Hand zu.

Der Aufruf, den du ergänzt

Das Beispiel zeigt den Weg nach der Zahlung: In der Edge Function, die den bezahlten Stripe-Checkout verarbeitet, kommt ein fetch auf POST /v1/orders dazu. Beträge in ganzzahligen Cent, die Stripe-Zahlungsreferenz als paymentRef, der API-Schlüssel aus den Secrets:

// Edge Function, nach bezahltem Stripe-Checkout (session per Stripe-API abgerufen)
const res = await fetch('https://api.rechnungskit.de/v1/orders', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${Deno.env.get('RECHNUNGSKIT_API_KEY')}`,
    'Content-Type': 'application/json',
    'Idempotency-Key': session.id // Stripe-Session-ID: verhindert Doppel-Belege
  },
  body: JSON.stringify({
    orderNo: session.id,
    paymentRef: session.payment_intent, // pi_... aus Stripe
    email: session.customer_details?.email,
    billingAddress: {
      name: session.customer_details?.name,
      country_code: session.customer_details?.address?.country, // Pflicht für die USt
      postal_code: session.customer_details?.address?.postal_code,
      city: session.customer_details?.address?.city,
      street: session.customer_details?.address?.line1
    },
    items: [
      { name: 'Pro-Plan', quantity: 1, unitGrossCents: 2900, taxRate: 19 }
    ]
  })
})

Das war der Code. Die Rechnung selbst entsteht nicht in diesem Aufruf, sondern sobald die Stripe-Zahlung bei Rechnungskit eintrifft und zur Bestellung passt. Ein bezahlt-Feld gibt es bewusst nicht: Den Zahlungsstatus liefert immer dein Zahlungsdienst, nie der Absender. So kann aus einer abgebrochenen Bestellung nie eine echte Rechnung werden.

Woher kommt der API-Schlüssel?

Den Schlüssel erstellst du in Rechnungskit unter Verbindungen → API (direkt unter app.rechnungskit.de/settings/api). Klick auf Schlüssel erstellen, vergib die Berechtigung orders:write (und invoices:read, wenn du fertige Rechnungen zurückholen willst), und du bekommst den vollständigen Schlüssel genau einmal angezeigt. Zum Ausprobieren nimmst du einen rk_test_-Schlüssel, für den Echtbetrieb rk_live_. Den Wert legst du in Lovable unter Cloud, Secrets ab (zum Beispiel als RECHNUNGSKIT_API_KEY), nie im Frontend. In der Edge Function liest du ihn mit Deno.env.get('RECHNUNGSKIT_API_KEY'), genau wie im Beispiel oben.

Verkaufst du physische Ware? Ein Schritt mehr

Bei rein digitalen Produkten und SaaS bist du mit dem Aufruf oben fertig: Die Rechnung entsteht, sobald die Zahlung passt. Verschickst du dagegen echte Ware, kommt ein zweiter Aufruf dazu, denn das Leistungsdatum auf der Rechnung ist der Versandtag, nicht der Zahltag: Eine Versendungslieferung ist mit dem Beginn der Versendung ausgeführt (Abschnitt 13.1 Abs. 2 UStAE). Sobald du die Bestellung verschickst, meldest du das mit POST /v1/fulfillments:

// Wenn die Ware rausgeht (z. B. im "als versendet markieren"-Flow deiner App)
await fetch('https://api.rechnungskit.de/v1/fulfillments', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${Deno.env.get('RECHNUNGSKIT_API_KEY')}`,
    'Content-Type': 'application/json',
    'Idempotency-Key': `fulfill-${orderNo}`
  },
  body: JSON.stringify({
    orderNo,                       // dieselbe Bestellnummer wie bei /v1/orders
    status: 'fulfilled',
    shippedAt: new Date().toISOString(),
    trackingNumber: 'DHL-1234567'  // optional
  })
})

Beim Anlegen der Bestellung setzt du dafür requiresShipping: true, dann wartet Rechnungskit auf diese Fulfillment-Meldung, bevor die Rechnung mit dem richtigen Leistungsdatum entsteht. Lässt du requiresShipping weg (Standard), gibt es keine Warte-Stufe und du brauchst /v1/fulfillments nie.

Einmalige Einrichtung, ehrlich benannt

Der Code ist einfach, aber ein paar Dinge richtest du einmal ein, sonst wundert man sich, warum keine Rechnung erscheint. Diese Punkte nimmt dir kein fetch ab:

• Stripe im Dashboard verbinden und auf API stellen. Deinen Stripe-Account verbindest du einmalig in Rechnungskit unter Verbindungen → Connect und wählst als Verkaufsgrundlage deine API-Bestellungen. Erst dann bringt Rechnungskit Zahlung und Bestellung zusammen. Das ist ein Klick-Schritt, kein Code.
• Länderkürzel mitschicken. Ohne country_code in der Rechnungsadresse lässt sich die Umsatzsteuer nicht bestimmen, und die Bestellung wird abgelehnt. Ein reiner E-Mail-Checkout reicht also nicht.
• Idempotency-Key setzen. Jeder POST braucht den Header, sonst erzeugt ein doppelter Aufruf (etwa eine neu geladene Erfolgsseite) zwei Bestellungen. Die Stripe-Session-ID ist ein guter Wert.
• Bei 5xx erneut senden. Deployments verursachen kurze Aussetzer. Wiederhol den Aufruf mit etwas Abstand, dann geht keine Bestellung verloren, während die Zahlung schon da ist.
• Steuersätze deiner Produkte prüfen. Rechnungskit ordnet neue Produkte automatisch zu, du bestätigst die Zuordnung einmal. Fehlt sie, wird der Beleg zurückgestellt, nicht falsch ausgestellt.

Zeig deiner KI die Doku

Rechnungskit veröffentlicht eine vollständige OpenAPI-3.1-Spezifikation unter api.rechnungskit.de/v1/openapi.json. Du kannst sie der KI in Lovable oder ChatGPT direkt geben mit der Bitte, eine Edge Function zu erzeugen, die zum Stripe-Checkout eine Bestellung an Rechnungskit meldet. Weil die Spezifikation die Pflichtfelder und sogar die Wiederhol-Regel enthält, kommt meist eine korrekte Funktion heraus. Den einen Schritt, den die KI nicht aus dem Code kennt, das Verbinden von Stripe im Dashboard, findest du oben. Die komplette Referenz mit lauffähigen Beispielen steht in der API-Dokumentation. Baust du deine App lieber mit Bolt, Replit oder einem anderen Baukasten? Das funktioniert genauso, siehe Rechnungen für no-code und KI-App-Builder.