Österreichische Steuer-Standardbots für Kanzleien

SIHub bietet zwei Standardbots im Bot-Shop: Österreich · E/A Steuerassistenz (tax-at-ea) und Österreich · Bilanz Steuerassistenz (tax-at-balance). Ein bestätigter Kauf erstellt den passenden Agentenentwurf und österreichisches Steuerwissen im Arbeitsbereich der Kanzlei. Die Vorlage startet im deterministischen Testmodus; für Modellantworten muss die Kanzlei einen eingerichteten Anbieter im Agenten wählen und den bestehenden Livebetrieb freigeben. Die Kanzlei prüft die Ergebnisse und übernimmt die Einreichung beim Finanzamt. SIHub übermittelt keine Steuererklärung und stellt keinen FinanzOnline-Zugang her.

Der Steuerbereich verwaltet Mandanten, Kassenverbindungen, Datenimporte, Berichtsentwürfe, amtliche Formularbäume und dokumentierte Prüfentscheidungen. Ein Mandant gehört genau zu einem Arbeitsbereich. Berichte, Belege und Gesprächsbindungen werden zusätzlich nach Mandant getrennt. Der Wechsel eines Agenten auf einen anderen Mandanten verlangt ein neues Gespräch. Öffentliche Widgets und Telefonchats sind für diese Standardbots gesperrt.

Einrichtung

1. Im Shop die gewünschte Vorlage erwerben; der Betreiber konfiguriert dafür SIHUB_STRIPE_PRICE_BOT_TAX_AT_EA bzw. SIHUB_STRIPE_PRICE_BOT_TAX_AT_BALANCE und die bestehende Stripe-Anbindung.
2. Im Steuerbereich einen Mandanten anlegen. Gewinnermittlung, Umsatzsteuer-Ist/Soll, Meldeperiode, Rechtsform, eigene UID und Steuerjahr sind mandantenbezogen. Die Zulässigkeit der Gewinnermittlungsart und der Meldeperiode prüft die Kanzlei.
3. Eine aktive, ausdrücklich lesende GET-Action für den MeineKasse-Export anlegen. Die vorhandene HTTPS-Hostfreigabe und Secret-Bindung müssen beim Betreiber eingerichtet sein. Im Steuerbereich die Action und die Kassen-Mandantenkennung verbinden.
4. Für einen Zeitraum synchronisieren und Folgeseiten bis zum Ende abrufen. Alternativ normalisierte JSON-Datensätze importieren. Zahlungs-, Ausgaben-, Anlagen- und Kontendaten müssen aus geeigneten Quellen hinzukommen, soweit die Kasse sie nicht enthält.
5. Unterlagen abstimmen und die Vollständigkeit je Datenart und Zeitraum im Portal bestätigen. Jeder Import neuer oder geänderter Daten hebt diese Bestätigung wieder auf. API-Schlüssel dürfen keine Vollständigkeit bestätigen und keine menschliche Prüfentscheidung treffen.
6. Bericht erstellen, offene Sachverhalte klären, erforderliche Korrekturen importieren und einen neuen Bericht erstellen. Owner/Admin dokumentieren die Prüfung. JSON-Exporte enthalten Bericht, Prüfstatus, Datenfingerprint, Prüfernotiz und Regelversion.
7. Im Bereich „Erklärungen“ E1, K1, U30 oder ZM und das verfügbare Jahr wählen. Formularvorschläge aus einem passenden Bericht ausdrücklich übernehmen, weitere Einkünfte/Beilagen ergänzen, Kopf- und Pflichtigen-Steuernummer erfassen und alle einschlägigen Sachverhalte prüfen. Die amtlichen XML-Felder bleiben einzeln bearbeitbar; Vorschläge werden nicht automatisch gebucht.
8. Einen Erklärungssnapshot speichern, lokal validieren und als Owner/Admin fachlich freigeben. Erst danach lässt sich eine aktuelle amtliche XML-Datei herunterladen. Die Kanzlei übermittelt sie selbst über FinanzOnline und kontrolliert das Ergebnisprotokoll. Einrichtung: Kasse und Stripe; Formate und Prüfumfang: FinanzOnline-Dateien.

