CDS to EMCS: How Customs Import Data Can Flow Into Excise Movements
- John Hall
- Customs Specialist at iCustoms.ai
A CDS import declaration and an EMCS e-AD describe the same shipment from two different regulatory angles. One asks whether the goods can legally enter the country and what they are worth. The other asks how they are going to move once duty is suspended. Because they describe the same goods, most of what the second form asks for is already sitting in the first one, typed in once and then typed in again.
This guide looks specifically at that first handoff: what data a CDS import declaration and an EMCS e-AD actually share, what EMCS asks for that customs never did, and where iEMCS closes the gap between them. For the fuller import journey from declaration to warehouse stock, see our guide to the EMCS import process.
Two Declarations, One Shipment, Different Questions
CDS exists to answer a customs question: is this consignment allowed in, what is it worth, and what duty or tariff applies. EMCS exists to answer an excise question: now that duty has been suspended rather than paid, who is responsible for these goods while they move, and can HMRC track them until they reach an approved destination. Same container, same commodity, two different regulators asking two different things, which is exactly why the data overlaps without either system ever being designed around the other.
What Actually Carries Across
A CDS import declaration under Procedure 07 already names the excise warehouse (Data Element 2/7), the warehouse’s C676 authorisation (Data Element 2/3) and the registered consignor moving the goods on (Data Element 2/2, code ECONR). Everything built on top of that identity data, the commodity description and CN code, the quantity and gross and net mass, the invoice reference and the packaging detail, describes the same physical shipment the e-AD is about to describe again.
This is the overlap iEMCS is built to close. It auto-populates up to 80 percent of the e-AD directly from the CDS import declaration once registered consignor status is confirmed, carrying the commodity, quantity and party detail straight across rather than asking someone to retype it from the same commercial invoice a second time.
What EMCS Still Needs That CDS Never Asked For
The remaining fields exist only because EMCS is solving a different problem. An excise product code, a separate classification from the CN code, tells HMRC what duty regime applies while the goods are suspended, and a CDS declaration has no reason to carry it. Alcohol strength matters to excise duty calculation in a way it does not to customs valuation. The movement guarantee reference is registered with HMRC separately from the import itself, because it covers the duty exposure while the goods are in transit, not the import transaction. And the transport detail, the mode of transport and the means of transport’s identity, is frequently not finalised until after the CDS declaration has already been filed, because the haulier is booked once the goods have cleared, not before.
iEMCS validates the completed e-AD against both the CDS declaration and the receiving warehouse’s own records before it is submitted, which is what catches a mismatch before HMRC does rather than after a rejection.
The Message Trail Behind a Single Movement
An e-AD is not a single form and done. HMRC’s EMCS message set carries the movement through its full lifecycle. IE815 opens it, submitting the draft e-AD that becomes valid once HMRC accepts it and issues the ARC. IE813 handles a change of destination if the consignee or the route changes mid-journey. IE810 lets the consignor cancel the movement, but only before the goods have actually been dispatched. IE818, the report of receipt, closes the movement out once the consignee confirms what arrived, within the five business day window HMRC expects.
iEMCS tracks that whole sequence in real time, the ARC, the journey status and the report of receipt, rather than leaving a business to check a government portal to find out where a movement stands. That is also what makes the process paperless in practice: nobody is printing a fallback document unless EMCS itself is unavailable.
How the Data Actually Reaches EMCS
iEMCS connects through an API-first architecture, which is how it links into ERP, TMS or WMS systems that already hold the shipment data, and it also supports bulk Excel upload for businesses that would rather work from a spreadsheet than build an integration. Both routes are covered in more depth in our guides to EMCS API integration and EMCS Excel upload; this article only needed to show that the auto-population described above works whichever route the data arrives through.
A Short Worked Example
A cider producer imports concentrate from outside the UK into a bonded warehouse in Kent. The CDS import declaration under Procedure 07 already carries the CN code for the concentrate, its net mass, the Kent warehouse’s C676 authorisation and the registered consignor’s ECONR ID. When the broker opens the e-AD in iEMCS, the commodity, quantity and party details populate automatically from that declaration. The fields left to add are the excise product code for the concentrate, the movement guarantee reference, and the haulier’s vehicle details once transport is booked. iEMCS checks the completed e-AD against the CDS record and the warehouse’s own data before submitting IE815, then tracks the ARC through to the report of receipt when the load arrives in Kent.
Common Misconceptions
A CDS declaration and an e-AD are unrelated forms. They are not. Most of the e-AD’s identity and commodity data already exists on the CDS declaration, which is why so much of it can carry across automatically.
Auto-population means nothing needs checking. It does not. The fields EMCS asks for that CDS never collected, the excise product code, the guarantee reference, the transport detail, still have to be added and validated before submission.
The e-AD is one submission and it’s done. It is not. IE815 opens the movement, but IE810, IE813 and IE818 can all follow depending on what happens before the goods are received.
Five Things to Take Away
- CDS and EMCS describe the same shipment from different regulatory angles, which is why so much of the data overlaps.
- iEMCS auto-populates up to 80% of the e-AD directly from the CDS import declaration once registered consignor status is confirmed.
- The remaining fields, excise product code, alcohol strength, movement guarantee, transport detail, exist only because EMCS is solving a different problem than CDS.
- An e-AD is a sequence of messages (IE815, IE810, IE813, IE818), not a single form, and iEMCS tracks the whole sequence.
- Whether the data arrives by API or bulk Excel upload, the same auto-population and validation applies before submission.
Frequently Asked Questions
You may also like:
Still Typing the Same Shipment Data Twice?
iEMCS auto-populates up to 80% of your e-AD directly from your CDS import declaration.
Subscribe to our Newsletter
About iCustoms
iCustoms is an all-in-one solution helping businesses automate customs processes more efficiently. With AI-powered and machine-learning capabilities, iCustoms is designed to streamline your all customs procedures in a few minutes, cut additional costs and save time.
Worried About the Fields CDS Never Asked For?
iEMCS validates your e-AD against your CDS declaration and warehouse records before HMRC ever sees a mismatch.