On this page
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 crucial. A retry should not create duplicate invoices on the platform.
- 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.