EMCS Data Mirroring: How to Reduce Duplicate Entry Across CDS and Warehouse Systems
- John Hall
- Customs Specialist at iCustoms.ai
A single duty-suspended shipment usually exists in at least three places: a CDS import declaration, an EMCS movement, and a warehouse’s own stock record. Each of those three is accurate on its own terms. The problem is that, without something connecting them, each one is also typed separately, by whoever happens to be filling in that particular screen, from whatever detail they have in front of them at the time.
That is the actual cost of running three unconnected systems: not that any one of them is wrong, but that the same commodity code, quantity and party detail gets keyed in three times, and three separate entries are three separate chances for one of them to drift from the other two. This guide covers that problem directly, rather than any single handoff. The mechanics of each individual connection, CDS into EMCS, EMCS into the warehouse, and the warehouse back out into EMCS, are covered in full in their own guides; this one is about what happens when those three points share data instead of each holding its own copy.
Where the Same Shipment Gets Typed Three Times
The pattern repeats at every stage of a movement. On import, a CDS declaration already carries the commodity, quantity and party detail; without a connection to EMCS, that same detail is typed again to open the eAD, covered in our guide to CDS to EMCS. On arrival, the eAD’s report of receipt confirms what came in; without a connection to the warehouse’s own stock system, that confirmation gets typed a third time to create the stock record, covered in our guide to EMCS to iWarehouse. On removal, the warehouse’s own record of what is being taken out and why has to become a fourth entry, an outbound eAD, covered in our guide to iWarehouse to EMCS. Three systems, four re-entry points, one shipment.
Why Three Separate Entries Also Means Three Places to Get It Wrong
Every one of those re-entry points is a place where the second copy can stop matching the first. A commodity code transposed on the way into the eAD does not announce itself; it sits quietly until someone cross-checks the CDS declaration against the movement and finds the two disagree. A warehouse stock record built from a rough note of what arrived, rather than the eAD’s own report of receipt, can drift from the actual duty-suspended quantity over weeks of ordinary handling. None of this shows up as a single dramatic failure. It shows up as a W1 return that takes longer to prepare than it should, because someone has to reconcile three records that were never the same record to begin with, or as an audit query that starts with “why doesn’t this match” rather than a straightforward answer.
What "Mirrors Both Ways" Actually Means
iEMCS’s own product page describes this directly: it “mirrors data both ways: CDS to EMCS, EMCS to warehouse, and warehouse to EMCS,” summarised on the same page as “enter once, mirror everywhere.” In practice, that means the commodity, quantity and party detail entered once, at whichever of the three points it first exists, whether that is a CDS declaration, an eAD, or a warehouse stock record, propagates to the other two rather than being independently retyped at each one. The three systems are not being asked to talk to each other as a custom integration project; the mirroring is a feature of routing all three through one connected platform in the first place.
This is a different claim from simply making data entry faster, and it is worth being precise about the difference. A faster form still produces three separate, independently typed records that happen to have been filled in quickly. Mirrored data produces one shared thread of the same underlying detail, referenced by the CDS declaration, the eAD and the warehouse record rather than duplicated across them.
Validation Is Part of the Mirroring, Not Separate From It
Mirroring on its own would still leave a gap if nothing checked the data along the way. iEMCS’s validation step, checking declaration data against CDS and warehouse records and flagging mismatches before submission rather than after, is what actually catches the case where something has genuinely changed, a quantity correction, a different consignee, and confirms the change is intentional rather than a typo working its way silently through three records. Mirroring keeps the three systems in sync; validation is what confirms that what they are in sync about is actually correct.
What This Looks Like Across a Full Movement
Put together, the mirroring runs the length of a single movement rather than sitting at one point in it. At import, CDS declaration data flows into the eAD. At receipt, the eAD’s report of receipt flows into the warehouse’s stock record. At removal, that same stock record’s existing detail flows back out into a fresh outbound eAD. iEMCS also keeps a six-year audit trail on every movement, so that shared thread of data remains traceable back through each of those points rather than only existing as three snapshots that were true at the moment each was taken.
A Brief Example
A spirits importer runs CDS declarations through one team, EMCS movements through another, and warehouse stock through a system neither team has direct access to. At their last excise audit, the auditor flagged a discrepancy between the quantity recorded on an eAD and the quantity the warehouse’s own system showed as received, three units apart on a shipment of several hundred. Nobody had made an obvious error; the eAD had simply been typed from the delivery note, and the warehouse record had been typed separately from what was physically counted onto the shelf, and the two had never been checked against each other until the audit did it for them. With CDS, EMCS and the warehouse mirroring the same data instead of each holding its own copy, that quantity exists once and is referenced three times, so a discrepancy would have to be flagged by validation before submission rather than discovered months later by an auditor.
What People Often Get Wrong
Data mirroring means integrating three separate pieces of software to talk to each other. Not in this case. Mirroring here is a feature of routing CDS, EMCS and warehouse data through one connected platform, not a custom integration project between three unrelated systems.
Mirroring only matters at high volumes. Reconciliation risk is not a volume problem. A single shipment typed into three systems separately can drift just as easily as a thousand can; it is simply less likely to be noticed quickly at low volume, not less likely to happen.
If every entry is typed correctly, mirroring doesn’t matter. Correct entries can still drift apart over time, particularly if one record is later corrected and the other two are not updated to match. Mirroring keeps the three as one shared thread rather than three copies that can independently go out of date.
Frequently Asked Questions
You may also like:
Typing the Same Shipment Into Three Different Systems?
See how CDS, EMCS and warehouse data can mirror both ways instead of being entered three separate times.
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.
Every Retyped Field Is Another Place to Get It Wrong
iEMCS validates against CDS and warehouse records and flags mismatches before you submit, not after.