Documenttype

Cognossement-data extraheren volgens jouw regels, niet die van ons.

De meeste tools lezen de pagina, geven je een JSON en wensen je succes met de integratie. SunnyExtract leest het cognossement — de zeevrachtbrief — met de context van jouw operatie (jouw havens, jouw geadresseerden, jouw toleranties), vergelijkt het met de handelsfactuur en de paklijst, en houdt alles wat niet klopt tegen in een Zero-Inbox waar je eigen team het afhandelt.

Voorbeeld

Een gescand cognossement wordt gestructureerde zendingsdata — en haalt de afwijking eruit die erin verstopt zat

Gescand cognossement — meerdere pagina's, vastgeniet aan de paklijst

voorbeelduitvoer
{
    "document_type": "bill_of_lading",
    "bl_number": "MEDUH2840173",
    "carrier": "MSC",
    "shipper": "Rotterdam Trading BV",
    "consignee": "Almacenes del Sur SL",
    "notify_party": "Iberia Customs Brokers SL",
    "vessel_voyage": "MSC ARUSHI / 447W",
    "port_of_loading": "NLRTM",
    "port_of_discharge": "ESVLC",
    "containers": [
        {
            "container_no": "MSCU7761430",
            "seal_no": "ML-8842197",
            "type": "40HC"
        }
    ],
    "packages": 1240,
    "gross_weight_kg": 14500.5,
    "freight_terms": "prepaid",
    "cross_check": {
        "commercial_invoice": "matched",
        "packing_list": "mismatch",
        "exception": "Brutogewicht: de paklijst geeft 14.480,00 kg aan en de B/L 14.500,50 kg — een verschil van 20,5 kg, wat ruim boven de tolerantie van 5 kg voor deze klant ligt",
        "routed_to": "zero_inbox"
    }
}

Gestructureerde uitvoer — velden gemapt, kruiscontrole gedraaid, uitzondering naar de Zero-Inbox

Het probleem

Waarom generieke OCR op cognossementen het in productie begeeft

Een cognossement is geen formulier. Elke rederij maakt het anders op, een flink deel komt binnen als een telefoonfoto van een fax, en juist de velden met het meeste risico — containernummer, gewichten, geadresseerde — zijn de velden waar stempels en handschrift op belanden. OCR leest wat er op de pagina staat. Het weet niet wat jouw operatie daar verwacht aan te treffen.

Elke rederij heeft zijn eigen lay-out, dus extractie op basis van sjablonen faalt zodra er een nieuwe rederij opduikt.

Documenten komen binnen als scans, telefoonfoto's en pdf's van meerdere pagina's waarin één B/L aan een factuur en een paklijst vastzit.

Container- en zegelnummers behoren tot de velden die het vaakst verkeerd worden gelezen, en kosten het meest als ze fout zijn.

Gewichten en aantallen spreken elkaar vaker tegen tussen cognossement, handelsfactuur en paklijst dan iemand toegeeft.

Een generieke API kent jouw interne projectcodes niet, jouw geadresseerden niet, en weet niet welke havenparen voor deze klant überhaupt plausibel zijn.

Als een extractie onzeker is, kan een API-only tool nergens met die twijfel naartoe — dus gokt hij, waardoor een foute waarde die er goed uitziet stilletjes in je TMS belandt.

De JSON is het makkelijke deel. De regels zijn het product.

Elke leverancier in deze categorie kan een cognossement in velden omzetten. Wat geen van hen meedraagt is jouw bedrijfslogica: de tolerantie die je accepteert tussen het gewicht op de B/L en de factuur, de geadresseerde die onder drie schrijfwijzen toch dezelfde klant is, de zending die niet geboekt mag worden voordat de douane deze heeft vrijgegeven. Die logica bouwen wij in de pipeline — en als ze faalt, stopt het document bij een medewerker in plaats van je systemen binnen te stromen als data die er goed uitziet.

Geëxtraheerde velden

Wat we uit een cognossement halen

