Klicke hier, um ein unverbindliches Erstgespräch zu buchen!

Doku für Abo-Anbieter mit eigenem Abrechnungssystem

Wie lege ich Abo-Rechnungen in Masse per API in weclapp an?

Du legst eine Abo-Rechnung per API mit POST /salesInvoice an, nachdem du den Kundendatensatz über GET /party gefunden oder mit POST /party angelegt hast; Abschluss, Versand und Zahlungszuordnung sind eigene Schritte. Die REST-API gibt es ab ERP Dienstleistung (Listenpreis weclapp, Stand Oktober 2026: 86 € bei jährlich bzw. 95 € bei monatlich gebuchter Lizenz je Nutzer:in und Monat, netto). weclapp hat keine festen Rate-Limits, begrenzt aber gleichzeitige Requests je Tenant: Überzählige warten aktuell bis zu 30 Sekunden, danach folgt HTTP 429.

Postman Collection für die weclapp API ansehen

Welche Schritte hat ein Abrechnungslauf?

weclapp erzeugt den Beleg, dein Abrechnungssystem weiß, wer im Monat was schuldet:

  1. Kundendatensatz finden oder anlegen: Suche in party über customerNumber, sonst POST /party.
  2. Rechnung anlegen: POST /salesInvoice mit customerId und salesInvoiceItems.
  3. Abschließen: Setze status per PUT /salesInvoice/id/{id}?ignoreMissingProperties=true auf DOCUMENT_CREATED (Rechnungsnummer, Dokument) und auf OPEN_ITEM_CREATED (offener Posten); von NEW direkt auf OPEN_ITEM_CREATED geht in einem Request (in einem Testmandanten geprüft).
  4. Versenden: Das übernimmt eine Beleg-E-Mail-Versandregel, kein eigener Endpunkt.
  5. Zahlung zuordnen: weclapp bucht Zahlungen auf offene Posten, mehr auf der Seite Abo-Zahlungen den Rechnungen zuordnen.

Eine Abschlussprüfung beendet den Lauf. Überblick: Buchhaltung für SaaS, Apps und Abo-Geschäft.

SchrittEndpunkt / ObjektFehlerfallWiederholung
1a Datensatz suchenGET /party, Filter customerNumber-inKein oder mehrfacher TrefferLesen ist wiederholbar; Mehrfachtreffer in die Prüfliste
1b Datensatz anlegenPOST /partyHTTP 400 (Validierung)Vorher erneut suchen, sonst Dubletten
2 Rechnung anlegenPOST /salesInvoiceHTTP 400 (auch request_timeout), HTTP 429, TimeoutWarten, Backoff, dann mit der Suche nach dem Lauf-Schlüssel neu beginnen
3 AbschließenStatuswechsel per PUT /salesInvoice/id/{id}?ignoreMissingProperties=trueHTTP 400 (ohne ignoreMissingProperties=true), 403 (laut Doku im Status nicht änderbar), 409optimistic_lock: status und version neu lesen, einmal erneut; context: nicht wiederholen
4 VersendenBeleg-E-Mail-Versandregel (Einstellung)Keine Empfängeradresse, Regel greift nichtAdresse pflegen, Regel prüfen
5 Zahlung zuordnenOffener Posten, Zahlung (Seite Zahlungszuordnung)Zahlung nicht eindeutigPrüfliste, keine Zwangszuordnung
6 AbschlussprüfungGET /salesInvoice/count mit Lauf-Präfix (commission-like), gezählt je StatusAnzahl weicht ab oder Rechnungen bleiben in NEWFehlende gezielt nachholen, nie den ganzen Lauf neu starten

Zahlen auf einen Blick

86 € / 95 €
ERP Dienstleistung je Nutzer:in und Monat (jährlich / monatlich), enthält die REST-API
55 €
Add-on Vertragsmanagement pro Person und Monat, für wiederkehrende Rechnungen durch weclapp selbst
30 s
maximale Wartezeit in der Queue, aktuell, danach HTTP 429
1 min
empfohlener Mindest-Timeout im Client

