How to Validate EORI Numbers in Node.js

Customs clearance delays

An invalid EORI will cause the customs declaration to be rejected outright. Goods sit in a customs warehouse or at the port while the issue is resolved. For perishable goods or time-sensitive shipments, this can mean total loss of the consignment. Even for non-perishable goods, daily storage fees at ports and airports add up quickly.

Regulatory fines

National customs authorities can impose penalties for incorrect declarations. In some jurisdictions, repeated submissions with invalid EORI numbers can trigger enhanced scrutiny of all future shipments, effectively red-flagging your business in customs systems.

Supply chain disruptions

Modern supply chains are tightly coupled. A delayed shipment at one point cascades through the entire chain — production lines stop, retail shelves go empty, contractual SLAs are breached. Validating EORI numbers before submission prevents these cascading failures.

TARIC and customs declarations

The EORI number is a mandatory field in TARIC-based customs declarations, the Import Control System (ICS2), the Export Control System (ECS), and the New Computerised Transit System (NCTS). Automated customs systems will reject declarations where the EORI number does not match the European Commission's EORI database.

No country-specific format checks

A catch-all regex cannot enforce that a Polish EORI has exactly 10 digits after the country code, or that a French EORI must contain a valid 14-digit SIRET number. Each country has its own rules for what constitutes a valid national identifier.

No registration verification

A syntactically valid EORI number may never have been registered, or it may have been revoked. The European Commission maintains the official EORI validation service — the only authoritative way to confirm that an EORI number is currently active is to query this registry.

No company details

When building customs software, you often need to verify that the EORI number belongs to the expected company. A regex tells you nothing about the registered operator's name, address, or status. Only the EC registry can provide this information.

(a) EORI not found in the EC registry

A format-valid EORI that returns ec.valid: false may be a newly registered number that has not yet propagated to the EC database, a number that was revoked, or simply a number that was never registered. Do not automatically reject it in all cases — consider the business context.

// Handle EORI not found in EC registry
if (result.valid && result.ec?.checked && !result.ec.valid) {
  if (result.ec.statusDescr === 'Not found') {
    // Could be newly registered — allow with manual review flag
    logger.warn('EORI not in EC registry:', eoriNumber);
    return { valid: true, registrationStatus: 'not_found', requiresReview: true };
  }
}

(b) EC service downtime

The European Commission's EORI validation service, like VIES for VAT numbers, experiences periodic downtime for maintenance and occasional outages. When the EC service is unavailable, the API returns ec.checked: false with ec.reason: "unavailable". Do not reject the EORI number in this case — treat it as "format valid, registry check inconclusive" and retry later.

if (result.ec && !result.ec.checked) {
  if (result.ec.reason === 'unavailable') {
    // EC service is temporarily down — do not reject
    logger.warn('EC EORI service unavailable for', eoriNumber);
    return {
      valid: result.valid,
      ecStatus: 'unavailable',
      message: 'Format validated. EC registry check will be retried.',
    };
  }
}

(c) GB post-Brexit — XI for Northern Ireland

After Brexit, the United Kingdom left the EU customs union. GB-prefixed EORI numbers are no longer in the EC EORI database. However, Northern Ireland businesses that trade with the EU under the Windsor Framework use the XI prefix — these are registered in the EC system and can be validated against it.

If your system handles UK-EU trade, you need to distinguish between GB and XI prefixes:

async function validateEoriWithBrexitHandling(eoriNumber) {
  const result = await validateEori(eoriNumber, { check: true });

  if (result.countryCode === 'GB') {
    // GB EORI — not in EC database, validate format only
    // For customs purposes, check with HMRC instead
    return {
      ...result,
      note: 'GB EORI — not in EC registry. Verify with HMRC if needed.',
    };
  }

  if (result.countryCode === 'XI') {
    // Northern Ireland — should be in EC database
    if (result.ec?.checked && !result.ec.valid) {
      return {
        ...result,
        note: 'XI EORI not found in EC registry — may need re-registration under Windsor Framework.',
      };
    }
  }

  return result;
}

(d) Format differences per country

Unlike VAT numbers or IBANs, EORI national identifiers vary dramatically between countries. Some countries use purely numeric identifiers (Poland: 10-digit NIP), others allow alphanumeric characters (Austria, UK). Some countries pad the national identifier to a fixed length, others allow variable length.

The API handles all these country-specific rules internally. You should not attempt to validate the national identifier format yourself — pass the raw EORI to the API and let it determine whether the format matches the issuing country's rules.

// ❌ Don't do this — you'll get country-specific rules wrong
function isValidEoriFormat(eori) {
  const countryCode = eori.slice(0, 2);
  const identifier = eori.slice(2);
  switch (countryCode) {
    case 'PL': return /^\d{10}$/.test(identifier);   // What about 13-digit REGON-based?
    case 'DE': return /^\d{1,15}$/.test(identifier);  // Some DE EORIs have letters
    case 'FR': return /^\d{14}$/.test(identifier);    // Not always SIRET-based
    // ... 24 more countries to maintain
  }
}

// ✅ Do this instead — let the API handle country-specific validation
const result = await iv.eori(eoriNumber);

Network failures in your code

Always wrap the API call in a try/catch. A network timeout should not cause your customs declaration process to crash — decide upfront whether to fail open or closed on API unavailability.

async function validateEoriSafe(eoriNumber, options = {}) {
  try {
    return await validateEori(eoriNumber, options);
  } catch (err) {
    // Log and decide: fail open (allow) or fail closed (reject)
    logger.error('EORI validation failed:', err.message);
    return { valid: null, error: 'validation_unavailable' };
  }
}