Was die beiden Bots vorbereiten

Der E/A-Bot wertet nachgewiesene Zahlungen nach der Nettomethode aus, berücksichtigt Teilzahlungen und vermeidet die doppelte Berücksichtigung bereits abgezogener Rechnungsrabatte. Einfache lineare AfA wird separat vorbereitet. Nicht bezahlte Rechnungen werden nicht einfach als zugeflossene Einnahmen behandelt.

Der Bilanz-Bot erstellt aus freigegebenen Journalbuchungen und Eröffnungsbeständen eine Kontenauswertung mit Bilanz- und GuV-Summen. Soll und Haben müssen ausgeglichen sein. Bestände, Bewertung, Rückstellungen, Abgrenzungen, außerbilanzielle Korrekturen und Abschlussbuchungen müssen in den Daten enthalten und fachlich geprüft sein. Kassenrechnungen werden nicht automatisch in eine vollständige Bilanz umgedeutet.

UVA wird für unterstützte österreichische Inlandssätze mit Vorsteuerprüfung als Entwurf berechnet. Belege brauchen einen ausdrücklich bestätigten Umsatzsteuerzeitpunkt (vat_date). Auslandsbezüge, Befreiungen und sonstige Sonderfälle mit ungeklärter Behandlung führen zu Prüfhinweisen oder Blockern. ZM erfasst belegte EU-B2B-Dienstleistungen nach Leistungszeitraum und Kunden-UID. Diese Dienstleistungen gehören nicht in die Kennzahl für innergemeinschaftliche Warenlieferungen.

Eine Einkommensteuer-Tarifrechnung für 2025 und 2026 erfolgt nur für ausdrücklich von der Kanzlei eingegebenes jährliches steuerpflichtiges Einkommen eines passenden Mandanten. Der Gewinn der E/A wird nicht ungeprüft als steuerpflichtiges Einkommen eingesetzt. Ohne diese eigene Eingabe betrifft die jährliche Berichtsfreigabe die Gewinnermittlung; die fehlende persönliche Steuerbasis bleibt sichtbar. E1 erfasst weitere Einkünfte, Abzüge, Freibeträge, Absetzbeträge und Steueranrechnungen gesondert. Einkommensteuer-Vorauszahlungen beruhen auf dem Bescheid nach § 45 EStG; es gibt keine österreichische „Einkommensteuervoranmeldung“.

E1 und K1 für 2025 enthalten den vollständigen Formularbaum des veröffentlichten BMF-Schemas mit seinen Beilagen. E/A-Positionen und Konten können anhand bestätigter Kennzahlzuordnungen zur Vorbelegung verwendet werden; ungeklärte Zuordnungen bleiben offen. Die Vorbereitung berücksichtigt die amtlichen E1a/E11- und K1-Summenformeln, dokumentierte steuerliche Korrekturen, bestätigte Gewinnfreibeträge sowie eine Körperschaftsteuerrechnung mit Rechtsform-/Quartalsangaben. U30 und ZM für 2025/2026 haben eigene amtliche Strukturen und Periodenprüfung. ZM-Beträge werden erst nach Aggregation ohne Centbetrag vorbereitet. Die Anwendungen führen keine amtliche UID-Abfrage aus.

Für E1/K1 2026 fehlt derzeit das veröffentlichte BMF-Jahresschema; diese Formulare sind deshalb nicht freigeschaltet. Der Fachstand und die konkreten Paragraphen stehen in Österreichische Steuerrechtsgrundlagen. Der Prüfstand ist 10. Oktober 2026. Die Quellen werden nicht automatisch aktualisiert. Sonderfälle wie EU-Warenlieferungen, OSS, Fremdwährungen, Kleinunternehmeroption, Erwerbsteuer, bezogene Reverse-Charge-Leistungen und Lohnverrechnung verlangen weitere fachliche Angaben. Ein vollständiger Formularbaum ersetzt weder fehlende Unterlagen noch die steuerliche Beurteilung dieser Sachverhalte.

API-Actions