Listenpreis weclapp, Stand Oktober 2026, netto.

Wie legst du die Rechnung an?

Das Schema kennt am Kopf unter anderem customerId, invoiceDate, dueDate, termOfPaymentId, servicePeriodFrom, servicePeriodTo und commission, je Position title oder articleId, quantity, unitPrice und taxId. Die API-Doku legt fest: id, version, createdDate und lastModifiedDate darfst du nicht senden, nicht vorhandene Felder lösen HTTP 400 aus, und dryRun=true führt die Geschäftslogik soweit möglich aus und validiert die Daten (bei Erfolg 200 statt 201). Prüfe im Testmandanten, dass nichts angelegt wurde. Dort verlangte der dryRun (12.10.2026) nur customerId; Rechnungsdatum (heute), Steuer (Mandantenstandard) und Einheit setzt weclapp selbst, wenn du sie weglässt. Zusätzliche Pflichtfelder zeigt der erste dryRun in deinem Mandanten. Die Antwort enthält weder id noch invoiceNumber und immer status: NEW; Statuswechsel und Löschen bildet der dryRun nicht ab.

Für die Nacht zum Ersten: weclapp speichert ein Kalenderdatum nach unserer Erfahrung als Mitternacht deutscher Zeit. Bildest du das Rechnungsdatum aus „heute in UTC“, erzeugt ein Lauf kurz nach Mitternacht noch das Datum des Vortags, am Monatsersten also den letzten Tag des Vormonats. Damit landet die Rechnung in weclapp im falschen Buchungszeitraum und passt nicht zur Leistungsangabe. Umsatzsteuerlich zählt in Deutschland der Zeitpunkt der Leistung, bei Vorauszahlungen die Vereinnahmung des Entgelts (§ 13 Abs. 1 Nr. 1 Buchst. a UStG), in Österreich kann eine zu späte Rechnung die Steuerschuld um einen Monat verschieben (§ 19 Abs. 2 Z 1 UStG 1994). Leite es aus dem Kalendertag in Europe/Berlin ab. Das ersetzt keine Steuerberatung.

Beispielcode

Pseudocode mit dem Python-Client weclappy, nicht ausgeführt und nur für einen Testmandanten gedacht. Er nutzt ausschließlich dokumentierte Endpunkte; die Postman Collection für die weclapp API enthält sie zum Ausprobieren.

import time
from weclappy import WeclappAPIError                       # Timeout/Verbindungsabbruch: Ausgang unbekannt (ebenfalls WeclappAPIError)

WAIT = (0, 2, 5, 10, 30)   # Sekunden: Queue und Verarbeitung abwarten, bevor neu angelegt wird

def find_invoice(client, key, waits=(0,)):
    for pause in waits:
        time.sleep(pause)
        rows = client.get("salesInvoice", params={
            "commission-eq": key, "properties": "id,version,status,commission,salesInvoiceType"})
        if any(r.commission != key for r in rows):        # 1. Filter still ignoriert (falscher Operator): Lauf anhalten
            raise RuntimeError(f"Filter ignoriert, nichts anlegen: {key}")
        hits = [r for r in rows if r.status != "CANCELLED" and r.salesInvoiceType != "CREDIT_NOTE"]   # 2. Storno und Gutschrift zählen nicht
        if hits:
            return hits
    return []

def finish(client, inv):
    if inv.status == "OPEN_ITEM_CREATED":                 # schon abgeschlossen
        return inv
    return client.put(f"salesInvoice/id/{inv.id}", {"status": "OPEN_ITEM_CREATED", "version": inv.version},
                      params={"ignoreMissingProperties": "true"})   # ohne den Parameter HTTP 400; keine salesInvoiceItems mitsenden; bei 409 neu lesen

