DMS10005
Also known as: unknown authorisation, VERGUNNING ONBEKEND
DMS10005 is the error code VERGUNNING ONBEKEND EN/OF VERGUNNINGHOUDER ONJUIST in table A99. The number is unknown in the Customs registers, or the holder on the declaration is not the holder of the authorisation.
What does DMS10005 say according to the code book?
The Codeboek Douane of 17 February 2026 names at DMS10005: VERGUNNING ONBEKEND EN/OF VERGUNNINGHOUDER ONJUIST. It is an acceptance-blocking error. Customs does not accept the declaration until the authorisation data is right. There is no MRN for as long as number and holder do not match what DMS knows. Unknown means: this number does not stand in the authorisations that DMS knows for this declarant or this importer. Incorrect holder means: the number exists, but the EORI attached to it is not the EORI that you put as holder or as represented person on the declaration. Both fall under the same code. Nearby codes exist beside 10005. DMS101AA speaks of authorisation data and/or authorisation holder unknown, with a note about the date of a proof of origin. DMS110AA says that the authorisation is known but the stated holder is incorrect. Read the exact code and the location. They send you to the same cluster, not to the same correction.
Which authorisation does the message mean?
The location names the type. An authorisation for placement in a customs warehouse, a periodic declaration authorisation, article 23, a REX-related data element, or a representation authorisation. Without reading that type, you fill in the wrong number and 10005 remains. Article 23, deferment of payment of import VAT, is a common source. The number must belong to the EORI of the importer who reverse-charges the VAT. If you put the forwarder's number on a declaration in which the importer is the declarant, or the other way round, the holder is incorrect. Direct and indirect representation make that difference harder, not smaller. A warehouse authorisation is a second source. The identification of the warehouse must be known and the declarant must be admitted to that warehouse. Nearby codes, such as DMS12009 and DMS12029, name the warehouse explicitly. 10005 remains the broad message when number or holder do not match.
How do you check number and holder?
Take the number from the master data of the client, not from an old declaration. Check the EORI of the holder against the EU register. Check whether the authorisation is still valid on the acceptance date. An expired authorisation behaves for DMS as unknown or incorrect, even if the paper still worked last year. Look at the form of representation on the declaration. Under direct representation the client is the declarant. The authorisation must belong to them. Under indirect representation you are the declarant and jointly a debtor. Some authorisations may then stand on your EORI, others must stay with the importer. That stands in the authorisation, not in the error code. Do not fill in a test number or a number of another client to get around the rejection. DMS checks against the real registers. A number that happens to exist but does not belong to this consignment is exactly the second branch of 10005: holder incorrect.
What if the authorisation does exist on paper?
Paper at the client is not an entry in the Customs system. An authorisation that has been applied for but not yet issued is unknown to DMS. An authorisation issued to an old legal person after a merger is incorrect for the new EORI. The register that DMS reads is the register that counts. In that case do not wait on a second filing with the same number. The client must have the position in the authorisation register confirmed. You prepare the declaration, but you do not file until number and holder are the same as in that register. With a foreign authorisation, for example a REX exporter outside the Netherlands, extra format rules apply. DMS10003 and DMS105AA concern the UCC format of the identification. 10005 remains the substance mismatch. First format, then existence, then holder. A well-formed number that does not exist is still unknown.
How do you prevent it repeating per client?
Record per client: which authorisation type, which number, which EORI of the holder, which declaration types fall under it, and until when it is valid. Check that set before the first declaration of the day goes to DMS, not after. A batch of fifty IMA filings for the same importer otherwise fails fifty times on 10005. That is not fifty causes. That is one master data item. Correct the card, then the open files. If the same 10005 then returns, the location will tell you whether a second authorisation on the same declaration is still wrong. DMS is Dutch. A Belgian or German authorisation that is valid in its own country is not thereby known in the Dutch register. For a declaration in DMS the authorisation you enter must belong to the Dutch handling, or stand as a foreign authorisation in the right format and the right role.
What do you do with the location in the message?
The path usually names Authorisation or a similar block, with an index if more authorisations stand on the declaration. Authorisation[2] is the second. Anyone who overwrites the first while the second is wrong keeps 10005. Count the blocks in the message, not the blocks your screen happens to show first. Note code, text and path in the file. At a later check or at a repeated rejection that is the evidence of what you corrected. The code alone says too little. VERGUNNING ONBEKEND EN/OF VERGUNNINGHOUDER ONJUIST names two branches. The path tells you which authorisation block was tested. If you cannot work it out, the Nationale Helpdesk Douane is the official desk for the meaning. They look in their registers whether the number is known. The Helpdesk does not fill the number in for you. That remains a data element from your power of attorney and from the client's authorisation.