Dit zijn de velden die we het vaakst mappen. Het schema dat je daadwerkelijk krijgt is dat van jouw operatie — extractie wordt per klant gebouwd, niet uit een dropdown gekozen.

Partijen

  • Afzender (shipper)

  • Geadresseerde (consignee)

  • Notify party

  • Rederij en SCAC-code

Zending

  • B/L-nummer

  • Schip en reisnummer

  • Laadhaven (POL)

  • Loshaven (POD)

  • Plaats van ontvangst en plaats van aflevering

  • Datum en plaats van afgifte

Lading

  • Container- en zegelnummers

  • Aantal en soort colli

  • Omschrijving van de goederen

  • Goederensoort en HS-code

  • Merken en nummers

Commerciële condities

  • Brutogewicht, nettogewicht en volume (CBM)

  • Vrachtcondities (prepaid of collect)

  • Incoterms

De workflow

Hoe de Zero-Inbox-workflow verloopt

Drie stappen. De derde is degene die niemand anders in deze categorie je verkoopt.

01

Vastleggen en extraheren

Het document komt binnen via e-mail, API of een map — pdf, scan of telefoonfoto. Het wordt geclassificeerd (cognossement, handelsfactuur, paklijst), gesplitst wanneer meerdere documenten in één bestand zitten, en de velden worden geëxtraheerd volgens het schema dat voor jouw operatie is gebouwd. Geen sjablonen, dus een nieuwe rederij is geen nieuwe integratie.

02

Jouw regels toepassen

De extractie wordt getoetst aan jouw bedrijfslogica in plaats van aan een generieke plausibiliteitstest: klopt het brutogewicht met de paklijst binnen de tolerantie die jij accepteert, is dit havenpaar mogelijk voor deze klant, hoort de geadresseerde bij een rekening die je echt hebt, mag deze zending al geboekt worden?

03

Zero-Inbox — je eigen team handelt de uitzondering af

Schone documenten stromen rechtstreeks je systeem in. Alles wat een regel breekt, of waar het model niet zeker over is, stopt en landt in de Zero-Inbox: één wachtrij, de scan aan de ene kant, het geëxtraheerde veld aan de andere, en de reden van het oponthoud in gewone taal erbij. Jouw operatieteam beslist. Niets twijfelachtigs bereikt stilletjes je ERP.

Levende context

Eén keer corrigeren. De regel blijft.

Er wordt hier geen black-box model in het geheim hertraind, en dat is precies de bedoeling. Als je operator iets corrigeert in de Zero-Inbox — een geadresseerde die een bestaande klant blijkt te zijn onder een andere schrijfwijze, een gewichtstolerantie die altijd al te krap was — wordt die correctie niet op dat ene document toegepast en daarna vergeten. Ze wordt bewaard als regel, binnen jouw context, en werkt meteen bij het volgende document.

Een correctie wordt een regel die je kunt lézen, geen gewicht dat ergens in een model verstopt zit — je ziet waarom de engine die beslissing nam, en je auditor ook.

De Deviation Inspector is de plek waar die context leeft: het mappen van namen van geadresseerden en leveranciers, routering naar projecten en vaults, de toleranties die je accepteert — jouw bedrijfsregels, op één plek en onder jouw beheer.

Wij houden de onderliggende extractieprompts scherp; jij beheert de bedrijfsregels. Geen van beide partijen hoeft te raden wat de ander heeft veranderd.

Dezelfde correctie is nooit twee keer nodig: vanaf het volgende document draait de regel al vóórdat het document een mens bereikt.

Afstemming

Cognossementen afstemmen volgens jouw regels

Extractie is de basis. Het werk dat je team echt uren kost is de kruiscontrole — en dat is precies het deel dat elke API-only leverancier bij jou teruglegt.

Driewegcontrole: het cognossement vergeleken met de handelsfactuur en de paklijst — aantallen, gewichten, containeraantallen en referenties, getoetst aan de tolerantie die jouw operatie accepteert in plaats van een keiharde tekstvergelijking.

Afstemming op goederenniveau: regels gekoppeld aan omschrijving en HS-code tussen documenten die dezelfde lading in andere woorden beschrijven.