def bill_one(client, sub, run_id, customers):
    key = f"{run_id}-{sub.contract_no}"                   # Lauf-Schlüssel
    customer_id = customers.get(sub.customer_no) or create_customer(client, sub, customers)
    hits = find_invoice(client, key)
    if len(hits) > 1:
        return record_error(sub, "mehrfach", key)         # Prüfliste, nicht raten
    if hits:
        return finish(client, hits[0])                    # existiert schon: nur noch abschließen
    try:
        inv = client.post("salesInvoice", {
            "customerId": customer_id, "commission": key,
            "invoiceDate": sub.invoice_date_ms,           # Berlin-Mitternacht
            "servicePeriodFrom": sub.from_ms, "servicePeriodTo": sub.to_ms,
            "salesInvoiceItems": [{
                "title": sub.plan, "quantity": "1",
                "unitPrice": sub.net_price,               # Dezimalstring, netto, Mandantenwährung
                "manualUnitPrice": True,                  # Preis nicht aus Preisliste (laut Feldname)
                "taxId": tax_id_for(sub),                 # z. B. GET /tax/findSalesTax, mit Steuerberatung abstimmen
                "servicePeriodFrom": sub.from_ms, "servicePeriodTo": sub.to_ms}]})
        return finish(client, inv)                        # Abschluss per PUT; ein POST allein endet in NEW
    except WeclappAPIError as exc:   # Transportfehler und Timeouts gesondert behandeln: nicht wiederholen, erst suchen
        if exc.is_validation_error:                      # HTTP 400 ohne request_timeout: kann nicht angekommen sein
            return record_error(sub, type(exc).__name__, exc.detail)
        found = find_invoice(client, key, waits=WAIT)     # 3. nach Fehler erst Wartefolge, dann Suche
        if found:
            return finish(client, found[0])               # Rechnung ist angekommen: nur noch abschließen
        record_error(sub, type(exc).__name__, exc.detail) # unklar: Prüfliste, im nächsten Pass wieder mit der Suche beginnen

Wie schließt du die Rechnung ab?

Die öffentliche Spezifikation nennt keinen eigenen Endpunkt zum Abschließen. Das Feld status kennt NEW, ENTRY_COMPLETED, DOCUMENT_CREATED, OPEN_ITEM_CREATED und CANCELLED, und PUT /salesInvoice/id/{id} nimmt es an; welche Übergänge der Server zulässt, beschreibt die API-Doku nicht. In einem Testmandanten geprüft: Mit ignoreMissingProperties=true und dem Body {"status":"DOCUMENT_CREATED"} vergibt weclapp die endgültige Rechnungsnummer und erzeugt das Dokument, {"status":"OPEN_ITEM_CREATED"} legt zusätzlich den offenen Posten an (GET /salesOpenItem), auch direkt aus NEW. dryRun=true taugt dafür nicht: Er lehnt den Statuswechsel immer ab, obwohl der echte Aufruf funktioniert. Teste mit einer echten Testrechnung und prüfe Status, Rechnungsnummer, Dokument und offenen Posten.

Für Teil-Updates nennt die Doku ignoreMissingProperties=true und version; 409 steht für optimistic_lock, context und persistence. Ohne ignoreMissingProperties=true lehnte weclapp den Status-Request im Test mit 400 ab (statusHistory is read-only); version war optional, eine veraltete version ergab 409. Sende keine salesInvoiceItems mit: Fehlt bei Teil-Updates die id eines Eintrags, entfernt weclapp ihn.

Ein POST ohne Abschluss endet ohne Fehlermeldung, die Rechnung bleibt in NEW, trägt nur eine vorläufige Nummer (PRES…) und hat laut weclapp noch kein Rechnungsdokument. Zähle deshalb am Ende nach Status. Nimmt dein Mandant den Statuswechsel nicht an, nennt die Dokumentation keinen anderen Weg: Schließe die Rechnungen im Mandanten ab oder brich den Lauf ab; wir schauen uns den Fall mit dir an.

Wie geht die Rechnung raus?

