Home Kennisbank Blog Over Logentic Plan een gesprek
· ~8 min lezen

B/L-nummer normaliseren: zo voorkom je mismatches bij de Douane

Normaliseer je connaissementnummer: max 17 tekens, geen spaties, hoofdletters. Controleer via Portbase of rederij om CVB afkeuring te voorkomen.

B/L-nummer normaliseren: zo voorkom je mismatches bij de Douane

Normaliseer een B/L-nummer door het te trimmen tot maximaal 17 tekens, alle spaties, streepjes en overbodige tekens te verwijderen en de resterende code volledig in hoofdletters te zetten. Controleer dat nummer daarna altijd bij de bron, via Portbase of de rederij, voordat je het in vak 40 invoert. Dat voorkomt directe afkeuring door het Container Vrijgave Bericht van de Douane en blokkade op de terminal.

Kort samengevat:

  • Het is essentieel om het B/L-nummer te normaliseren door spaties, streepjes en kleine letters te verwijderen en alles in hoofdletters te zetten, om mismatches te voorkomen.
  • Het correcte formaat voor het B/L-nummer stopt bij 17 tekens en moet beginnen met de hoofdletterigen SCAC-code van de rederij, die hoofdletters moet blijven.
  • In vak 40 moet je het genormaliseerde nummer altijd met de juiste code zoals N705 of X-705 invoeren, afhankelijk van of het container- of ferryvervoer betreft.
  • Het vergelijken en valideren van het genormaliseerde nummer met bronnen als Portbase voorkomt fouten en bespaart tijd bij afwijkingen.
  • Automatisering via AI kan handmatige normalisatie ondersteunen en de kans op fouten verminderen, vooral bij groeiend volume.
Logentic
Minder fouten bij handmatige invoer
Logentic leest e-mails, haalt relevante gegevens eruit en voert ze in bestaande TMS-systemen in, zodat logistieke teams efficiënter werken.

Inhoudsopgave

Welke formaat- en syntaxisregels gelden voor een B/L-nummer?

Een B/L-nummer is geen vrij te kiezen code. Het volgt een structuur die rederijen en douanesystemen verwachten, en afwijkingen daarvan zijn de meest voorkomende oorzaak van mismatches. Volgens de uitleg van Voorbeid op het CVB telt een B/L-nummer doorgaans maximaal 17 tekens, waarvan de eerste vier letters meestal de SCAC-code van de rederij vormen (de Standard Carrier Alpha Code). Die letters moeten in hoofdletters staan, want systemen als het DMS matchen hoofdlettergevoelig.

In de praktijk gaat het mis op een paar vaste plekken:

Het stappenrecept is simpel: trim overtollige spaties, forceer hoofdletters, verwijder speciale tekens en streepjes, en controleer ten slotte de lengte. Een correcte notatie is bijvoorbeeld ABCD0510098765431. Een incorrecte variant, zoals ABCD-0510-098765431 met streepjes en een spatie aan het einde, leidt vrijwel zeker tot een mismatch zodra het systeem het nummer vergelijkt met de bron.

Wat hoort er in vak 40 en hoe ziet dat er in de praktijk uit?

Vak 40 van de aangifte is waar het B/L- of zendingsnummer terechtkomt, en de code die daarbij hoort, bepaalt hoe het systeem het nummer interpreteert. Historisch werd hier de code X-705 gebruikt voor de voorafgaande regeling; in het huidige DMS is dat vaak N705. Beide verwijzen naar hetzelfde principe: het systeem moet weten dat het te maken heeft met een cognossement of vervoersdocument dat teruggekoppeld kan worden naar de oorspronkelijke boeking.

In de praktijk zie je twee typische invoervoorbeelden:

  1. Containervervoer: X-705 ABCD0510098765431, waarbij ABCD de SCAC-code van de rederij is en de rest het genormaliseerde B/L-nummer.
  2. Ferryvervoer: hier wordt vaak niet het B/L-nummer maar het zendingsnummer (booking- of shipment reference van de ferrymaatschappij) ingevuld, omdat een klassiek cognossement bij ferrytransport doorgaans ontbreekt.
  3. Bevestiging vóór indienen: controleer het ingevoerde nummer altijd tegen Portbase of rechtstreeks bij de vervoerder, zeker wanneer het om een eerste zending met een nieuwe rederij gaat.

Dat onderscheid tussen ferry en container is een van de meest onderschatte foutbronnen. Teams die gewend zijn aan containervervoer vullen bij een ferryzending soms toch een B/L-formaat in, terwijl het systeem daar een zendingsnummer verwacht. De PLDA-handleiding voor zeevracht beschrijft dit onderscheid en de bijbehorende rapportcodes in detail.

Hoe bouw je een validatie-workflow die mismatches voorkomt?

Normaliseren zonder validatie is een half werk. Het nummer kan perfect opgemaakt zijn en toch niet overeenkomen met wat de rederij heeft geregistreerd. Een werkbare workflow ziet er zo uit:

Elke controlestap hoort een spoor achter te laten. Log de lengte-check, de SCAC-match, het containernummer en het gewicht, en bewaar die audit-trail. Dat is niet alleen voor interne kwaliteitsborging, het is ook je verdediging als de Douane achteraf vragen stelt over een aangifte.

Escaleer op tijd. Zodra een validatie een afwijking toont die je niet zelf kunt verklaren, vraag dan een amendment aan bij de rederij vóórdat je de aangifte indient. Wachten tot na indiening kost bijna altijd meer tijd dan vooraf corrigeren.