Die Standardbots verwenden vorhandene SIHub-Authentifizierung: Arbeitsbereich-Bearer-Schlüssel mit read/write bzw. angemeldete Sitzung mit CSRF-Schutz. Der bestehende Textchat ruft externe Tools nicht automatisch auf. Kassen-Actions werden im Steuerbereich ausdrücklich synchronisiert. Der authentifizierte Steuerchat erhält serverseitige Jahressummen ausschließlich für den zugeordneten Mandanten; fehlende Daten oder Prüfblocker bleiben sichtbar.

Action	Methode und Pfad	Zweck
taxAtState	GET /api/tax-at/state	Mandanten und vorhandene Prüfberichte
taxAtCreateClient	POST /api/tax-at/clients	Mandant anlegen
taxAtUpdateClient	PATCH /api/tax-at/clients/{identifier}	Profil und Vollständigkeit
taxAtImport	POST /api/tax-at/clients/{identifier}/import	Normalisierte Datensätze versioniert übernehmen
taxAtRecords	GET /api/tax-at/clients/{identifier}/records	Aktuelle Datensätze, 500 je Seite
taxAtSync	POST /api/tax-at/clients/{identifier}/sync	Eine MeineKasse-Exportseite lesen
taxAtReport	POST /api/tax-at/clients/{identifier}/reports	Berichtssnapshot erzeugen
taxAtReadReport	GET /api/tax-at/reports/{identifier}	Entwurf und Prüfstand lesen
taxAtReview	POST /api/tax-at/reports/{identifier}/review	Menschliche Prüfung durch Owner/Admin
taxAtExport	GET /api/tax-at/reports/{identifier}/export	JSON-Arbeitsunterlage herunterladen
taxAtAssignClient	POST /api/tax-at/agents/{identifier}/client	Mandant dem passenden Standardbot zuordnen
taxAtFilingCatalog	GET /api/tax-at/filing/catalog	Amtliche Felder, Beilagen, Jahre und Fachbestätigungen
taxAtPrepareDeclaration	POST /api/tax-at/clients/{identifier}/declarations/prepare	Vorschläge mit Herkunft aus einem Bericht
taxAtFilingPreview	POST /api/tax-at/filing/validate	Ungespeicherte Formularwerte und XML-Vorschau prüfen
taxAtDeclarations / taxAtSaveDeclaration	GET / POST /api/tax-at/clients/{identifier}/declarations	Unveränderliche Erklärungssnapshots
taxAtReadDeclaration	GET /api/tax-at/declarations/{identifier}	Werte, Prüfungen und Datenstand lesen
taxAtValidateDeclaration	POST /api/tax-at/declarations/{identifier}/validate	Aktuelle lokale Prüfung
taxAtReviewDeclaration	POST /api/tax-at/declarations/{identifier}/review	Fachliche Freigabe oder Ablehnung durch Owner/Admin
taxAtExportFinanzOnlineXml	GET /api/tax-at/declarations/{identifier}/export.xml	Aktuelle freigegebene amtliche XML-Datei
taxAtArchiveFinanzOnlineXml	GET /api/tax-at/declarations/{identifier}/archive.xml	Original einer früheren Freigabe, Owner/Admin
taxAtSetupStatus / taxAtSetupCheck	GET /api/tax-at/setup/status / POST /api/tax-at/setup/check	Lokaler Stand und lesende Stripe-Preisprüfung

Fachbestätigungen und Freigaben benötigen eine angemeldete Sitzung; API-Schlüssel dürfen diese nicht ersetzen. Änderungen an Belegen, Profil, Schema oder relevanten Regeln sperren den aktuellen Export eines früheren Snapshots. Das Archiv bleibt als gekennzeichnete Originaldatei mit dem ursprünglichen Hash verfügbar. Ein verknüpfter Jahresbericht muss dasselbe vollständige Jahr betreffen; K1-Abschluss-/Liquidationsdaten und U30/ZM-Meldeperioden müssen genau zum Quellbericht passen. Abweichende Geschäftsjahre oder Liquidationszeiträume benötigen eigene manuelle Abschlussunterlagen. Für die Freigabe muss auch der verknüpfte Quellbericht geprüft sein. Eine Erklärung für ein anderes Jahr als das aktuelle Mandantenprofil ist manuell möglich und verlangt eine gesonderte Abdeckung dieses Jahres.

