MeineKasse und Stripe für Steuerbots einrichten

Die beiden Bots verwenden vorhandene SIHub-Arbeitsbereiche, eine lesende MeineKasse-Action und feste Stripe-Einmalpreise in EUR. Der Betreiberhelfer scripts/setup-tax-integrations.py zeigt zunächst einen Plan. Mit --apply prüft bzw. erstellt er die gewählten Stripe-Objekte oder bindet ein neues Kassen-Service-Secret an den festgelegten Mandanten. Er erstellt keine Zahlung und übermittelt keine Steuererklärung.

Private Konfiguration vorbereiten

Verwende die vorhandene SIHub-Betreiberdatei, zum Beispiel /etc/sihub/sihub.env, mit DATABASE_URL und öffentlicher HTTPS-Adresse AIHUB_PUBLIC_URL. Die MeineKasse-Datei muss separat vorliegen und vom MeineKasse-Dienst geladen werden. Beide Dateien müssen reguläre Dateien im Eigentum des aufrufenden Betriebskontos mit Modus 0600 sein. Symlinks und zwischenzeitlich veränderte Dateien werden abgelehnt. Den Helfer aus dem SIHub-Verzeichnis mit dessen Python-Umgebung starten.

Secrets gehören in diese Betreiberdateien oder die vorhandene Secret-Verwaltung. Die verdeckte Abfrage eines fehlenden Stripe-Schlüssels liest ihn direkt am Terminal; Übergabe als Kommandozeilenargument oder im Chat ist nicht vorgesehen. Der Helfer gibt keine Schlüssel aus. Jede Änderung erhält eine private Sicherung. Dienstkonfiguration und EnvironmentFile müssen auf die gewählten Dateien zeigen; anschließend die betroffenen Dienste neu starten und den lokalen Stand unter /api/tax-at/setup/status prüfen.

Beide Stripe-Preise festlegen

Für jeden Bot muss entweder ein vorhandenes öffentliches price_...-Objekt oder ein ausdrücklich festgelegter Betrag vorliegen. Beträge sind EUR-Dezimalwerte; der Helfer berechnet Centbeträge ohne Float-Rundung. exclusive bedeutet Nettopreis, inclusive Bruttopreis. Beispiele enthalten Platzhalter für vom Betreiber festgelegte Werte:

python scripts/setup-tax-integrations.py --env-file /etc/sihub/sihub.env stripe \
  --ea-amount '<E/A-Preis in EUR>' --balance-amount '<Bilanz-Preis in EUR>' \
  --tax-behavior exclusive

Vorhandene Preisobjekte prüfen:

python scripts/setup-tax-integrations.py --env-file /etc/sihub/sihub.env stripe \
  --ea-price-id '<price_...>' --balance-price-id '<price_...>'

Zum Ausführen --apply vor stripe ergänzen. Der Helfer prüft Konto und Test-/Livemodus. Bestehende Preise müssen aktiv, einmalig, in EUR und im gleichen Modus sein. Neue Produkte und Preise erhalten stabile Idempotenzkennungen. Er hinterlegt SIHUB_STRIPE_PRICE_BOT_TAX_AT_EA, SIHUB_STRIPE_PRICE_BOT_TAX_AT_BALANCE, Konto-/Webhookkennung und Webhook-Secret. Ein vorhandenes Webhook-Secret wird nur bei bestätigter Konto-, Modus-, Endpoint- und Ereignisbindung wiederverwendet. Kontomigration und Moduswechsel bei bestehenden Käufen werden nicht automatisch durchgeführt.

Das Preisfeld tax_behavior berechnet für sich allein keine Umsatzsteuer. Wer Stripe Tax bereits eingerichtet hat, kann --automatic-tax ergänzen; der Helfer prüft die aktive Einrichtung vor dem Anlegen von Objekten und setzt dann SIHUB_STRIPE_AUTOMATIC_TAX=1. Er richtet keine Steuerregistrierungen ein. Ohne diese Option bleibt die konkrete Steuer-/Rechnungsabwicklung Betreiberaufgabe. Stripe: Steuerkonfiguration, Preisobjekte.

Checkout für die Steuerbots sammelt Firmen-Steuerkennzeichen und aktualisiert Namen und Rechnungsadresse des Stripe-Kunden. Die Erfassung eines Kennzeichens ersetzt keine fachliche UID-Prüfung. Zahlungs- und Steuerbelege sind anhand der tatsächlichen Stripe-/Rechnungskonfiguration zu kontrollieren. Stripe: Steuerkennzeichen in Checkout.

