# CTC/clearance and portals in the EU: how to build reliable integrations

In clearance or portal-driven systems, the platform response (accepted/rejected, IDs, timestamps) can be part of the legally relevant record. That changes what you store, how you retry, and how you support customers.

## What “clearance” / CTC means (without the buzzwords)

In clearance-style models, an invoice is sent to a platform that returns an acknowledgement (often with a platform ID). Delivery to the buyer may depend on that acknowledgement.

This creates an extra lifecycle: draft → submitted → accepted/rejected → delivered/archived.

## Engineering implications: storage, retries, idempotency

Treat the platform as a state machine. You must store: the exact XML sent, submission IDs, acknowledgements, timestamps, and any transformed “accepted” version returned by the platform.

Idempotency is important. A retry should not create duplicate invoices on the platform.

## Checklist: Engineering implications: storage, retries, idempotency

- Use stable invoice keys for deduplication
- Persist every response payload
- Expose status to users (submitted/accepted/rejected)

## Support playbook: what you need to answer quickly

When an invoice fails in a clearance model, users need a clear explanation: what failed (data vs delivery), what to fix, and whether they can resend safely.

Build “support artifacts” into the product: downloadable XML, validator logs, and platform acknowledgement IDs.

## Related resources

- [KOSIT validator errors (how to fix)](/resources/kosit-validator-errors)
- [EU e-invoicing overview](/resources/eu/eu-e-invoicing-2026)
- [Italy country guide (SdI)](/resources/countries/it)
- [Poland country guide (KSeF)](/resources/countries/pl)