EMCS API Integration: How to Connect Excise Movements With Your ERP, TMS or WMS
- John Hall
- Customs Specialist at iCustoms.ai
If your business already runs an ERP, a warehouse management system or a transport management system, logging into a separate EMCS portal to key in movement data is the part of the process everyone eventually wants to remove. The question is not whether that connection is possible, HMRC publishes an EMCS API for exactly this, it is whether to build and maintain that connection yourselves or connect through a platform that already has.
This guide covers both. It sets out what HMRC’s own EMCS API actually gives you, what building against it directly involves day to day, and where a connected platform like iEMCS changes that equation for a business whose core job is not maintaining customs and excise integrations.
What HMRC's EMCS API Actually Gives You
HMRC’s EMCS API is a REST-based service, currently at version 1.0 and in beta, though HMRC states it is ready for production use. Requests and responses use XML payloads, with responses wrapped in JSON, and the service runs on separate sandbox and production base URLs so integrations can be tested before they touch a live movement. The endpoints cover the core of what a connected system needs from EMCS directly:
- Submitting a new draft excise movement
- Retrieving a list of excise movements, or a single movement
- Submitting a message against an existing movement
- Retrieving all messages, or a single message, for a movement
- Retrieving information about an excise trader
- Subscribing or unsubscribing an excise registration number to push or pull notifications
That last pair matters for anyone thinking about real-time status: notifications mean a connected system can be told when something changes on a movement, rather than having to poll EMCS repeatedly to find out.
What Building Against It Directly Involves
HMRC’s own onboarding path is a reasonable one, but it is a software project, not a settings change. It starts with registering for a developer account, reading the EMCS API service guide and the technical interface specification, and working through the testing guide using HMRC’s sandbox, which simulates the production environment with test users created through a separate test-user API. Only once that is working does a business apply for production credentials, which HMRC says can take up to ten working days to check and approve, and agree to the API’s terms of use before those credentials are issued.
None of that is a one-off cost, either. HMRC versions the API, and a backwards-incompatible change increases the version number, with a changelog published separately. A team that builds directly against the API is signing up to track that changelog for as long as the integration is in use, not just to get it live once.
Where iEMCS Fits: One Connection Instead of a Direct Build
iEMCS’s own product page is explicit that it is built API-first, describing itself as connecting to “your existing ERP (SAP, Oracle, or your own systems), WMS, or TMS.” A business does not have to choose between EMCS integration and keeping its current systems; the integration point is iEMCS, not HMRC’s raw endpoints, so there is one connection to build and maintain rather than an ongoing relationship with HMRC’s own developer hub, sandbox and versioning schedule.
iEMCS offers three ways in, and lets a business pick per workflow rather than committing to one for everything. “Send us your data via secure API and receive instant confirmations, status updates, and ARCs back in real time” covers the fully connected route. A bulk Excel upload lets a team submit multiple movements at once without any engineering work, with iEMCS validating, submitting and tracking each one. Direct entry through the iEMCS interface covers occasional users or single-movement workflows where building any integration at all would be overkill. As the product page puts it, “you choose the integration path, we handle the rest.”
That same connection also carries data the other way. iEMCS mirrors data bidirectionally, CDS to EMCS, EMCS to warehouse, and warehouse to EMCS, so an ERP or WMS that is already the source of truth for stock and customs data does not end up maintaining a second, separately typed copy of it inside EMCS.
What Real-Time Actually Means Here
Real-time is a specific claim worth being specific about. On the API path, iEMCS returns confirmations, status updates and ARCs back to the connected system as they happen, rather than requiring a separate login to check. Every ARC, journey time and report of receipt is also tracked centrally, so a status question, has this movement been received, is this ARC still open, can be answered from one dashboard instead of cross-referencing EMCS, the warehouse system and a spreadsheet.
The EMCS API Isn't the Same Everywhere
It is worth knowing, if your excise operations are not purely UK-based, that HMRC’s EMCS API is HMRC’s own implementation, not a shared EU standard. Finland’s tax administration, for example, publishes its own REST EMCS interfaces through the Vero API service, with a JSON message format, its own notification service and its own API key requirements. The endpoints and formats differ by tax authority even though the underlying EU excise movement rules are shared, which is one more reason a direct build against any one country’s EMCS API is a jurisdiction-specific project rather than a reusable one. This article, and iEMCS itself, is scoped to HMRC’s UK implementation.
A Short Worked Example
A mid-size drinks distributor runs SAP as its ERP and currently has someone export movement data to a spreadsheet, then re-key it into EMCS by hand each time stock moves. Building directly against HMRC’s EMCS API would mean registering a developer account, mapping SAP’s data into the XML payloads the API expects, testing in the sandbox, applying for production credentials, and then keeping that build current as HMRC versions the API going forward. Connecting SAP to iEMCS instead means one API integration, on iEMCS’s side, with iEMCS handling submission, validation and version changes against HMRC’s own API, while returning confirmations, status updates and ARCs back to SAP in real time.
Misunderstandings
An EMCS API integration means my ERP talks to HMRC directly, with nothing in between. Even a direct build still goes through HMRC’s developer hub credentialing and its own XML message format; something has to translate your ERP’s data into that format either way, whether you build it or a connected platform already has.
Once production credentials are approved, the integration is finished. HMRC versions the API and publishes a changelog for backwards-incompatible changes, so a direct build is an ongoing maintenance commitment, not a one-off project.
API integration is the only way to connect to EMCS. It is not, and does not have to be for every workflow. iEMCS also supports bulk Excel upload and direct entry, so lower-volume or occasional movements do not need an engineering project behind them.
Five Key Takeaways
- HMRC’s EMCS API is a real, documented REST API with sandbox and production environments, and it is what any direct integration is ultimately built against.
- Building against it directly is a genuine software project: developer registration, sandbox testing, a production credential approval that can take up to ten working days, and ongoing changelog maintenance.
- iEMCS connects to an existing ERP, WMS or TMS as its own API-first layer, so a business integrates once with iEMCS rather than maintaining its own relationship with HMRC’s endpoints and versioning.
- iEMCS offers three input paths, secure API, bulk Excel upload, and direct entry, so the integration effort can match the workflow rather than forcing every movement through the same route.
- Real-time in this context means confirmations, status updates and ARCs returned as they happen, plus centralised tracking of every ARC, journey and report of receipt.
Frequently Asked Questions
You may also like:
Weighing a Custom Build Against HMRC's EMCS API?
See what a secure API connection to iEMCS gives your ERP, WMS or TMS without building the excise side yourself.
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.
Tracking API Versions and Changelogs Isn't Your Core Job
iEMCS keeps pace with EMCS API and message-format changes so your integration doesn’t have to.