AEO authorisation is granted once. AEO monitoring runs every day after that. An evidence register separates the two. That is exactly where a forwarder loses the status. Without noticing.
AEO, the Authorised Economic Operator status, is a customs status. It sits in Art. 38 of the Union Customs Code (UCC, Regulation (EU) No 952/2013). It comes in two forms. AEO-C for customs simplifications. AEO-S for security. Before granting it, customs reviews a self-assessment questionnaire. Plus expert reports. Plus a site visit. The basis is the appropriate security standards under Art. 28 of Implementing Regulation (EU) 2015/2447. Every forwarder with AEO status knows this part. Because it happened once.
The other part is Art. 23(2) UCC. The holder must inform customs of every event. Without delay. If it could affect the authorisation. That is an independent, unprompted duty. Nobody asks for it. It applies anyway. On top comes the practice of updating the questionnaire at least once a year. And rolling the changes into a monitoring report.
What happens next is predictable. The questionnaire gets filled in once. Filed. Marked done. The evidence behind it lives in spreadsheets and mail. Three points break every time.
First, carrier security declarations. An AEO holder must secure its trading partners. It informs them of their duties. It works toward contractual agreements. In practice: one signed security declaration per subcontractor. With a validity date. The declaration expires. Nobody puts that date in a calendar. The subcontractor keeps driving. Without a valid declaration.
Second, access logs. Who was at the gate, at which dock, in which vehicle, and when. AEO-S requires controlled access to premises and cargo. The record sits in a gatekeeper's notebook. Or it does not exist.
Third, matching the customs transaction to the shipment. Every customs declaration gets an MRN through ATLAS. An eighteen-character reference number. Assigned automatically the moment the declaration is accepted. The MRN is the only reliable foreign key. Between the customs transaction and the shipment. In practice it sits in a separate customs application. The shipment runs under a different number in the TMS. The two systems never talk.
All three points can run as a data record. Not as a stack of paper.
The evidence register carries three entries per subcontractor. The security declaration with its validity date. The training record for security-relevant duties. The insurance confirmation. Every entry carries an expiry date. Without a date, no entry counts as active.
Access logs come as a by-product. From telematics and gate systems already running. Not from new hardware. Our post on the TAPA incident log built from telematics events covers that in detail. Geofence, door and route events turn into a log there. For the AEO evidence, the same raw data answers a different question. Not "what happened". But "who had access, and when".
The customs match needs a join. Between the MRN and the shipment number. Held in exactly one place. Instead of two systems with two versions of the truth. Once that join exists, matching a customs declaration to a shipment takes seconds. Instead of a search across two filing systems.
Above all three sits the expiry alert. With a handling status. A security declaration expiring in fourteen days creates a case. Open. In clarification with the subcontractor. Resolved. No alert disappears because nobody acknowledged it. That separates an alert from an email sinking in an inbox. The same register logic already carries the supply chain evidence for CSRD and LkSG. There it serves the customer's questionnaire. Not customs.
A direct check of public.workflow_runs did not help here. That is the run-log database behind Exasync's automations. It holds no matching metric for this mechanism. No customer process yet counts expiry alerts for security declarations. Or an MRN-to-shipment match. So this post presents the mechanism. Not an invented number.
For the customs officer, the day of the annual self-assessment changes. Otherwise he would guess the questionnaire against a state from twelve months back. Now a list is ready. Which evidence expired. Which is in clarification. Which was added since the last review. The monitoring report becomes a query. Not a night shift.
For dispatch, little changes. That is the point. Checking a subcontractor's security declaration is not their job. It should not have to be. The register runs alongside dispatch. Nobody in trip planning answers a customs question before a vehicle leaves.
During an audit or a reassessment of the authorisation, the most changes. Gathering security declarations, access data and customs transactions used to take weeks. Now the data for the requested period is already there. That does not shorten the audit itself. It shortens the scramble before it. And that is exactly where the time pressure builds before every audit in practice.
An expiry alert shows a missing declaration. It does not say whether the subcontractor still meets the agreed security standards. That stays a question for a human. Not for the register. Likewise, no alert decides whether an event under Art. 23(2) UCC needs reporting. The system surfaces the change. The legal judgment stays with the customs officer. And the MRN match only works when both reference numbers exist as data. A declaration still filed by fax breaks that. So does an isolated customs system with no export option. There, the join stays manual work.
Many forwarders with AEO status have none of this built yet. Even so, the first move should not be new customs software. The first step is the evidence register with expiry dates. That is the simplest place where the most breaks unnoticed.
A question for readers holding an AEO authorisation. Where does your list of subcontractor security declarations live today? And who last checked whether one of them had expired?