Für den E-Mail-Versand gibt es an der Rechnung keine eigene Aktion. Den Versand steuern Beleg-E-Mail-Versandregeln (Globale Einstellungen > Verkauf & Einkauf), die auf Ereignisse wie SALES_INVOICE_DOCUMENT_CREATED reagieren. Das Feld disableRecordEmailingRule am Beleg beschreibt die Spezifikation nicht; dem Namen nach schaltet es die Regel für diesen Beleg ab. Teste das mit Testadressen. Die Regel selbst lässt sich über active deaktivieren, dann für alle Belege des Mandanten. Ob sie bei per API abgeschlossenen Rechnungen auslöst, beschreibt weclapp nicht.

Was tust du nach einem Timeout?

Eine Praxisregel von wals.pro, keine Vorgabe von weclapp: Gib jeder Rechnung einen Lauf-Schlüssel aus Lauf und Vertrag, etwa 2026-11-A4711, in einem filterbaren Feld. Wiederhole nach einem Timeout oder HTTP 429 nicht sofort, denn die Anfrage kann noch in der Queue stehen. Suche mehrfach mit wachsendem Abstand (etwa nach 2, 5, 10 und 30 Sekunden) und lege die Rechnung nur neu an, wenn sie danach fehlt; sonst kommt der Fall in die Prüfliste. Stornierte Belege und Gutschriften tragen ihren Schlüssel weiter (createCreditNote übernimmt die commission) und zählen nicht. Die commission steht als „Kommission“ auf dem Rechnungsdokument, der Lauf-Schlüssel ist also für deine Kund:innen sichtbar; wähle ihn so, dass er dort stehen darf.

Die API-Dokumentation (Abschnitt Filtering) sagt, Filter auf unbekannte oder nicht filterbare Felder würden still ignoriert. In einem Testmandanten (12.10.2026) war es differenzierter: Ein falscher Feldname (comission-eq) ergab HTTP 400, ein falscher oder fehlender Operator (commission-equals, commission=…) wurde still ignoriert und lieferte alle Rechnungen. Der Code bricht deshalb ab, wenn ein Treffer nicht zum Schlüssel passt. Teste die Suche vorab mit zwei Testrechnungen. Einen Idempotenz-Schlüssel für POST haben wir in der API-Dokumentation nicht gefunden.

Wie korrigierst du eine doppelte Rechnung?

Das hängt vom Status ab (weclapp-Dokumentation, Seite geändert 18.09.2023). Im Status „Neu“ oder „Erfassung beendet“ (in der API NEW und ENTRY_COMPLETED) gibt es noch kein Rechnungsdokument und damit keinen Stornobeleg; DELETE /salesInvoice/id/{id} funktionierte im Test in NEW (HTTP 204). Verlass dich dabei nicht auf dryRun=true: Er meldete auch bei einer abgeschlossenen Rechnung 200, der echte Aufruf dort 409 (cannot be deleted). Ab dem Rechnungsdokument lässt sich die Rechnung nicht mehr löschen, nur stornieren, per API mit POST /salesInvoice/id/{id}/cancel (Body {}). Die Workflow-Aktion dafür gibt es laut weclapp nur beim Zahlstatus „offen“; bezahlte Rechnungen korrigierst du über die Gutschrift (createCreditNote), den Beleg des Rechnungsausstellers, nicht die Gutschrift nach § 14 Abs. 4 Nr. 10 UStG. Prüfe vorher, ob eine Versandregel den Stornobeleg automatisch verschickt. Gilt für den Umsatz die E-Rechnungspflicht (Umsätze ab 2027 bzw. 2028), muss auch der Stornobeleg oder die Berichtigung als E-Rechnung ausgestellt werden; in den Übergangsfristen genügt weiterhin eine sonstige Rechnung (BMF-FAQ, Frage 7b).

Eine versendete Doppelrechnung mit ausgewiesener Umsatzsteuer klärst du mit deiner Steuerberatung (§ 14c UStG). Das ersetzt keine Steuerberatung.