Das vollständige Schema liefert OpenAPI. Berichtzeiträume verwenden start und end als YYYY-MM-DD innerhalb eines Kalenderjahrs. Quellenidentitäten werden intern getrennt; Querverweise eines Imports beziehen sich auf dieselbe Quelle.

MeineKasse-Exportvertrag

Die GET-Action erhält tenant_id, start, end und optional cursor. Eine Antwort verwendet:

{
  "schema_version": 1,
  "tenant_id": "kassen-mandant-123",
  "records": [],
  "next_cursor": null
}

Jede Seite enthält höchstens 500 Datensätze; next_cursor ist nur bei weiteren Seiten gesetzt. Ein abweichendes Mandantenkennzeichen wird abgelehnt. Echte Betreiberzugänge bleiben in serverseitigen Secrets. Ein erfolgreicher Abruf bestätigt keine steuerliche Vollständigkeit.

Ein Import lautet {"source":"MeineKasse","records":[...]}. Jeder Datensatz braucht type, id und eine ganzzahlige revision ab 1. Gleiche Revisionen sind idempotent. Inhaltlich geänderte Datensätze benötigen eine höhere Revision. Vorherige Revisionen und Prüfentscheidungen bleiben gespeichert. Originaldatensätze mit Positionen und Quellnachweisen werden zusätzlich zum Berechnungsmodell aufbewahrt. Nach dem ersten erfolgreichen API-Import ist die Kassenmandantenkennung fest zugeordnet; für einen anderen Kassenmandanten ist ein neuer SIHub-Mandant erforderlich.

Typ	Wesentliche Felder
customer	name, country, business, uid, uid_validated, uid_checked_at
invoice / expense	number, date, service_date, vat_date, kind, currency, net, vat, gross, vat_rate, tax_treatment; optional customer_id, discount, reverse_charge_note, original_id
payment	document_id, document_type, date, amount, direction, refund
asset	name, cost, in_service_date, useful_life_years
journal	date, opening, entries mit account, label, category, debit, credit

Beträge sind EUR-Dezimalstrings mit höchstens zwei Nachkommastellen. net, vat und gross enthalten bereits alle Rechnungsrabatte; discount ist Zusatzinformation. Eine gemischte Steuersatzrechnung benötigt eine fachlich abgestimmte Aufteilung statt eines geratenen Mischsatzes. tax_treatment ist domestic, eu_b2b_service, eu_goods, exempt oder review; unsupported oder ungeklärte Fälle werden nicht als steuerlich fertig ausgegeben.

Gutschriften verwenden positive Beträge und kind:"credit_note" mit original_id. Zahlungen verwenden den tatsächlichen Geldfluss: normale Einnahme in, normale Ausgabe out, Erstattung dazu umgekehrt mit refund:true. Negative Zahlungen werden nicht zusätzlich mit einem zweiten Vorzeichen verrechnet. Preisänderung und ursprünglicher Rechnungsfehler sind steuerlich verschiedene Korrekturen und benötigen eindeutige Angaben.

Ausgaben brauchen die betriebliche Kategorie, Abzugsfähigkeit (deductibility_percent) und eine ausdrückliche Vorsteuerfreigabe (input_vat_deductible). Anlagenkäufe müssen über asset_id bzw. capital_asset markiert sein, damit Anschaffung und AfA nicht doppelt als Aufwand gezählt werden. uid_validated ist ein übernommener Prüfnachweis; SIHub führt derzeit keine eigene VIES-/FinanzOnline-UID-Abfrage durch.

Datenhaltung

MariaDB speichert Mandanten, Belegrevisionen, Berichtssnapshots und Mandantengesprächsbindungen. Die automatische Schemaaktualisierung ergänzt die Tabellen beim Start. Die normale Gesprächslöschung entfernt keine Buchhaltungsbelege oder Berichte. Backups müssen diese Tabellen einschließen. Der Betreiber muss die gesetzliche Belegaufbewahrung einschließlich längerer Sonderfristen, Unveränderbarkeit, Zugriffsrechte und Sicherungen organisatorisch und technisch umsetzen; die Versionierung allein ist keine vollständige BAO-Archivierung.