Skip to main content

Guide

Markdown export

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.