Was klärst du steuerlich vorab?

Eine Rechnung nach § 14 Abs. 4 Satz 1 UStG braucht eine einmalig vergebene fortlaufende Nummer (Nr. 4) und den Zeitpunkt der Leistung (Nr. 6), bei Abos den Leistungszeitraum. Für Rechnungen bis 250 € brutto (§ 33 UStDV) und von Kleinunternehmern (§ 34a UStDV) genügen weniger Angaben; bei Leistungen mit Reverse Charge nach § 13b gilt das nicht. Das Schema führt invoiceNumber als schreibbares Feld; wann weclapp die Nummer aus dem Nummernkreis vergibt, beschreibt weclapp nicht. In einem Testmandanten (12.10.2026) trug eine neue Rechnung zunächst nur eine vorläufige Nummer (PRES…, eigener Nummernkreis); die endgültige Rechnungsnummer folgte erst beim Abschluss. dryRun verbrauchte keine Nummer, und eine gelöschte Rechnung in NEW hinterließ eine Lücke nur im vorläufigen Kreis. Nicht getestet ist ein Abbruch zwischen Anlage und Abschluss. Prüfe das in deinem Mandanten und stimme es mit deiner Steuerberatung ab. Setze invoiceNumber nicht selbst. Erzeugt dein Billing-Tool noch eigene Rechnungen, schalte Erstellung und Versand ab oder kennzeichne sie eindeutig als Kopie; über dieselbe Leistung darf es nur eine Rechnung mit Steuerausweis geben, sonst schuldest du die ausgewiesene Steuer mehrfach (§ 14c UStG).

Die Steuerbehandlung je Kundengruppe (Inland, Reverse Charge, OSS) legst du vorab mit deiner Steuerberatung fest; ein für alle Kund:innen fest verdrahteter taxId reicht nicht. Bei Leistungen an Unternehmen in anderen EU-Staaten, für die der Empfänger die Steuer schuldet, stellst du die Rechnung bis zum 15. des Folgemonats aus, gibst beide USt-IdNr. an und weist auf die Steuerschuldnerschaft des Leistungsempfängers hin (§ 14a Abs. 1 UStG). Dein Lauf braucht dafür eine eigene Regel. Findet GET /tax/findSalesTax keine passende Steuerregel, liefert der Aufruf im Test ein leeres Ergebnis statt eines Fehlers; behandle das als Prüffall. servicePeriodFrom und servicePeriodTo (an Kopf und Position) sowie deliveryDate nimmt die API an und speichert sie. Im Standardformular eines Testmandanten erschienen sie nicht auf dem PDF; passe dein Formular an, wenn der Leistungszeitraum gedruckt werden soll. Grundlage: § 14 UStG. Die Paragrafen in diesem Abschnitt gelten für Deutschland. Für Österreich gelten § 11 und § 19 UStG 1994, mehr auf der Seite Buchhaltung für SaaS in Österreich. Das ersetzt keine Steuerberatung.

Was brauchst du an Lizenz?

Die REST-API gehört zu ERP Dienstleistung und ERP Handel, nicht zum Starter. Wiederkehrende Rechnungen, die weclapp selbst erzeugt, gehören laut weclapp zum kostenpflichtigen Add-on Vertragsmanagement, 55 € pro Person und Monat (Listenpreis weclapp, Stand Oktober 2026); für Rechnungen, die dein System per API anlegt, brauchst du es nicht. Für einen reinen API-Betrieb reicht eine Lizenz, eine Mindestanzahl gibt es nicht. Mehr zu Format und Lizenz: E-Rechnung für Abo-Anbieter.

Was gilt bei Last und Rate-Limit?

