> For the complete documentation index, see [llms.txt](https://one-loop.gitbook.io/help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://one-loop.gitbook.io/help/marketplace-apps/lexware-office/steuern-und-grenzuberschreitende-falle.md).

# Steuern und grenzüberschreitende Fälle

Steuern sind kein Feld, das sich mit einer Zahl allein korrekt beschreiben lässt. Die Lexware-Office-App unterscheidet deshalb klar zwischen bereits vorhandenen Zahlungsdaten und bewusst konfigurierten Dokumentdaten.

Diese Seite erklärt den technischen Aufbau. Sie ersetzt keine Steuerberatung; bei besonderen Fällen solltest du die fachliche Einordnung vor der Automatisierung klären.

## Zwei Betriebsarten

### Zahlung oder Bestellung als Quelle

Wenn eine Rechnung aus einer bezahlten Transaktion entsteht, sind die tatsächlich gebuchten Werte maßgeblich. Die App übernimmt Beträge und die vorhandene Steuerinformation. Sie ersetzt fehlende oder widersprüchliche Angaben nicht durch einen pauschalen Steuersatz.

Das ist wichtig, weil eine Zahlung nicht automatisch alle Angaben enthält, die für einen komplexen rechtlichen Fall erforderlich sind. In so einer Situation führt die App zu einem kontrollierten Fehler statt zu einem Beleg, der nur scheinbar korrekt ist.

### Eigene Felder als Quelle

Bei manuell aufgebauten Angeboten und Rechnungen legst du Positionen und Steuerdarstellung im Workflow bewusst fest. Dafür kannst du getrennte Workflow-Zweige verwenden, zum Beispiel nach Land, Kundentyp oder einer vorherigen Prüfung.

Du bestimmst dabei je nach verfügbarer Action:

* Steuerart
* Steuerunterart
* Steuersatz
* erforderlichen Hinweis
* passende Positionen und Beträge

## Warum ein Steuersatz allein nicht reicht

Ein Wert von 0 % kann sehr unterschiedliche Gründe haben. Ob ein Fall korrekt abgebildet ist, hängt unter anderem von Kundentyp, Leistungsort, Steuerart und erforderlichem Hinweis ab.

{% hint style="danger" %}
Ein Steuersatz von 0 % allein beschreibt keinen rechtlichen Steuerfall. Steuerart, Kundentyp, Leistungsort und Hinweis müssen zusammenpassen.
{% endhint %}

## Typische Workflow-Struktur

Baue nicht einen einzigen Dokumentschritt für alle Fälle. Lege vorher eine Bedingung an und führe jeden klar abgegrenzten Fall in einem eigenen Zweig:

```
Kontakt- und Auftragsdaten prüfen
        ↓
Land und Kundentyp bewerten
        ↓
Passenden Steuerzweig wählen
        ↓
Dokument-Action mit der dafür vorgesehenen Steuerlogik ausführen
        ↓
Ergebnis und PDF prüfen
```

| Szenario                          | Empfohlener Aufbau                                                          |
| --------------------------------- | --------------------------------------------------------------------------- |
| Inland, normal steuerpflichtig    | Standardsatz und passende Positionen im dafür vorgesehenen Zweig            |
| Verkauf in der Schweiz            | eigener Zweig mit der zu deinem Fachkonzept passenden Schweizer Steuerlogik |
| EU-Unternehmen mit Reverse Charge | eigener B2B-Auslandszweig mit passender Steuerart und Hinweis               |
| Innergemeinschaftliche Lieferung  | eigener Zweig mit rechtlicher Klassifikation und vollständigen Kundendaten  |
| Steuerfreier Sonderfall           | 0 % nur zusammen mit der passenden Steuerart und Begründung                 |

## Reverse Charge

Reverse Charge kann bei manuell aufgebauten Angeboten und Rechnungen über einen eigenen Workflow-Zweig umgesetzt werden. Prüfe vor dem Start den Unternehmensstatus, das Land und die erforderliche Steueridentifikation.

Bei Dokumenten, die direkt aus dem Zahlungssystem erzeugt werden, ist Reverse Charge nicht zuverlässig abbildbar, wenn die Zahlung selbst diese rechtliche Klassifikation nicht enthält. Nutze für diesen Fall einen manuellen Dokumentzweig mit bewusst zugeordneten Daten.

## So prüfst du einen Steuerfall

1. Starte mit einem klar abgegrenzten Testkontakt und einer Testposition.
2. Prüfe vor dem Workflow Land, Kundentyp und Steuerdaten.
3. Führe genau den vorgesehenen Workflow-Zweig aus.
4. Öffne den Beleg in Lexware Office und vergleiche Betrag, Steuerdarstellung und Hinweis.
5. Erst nach dieser Prüfung übernimmst du den Aufbau in den produktiven Prozess.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://one-loop.gitbook.io/help/marketplace-apps/lexware-office/steuern-und-grenzuberschreitende-falle.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.