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. 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 die Zahlung ohnehin verarbeitet: in der Supabase Edge Function hinter deinem Stripe-Webhook. Ein API-Aufruf, und aus dem Verkauf wird eine ZUGFeRD-Rechnung mit deinem Nummernkreis, revisionssicher archiviert und fertig für die DATEV-Buchung.

Warum das mit Lovable besonders gut zusammenpasst

Eine Lovable-App bringt schon alles mit, was die Anbindung braucht. Sie läuft auf Supabase mit Edge Functions, also serverseitigen Funktionen, und genau so ruft man eine externe API sauber auf: nicht aus dem Browser, sondern aus der Edge Function, mit dem Schlüssel in den Secrets. Für den Stripe-Checkout legt Lovable diese Funktion inklusive Webhook ohnehin an. Du ergänzt dort nur den Aufruf an Rechnungskit. Deshalb ist die Integration weniger neuer Code als ein kleiner Zusatz an einer Stelle, die schon existiert.

Der Aufruf, den du ergänzt

In deiner Edge Function, die den erfolgreichen 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:

// Supabase Edge Function, nach erfolgreichem Stripe-Checkout
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 Einstellungen, 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 (§ 13 UStG). 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 Einstellungen, Verbinden 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 doppelt ausgelöster Stripe-Webhook 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 Supabase Edge Function zu erzeugen, die nach dem 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.