Die weclapp API hat keine festen Rate-Limits, aber ein Limit für gleichzeitig aktive Requests je Tenant: Überzählige Requests werden nicht abgelehnt, sondern warten in einer Queue, und nach aktuell bis zu 30 Sekunden antwortet die API mit HTTP 429. Dazu bewertet weclapp anhaltend hohe Last nach effektiver Request-Zeit. Timeouts von mindestens einer Minute, Backoff und die Wait-Header erklärt die Seite Hat die weclapp API ein Rate Limit?.

Beispiel: Monatslauf mit 1.200 Rechnungen

Ein fiktives Beispiel, ein Muster und keine Vorgabe von weclapp: Ein App-Unternehmen rechnet am Monatsersten 1.200 Abos ab. Der Lauf startet kurz nach Mitternacht und arbeitet in Paketen mit wenigen parallelen Requests. Je Rechnung folgen Suche und Anlage, dann der Abschluss; Fehler landen in einer Prüfliste. Am Ende zählt er nach Status und vergleicht Anzahl und Nettosummen mit der Soll-Liste.

Die Laufzeit schätzt du so: Rechnungen × Requests je Rechnung × Median der Antwortzeit ÷ parallele Requests. Mit der Annahme von drei Requests je Rechnung (Suche, Anlage, ein Statuswechsel direkt auf OPEN_ITEM_CREATED) sind es 3.600 Requests; mit zwei getrennten Statuswechseln wären es vier Requests und 4.800. Den Median misst du im Testlauf, ohne die Wartezeit aus X-Weclapp-Wait-Ms.

Vor dem Lauf prüfen

Icon: Schlüssel

Lauf-Schlüssel prüfen

Warten, suchen, jeden Treffer gegen den Schlüssel abgleichen, Stornierte und Gutschriften ausschließen.

Icon: Checkliste

Nach Status zählen

Rechnungen, die in NEW bleiben, zeigen einen fehlgeschlagenen Abschluss.

Icon: Versand

Versand testen

disableRecordEmailingRule und Versandregeln im Testmandanten prüfen.

Icon: Zeitzone

Datum in Berlin-Zeit

Rechnungsdatum aus dem Kalendertag in Europe/Berlin ableiten.

Wann passt das nicht?

Passt

  • Dein Abrechnungssystem kennt Kundendatensatz, Tarif und Leistungszeitraum.
  • Du kannst einen Lauf bauen, betreiben und in einem Testmandanten prüfen.
  • Du willst Mahnlauf und Buchhaltungsexport im selben System.

Passt nicht

  • weclapp soll Rhythmus und Verlängerung der Abos steuern: Dafür ist das Add-on Vertragsmanagement gedacht.
  • Du brauchst die Rechnung binnen Sekunden nach jeder Zahlung: Unter Last warten Requests.
  • Dein Mandant nimmt den Abschluss per API nicht an, was dryRun=true nicht zeigt: Dann bleibt der Lauf unvollständig.
  • Du musst bald E-Rechnungen an inländische Firmenkund:innen ausstellen und kannst den Formatweg nicht testen: Kläre das zuerst. Das ersetzt keine Steuerberatung.

Häufige Fragen

Welche weclapp-Lizenz brauche ich für die API?

Die REST-API gibt es ab ERP Dienstleistung, nicht im Starter. Listenpreis weclapp, Stand Oktober 2026: 86 € (jährlich) bzw. 95 € (monatlich) je Nutzer:in und Monat, netto. Für einen reinen API-Betrieb reicht eine Lizenz, eine Mindestanzahl gibt es nicht. Mit einer Lizenz ERP Dienstleistung stellst du beliebig viele Rechnungen.

Wie viele Rechnungen kann ich pro Minute anlegen?

Eine feste Zahl pro Minute nennt weclapp nicht, die API hat keine festen Rate-Limits. Es gibt ein Limit für gleichzeitig aktive Requests je Tenant, und überzählige Requests warten aktuell bis zu 30 Sekunden, danach folgt HTTP 429. Eine Zahl für die Parallelität nennt weclapp nicht. Starte mit wenigen parallelen Requests und beobachte die Wartezeit.

