# CTC/Clearance und Portale in der EU: belastbare Integrationen bauen

In Clearance‑ oder portalgetriebenen Systemen kann die Plattform‑Antwort (angenommen/abgelehnt, IDs, Zeitstempel) Teil des rechtlich relevanten Nachweises sein. Das verändert Speicherung, Retries und Support‑Prozesse.

## Was „Clearance“ / CTC bedeutet (ohne Buzzwords)

In Clearance‑Modellen wird eine Rechnung an eine Plattform gesendet, die eine Bestätigung zurückgibt (oft mit Plattform‑ID). Die Zustellung an den Käufer kann von dieser Bestätigung abhängen.

Dadurch entsteht ein zusätzlicher Lebenszyklus: Entwurf → eingereicht → akzeptiert/abgelehnt → zugestellt/archiviert.

## Engineering‑Folgen: Speicherung, Retries, Idempotenz

Behandeln Sie die Plattform als Zustandsmaschine. Speichern Sie: das exakte gesendete XML, Submission‑IDs, Bestätigungen, Zeitstempel und ggf. von der Plattform zurückgegebene „akzeptierte“ Versionen.

Idempotenz ist entscheidend. Ein Retry darf keine doppelten Rechnungen erzeugen.

## Praxis-Checkliste: Engineering‑Folgen: Speicherung, Retries, Idempotenz

- Stabile Invoice‑Keys für Deduplizierung nutzen
- Jede Response‑Payload persistieren
- Status für Nutzer sichtbar machen (eingereicht/akzeptiert/abgelehnt)

## Support‑Playbook: was Sie schnell beantworten müssen

Wenn eine Rechnung im Clearance‑Modell scheitert, brauchen Nutzer klare Antworten: Was ist fehlgeschlagen (Daten vs Zustellung), was ist zu korrigieren, und kann man sicher erneut senden?

Bauen Sie „Support‑Artefakte“ ins Produkt: downloadbares XML, Validator‑Logs und Plattform‑Bestätigungs‑IDs.

## Verwandte Ressourcen

- [KOSIT‑Validator‑Fehler (Lösungen)](/resources/kosit-validator-errors)
- [EU‑E‑Rechnung Überblick](/resources/eu/eu-e-invoicing-2026)
- [Länder‑Guide Italien (SdI)](/resources/countries/it)
- [Länder‑Guide Polen (KSeF)](/resources/countries/pl)