Nach dem Neustart kann ein Owner/Admin POST /api/tax-at/setup/check ausführen. Diese Prüfung liest die beiden konfigurierten Stripe-Preise; sie erzeugt weder Checkout noch Zahlung. Einen Testkauf mit einem getrennten Testkonto durchführen, bevor echte Verkäufe aktiviert werden.

MeineKasse an einen Mandanten binden

Zuerst einen echten Kanzlei-Arbeitsbereich und darin einen Steuermandanten anlegen. Erforderlich sind SIHub-Arbeitsbereich-ID, SIHub-Mandanten-ID, MeineKasse-Mandantenkennung, zugehörige feste Datenbankkennung und öffentlich erreichbarer HTTPS-Exportendpoint. Der Exporter muss in MeineKasse registriert sein:

python scripts/setup-tax-integrations.py --env-file /etc/sihub/sihub.env cash \
  --cash-env-file /etc/meinekasse/meinekasse.env \
  --workspace-id '<SIHub-Arbeitsbereich>' --client-id '<SIHub-Mandant>' \
  --tenant-id '<MeineKasse-Mandant>' --database '<Kassendatenbank>' \
  --endpoint 'https://<Kassenhost>/api/sihub/tax-export'

Zum Ausführen --apply vor cash ergänzen. Der Helfer prüft die lokale Arbeitsbereich-/Mandantenzuordnung und vorhandene Action, erzeugt ein zufälliges Service-Secret und speichert es ausschließlich in der SIHub-Datei. Die MeineKasse-Datei erhält nur dessen SHA-256 mit fester Mandanten-/Datenbankbindung in MEINEKASSE_SIHUB_EXPORT_BINDINGS. Andere Bindungen bleiben erhalten. In SIHub wird eine aktive GET-Action mit read_only=true, auto_execute=false, festem tenant_id und gebundenem HTTPS-Host angelegt bzw. aktualisiert.

Der separate Schalter AIHUB_TAX_SYNC_ENABLED=1, die Liste AIHUB_TAX_SYNC_WORKSPACE_IDS und die Arbeitsbereichseinstellung tax_sync_enabled=true geben nur den lesenden Steuerimport frei. Demo-Arbeitsbereiche sind ausgeschlossen. Die Einrichtung aktiviert keine Modellantworten oder Telefonanrufe. Für den bestehenden allgemeinen Livepfad gelten weiterhin dessen eigene Freigaben.

Die Einrichtung schreibt zwei private Dateien und eine Datenbankkonfiguration. Stabile private Dateisperren koordinieren parallele Helferaufrufe bis zum Datenbankabschluss. Bei einem Schreib- oder Datenbankfehler werden ausschließlich die eigenen unveränderten Dateistände zurückgesetzt; fremde zwischenzeitliche Änderungen bleiben erhalten und verlangen einen Abgleich mit den privaten Sicherungen. Der abschließende Datenbankschritt prüft Mandant, Arbeitsbereich und Action erneut. Die Ausgabe remote_verified=false bedeutet, dass noch kein echter Kassenabruf stattgefunden hat.

Beide Dienste mit den aktualisierten Betreiberdateien neu starten. Anschließend im Steuerbereich einen begrenzten Zeitraum synchronisieren, den zurückgegebenen Mandanten und Originalbelege prüfen und bis next_cursor=null weiterblättern. Der erste erfolgreiche Import bindet die Kassenmandantenkennung dauerhaft an den SIHub-Mandanten. Bank-, Zahlungs-, Ausgaben-, Anlagen- und Abschlussdaten ergänzen, soweit sie nicht im Export enthalten sind; der Abruf bestätigt keine Vollständigkeit.

Erklärungen freigeben und übermitteln

E1/K1 stehen für das veröffentlichte Jahreserklärungsschema 2025 bereit, U30/ZM für die unterstützten Zeiträume 2025/2026. Unter FinanzOnline-Dateien sind Originalquellen, Prüfumfang und nicht lokal durchführbare Behördenprüfungen beschrieben. Für E1/K1 2026 ist ein neues veröffentlichtes und geprüftes BMF-Schema erforderlich.

Bericht und Formular abstimmen, Vorschläge ausdrücklich übernehmen, fehlende Angaben ergänzen und alle einschlägigen Fachbereiche bestätigen. Nach lokaler Validierung speichert Owner/Admin die Fachentscheidung. Nur ein freigegebener, unveränderter und weiterhin gültiger Snapshot liefert einen aktuellen XML-Export. Die Kanzlei übermittelt die Datei selbst und prüft das amtliche Ergebnisprotokoll. Der Archivdownload enthält exakt die ursprünglich freigegebene Datei auch dann, wenn spätere Datenänderungen ihren aktuellen Export sperren.