Was mache ich nach einem Timeout beim Anlegen?

Wiederhole den Request nicht blind, denn die Rechnung kann schon angelegt sein oder noch in der Queue stehen. Suche mit wachsendem Abstand nach deinem Lauf-Schlüssel und prüfe jeden Treffer, weil weclapp Filter mit falschem Operator still ignoriert. Stornierte Belege und Gutschriften zählen nicht. Findest du nichts, kommt der Fall in die Prüfliste. Das ist eine Praxisregel von wals.pro, keine Vorgabe von weclapp.

Wie versende ich die Rechnungen per E-Mail?

Im Schema gibt es dafür keine eigene Aktion an der Rechnung. Den Versand steuern Beleg-E-Mail-Versandregeln in den Globalen Einstellungen unter Verkauf & Einkauf. Prüfe vor dem Lauf in einem Testmandanten, welche Regel für per API abgeschlossene Rechnungen greift, damit keine echten E-Mails an Kund:innen gehen.

Kann ich XRechnung oder ZUGFeRD per API erzeugen?

In der öffentlichen API-Spezifikation gibt es an der Rechnung weder ein Feld noch einen Endpunkt für XRechnung, ZUGFeRD oder eine Leitweg-ID; der einzige Dokumentweg ist der PDF-Download. weclapp schreibt in jedem Paket E-Rechnungen als ZUGFeRD, XRechnung und UBL; für ZUGFeRD gibt es eine globale Einstellung für alle PDF-Rechnungsdokumente, XRechnung läuft über eine optionale Workflow-Aktion. Ob ein per API gesteuerter Massenlauf diese Wege auslöst, ist offen: Das PDF einer per API abgeschlossenen Testrechnung enthielt mit der Einstellung unseres Testmandanten keine eingebettete Datei. Kläre das vor dem ersten Lauf im Testmandanten, wir unterstützen dabei. Die Ausstellungspflicht gilt zwischen inländischen Unternehmen für Umsätze, die ab 01.01.2027 ausgeführt werden; hattest du im Vorjahr höchstens 800.000 € Gesamtumsatz, gilt sie ab 01.01.2028. Kleinbeträge bis 250 € brutto und Kleinunternehmer sind ausgenommen. Weitere Ausnahmen erklärt die Seite E-Rechnung für Abo-Anbieter. Das ersetzt keine Steuerberatung.

Wie teste ich den Lauf, ohne Kund:innen zu belasten?

Starte in einem Testmandanten: weclapp bietet 30 Tage kostenloses Testen. Richte dort Steuern, Zahlungsbedingungen, Nummernkreis und Versandregeln wie in deinem Produktivmandanten ein. Prüfe neben dryRun=true, der Abschluss und Löschen abgeschlossener Rechnungen nicht abbildet, einen echten Durchlauf mit Testadressen, und starte den ersten Produktivlauf mit wenigen Rechnungen.

Wie storniere ich eine doppelte Rechnung?

Das hängt vom Status ab. Im Status „Neu“ oder „Erfassung beendet“ gibt es noch kein Rechnungsdokument und damit keinen Stornobeleg. Ab dem Rechnungsdokument kannst du die Rechnung nur stornieren, per API mit POST /salesInvoice/id/{id}/cancel; bezahlte Rechnungen korrigierst du laut weclapp über die Gutschrift. Eine versendete Doppelrechnung behandelst du steuerlich mit deiner Steuerberatung. Das ersetzt keine Steuerberatung.

Probiere die Endpunkte aus, bevor du den Lauf baust.

Die Postman Collection enthält alle Endpunkte der weclapp API-Dokumentation und zusätzlich nicht dokumentierte, für die weclapp keine Zusage gibt; diese Seite nutzt nur dokumentierte. Den Lauf selbst gehen wir im Gespräch mit dir durch.

Du planst einen Massenlauf und willst das Muster gemeinsam durchgehen?

Oder schreib uns

Schreib kurz, worum es bei dir geht.