Pro-tip: Bewaar per zending niet alleen het eindresultaat van de validatie, maar ook de brontekst van de boekingsmail. Bij een geschil met de rederij over een amendment is dat vaak het enige bewijs dat de fout niet bij jouw team lag.

Welke fouten komen het meest voor en hoe herstel je ze snel?

De meeste mismatches ontstaan niet bij normalisatie zelf, maar eerder in de keten: bij de verzendinstructies (Shipping Instructions) die de klant aanlevert. Typische patronen zijn kopieerfouten uit een eerdere zending, het per ongeluk gebruiken van een tijdelijk boekingsnummer in plaats van het definitieve B/L-nummer, en een verkeerd overgenomen gewicht dat niet overeenkomt met het cognossement.

Herstel volgt meestal dezelfde route:

De echte schade zit in de vertraging. Een amendment kan de vrijgave van een container met dagen opschuiven, en foutieve velden op een Bill of Lading brengen vaak extra administratiekosten met zich mee bovenop het tijdverlies. Preventie blijft daarom goedkoper dan herstel: een vaste checklist, EDI- of API-validatie tegen de bron, en een verantwoordingslog per zending.

Hoe neemt automatisering normalisatiefouten weg?

Handmatige normalisatie leunt op discipline: iedere medewerker moet exact dezelfde stappen volgen, elke keer opnieuw. Zodra het volume groeit, glipt er ergens een spatie of kleine letter doorheen.

Automatische extractie en normalisatie vervangen niet de menselijke controle, ze verkleinen alleen de kans dat een fout ooit bij die controle terechtkomt.

Het resultaat is een lagere foutkans, een kortere verwerkingstijd per zending en een consistente auditlog die precies laat zien wanneer en hoe een nummer is gevalideerd. Teams die overstappen op deze aanpak doen er goed aan te starten met een kleine pilot, bijvoorbeeld 5 tot 10% van het dagelijkse volume, en menselijke review te behouden voor uitzonderingen. Wie wil zien hoe dat er in de praktijk uitziet, vindt meer op de Logentic-pagina over B/L- en CMR-verwerking.

Praktische overwegingen voor operationele teams

Praktische overwegingen voor operationele teams — overview diagram

Wie normalisatie structureel wil verbeteren, meet eerst. Volg de mismatch rate per maand, het aantal amendments dat nodig is, en de doorlooptijd van boekingsmail tot geldige aangifte, vóór en na elke procesverandering. Zonder die cijfers blijft elke verbetering een gevoel in plaats van een feit.

Wijs één rol aan die eigenaar is van de normalisatieregels, zodat wijzigingen in SCAC-codes of DMS-vereisten niet blijven hangen bij losse medewerkers. Start een pilot op een beperkt deel van het volume, meet de mismatch rate voor en na, en breid pas uit zodra de cijfers structureel verbeteren. Die volgorde, klein beginnen en meten, werkt beter dan een volledige omschakeling in één keer.

— Bogdan

Automatiseer normalisatie en validatie met Logentic

Handmatig normaliseren werkt, tot het volume te groot wordt voor consequente controle.

Logentic

Dat betekent geen migratie van je bestaande systemen en geen extra personeel om volumegroei op te vangen. Er zijn AI-oplossingen die werken binnen CargoWise, Softpak, Descartes en Boltrics, en koppelen met Portbase voor bronvalidatie. Wil je zien hoe dat voor jouw team werkt? Vraag een demo aan via de pagina over B/L- en CMR-verwerking en start met een beperkte pilot op je eigen boekingsvolume.

Bronnen

Voor bronvalidatie is Portbase het aangewezen startpunt, met zowel webtoegang als API-koppelingen voor geautomatiseerde checks. Officiële handleidingen, zoals die van PLDA voor zeevracht, geven de technische details achter rapportcodes en niveaus. Voor achtergrond over de velden op een cognossement zelf helpt de uitleg over connossementen, en wie automatische extractie wil koppelen aan een Portbase-integratie leest verder op de pagina over Portbase-koppeling.

Veelgestelde vragen

Wat betekent “B/L” precies?

B/L staat voor Bill of Lading, in het Nederlands het cognossement: het vervoersdocument dat een rederij afgeeft als bewijs van ontvangst van de lading en als vervoerscontract.

Wie is de consignee op een Bill of Lading?

De consignee is de partij aan wie de goederen worden afgeleverd, meestal de koper of ontvanger die het recht heeft om de lading bij aankomst op te eisen.

Wat is een cognossement?

Een cognossement is de Nederlandse benaming voor de Bill of Lading: het document dat vervoer, eigendom en ontvangst van een zending vastlegt en dat nodig is voor de douaneaangifte.

Waarom leidt een fout B/L-nummer tot afkeuring door de Douane?

Sinds de invoering van het Container Vrijgave Bericht vergelijkt de Douane het ingevoerde nummer direct met de bron bij de rederij. Bij een mismatch volgt afkeuring en kan de container geblokkeerd blijven op de terminal.

Moet ik voor ferryvervoer ook een B/L-nummer normaliseren?

Nee, bij ferryvervoer vul je meestal het zendingsnummer van de ferrymaatschappij in plaats van een klassiek B/L-nummer, omdat een cognossement daar vaak niet wordt uitgegeven.

Aanbevelingen

Wil je zien hoe Logentic dit werk automatiseert?

Plan een gesprek →

← Alle artikelen