Afstemming van leveringen van derden: papierwerk van rederijen en expediteurs vergeleken met je eigen leveringsregistratie, zodat een afwijking boven water komt voordat het een factuurgeschil wordt.

Elk verschil wordt een uitzondering met een duidelijke reden, nooit een stille aanpassing — het bereikt de Zero-Inbox met beide waarden naast elkaar.

Waar dit document wordt gebruikt

Operaties die dit document verwerken

Dit documenttype maakt deel uit van de bredere workflows die we bouwen voor de operaties hieronder.

FAQ

Veelgestelde vragen

Welke velden haalt jullie cognossement-extractie eruit?

Meestal het B/L-nummer, de afzender, de geadresseerde, de notify party, de rederij, schip en reis, laad- en loshaven, container- en zegelnummers, het aantal colli, de omschrijving van de goederen, de HS-code, bruto- en nettogewicht, en de vrachtcondities. Omdat de pipeline per klant wordt gebouwd en niet uit een menu wordt gekozen, is het schema dat je krijgt het schema dat jouw operatie echt nodig heeft — inclusief je eigen projectcodes, interne referenties en rekeningnummers.

Bieden jullie kant-en-klare afstemming van cognossementen?

Nee, en dat is een bewuste keuze. Afstemming is waar operaties het meest van elkaar verschillen: de tolerantie die je op een gewicht accepteert, welke referentie leidend is, wat telt als dezelfde goederensoort in twee bewoordingen. Een generieke matcher mist echte afwijkingen of overspoelt je met valse meldingen. We ontwerpen de afstemmingsregels samen met jou tijdens de workflow review en bouwen ze in je pipeline.

Wat gebeurt er als de scan onleesbaar is of een veld met de hand is ingevuld?

Het document stopt. In plaats van een gegokte waarde je TMS of ERP in te duwen, wordt het onzekere veld gemarkeerd en landt het document in de Zero-Inbox, waar je team de scan naast de geëxtraheerde data ziet en de reden waarom het is tegengehouden. Een mens beslist, en het gecorrigeerde document loopt daarna verder door de pipeline.

Leert het systeem van onze correcties?

Ja, maar niet door achter je rug om een model te hertrainen. Een correctie in de Zero-Inbox wordt opgeslagen als regel binnen jouw context — de geadresseerde die hoort bij een rekening die je al hebt, de tolerantie die te krap stond — en vanaf het volgende document draait die regel vanzelf. Je kunt hem lezen en aanpassen in de Deviation Inspector. Dat is een bewuste keuze: een operatieteam kan geen gewicht in een neuraal netwerk auditen, maar een bedrijfsregel wel.

Kunnen jullie cognossementen van elke rederij aan?

Extractie werkt niet met sjablonen, dus een lay-out die we nooit eerder hebben gezien vraagt niet om een nieuwe integratie: de pipeline leest het document voor wat het is in plaats van het te vergelijken met een opgeslagen formulier. Wat wél ingericht moet worden is jouw bedrijfslogica: de regels, de toleranties en de systemen waar de data naartoe gaat.

Is dit gewoon een OCR-API voor cognossementen (vrachtbrieven)?

Nee. OCR is een invoer, niet het product. Tekstherkenning levert alleen tekst op; de waarde zit in wat daarna gebeurt — classificatie, validatie tegen jouw regels, kruiscontrole met de factuur en de paklijst, en een uitzonderingspad dat door mensen wordt nagekeken. Een OCR-API geeft een JSON terug en legt het moeilijke werk bij jou neer.

Vraag een persoonlijke workflow-review aan

Vertel ons hoe je documentworkflow nu werkt. We beoordelen elke aanvraag handmatig en stemmen de demo af op echte operationele knelpunten.

Vraag een persoonlijke workflow-review aan

We gebruiken analytische cookies (Google Analytics) om te zien hoe de site wordt gebruikt en om hem te verbeteren. Ze draaien alleen als je ze accepteert. Cookiebeleid